Jump to content

Strange VISA timeout issue using "plugins"


PA-Paul

Recommended Posts

Hi all,

I have an irritating VISA timeout error which I can't seem to track down. Any help would be most gratefully recieved.

So, I'm controlling a tuneable laser over an RS232 link. The laser in question accepts byte code instructions, not all of which lead to responses from the laser. I have written a VI which communicates with the laser and can do the 4 main things I need - turn the laser on and off, set the laser wavelength, check the laser wavelength and set the laser to sweep through its wavelength range. As a standalone VI I have no problems running this at all. It seems completely stable (as far as anything can be!)

In my main application I call the laser control VI by reference (since I have a couple of different lasers I want to use with the same main application). The main App commands the laser to sweep through its wavelengths, and then tune to a specific wavelength. It then monitors a couple of external parameters via a USB-DAQ card and from time to time will send the laser to a new wavelength depending on the results of the monitoring. And its here I seem to have an issue. The laser initialises fine, I can make the laser sweep through its wavelengths fine. But when the laser has to tune to a new wavelength, it tunes once or twice and then gives me a VISA time out error on a VISA read command (Which is part of the "set wavelength" command). Within the main application I also have the ability to manually force the laser to tune (using the exact same set wavelength code within the app) and this seems to work reliably.

I've tried running the laser control VI in a loop as fast as possible to see if I can make it fail, but I can't. The only way I've been able to make it fall over myself was writing a simple program that called the laser control VI by reference and then commanded wavelength changes in a loop (alternating between two wavelengths). This setup was actually stable until I probed the error wires into and out of the set wavlength vi... at which point I noticed that the comms with the laser were suffering if I moved things around on the screen (I have a tx and rx led on the laser itself so can see if things are being sent/recieved). Without the probes, there was no problem, the leds were flashing at a nice constant rate. with the probes in place the flahing was much more stuttery especially if i moved the probes on screen. Adding the probes also seemed to induce the timeout error...

If anyone has seen anything like this before or can think of other things I can try, I'd be most appreciative!

Thanks all

Paul

Link to comment

Hi all,

I have an irritating VISA timeout error which I can't seem to track down. Any help would be most gratefully recieved.

So, I'm controlling a tuneable laser over an RS232 link. The laser in question accepts byte code instructions, not all of which lead to responses from the laser. I have written a VI which communicates with the laser and can do the 4 main things I need - turn the laser on and off, set the laser wavelength, check the laser wavelength and set the laser to sweep through its wavelength range. As a standalone VI I have no problems running this at all. It seems completely stable (as far as anything can be!)

In my main application I call the laser control VI by reference (since I have a couple of different lasers I want to use with the same main application). The main App commands the laser to sweep through its wavelengths, and then tune to a specific wavelength. It then monitors a couple of external parameters via a USB-DAQ card and from time to time will send the laser to a new wavelength depending on the results of the monitoring. And its here I seem to have an issue. The laser initialises fine, I can make the laser sweep through its wavelengths fine. But when the laser has to tune to a new wavelength, it tunes once or twice and then gives me a VISA time out error on a VISA read command (Which is part of the "set wavelength" command). Within the main application I also have the ability to manually force the laser to tune (using the exact same set wavelength code within the app) and this seems to work reliably.

I've tried running the laser control VI in a loop as fast as possible to see if I can make it fail, but I can't. The only way I've been able to make it fall over myself was writing a simple program that called the laser control VI by reference and then commanded wavelength changes in a loop (alternating between two wavelengths). This setup was actually stable until I probed the error wires into and out of the set wavlength vi... at which point I noticed that the comms with the laser were suffering if I moved things around on the screen (I have a tx and rx led on the laser itself so can see if things are being sent/recieved). Without the probes, there was no problem, the leds were flashing at a nice constant rate. with the probes in place the flahing was much more stuttery especially if i moved the probes on screen. Adding the probes also seemed to induce the timeout error...

If anyone has seen anything like this before or can think of other things I can try, I'd be most appreciative!

Thanks all

Paul

I don't think I ever got a straight answer but I have this suspicion that "Call by ref" runs in the UI thread, so couple that possiblilty with some of those old serial wdget being impatient about comm time-outs...

1) Can you make it worse by run a parallel VI set to run in the UI thread that gobbles up CPU (to confirm)?

2) Can the timeout on the laser be extended?

3) Run the laser code as an active object then interact with it to do the laser work for you?

That's all that comes to this mind,

Ben

Link to comment

Hi Ben,

Thanks for the reply, can you clarify what you mean by running the laser code as an "active object"?

Thanks

Intead of using the invoke node on a VI that does what you want, set-up a background VI that will do the same thing but without the "invoke node" whenever it is told to do so. In my case I use queues to send the message to thew background VI.

But that was only a suggestion on how to get er done without using invoke node with the assumption that the UI thread was slowing you down causing timeouts. I did a lot of specualting to help give you ideas.

If they help, only you can judge.

Ben

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.