Running 2 VI's simultanously - will I get problems?

[vtiu]

In my project I have two VI's which I need to run at the same time. VI 1 reads data from various channels on an OPC Server (about 40). Read and display is 1 second interval whilst log is few minutes or longer. This VI uses sub VI ReadData. This is basically my display and log.

The VI 2 is my control VI. It also uses sub VI ReadData and a second sub VI WriteData. Both of which connect to the same OPC server.

As I cannot test the system at present. Can anyone say if I will get problems with this setup, bearing in mind that timing is not really relevant?

Should I be looking at reentrancy?

I hope that this is enough information.

Many thanks.

Regards

Mark

[Bob_Schor]

Both your routines use a VI called "Read Data".  It is not clear (to me) what this VI does, but if it connects to a Data Source, reads it, and returns the Data, then it seems logical (to me) that it will return the data to only the VI that calls it first, and when it does, it can be called by the second to read (different?) data.

I think you will help yourself if you utilize a much under-used Programming Tool -- a pencil (or a pen) and a piece of paper.  Write a description of what you are trying to do (i.e. explain your program to yourself).  What are the two (simultaneous?) Tasks?  How do they relate to "data"?  What "timing" is involved?  How (if any/ever) do the Tasks interact?

It certainly is possible to have multiple loops.  Most of the routines I write have such loops, as do many of the Design Templates and Projects that ship with LabVIEW (look at the Producer/Consumer Template, the Queued Message Handler Project, and others).  Generally, loops "do their own thing" and communicate with each other, usually passing data along.

Bob Schor

[Yamaeda]

Will you get problems? Yes, you'll create lots of bugs and pull your hair, though that's nothing unique to this case. 🙂

If timing isn't a problem, it sounds like it should be fine. Reentrancy would actually create problems in this case, as you want Read Data to be the only one to communicate with the OPC, and only 1 of those at a time.

Would it be a good idea to integrate the 2nd read into the 1st? Add whatever you planned to read in the 2nd one to the 1st ones reads and either store them in an Action Engine or send updates as a user event to the 2nd one.

That way you'll only have 1 Read and 1 Write and have reduced the points of error.

[vtiu]

@Bob: Both your routines use a VI called "Read Data".  It is not clear (to me) what this VI does, but if it connects to a Data Source, reads it, and returns the Data, then it seems logical (to me) that it will return the data to only the VI that calls it first, and when it does, it can be called by the second to read (different?) data.

This is exactly what is happening. The ReadData sub VI in the Display VI connects to the OPC server and reads various input channels. The same sub VI in the control VI also connects to the OPC server but reads the output channels and writes to them as well (WriteData subVI). I have used the wrong word simultanously here as this is not the case. The ReadData can be "queued". Timing is not relevant here, as both Display VI and Control VI are "slow". I have made a test and the Display needs a time delay in the loop of at least 250 ms to prevent a "crash". At present I am using 750ms and this is fine. This is what I meant by "slow".

There is no interaction between the two Display and Control VI's.

Thank you for your reply.

Regards

Mark

[vtiu]

---

@Yamaeda wrote:

Will you get problems? Yes, you'll create lots of bugs and pull your hair, though that's nothing unique to this case. 🙂

If timing isn't a problem, it sounds like it should be fine. Reentrancy would actually create problems in this case, as you want Read Data to be the only one to communicate with the OPC, and only 1 of those at a time.

---

This is basically the answer to my question! "only 1 of those at a time" - exactly. Thank you.

Regards

Mark

[Ola_A · Accepted solution]

Not a definite answer, but at least this works for me without problems!

I have a log program that logs from a machine via OPC, some 100 variables every 1s, when the machine is producing. But I also wanted to log durings nights, and when the log program missed the start etc. So I added a second small log program that only logs every 5s. Of course uses same sub-vi's as the first. So I was worried that they would interfer, but I have not seen any problems.

You can probalby test your system in the lab by setting the "Simulate device" in OPC server on the PC. If it works with this setting and read every 100ms or so, I think you can be safe that it will work in real situation at 1000ms.