GPIB timeout in state machine

[dr._messina]

I am having a GPIB timeout problem when I incorporate an Acton Research Corp. SP150 monochromator VI inside of a larger state machine. The VI works fine on its own. It is the only GPIB device being used, and I have probed every input to verify that it is getting the correct parameters. I have also increased the timeout (to 25000 ms) and disabled the timeout with no luck. Is there a known issue that might resolve this? I would switch to serial communication but my two serial ports are taken by other devices (see below).

The state machine is for time-correlated single photon counting with a Becker-Hickl 630 board. We are using the state machine to operate various instruments, e.g., Acton Research Corp. SP150 Monochromator, polarizer on a New Focus piezo rotary stage with US Digital optical encoder. Not all of the states are coded yet, but coded states work as expected.

[johnsold]

One thing that may be an issue: In the loops containing the SP150 VI, the termination condition requires two doubles to be exactly equal. Due to the way numbers are represented in binary this can sometimes be a problem. For example, 0.1 and 0.099999999999999 both look the same if displayed to 3 significant figures but the inequality test will declare them to be different.

Exactly what happens? Do you get GPIB error? Does the SP150 VI execute and never return a valid result or does it not complete?

Try to be as specific as possible about what actually happens.

Lynn

[dr._messina]

Lynn-

The stand-alone VIs for the SP150 work perfectly. Inside of the state machine, the SP150 code never completes and gives a GPIB timeout (code 14), and asks to continue or abort. Continuing will only repeat the same error, and aborting stops execution of the entire state machine VI.

I should have mentioned that the part of the code I have been modifying and testing is only the "GOTO Monochromator" under the "True" state for Wavelength. I have ignored other state calls to the SP150 VIs until I figure out what works.

I tried putting the SP150 code into the LabVIEW example state machine VI (that my state machine was built from) so that it was the only "real" event in the state machine. I got the same error. So, I made a call to the SP150 Read sub-VI outside of the state machine event handler making it get called before entering the state machine event handler. This solved the problem. I assume it was a pseudo initialization. However, this did NOT fix the problem in my larger state machine VI. I tried also using the LabVIEW GPIB Initialization VI for a true initialization. This VI returns no error inside the state machine, but then, once calling the SP150 Read or Write VIs, it times out still. As I mentioned, increasing the timeout to 25000 ms or disabling it completely doesn't help. It seems like either the wrong parameters are being sent and confusing the GPIB device. I checked this many times, though. Or somehow the PCI-GPIB card is being used by some other part of the state machine. Although, there are no other GPIB devices connected.

I'll fix the comparison statement you mention, but I'm not even getting to the comparison statement for that to be a problem.

Thanks for the quick reply,
-Troy

[JLS]

Hello,

Simply placing a subVI in a state machine should not affect it's execution; I would recommend executing that subVI inside the state machine just as you do outside the state machine to verify this, even if it means using a trivial state machine (cycling through states like a sequence structure).  Can you verify, perhaps using the VISA Interactive control (in MAX see Tools -> NI-VISA -> Interactive Control) or the NI-488.2 Communicator (in MAX see right click on your device after scanning for instruments and select "Communicate with Instrument")?  If you can open and run NI-Spy in the background and post the capture, I'll have a better idea of what's going on (see step 0. below for a link to instructions)!

I would use the following sequence of troubleshooting steps:

0. Open and run NI-Spy; here are directions for obtaining a capture:

http://digital.ni.com/public.nsf/websearch/8D890EC09B15C05A86256E6F007E3E86?OpenDocument

1. Use one of the above utilities to verify proper communication, as you plan to do in your application.

2. Write a simply program using either the GPIB or VISA API to mimic the sequence of events you used in 1. above.

3. Integrate the simple program from 2. above into your larger application, placing the relevant code within your state machine if necessary.

Ok, I hope this helps!

Best Regards,

JLS

[dr._messina]

After a week of battling the issue, I bought a USB to RS-232 cable and solved the problem by controlling the monochromator serially. Everything is working now, and I am happy. I still don't understand why it wouldn't work with GPIB.
Thanks for the advice. I'll keep it in mind the next time I have trouble.
-troy

[JLS]

Hello,

That's one way to solve it 🙂  Sorry you had to resort to that - definitely repost if you have any other problems!!!

Thanks for the update as well!

JLS

[dr._messina]

Actually, now I am having issues with the Levenberg-Marquardt non-linear least squares fitting VI. I am fitting to a polarizer curve, which is y=Acos^2(theta+phase)+y0. For some reason, even when I give the L-M VI simulated data (which shows up correctly) from a function node within my VI, it doesn't curve fit properly. I've also used the example VI where one can input a function to simultaneously create and fit data points. It doesn't work here either. The variables for theta and phase are adjusted, but not always correctly fit, and the amplitudes never change from the initial guess I input regardless of how close or far away the initial guess is to the real value. Giving std. dev. input doesn't change the outcome. I am using LV 6.0.2. Any suggestions?
-Troy

[ChrisJ]

Hi Troy,

You may want to create a new thread for your latest question. You're likely to get more responses from a new thread with a title that corresponds to the question.

Regards,
Chris J