Gregg Levine wrote:
>
> Hello from Gregg Levine at Jedi Knight Computers in Queens NY, USA:
> One question materializes: Does all of this apply when the instruments are
> made in house, as opposed to being manufactured by, say HP, or someone
> else?
IMHO (In My Humble Opinion) the issues raised here would affect any vendor
of HPIB cards or HPIB based instruments. We use both NI cards and HP
cards, and except in specific cases we cannot say one works better or worse
than the other.
Issues such as software defect rates, testing procedures, and design of
real-time systems are of course universal to the industry.
Now what happens in any specific case has to be addressed on its own merits
and such general comments can only be a guideline to troubleshooting that
could lead to almost any conclusion in reality.
[<>] regards -- gvg
--
Greg Goebel ftp://fcext3.external.hp.com/dist/mxd/index.html
HP MXD Marketing http://hpislsup.lvld.hp.com (HP only)
pctm@lvld.hp.com http://www.geocities.com/CapeCanaveral/Launchpad/6000
>
> Hello from Gregg Levine at Jedi Knight Computers in Queens NY, USA:
> One question materializes: Does all of this apply when the instruments are
> made in house, as opposed to being manufactured by, say HP, or someone
> else?
IMHO (In My Humble Opinion) the issues raised here would affect any vendor
of HPIB cards or HPIB based instruments. We use both NI cards and HP
cards, and except in specific cases we cannot say one works better or worse
than the other.
Issues such as software defect rates, testing procedures, and design of
real-time systems are of course universal to the industry.
Now what happens in any specific case has to be addressed on its own merits
and such general comments can only be a guideline to troubleshooting that
could lead to almost any conclusion in reality.
[<>] regards -- gvg
--
Greg Goebel ftp://fcext3.external.hp.com/dist/mxd/index.html
HP MXD Marketing http://hpislsup.lvld.hp.com (HP only)
pctm@lvld.hp.com http://www.geocities.com/CapeCanaveral/Launchpad/6000
>
> Dear Ricardo,
> By means of well applying the GPIB handshake protocol, the controller should
> automatically choose for the lowest speed, which is determined by the
> instrument with the lowest speed.
> This problem has nothing to do with the age of the equipment used or the speed
> of the computer, but is simply the result of an improper implication of IEEE
> 488.1 in either the instrument or the controller.
Actually it has a good deal to do with the age of the instrument. Older
instruments tend to be necessarily more immature in terms of HPIB
implementations. Rather like the fact that airplanes built in 1950 were
generally much more unsafe than aircraft built today.
The speed of the computer has been demonstrated beyond any doubt by
experience to have a very strong relationship to operation of HPIB
interfaces and devices. Every time we have moved up to a new level of
processor speed, we have found new problems come out of the woodwork.
It is perfectly common for us to receive reports of HPIB and instrument
configurations that work on older PCs but do not when ported to faster
PCs.
In some cases this has shown up weaknesses in our HPIB implementations, and
we have had to make changes with our HPIB software on occasion, as is
revealed by an inspection of the revision history of the HP I/O Libraries
on our website.
Instrument firmware has also been confirmed in many cases as the problem.
To be sure, this is obviously classified as a failure to handle HPIB
protocols correctly, but that's rather talking in circles. If the problem is
that the instrument doesn't respond to HPIB properly, then obviously it
doesn't have a proper HPIB implementation. However, this is just a word
game.
The instrument's problems may be due to HPIB protocol mishandling, but there
is also the concern of real-time software design. Handling a high-level
command transaction over HPIB, or any other interface for that matter, is
a type of real-time software interaction, particularly since the instrument's
CPU is trying to perform measurements at the same time. If the firmware
doesn't handle the events, such as interrupts, properly, it may fall over
and crash or simply be blocked. This is an obvious issue to anyone who
has ever tried to design software to keep up with events, and of course
the reliability of software is known to be low in general.
If an instrument was designed when PC speeds were 20 or 33 MHz, it may have
hidden defects in real-time handling that are revealed when the controller
is operating at 200 or 330 MHz or above. Particularly if the instrument has
a, say, 16 MHz 68000 CPU or something even less potent. When "real-time"
meant milliseconds, it could keep up, when it meant microseconds or lower,
it is strained to keep up. If there is a hidden weakness in the firmware,
there was no way to find it as long as a CPU couldn't run it fast enough.
One simple example of this problem is one we run into every now and then.
Somebody sets an instrument to perform a particular function, and then does
an SPOLL in a loop to determine when the operation is flagged as done.
The flag never happens. Why? Because the instrument is continually attending
to the interrupt caused by receiving the SPOLL and has no time to attend to
making the measurement. Put a WAIT in the SPOLL loop and it works just fine.
In this case, there is no problem with the HPIB transactions, which are
working properly. However, the instrument's puny and slow CPU is simply
overwhelmed by conditions it was never designed to meet.
What the exact cause is in any specific situation is of course hard to
determine. We have no known HPIB protocol problems with HP HPIB cards at
this time, though that does not rule out such problems. Both card and
instrument problems may be revealed by PCs with faster CPUs. It is very
important for us to test the fastest PCs as they come out to see if we have
problems we could not test for before.
In any case, the matter is academic, as the solution in this case is to
add wait intervals.
> This could easily be checked by a bus analyzer.
> This is the answer of the person who developped world's first GPIB chip, the
> Philips HEF 4738.
> For further information you can consult ACEA.
> You can also visit the website of ACEA for more information on GPIB, IEEE
> 488.1/2 and SCPI.
What the designers of a weapon and the paper specs of that weapon may say
may not be exactly what the soldier in the field observes when he actually
has to use it. Theory is pristine, reality is messy.
> Piet Beems
>
> Ricardo Castanha wrote:
>
> > When addressing instruments via a GPIB connection with HP-VEE 4.0 i have
> > encountered timeout problems. These problems were related to the speed at
> > which the commands were executed as there were no problems if the
> > instruments were addressed while a BUS I/O monitor was open. Also
> > addressing the same instruments with a slower computer showed no problems.
> >
> > Is there a way of reducing the execution speed of the GPIB commands in
> > HP-VEE?
> >
> > Ricardo Castanha
> >
> > ________Please notice the change in address and phone number______________
> >
> > Philips Semiconductors
> > Building FB 3.101
> > Gerstweg 2
> > 6534 AE Nijmegen
> > The Netherlands
> >
> > Phone: +31 24 353 4334
> > Fax: +31 24 353 3589
--
Greg Goebel ftp://fcext3.external.hp.com/dist/mxd/index.html
HP MXD Marketing http://hpislsup.lvld.hp.com (HP only)
pctm@lvld.hp.com http://www.geocities.com/CapeCanaveral/Launchpad/6000