Enhance Loop Conditional Terminal

[okubik]

Hi,

I want to start discussion about how to enhance Loop Conditional Terminals in LabVIEW. Generally my idea is to have an easy way how to monitor Conditional Terminal of user-defined "primary" loop. Under the hood there can be for instance notification triggered from the "primary" loop and one or more "slave" loop(s) equipped with "Wait for notification" (with timeout = 0) with predefined logical operation on the terminal input.
So this allows you to have one STOP source loop and one or more listeners.

Anyone wants to expand this idea?

[Intaris]

This is an interesting idea but how do you deal with the situation where Loop 1 stops and starts again before Loop 2 actually stops.  Does it stop because the stop signal for the first iteration was activated or does it keep running because the current Loop 1 is also running?

Would we need a queue of notifiers to maintain the correct number of iterations between loops independent of the execution speed?

[okubik]

2 Intaris:

Nice catch. Any current "easy solution" generates this kind of race conditions as well. I can only imagine yours scenario as "situation 2" shown in the following image. However it is pretty the same like subVI which wouldn't be supported with this feature.

(Note: Blue loop is "stop notification" source, Red is monitoring for stop notification)

[Intaris]

I was thinking more along the lines of each loop being within its own outer loop, I guess it would be situation 3....  Not being supported would seem the easiest way out.

[johnsold]

I am not convinced that this is worth the extra complexity in the loop structure.  The extra code necessary would probably slow loops which need to execute as fast as possible (although the smart compiler might be able to remove it). 

Would it apply to condtional terminals in for loops?

For cases where I want to stop multiple loops without notifiers or queues and trhe BD space they occupy, I have created a FGV/Action Engine wrapped in a special purpose VI dedicated to stopping. It has a small icon to minimize BD space and does not require any wiring except the output boolean.

Lynn

[Ardent]

2 johnsold - I guess that the usage of this "multistop" could be determined on edit time, in which case it would only slow down loops which would use the functionality - it could be something like a polymorphic conditional terminal

[Thoric]

I think this has great merit, it will especially appeal to newcomers to LabVIEW who are attempting to learn parallel operations without wanting to introduce messaging between loops. If this existed, I know that I would try to use it occasionally in draft code segments when I'm trialling stuff.

Keep it simple though. One publisher, multiple subscribers.

For multiple pairings, we just need names (use the source loop labels?).