VISA time-out

[Robtn]

I work in a high-energy physics lab that uses LabVIEW to maximize the output of a MIR laser. The problem we're having involves our piezo-electric signal box, (that adjusts the laser cavity length by sending voltages to piezo-electric crystals) which we communicate with using an RS-32 connection.

It will be difficult for me to send a picture of the block diagram, but suffice to say that I'm using a VISA read-in that reads from the COM1 port. The piezo box sends a signal approximately every 3 minutes, so we're constantly waiting for the signal to reach the VISA. This is a problem because as the VISA is waiting it times out the program, so we can't run the program in parallel with a larger one. Is there a way to avoid this problem?

In particular, what I'd like is something that reads from the RS-32 constantly without waiting for it to send a signal. If it can be done without VISA, that would be great. I don't remember the exact version of LabVIEW we're using, (the computer is in the lab, and I'm not there at the moment) but it's greater than 8.

[Mark_Yedinak]

If you aren't interested in the timeout then you can always ingonre it. Check the error after the timeout and if it is a timeout error simply clear the error and loop back around. It is not the most efficient or elagant solution but it should work for you. Without seeing your code it is hard to comment specifically about ways to modify the design itself but I have written parallel tasks were one task is constantly reading from a VISA connection. The read task simply ignores timeout errors. This will allow you other tasks to continue running.

[Dennis_Knutson]

You can use the VISA Bytes at Serial Port to see if there is any data. Put this into a loop and exit when bytes is greater than 0. Be sure to put a small wait in the loop so you don't use all of the cpu resources.

[Robtn]

That sounds like a good solution, but even if the loop error is ignored, I think it will still slow down my main program. Correct me if I'm wrong, but it seems like there's a default timeout of about 10 seconds on the VISA read-in, so even if the error is ignored, I'm still waiting for it to recognize that it has timed out. What I originally wanted was to put the VISA read-in in my main program and have it work while other things are going on. One thing I thought of was to make a separate while loop and have the VISA in that, but it didn't seem to work.

My first solution was similar to yours, where I have a read-in constantly working in the background in a separate VI which sends the signal it obtains to a text file that the main program can read. 

I think that's what we're going to go with, unless there's something other than VISA which I don't know about. Thanks for your suggestion.

[RavensFan]

You've got several options,

1.  Reduce the VISA timeout to a smaller number than 10 seconds.

2.  (I think the best option) is to put the VISA communication in a separate loop.  You'll have to explain more as to what you did and why it didn't work for you.  The preferred method for passing data between loops is a queue in a producer/consumer architecture.  Now if you dequeue element has an infinite timeout, that will cause the consumer loop to pause.  So the best scenario there is to use a small timeout on that function, and use the Timed Out?  output to determine whether it got data in the queue or timed out, and do whatever is appropriate based on that afterward within a case structure.

3.  Use an event structure and register for a user event based on bytes at port.

Using a text file as a data transfer mechanism I would use only as a last resort.  It would slower, you run the risk of some error being cause by two different parts of the program contending for the same file, and it is just a hack.

[Robtn]

I like those ideas. In particular I will try 2 first. 

The text file part is actually a fairly unimportant process. It really isn't THAT necessary to have the two VIs running in parallel, it's just nice to have a display on one interface (the big program).  Yes, there could be errors if the two VIs are vying for the same file, but it's really not a large concern since it operates separately from the other processes in both VIs. 

What I really wanted was to just do away with the separate programs if possible, and I think it's possible with your ideas, I'll try them.