Correct way to use same instruments in 2 different VI's

[iamashwin99]

I am trying to make a VI for automating Resistance vs Temperature measurements using LakeShore 336 temperature controller and Keysight B2912a source meter as the instruments.

So I want to make 2 separate VI's one to enter setpoint in LS336 in ramping mode (start to end at constant increment a second) and the other VI to take measurement data into a file and to plot the same on that VI (this VI will be in loop as long as user doesn't quit).

Now my doubt is that since 2 VI's are controlling LS336, should I use initialise and close blocks in both the VI's or Initialise in the control.vi and close in measure.vi.

I'm getting this doubt since If I keep both modules in both vi, then when I  use control.vi first then the instrument goes to the required mode but when I run the measure.vi it stops being in that mode but just goes to normal mode and reads temperature data.

[GerdW]

Hi ashwin,

Now my doubt is that since 2 VI's are controlling LS336, should I use initialise and close blocks in both the VI's or Initialise in the control.vi and close in measure.vi.

Init and close the communication in a 3rd VI and wire the VISA reference (?) to those 2 VIs…

It seems you have a shared resource here, so you also need to handle race conditions: it could be a bad idea to send commands to your device from two parallel running VIs: which VI gets which answer from your device?

[wiebe@CARYA]

If you make a non-reentrant sub VI that writes a command and (waits for and) reads the answer, you should be OK. Splitting the write and read won't work, you'll get race conditions.

Alternatively, you can make something run in parallel, and have send\receive messages to\from it.

Alternatively, you can make something run in parallel, that continuously collects data, and stores it in a buffer that the rest of the application can read. This can be in combination with sending messages to it.

[crossrulz]

In my experience, it is best to have a Queued Message Handler to take care of all communications with your controller.  This is a VI that runs in parallel with the rest of your code.  It accepts commands via a queue and does whatever it needs to in order to perform that command.  It should complete said command before it loops back around to looking for the next command.  I will often use the queue timeout to periodically grab measurements and send them out via another Queue or User Event for the sake of logging (have a separate QMH to handle logging of data).