Non-blocking SubVI output terminals?

[Zazoo]

Is it possible to prevent an output terminal of a SubVI from blocking while the SubVI executes?

Thank you,

Mike

[pincpanter]

I don't see any way a terminal could block anything else. May you elaborate the question?

[Guruthilak]

dont wire the output terminal to anything......

[smercurio_fc]

In a word, no. LabVIEW is dataflow programming, not procedural programming. Nodes execute once data is present. If you've connected a wire to a node, then that node must wait until there is data on that wire from the source. If the source is a subVI, then the wire must wait until the subVI completes because it is not omniscient and cannot possible know what data will be placed on it. If wires could see into the future then we would have clearly solved the mystery of the arrow of time. In that case, we would then be able to build a time machine, which would allow us all to go back and witness some real neat chariot races back in good ol' Ancient Rome. Some say they want to see the pyramids being built. Pshaw, I say. Who wants to see a bunch of blocks being moved around. Now, if you were to tell me that we were going to go back and see Stonehenge being built, then I'd say "Hell, yeah!". After all, I want to meet the aliens who used their super-nifty anti-gravity devices to help those cheery druids set up those dominoes. Of course, anyone who does participate in this traipsing around time would need to be firmly told: "Now don't go killing your grandfather, or we're going to have to have words with you!"

I'm prettty sure alfa has some thoughts on this. I kind of miss his existential nonsense.

So, no.

[Ben]

---

@smercurio_fc wrote:

In a word, no. LabVIEW is dataflow programming, not procedural programming. Nodes execute once data is present. If you've connected a wire to a node, then that node must wait until there is data on that wire from the source. If the source is a subVI, then the wire must wait until the subVI completes because it is not omniscient and cannot possible know what data will be placed on it. If wires could see into the future then we would have clearly solved the mystery of the arrow of time. In that case, we would then be able to build a time machine, which would allow us all to go back and witness some real neat chariot races back in good ol' Ancient Rome. Some say they want to see the pyramids being built. Pshaw, I say. Who wants to see a bunch of blocks being moved around. Now, if you were to tell me that we were going to go back and see Stonehenge being built, then I'd say "Hell, yeah!". After all, I want to meet the aliens who used their super-nifty anti-gravity devices to help those cheery druids set up those dominoes. Of course, anyone who does participate in this traipsing around time would need to be firmly told: "Now don't go killing your grandfather, or we're going to have to have words with you!"

I'm prettty sure alfa has some thoughts on this. I kind of miss his existential nonsense.

So, no.

---

Nice diatribe there Saverio but...

See here.

Notes:

1) I have used it multiple times and it works.

2) There was a bug in about lV 7.1 where the setting did not work.

3) The values returned by a sub-VI when skipped are the "default default" meaning what the LV default value is and NOT the default defined for the output.

Ben

PS: Kuods for making me smile and invoking alfa.

[smercurio_fc]

Thanks for reminding me about that Ben. So many little things in LabVIEW...

However, I don't think what the OP is trying to do and what that feature does are quite the same. That feature allows the call to be skipped alltogether (assuming the subroutine is already running in another thread). I think the OP wants the subVI to run, but let the rest of the code continue. Of course, inherently, LabVIEW will already do this until it gets to the point where it needs data that comes from the subVI. I'm speculating the OP doesn't quite understand dataflow programming.

[Ben]

Agreed.

I am just splitting hairs and refressing synaps as a public service.

Take care,

Ben

[SteveChandler · Accepted solution]

Consider the following snippet

When you run this you will (almost) immediately see the value of "Numeric out". You will see the results of the array after one second. If you were to make this a SubVI and call it from another VI you will see both indicators update after one second. The fast one has to wait on the slow one. That is normal and is the way LabVIEW works and has always worked. It makes sense and makes the code easy to follow and debug.

But what if you were to inline the SubVI? What would the expected behavior be? In fact what happens is that LabVIEW wraps a sequence structure synchronization barrier around the code like this prior to inlining a VI

That makes the inlined VI act as a normal VI. NI has said that it would be very easy to simply not put the barrier around the code as an inline configuration option. I call that hard inline but there is probably a better name for it. (By the way there is some excellent discussion in that thread)

To be honest I don't know what I would do with that option. In the back of my head this nagging voice keeps telling me it could be a very useful option some day. It gives us the ability to do something that is currently not possible. Someone will come up with a really clever trick if it does become possible.

[Zazoo]

My question was whether LabVIEW had some mechanism to allow an output terminal of a SubVI to pass data out to the top-level VI as soon as it was avaialable (vs. blocking all terminals until the entire SubVI has finished executing.)

I guess not.

Thank you,

Mike

[Mark_Yedinak]

There are ways to do this. The most basic would be to use a queue or a notifier. However for this to work the subVI would need to run in parallel to the part of the calling VI that would service the queue or notifier. This type of architecture is the basis for the producer/consumer architecture. This is two parallel tasks that communicate using a queue or notifier. (Queues are typically better than a notifier since you can effectively buffer the data.)