LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

GPIB reads intermittently return 0.000e+0

I've had some time to debug the second application with the two Agilent meters measuring resistance. First, I had to swap one of the 34411As with an older 34401A meter because a coworker needed the higher accuracy meter; then I noted that I only got the measurement dropouts with the 34411A meter, not with the older 34401A meter.

 

After delving down into the drivers, there are three potential functions that can be called from the Read: Single Point vi depending on the trigger, buffer, and math configurations:

  - Fetch Measurement (Fetch)

  - Fetch Measurement (Read)

  - Fetch Measurement (Fast Read)

The first two use a Spreadsheet String to Array function that handles empty strings elegantly enough; an empty string results in an empty array of doubles. That's what the 34401A meter uses; no problem here.

The 34411A meter uses the Fast Read function that reads directly from instrument memory and interprets the result using Agilent's Definite-Length Block format. Each memory item is in the format #DI<data>, where D is a non-zero integer representing the number of digits in the I integer that follows, and I is an integer count of data bytes to be returned. So a standard read from memory in my application would result in a single value returned of the format

  #18<8 data bytes><carriage return><new line>

 

I found that whenever I had a missed data point, the value returned from memory would be

  #18<carriage return><new line>

-- basically, no data would actually be returned. It wasn't an empty string, but there was no data in the returned string.

 

I'm assuming at this point that this is an Agilent issue, not a LabVIEW issue - does that sound correct?

 

Unfortunately my original issue with the e-loads isn't so simple to debug; I'll need to wait until I can run the development station on an old ETU to insert any kind of check for an empty string.

0 Kudos
Message 11 of 15
(898 Views)

@NickDngc wrote:

I've had some time to debug the second application with the two Agilent meters measuring resistance. First, I had to swap one of the 34411As with an older 34401A meter because a coworker needed the higher accuracy meter; then I noted that I only got the measurement dropouts with the 34411A meter, not with the older 34401A meter.

 

After delving down into the drivers, there are three potential functions that can be called from the Read: Single Point vi depending on the trigger, buffer, and math configurations:

  - Fetch Measurement (Fetch)

  - Fetch Measurement (Read)

  - Fetch Measurement (Fast Read)

The first two use a Spreadsheet String to Array function that handles empty strings elegantly enough; an empty string results in an empty array of doubles. That's what the 34401A meter uses; no problem here.

The 34411A meter uses the Fast Read function that reads directly from instrument memory and interprets the result using Agilent's Definite-Length Block format. Each memory item is in the format #DI<data>, where D is a non-zero integer representing the number of digits in the I integer that follows, and I is an integer count of data bytes to be returned. So a standard read from memory in my application would result in a single value returned of the format

  #18<8 data bytes><carriage return><new line>

 

I found that whenever I had a missed data point, the value returned from memory would be

  #18<carriage return><new line>

-- basically, no data would actually be returned. It wasn't an empty string, but there was no data in the returned string.

 

I'm assuming at this point that this is an Agilent issue, not a LabVIEW issue - does that sound correct?

 

Unfortunately my original issue with the e-loads isn't so simple to debug; I'll need to wait until I can run the development station on an old ETU to insert any kind of check for an empty string.


Ewww, that's ugly.  It's not that simple to assign blame, though.  A "fast read" to me implies a raw memory dump and if nothing is there, so be it.  It wouldn't even check to see if a measurement was made or not.  Even the format is not human friendly.  The goal is to get data out the port ASAP.  Maybe your computer is fast enough that it occasionally asks for results when there are none to be had.  In this case, there are two options:

  1. Revert to the "Fetch" or "Read" - which are probably the same operation; "Fetch" being the SCPI-compatible version of the same command.  (DISCLAIMER: I am working from addled memory here; I believe "Read" to be an HP/Agilent/Keysight - specific command.)  These two methods trigger the read, so you will always have data.  It will also be slower.  Probably a lot slower.
  2. Find some way to account for a "bad" read.  e.g., if there are control characters in the string you just read, it must be bad, therefore ignore it.

I left out a third option, "put a manual wait" in your read loop, because I figured the idea was to read data ASAP.

 

I'm not sure how to handle your other problem, either.  I have to think about that one.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 12 of 15
(893 Views)

Actually, I wonder if the answer for the first problem is the answer to the second, also?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 13 of 15
(890 Views)


Ewww, that's ugly.  It's not that simple to assign blame, though.  A "fast read" to me implies a raw memory dump and if nothing is there, so be it.  It wouldn't even check to see if a measurement was made or not.  Even the format is not human friendly.  The goal is to get data out the port ASAP.  Maybe your computer is fast enough that it occasionally asks for results when there are none to be had.  In this case, there are two options:
  1. Revert to the "Fetch" or "Read" - which are probably the same operation; "Fetch" being the SCPI-compatible version of the same command.  (DISCLAIMER: I am working from addled memory here; I believe "Read" to be an HP/Agilent/Keysight - specific command.)  These two methods trigger the read, so you will always have data.  It will also be slower.  Probably a lot slower.
  2. Find some way to account for a "bad" read.  e.g., if there are control characters in the string you just read, it must be bad, therefore ignore it.

I left out a third option, "put a manual wait" in your read loop, because I figured the idea was to read data ASAP.

I'm not sure how to handle your other problem, either.  I have to think about that one.


In this case, the problem is not that I'm reading before there's data available; the "Fast Read" vi checks to see if anything is in memory before sending the R? command. The problem is that the meter itself has put a bad value in memory; just the header without the subsequent data. When the vi strips off the header information, there's no data left to extract a value from.

 

Having said that, I can modify the Fetch Read vi as you suggested; after the vi strips the header, check to see if the resulting string is empty or made up of only control characters. If so, return an empty array of doubles; otherwise, return the data. I could also modify the call stack to change which low level VI is called for a Read Single Point, although I'm reluctant to modify the provided driver too much; harder to remember to include on future applications.

0 Kudos
Message 14 of 15
(882 Views)

All of them are pretty ugly options, huh?  Smiley Frustrated

 

I wonder if there is a firmware update?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 15 of 15
(876 Views)