I wrote a Labview app for a Keithley 34465A multimeter to be able to measure the current of a short biphasic current pulse. Initially I started with the NI drivers that are available, but they did not work. I could not even run the simple example VI to read a single measurement. The VI would time out on a read (error code -1073807339) after writing the SYST:ERR? command, and the next time I ran it, I would get error code -1073807360 on the Visa Open. After that, If I clicked on the VISA resource name control to refresh the device list it would just hang until I unplugged the 34465A from the USB. I also had to power cycle the 34465A or Windows would not recognize the device when I plugged it back in.
After working with the system half the day, and trying various commands using the NI-VISA Interactive Control application, I ended up abandoning the NI driver VIs (which were having issues with the same read after a SYS:ERR? write) and brute-forcing with the attached VI, which was working perfectly on Friday. I was able to repeatedly run the VI with no issues. My Errors array indicator would show +0, No Errors. I powered off all of the equipment for the weekend.
Come Monday, I powered everything up and tried to run the VI again. I'm back to the same issue I had on Friday where I get a timeout on the VISA Read after a Write of SYST:ERR?. Same situation, where I end up having to exit LabVIEW, shut off the 34465A, and start everything back up. I have no idea why this VI is failing, and why the same VI was working on Friday. Perhaps there was something I did in the interactive control app that fixed some problem?
FYI, I'm running LV17 with NI-VISA 19.2 running under Windows 7 Pro.
Solved! Go to Solution.
Thanks, Albert, for your reply. I already did that and verified that the commands work. Like I said, it was all working Friday, and my array of return codes only showed "+0, "No error". I even went back this morning into Interactive Control and sent each of the messages through that interface again, and they all work fine.
However, back in the VISA Interactive Control application, I found an interesting observation. If I run my VI, I get the read timeout. Then, If I do a Query of the SYST:ERR? command through the interactive app, it works with no errors. Same thing again, no errors. On the third time, I get a timeout. This happens every time I try this. After the third time when it times out, it seems to always work on subsequent queries.
After trying just the error query in a VI by itself and still getting the same problem, I tried just a *IDN? query, to make sure the query worked. It did, and when I rewired the error query and tried it, it worked. The tried adding the *IDN? query before everything and it works fine. Go figure...
Anyway, this works:
Argghhhh! NOT A SOLUTION! It was working every time I ran it, then I closed out the interactive control and some other open VIs, and it wouldn't work when I ran it again. Still searching for the answer...
I think you are hitting a timeout.
*RST is a reset, it ca take a few seconds for the instrument to come back
But you don't have a delay or set a long timeout (default after reset is probably 1s)
After *RST is a long string of commands and ending with a separate SYST:ERR? querry.
The instrument must reset, receive all commands in the queue then process all the commands you sent before the read after the SYST:ERR? querry times out.
Setting a 3-10s timeout before the chain of commands, then reverting back to 1s after the SYST:ERR? should take care of your issue.
FYI it would be exactly the same with the driver VIs. They usually want you to set a long timeout at certain points.
Thanks for your reply. RST is not taking much time at all. After doing even more investigation, it appears that the *ESR 48 command is causing problems with the SYST:ERR? query. I found some examples where it was set to 32, and changed it to *ESR 32 instead. Now my original VI I posted works with this change, and completes in a fraction of a second. I've exited LabVIEW, done a clean power-on of 34465A, and am unable to make it fail now. I'm not a GPIB expert, so maybe one of you gurus would have some insight as to why that setting caused a failure.
I should note that the Initialize VI in the NI drivers for the 3446X series has a *ESR 48 command, and it is issued no matter how you configure Initialize. Their Example VIs DO NOT WORK because they also do a SYST:ERR? query during initialization. Perhaps they work on earlier models, but they do not work on the 34465A, at least after a device power-on.
Glad you found a solution.
Interesting that your instrument doesn't work with drivers. Though the NI site doesn't show your model as tested specifically. What Firmware version are you running? There's a list of resolved defects here, https://www.keysight.com/upload/cmc_upload/All/Firmware_Release_Notes_3.02.pdf
I had a glance but don't see references directly to status registers. I wonder if a firmware is to blame for the *ESE behaviour. *ESE 60 should be used to catch all errors, while *ESE 32 is only going to return command errors (command syntax or parameters out of range), but not instrument specific errors. Personally I'd like to get both back from my instrument. If your firmaware is really out of date, perhaps an update to see if you can improve things.