Loop Stop with multiple inputs

[M-A.D]

The loop stop function now accepts errors directly which is an improvement but there are many cases where loops must stop based on multiple sources.

If the stop function had several inputs (eg 4 - one one each side), this would allow multiple errors or stop commands all OR'd internally within the stop function to work without the clumsy OR function that is so commonly used.

There is no reason the OR couldn't be built into it and make everyone's live's easier. It would also simplify coding and increase speed of development.

[AristosQueue (NI)]

Multiple terminals -- my knee jerk is against it, but I have some secondary thoughts that might make it viable.

Multiple terminals does not seem to me like something easy to read... I'm imagining what that would look like, and I suspect I could easily miss one on my own diagrams, which are mostly relatively clean, and I shudder to think what might happen on some of the more ... novel block diagrams I've seen over the years. At least right now I can track upstream to figure out why the loop is stopping. Yes, we could add a search ability, but that only helps if you know to go searching. So that makes me think we'd want to annotate every one of those stop terminals with a glyph that says "there's more than one of me!", maybe put a number in the stop sign/continue circle that says how many of these are scattered about on the diagram. With all that, the idea might be workable.

Having said that, it would still be subject to Intaris' objection that there wouldn't be a single wire for a conditional breakpoint probe.

We'd also have to figure out what to do with the compound logic (mix of continue logic and stop logic) and when to explain to users "you can't use the multiple stop to do what you want, you need to drop some Boolean nodes and wire to a single stop".

Tricky. Perhaps put it up as a new idea so collective can cobble together a more coherent proposal for how it might work.

[Darin.K]

Well I will remain in the obscurity of the comments of an idea going nowhere for the moment.

If your loop looks like it has measles, then I think it would be a sign of misuse.  If it were a fixed location terminal like the N terminal then I would say loosing track would be a problem, but since we already have to play "Where's Waldo?" I do not see much difference between 1 and 3.  Easy to have a RCM option to find conditional terminals, helpful even if there is only 1.

I have no idea how readable it will be in the end, I can not try it.  I do know how unreadable a string of booleans converging on a compound boolean node with some tiny inversion dots is to read and comprehend.  I like the idea of having the information and the decision close together on the BD, as well as having the natural condition instead of using negation.

Adding a conditional probe for the stop terminal is also an intriguing idea.  It would be easy to treat all of them in the same probe.

The combination logic is simple:  any one that wants to stop the loop stops it (OR all of the Stop terminals), all of the continue terminals must be true (AND those inputs). 

It is like being able to sprinkle a few break statements in a C for loop instead of checking ten different conditions every time through the loop.

[Darren]

Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.