Running two labview instance accessing the same hardware ressources

[laurentm198]

Hi, 

I am currently wondering whether it is possible to launch two labview instances in same time running in parallel while those two instances would access successively the same hardware device (meaning when one instance use the hardware resoure, the other instance don't need to access it and vice-versa) ?

[santo_13]

Actually, it is not logical, instead create another LabVIEW application which will control the instrument. Now your applications A and B will communicate with the instrument control application C, this way you can ensure both applications A and B do not attempt to control the instrument at the same time.

[billko]

---

@santo_13 wrote:

Actually, it is not logical, instead create another LabVIEW application which will control the instrument. Now your applications A and B will communicate with the instrument control application C, this way you can ensure both applications A and B do not attempt to control the instrument at the same time.

---

Yes, this is the same concept as having two VIs in the same instance accessing an instrument through a (non-reentrant) subVI.

[pincpanter]

I agree with the answers you already got, but strictly sticking to your question: yes, in principle it's possible but only one of them at a time must have a reference/handle open on the shared resource.

[Yamaeda]

Depending on your requirements it can work. I did it with a simple weighing program.

The user could have 2-4 objects that they needed the weight of from time to time, so each instance was a test of an object with a timer and they had a button that read the measurement from a scale (they did a number of steps in between). It opened VISA, took a reading and closed the ref.

It was a very low frequency scenario and no chance of simultaneous readings.

[Frozen]

---

@pincpanter wrote:

I agree with the answers you already got, but strictly sticking to your question: yes, in principle it's possible but only one of them at a time must have a reference/handle open on the shared resource.

---

Expanding on this statement... You must handle the condition where one program has the HW handle locked while the second program wants to use it. So think ahead. What is going to happen to the second program? Hopefully it will not crash (error out).

[Kevin_Price]

I've used both of the methods suggested (one by Santhosh, one by Yamaeda).

What Santhosh described is more generally applicable, but also takes more work to create and debug.  I've done both at various times. 

I recently had the kind of app Yamaeda referred to where the need for the shared resource was on a low duty cycle.  Each app would need it occasionally and very briefly, so contention would be fairly rare.  Roughly once every couple of minutes there might be contention for a half second or so.  So I decided to just go with the easier approach he mentioned.

There's still some extra work, but not very much.  You just code each app to *expect* that some of its attempts to open the VISA resource will fail with a particular error stating that the resource is present in the system but not available to reserve.  Then make sure both apps keep trying a few times, not forever but long enough to be sure that it isn't the other known app causing the unavailability.

-Kevin P

[laurentm198]

Can you share some examples / .vi or anything so we can visualize a bit better ?

[RTSLVU]

I would suggest you combine the two seperate programs into one program instead of two independent programs fighting over the same resource.

It's far easier to control access to a single resource from two independent loops in one program than two independent programs.

But honestly I need more information, what kind of instrument and what do the two programs do?

[JÞB]

---

@Kevin_Price wrote:

I've used both of the methods suggested (one by Santhosh, one by Yamaeda).

What Santhosh described is more generally applicable, but also takes more work to create and debug.  I've done both at various times. 

I recently had the kind of app Yamaeda referred to where the need for the shared resource was on a low duty cycle.  Each app would need it occasionally and very briefly, so contention would be fairly rare.  Roughly once every couple of minutes there might be contention for a half second or so.  So I decided to just go with the easier approach he mentioned.

There's still some extra work, but not very much.  You just code each app to *expect* that some of its attempts to open the VISA resource will fail with a particular error stating that the resource is present in the system but not available to reserve.  Then make sure both apps keep trying a few times, not forever but long enough to be sure that it isn't the other known app causing the unavailability.

-Kevin P

---

I like your approach Kevin but.....

Nobody has yet suggested the simple expedient of interpreters communication by simply writing to a *.loc file.  Just a quick text that tracks what app is just about to lock a resource (potentially even a list of what apps are waiting) then only allow attempts to open the resource after successfully writing to the file.  And, of course, the app using the resource should clear the *.loc file after closing is session.

essentially its the dining philosophers problem

You have to pick up a fork and wait for the other