10-07-2011 11:12 AM
Hello, We have a program that uses GPIB communication to talk to 2 devices. We have LabVIEW 2009 and use VISA vi's. For some reason, an error occurs while the program is running at random points during the test. When this happens, we are unable to run the program until we run scan for instruments in Measurement & Automation. What is Measurement & Automation doing that clears the GPIB error? Any advice would be greatly appreciated!
THANKS!
10-07-2011 08:27 PM
My guess is that the instrument scan process resets and clears the GPIB interface thus returning it to a known state. The bigger question is what are you trying to do that messes up the bus? What kind of instruments are you trying to communicate with?
Mike...
10-10-2011 12:07 PM
Hi momo,
I also agree with mikeporter about the scanning for intstruments putting the interface into a known state. As mike has stated, it's mostly important to find out what you're VIs are doing and monitor the state from this VI. One suggestion that I can give you is to add a breakpoint where your device changes states then you can monitor exactly where it is going into an unknown state.
Does this error occur quickly when running your program, or does it take a while before it throws it? Additionally, a screen capture of the actual error would be extremely helpful.
Lastly, you're probably going to see the most forum reply action in the Instrument Control (GPIB, Serial, VISA, IVI) forum . I think the best step would be to repost your question there along with some more information (see mikeporters response) and a screencapture of this error. Then you can supply a link in this thread to the new thread that you've opened up, just to tie the two together.
Hope this helps!
10-11-2011 08:23 AM
Good question. I wish I knew. It's an intermittent problem. We'll run a test with no issues and the next will fail. The equipment we are communicating with is a Ruska 6660 and Schwien both are fairly old devices, as well as, the LabVIEW code. We are using LabVIEW 2009 and a new computer. I put some delays in the code but it doesn't seem to make a difference.
10-11-2011 08:33 AM
Will do (Post to Instrument Control). THANKS!
10-11-2011 09:49 AM
I always append a *OPC? to my non-query commands to make them queries. You can then be assured that the device has completed the command because *OPC? forces the addressed equiment to respond with something (usually a "1" or some permutation (I've seen "+1" and "01" returned before)) when the command is complete. This command is supported by most equipment; I know the Ruska certainly does.
A rule I live by: If you have to add a wait statement, you don't truly understand how to communicate with the equipment. 😉
10-11-2011 09:53 AM
Thank you! I will give the *OPC? a try.
10-11-2011 10:05 AM
Don't forget that it's a query - you will have to read the buffer exactly as if you are expecting an answer (because you ARE). 😄
10-11-2011 10:08 AM
10-11-2011 12:08 PM
I had similar problems when using "old" equipment (pre 488.2),
They did not understand *OPC, *IDN and such.
I could talk to it but when I went to talk to another instrument the error would occur on the 2nd instrument when it was instrument 1 causing the problems.
I found if I sent the IFC command to the GPIB bus after I was done with instrument 1 (non 488.2) before talking to instrument 2 things worked better.