LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What code is in Measurement and Automation?

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!

0 Kudos
Message 1 of 10
(2,226 Views)

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...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 2 of 10
(2,205 Views)

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!

Lea D.
Applications Engineering
National Instruments
0 Kudos
Message 3 of 10
(2,174 Views)

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.

0 Kudos
Message 4 of 10
(2,155 Views)

Will do (Post to Instrument Control).  THANKS!

0 Kudos
Message 5 of 10
(2,149 Views)

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.  😉

 

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 6 of 10
(2,136 Views)

Thank you!  I will give the *OPC? a try.

0 Kudos
Message 7 of 10
(2,127 Views)

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).  😄

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 8 of 10
(2,115 Views)

Smiley Happy

0 Kudos
Message 9 of 10
(2,110 Views)

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. 

Omar
0 Kudos
Message 10 of 10
(2,097 Views)