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?

[X.]

My personal experience is that most parallel loops do not interact simply by stop signals. In a producer/consumer scheme, messages and data usually justify using queues and passing a stop signal via the same queue is easy enough.

Your suggestion might however simplify the task of newcomers who may need this simple (simplistic?) solution. Almost all LV beginners (including me, in the past) will try to stop two parallel loops by dropping a Boolean control inside one of the loops and wire it to the conditiona terminal of both loops. With the expected failure to stop the second loop...

Other than that, I don't quite see the utility of this feature for even a moderately sophisticated code.

Just my opinion.

[ToeCutter]

This is genius- even your little icon, all what 8x16 pixels of it... genius.

I think this simplifies the code for a scenario that arises regularly. Parallel loops arent always communicating via a queue after all.

Just one extra idea- how about the ability for more than one loop to be the signaller, and allowing a loop to both signal and receive. Example: primary loop contains a stop button, 'secondary' loops have error wines wired to the stop button.

An even further 'enhancement'- multiple groups- butttons only communicate with others in their group. Groups higher than zero have a little number displayed in the icon.

+1K

[A-T-R]

Generally: Kudos to this!

@ToeCutter: ...but don't over-complicate it!

A.

[X.]

Let me clarify: I mentioned queues because this is what comes up naturally past a certain level of code sophistication (I am not familiar with the actor framework which is supposed to solve all the problems you never had :-).

You can also use notifers:

I would argue that if you remove all the widgets I have included for the code to actually do something, this is not really a complex code and it does exactly what the OP wanted it to do.

[donkdonk]

I think it's a good idea.

(I would even go one step further: also add a timeout, but hat may be an idea on its own).

I know a lot of people think that everything has to be built using a scalable architecture.

But I think it certainly has its use case, especially in your own lab where you just want to throw in some loops and have some quick and dirty results.

I always find these queues and notifiers with their non-dataflow-wires clutter the diagram.

(they are very powerful, but not always required)

[tomlawton]

While it's a neat implementation, if you're after a quick-and-dirty simultaneous stop, a <flameSuit> Local Variable </flameSuit> will achieve what you're after, with the advantage of explicit readability...

(Mechanical action gets inevitably interesting, using local booleans....)

[X.]

Very quick and extremely dirty:

[okubik]

Hi Guys,

I have to say that I partially agree with every single opinion written above. My idea is definitely not meant for large and sophisticated applications. I am counting only with limited scope. Basically this may be a way how to pass "stop" notification within one VI (no into subVIs). I saw dozens codes using local variables which I consider as the dirtiest way how to share data between multiple loops. They are introducing race conditions, they executes only in UI thread and so on...

Second common way how "NI recommends" to stop loops by error (like it is done in master/slave design patterns) which I again consider as dirty method.

Here is one possible implementation:

That's why I think this can be an useful way how to make "not that dirty codes" for everybody who is developing small reconfigurable applications on daily/weekly basis. Finally this brings users to "not care that much" about how to stop parallel loops any more.

Ondřej K.

[tst]

How about if instead of this whole thing LV simply ships with a simple VI or two which will do this (such as Set Stop and Read Stop)? Once you set the stop, all readers output T until it is reset (explicitly or with a first call primitive). You can then have it work by name, etc.

That should give you the functionality you want with code which is easy to undersand and use without requiring a change to the language.

[crossrulz]

Tst,

Are you recommending something like a Functional Global Variable that every loop can read to see if they should stop?  I have done something like that before.  It worked really well until I tried to but a user event in there to stop my event structure.  I need to get back to playing with it.

Adding a name aspect is an interesting idea.  But would that add too much complexity?  Again, I need to find time to play with that code again.