Two VISA read operations "simultaniously"?

[Ledor]

Hey,

I want to implement the control of a Linkam stage in an existing LabVIEW Code. Therefore I need to know if LabVIEW could get a Problem, when I use two VISA read or write operations at the same time and they are talking to the same device.

A little bit more in detail: I am reading out the actual temperature of the stage by sending a command via VISA write to the stage and after that reading the answer via VISA read, and this is happening all the time while the program runs in a while loop. When I want to set a new temperature, another VISA read/write starts by changing a case in another, parallel running, while loop. The problem is that this is not running stable and I am asking myself, and now you :-D, if it's due to the "parallel" running loops including the VISA read/writes.

Kind Regards,

Daniel 

[crossrulz]

You will run into race conditions unless you are very careful.

My recommendation is to make a Queued Message Handler (QMH) to handle your stage.  The idea is you have a separate loop that waits for a message via a queue.  Once it gets a message, it acts on it (read temperature, go to XYZ).  If you need data back, the message can contain a reference to a queue to send the data back on.

Another route to go would be an Action Engine which uses the idea of uninitialized shift registers to hold your reference and you perform whatever you need to inside of the AE.

[Artem.SPb]

Of Course it bad idea to use one source in two places. Use state machine

[Bob_Schor]

Yes!  That is (as they say) "asking for trouble".  If they truly are asynchronous, and each is of the form "VISA Ask for something, VISA Get what you asked for", then you could easily have a sequence of two sequential "Asks" followed by two "Gets", only one of which is likely to be satisfied (and even then, it might not have the value for its "Ask", if you get what I mean).  

Bob Schor

[Ben]

---

@crossrulz wrote:

You will run into race conditions unless you are very careful.

My recommendation is to make a Queued Message Handler (QMH) to handle your stage.  The idea is you have a separate loop that waits for a message via a queue.  Once it gets a message, it acts on it (read temperature, go to XYZ).  If you need data back, the message can contain a reference to a queue to send the data back on.

Another route to go would be an Action Engine which uses the idea of uninitialized shift registers to hold your reference and you perform whatever you need to inside of the AE.

---

I have to agree with Tim.

The VISA resource in this example is a shared resource that needs to be protected. Creating Actions for each type of interaction (query, wait for reply) will ensure that the various types of operation can be shared across multiple threads.

Ben