PA-Paul Posted February 3, 2011 Report Share Posted February 3, 2011 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 Quote Link to comment
Grampa_of_Oliva_n_Eden Posted February 3, 2011 Report Share Posted February 3, 2011 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 Quote Link to comment
PA-Paul Posted February 4, 2011 Author Report Share Posted February 4, 2011 Hi Ben, Thanks for the reply, can you clarify what you mean by running the laser code as an "active object"? Thanks Quote Link to comment
Grampa_of_Oliva_n_Eden Posted February 4, 2011 Report Share Posted February 4, 2011 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 Quote Link to comment
ShaunR Posted February 4, 2011 Report Share Posted February 4, 2011 Why not just pass the VISA com reference to a normal VI and just track the com reference instead of the vi reference. Quote Link to comment
Grampa_of_Oliva_n_Eden Posted February 4, 2011 Report Share Posted February 4, 2011 Why not just pass the VISA com reference to a normal VI and just track the com reference instead of the vi reference. if there are different widgets hanging off that visa ref that talk different languages then differnt sub-VI are used. If we don't know the nature of the widget.... Ben Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.