07-23-2018 10:05 AM
(Duplicate post from https://community.keysight.com/message/86401)
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.
Drivers: Agilent 3446X Series.lvlib version 22.214.171.124 (if they update this number))
07-23-2018 01:35 PM
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.
07-23-2018 02:17 PM
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.
07-23-2018 02:31 PM
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.
07-23-2018 02:40 PM
A couple of notes:
07-23-2018 02:49 PM
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.
07-23-2018 03:59 PM
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.
06-11-2019 09:03 AM
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).
06-11-2019 03:43 PM
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.
06-25-2019 04:27 PM
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.