I have two separate and unrelated applications that display a similar problem: GPIB reads to an instrument intermittently return values of exactly 0.000e+0 (or -0.000e+0).
The first application is a relatively complicated heritage application that (among other things) polls 10 electronic load modules distributed across 2 Agilent N3300A chassis for voltage measurements. The electronic loads are mounted in a rack with several other GPIB instruments, and the system is controlled by a PXI-8106 controller. The application allows the user to select an acquistion period for the electronic loads (2s minimum, 10s maximum) and a separate acquisition period for queries to a power supply. Once the user enables acquisition:
-- One loop waits for the acquisition period to expire, then gathers data from the eLoads and sends a notifier
-- A separate loop waits on the notifier to arrive and then displays data on the screen and writes data to a log file
5 of the values are expected to be ON (power supply voltages of +/-5, +/-12, and 3.5) while 5 are OFF (values in the low millivolt range). Every once in a while, one of the ten values written to the log file is exactly 0.000e+0 -- pretty much a physical impossibility. The voltage normally corresponds to the first channel in one of the load banks, although once it has been the last channel in a load bank. The bad value can be made pretty repeatable by decreasing the acquisition period; at the minimum period allowed by the software of 2s, I can get one of these bad values almost always within the first few seconds of acquisition.
In a totally separate application, I used the LabVIEW Queued Message Handler Acquisition template to acquire two resistance measurements from two Agilent 34411A meters. The controller I'm using is a clone of the system mentioned above (LabVIEW 2012, PXI-8106, etc.), but there are no other commonalities. The application allows the user to set an acquisition period; whenever that period expires, a GPIB Read is performed and sent via Notifier to a separate loop for display and logging. I have a very similar problem: intermittent 0.000e+0 readings occur, usually within a few minutes of starting the application.
We assumed the problem with the first application was due to GPIB cabling topology or problems with the Agilent N3300A loads until we had the same problem with the trivial GPIB setup in the second application. Now the only common points are the PXI-8106 controller, the LabVIEW/NI-VISA/GPIB/488 driver versions, and the NI special GPIB cable from the controller to the first instrument.
Any ideas why a GPIB instrument would intermittently return physically-impossible 0.000e+0 values without throwing any other kind of error? Or is it something specific to the Notifier topology?
Can you confirm if what you're getting back from the device is an empty string or an actual zero? Also, what versions of the drivers do you currently have, and has this ever been a non-issue before?
LabVIEW 2012 SP1
NI VISA 5.3
NI Serial 3.9.1
NI 488.2 3.1.1
Not sure how to confirm whether it's an empty string or a hard zero. How would I do that?
Once we ran into this issue, test engineers at the next level up confirmed they have seen the issue as well -- is that what you mean?
I'm using the Agilent 34401 VISA plug-and-play drivers: polymorphic Read (Single Point), which calls Fetch Measurement, which calls either Fetch Measurement (Fetch) or Fetch Measurement (Fast Read), which calls (etc.) eventually down into the VISA Reads. Do I need to descend all the way down the hierarchy of calls, modifying the drivers to add an indicator at each level to pass up the actual string of the VISA return value? Looks possible but clunky - is there an easier way?
Looking forward - what's the significance of the empty string vs the 0 value? What would the fix be?
An empty string means nothing was read. Like if the read timed out. This would turn into zero as a number, since the empty string would return the default for the data type, which is zero, so you can't distinguish between a bad read and bad data.
See if the string is equal to "".
Or us the "Emtpy String/Path?" Function.
I wonder if this could be an instrument firmware bug?
Yeah sorry that was my question; I understand how the empty string would be translated to a zero, but I don't understand how an otherwise properly formatted GPIB query can result in an empty response without triggering some kind of error or warning. In the heritage application, the error handling is...uneven, so I could see missing something there. In my new application (based off the LabVIEW template), however, any acquisition error should be reported up the chain to the top level application and handled by the General Error Handler vi (i.e., I should see a popup display notification).
And I originally had the instrument as a potential failure cause, but now it's shown up on two different instruments (although from the same manufacturer).
I wonder if it might be that if you request data and none is available, it returns a zero?