Cryptic errors with Agilent(Keysight) instruments (with solution)

[BertMcMahan]

I had an installed program that was running fine on my user's computer. The user upgraded her computer, then the program suddenly stopped working correctly, despite using the same installer. This is using an Agilent oscilloscope and function generator, connected via USB, using the official Keysight drivers.

The weirdness was that the test would run fine once, then crash at the END of the test. The test ran fine the first time but then crashed the instruments at the end, requiring a reboot of both the oscilloscope and the function generator. I received a few error codes, including -1074000000 (Error reported by instrument), as well as -1073807312 (some kind of weird User Abort code), plus -1073807360 (Unknown system error... very helpful!)

Obviously the first code isn't a LabVIEW thing, but the second two didn't turn up much helpful info in Google.

It turned out to be a USB driver issue. Somehow, the default Windows drivers would start up the connection fine, but sometime after using it a while (seemingly at the end of the test, probably at VISA Close), it would hard-crash the instruments themselves.

The solution was to install the official Keysight drivers including their USB driver. It took a while to figure this out since the communication DID work for a whole test routine before it caused the crash.

So I don't need any help for this, but wanted to have these error codes logged for future Googler's who are having this issue... in short, the default Windows USB drivers for the scope will initially work fine but will crash your instruments seemingly randomly 🙂

Here is the download that fixed the issue:

https://www.keysight.com/us/en/lib/software-detail/computer-software/keysight-instrument-control-bun...

[BertMcMahan · Accepted solution]

Replying to self to mark as Solved, good luck to anyone else seeing this code!

[BertMcMahan]

I realized I made a mistake in my original post. I first said "...using the official Keysight drivers". I meant to say that I had coded my program using the Keysight LabVIEW drivers, which are basically VISA wrappers. Obviously I didn't have the Keysight USB drivers installed, as that's what the issue was.

[RTSLVU]

 I have long since abandoned USB as a serious interface option. 

There's just too many things that can make USB unreliable, from counterfeit chipsets, crappy drivers, to Windows Power Management.

[Frozen]

---

@RTSLVU wrote:

 I have long since abandoned USB as a serious interface option. 

There's just too many things that can make USB unreliable, from counterfeit chipsets, crappy drivers, to Windows Power Management.

---

Don't tell me your using GPIB then 🙄

[RTSLVU]

---

@Frozen wrote:

---

@RTSLVU wrote:

 I have long since abandoned USB as a serious interface option. 

There's just too many things that can make USB unreliable, from counterfeit chipsets, crappy drivers, to Windows Power Management.

---

Don't tell me your using GPIB then 🙄

---

Well most equipment these days that has USB also has LXI, and its implementation has been solid. 

I actually have no problem with properly implemented USB, for instance I do use a NI GPIB-USB-HS in our older ATE systems that still have equipment with GPIB and have never had an issue with it.

I just no longer take the risk of relying on USB when buying new equipment or building new ATE as we have been burned too many times.

[jjean]

Hello,

Thank you for posting this thread. I am trying to setup Keysight 34450A DMMs to run in LabVIEW and experienced the issue you described. I have tried implementing your solution by downloading the bundle. First, the bundle download always fails ("Couldn't download. Network issue," even though there is no problem with my own network). So, I downloaded each separately, noting I already had IO Libraries and Command Expert installed. This (adding BenchVue) understandably did not resolve the issue. I am using LabVIEW base on Win11x64 (and a middle-aged brain).

I am using the AG34401 driver package (the only driver I could find) and connected the Initialize, Measure, Read, and Close blocks available in the palette. An error (-1074003951) outputs from the Initialize block, stating:

'Agilent 34401.lvlib:Initialize.vi<ERR>
The ID Query failed. This may mean that you selected the wrong instrument or your instrument did not respond. You may also be using a model that is not officially supported by this driver. If you are sure that you have selected the correct instrument and it is responding, try disabling the ID Query...'

Upon disabling the ID Query at the Initialize block, the SW then proceeds to communicate with the DMM, which beeps, then it fails at the Read block output (Error code -1074000000):

'Agilent 34401.lvlib:Error Query.vi<ERR>
Instrument reports:
-113,"Undefined header"
+0,"No error" '

The Measurement output remains at 0 and does not correspond to the actual voltage (e.g., 5 V).

Any ideas where to go from here? Is there a driver out there for the 34450A, which I can't seem to find?

Thanks in advance for any and all feedback!

[Kyle97330]

This page should be the driver for both the 34405A and the 34450A:

https://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=70943B8EC0DB1381E04400144FB7D...

[DavidBoyd]

Pursuing the available LabVIEW driver code for these instruments is perhaps your best bet, especially if it includes ready-to-go demo code beyond just the collection of individual functional VIs.  Tracing the demo code may give you a clue about initial setup of the interface you might've missed.

Failing that, as a very general suggestion for troubleshooting, you may want to try using NI IO Trace (if you're sufficiently old, your brain still thinks of it as "NI Spy").  Once you have it configured to capture the VISA calls and their buffers, it may give you something helpful to go on... like missing or unexpected message termination values.

More than once in the past this tool quickly lead me to the inevitable dope slap moment and got me unstuck.

Best regards,

Dave

[jjean]

That worked!  Thanks to your tip, this was a simple fix once the driver folder was in the correct directory version for LabVIEW to see it. You saved me from scapegoating Win11 and attempting a Windows downgrade (for now, anyway).