Instrument Control (GPIB, Serial, VISA, IVI)

Showing results for 
Search instead for 
Did you mean: 

34465A Freezes on Error Code



(Duplicate post from


A34465A Error Codes seems to freeze LabVIEW after a few hours of operation.


I never had this before (in the past 3-4 years). We sent out the DMM  for calibration and now it seems to be an issue. LabVIEW freezes (doesn't seem to be stuck in the while loop but stuck at the receive VISA).


Not sure if this is a Driver or Firmware or Harware issue.


Products information:

Agilent A34465A

Firmware A.02.08-02.37-02.08-00.49-02-01

Drivers: Agilent 3446X Series.lvlib version (if they update this number))

LabIVEW 2011


AG34465A Bug Frozen within Error Query.PNG





0 Kudos
Message 1 of 15

So it stops during the VISA read after being issued the ":SYST:ERR?".  It just hangs indefinitely?  Does it come back after 10mins or never?  What does the instrument panel say?  Does the instrument have an error message indicated?  Is the instrument hung?


Did the CAL update the firmware too?  I'd suggest downloading the latest version of the LabVIEW driver for the DMM (modified Mar 19 2018) but it seems to only be compatible with LabVIEW versions >2014.


I'd check if the firware was updated and the name of the instrument changed from something like "Agilent 34465a" to "Keysight 34465a" and the the VI causing problems isn't trying to read the instrument name using a specific number of characters.  This has caught me twice in old code with newer instruments.


Beyond that some other ideas..

 - CALL KEYSIGHT!  They can get the logs of diagnostics run during cal and trace all work that was done to see what may have cahnged; firmware, etc..

 - send it back to Keysight to see if the communication board is working as expected.

 - post the code and exactly where it fails. 

- use NI IO-trace to watch the communications and help debug the issue.

- set a longer instrument timeout.




0 Kudos
Message 2 of 15

That's the odd thing, it doesn't recover at all. It hung all weekend without errors in the front panel or log. It responded correctly to a "Shift" to go into manual. It did multiple batch runs (8 runs of 122 calls to DC Voltage and hung near the end of the 9th run).


I don't think the CAL changed the firmware, as it is still a very old firmware version.


I remember having to contact NI to get drivers for LV2011.


I can check for a name change, but my software uses the IDN to identify which drivers to take and takes the correct one as the library name on the title bar of the screenshot.


It's hard to debug as it happens after a long time running.


Zipped the drivers. The error happens in the Error Code.

0 Kudos
Message 3 of 15

So this is just a routine error check inside another VI after a measurement of voltage?

I'd make a torture case.  Put the measurement/error check VI in a tight loop, run it 1000x with a slight (1s?) delay and record the entire session with NI IO trace.  Is it still random?  Timeout issue?


Shipping might have rattled something inside the instrument (Hp4156C).  I've had this with one of mine I sent for cal.  Got it back and communications weren't working, sent it back and they said the board had been unseated somehow.  To be safe they replaced it with a new board (free) and shipped back.  Been working fine since.

0 Kudos
Message 4 of 15

A couple of notes:

  1. Is each command/query terminated?  Typically, I add a newline character or a ";" appended to every command written to the instrument.  Otherwise, the instrument may not interpret a command/query and will not act. By doing such, you may have inadvertently filled the instruments' input buffer and it has no idea on how to respond and locks up.
  2. Always close out the instrument when the task is completed.  Instruments tend to react odd when handling multiple opens without any closings.
Help the Community (and future reviewers) by marking posts as follows:
If it helped - KUDOS
If it answers the issue - SOLUTION
Message 5 of 15

Minions is suggesting to add a ";" to the ":SYST:ERR?" command where you see the hang.  That's a good point.  How many times does that while loop iterate before it hangs?  Perhaps add a counter as well.


I re-read that little note in the BD before the ":SYST:ERR?" command check.  That CLR might be the issue, it sounds like a kludge.  Whenever I have to resort to a CLR to make things work I typically add a little delay after a CLR.  So perhaps a 1s delay might also be in order.


Make a modified Error Check.VI and replace the existing one, put that in a tight loop and see if your debugging doesn't come up with something.

0 Kudos
Message 6 of 15

Like I mentioned, it works fine for a long time. It took >1000 calls to the same function before it froze and >4500 various DMM calls.



There's only 1 open at start of software Initialization and one close at exit of software, none of which are done during resets of batch runs.


I will try a long loop testings.

0 Kudos
Message 7 of 15

I think I solved it, at least it hasn't frozen since.

I swapped (Make This Case Error) the condition of the main Error Case to execute the SYS:ERR? if there's an error at the input rather than doing it for each command.


The CLR wasn't the issue (although I left the 1000ms delay between the CLR and STB in the final implementation).

Message 8 of 15

Glad it works, and nice fix.

But what does the error report when it does happen?  Would still be nice to fix the root cause.



0 Kudos
Message 9 of 15

I wasn't able to get the error report. The DMM automatically clears all errors when requested so I was never to get it when it used to freeze. It would indeed be nice to get the root cause.

0 Kudos
Message 10 of 15