Solution for propagate latched boolean between loops

[Bobillier]

Hi

Today i have write a trick to solve one old limitation of Labview. As you know , you can't create local for latched boolean. And sometimes

it will be useful if we have one.(for example to propagate latch action between few parallels loops). My solution use event with dynamic registration. (see Trig on latch boolean action).

TestTRIG.vi

Trig on latch boolean action .vi

But it's not all. With this trick, If you modify Latch boolean ref input by another kind of ref type and/or modify the kind of registration, you can easily propagate any kind of action.

However, i have one question about this trick.

At start, i have write one first solution where event registration is do only at first run and aren't unregistered.

And after i have modify this trick, and create registration if not exist and unregister it when latch arrived.

In this case, you have new registration for every latch.

My question is to know which solution is best, and if it's bad to not unregister dynamic event.

Eric

[Saverio]

Interesting, but from a practical perspective, that seems like an awful lot of stuff to go through just to get the ability to get a value change event for a latched Boolean. It seems to me to be easier to simply use a switched Boolean and reset it via a local at the beginning of the code.

[Daklu]

It seems to me to be easier to simply use a switched Boolean and reset it via a local at the beginning of the code.

Unless the boolean needs to be reset without exiting and restarting the program.

As you know, you can't create local for latched boolean. And sometimes

it will be useful if we have one.(for example to propagate latch action between few parallels loops).

Latched booleans are simply modified switched booleans that automatically reset as soon as the value is read. They are a convenience for us as programmers so we don't have to write reset code in those situations where we're just doing a single read and reset. It's not intended to be used as a general replacement for all button reset code.

The fact that you're trying to do something latched booleans cannot do--have parallel loops read the latch--is a strong indication that something is wrong with your approach. The problem is you have too many loops reacting directly to the state of your front panel controls. You'll have a much easier time if you restrict all front panel control reads to a single loop with an event structure, and have that loop send messages to the other loops to let them know the button was pressed.

[Saverio]

Unless the boolean needs to be reset without exiting and restarting the program.

I don't quite understand what you are referring to here. I provided the resetting of the button via a local at the beginning of the program as just an example (albeit a common usage scenario). Clearly, you can reset it anytime you want.

[Daklu]

I provided the resetting of the button via a local at the beginning of the program as just an example (albeit a common usage scenario). Clearly, you can reset it anytime you want.

Yes, but you can't reset the boolean until all the loops have had a chance to read the value. That means you have to add a global checklist of who has read it and who has not and have each loop mark the checklist when it has read the boolean. Then you need code that either polls the checklist to reset the boolean or have each loop check to see if it's the last one to read the boolean. When parallel loops are reading the same control it's not simply a matter of wiring a constant into a local variable. Can you do it that way? Sure, but it's error-prone, doesn't scale well, and there are better ways to do it.

[Saverio]

I thought all we were looking for was a simple value change event to use in an event structure. When did we get to multiple loops reading the same control and global checklists? Did I miss a message?

[Daklu]

From the original post:

"(for example to propagate latch action between few parallels loops)"

and

"But it's not all. With this trick, If you modify Latch boolean ref input by another kind of ref type and/or modify the kind of registration, you can easily propagate any kind of action."

I may be misunderstanding the op, but I interpret his comments as meaning he wants the boolean value available to multiple loops. On the other hand, I didn't test his code and I haven't spent enough time looking at it to fully understand what he's doing, so maybe I'm wrong.

[Daklu]

Here's the block diagram of Eric's example of how to use the vi posted above.

He's definitely wanting to read the front panel controls in multiple loops. The Stop button could be replaced with a switched boolean instead of a latched boolean, like Saverio said, but the Increment Count button would be harder to implement as a switched boolean. (A switched Increment Count button would also have slightly different behavior, remaining pressed until both the Master and Slave 1 finished reading it.)

There is one non-obvious side effect to doing this instead of passing messages. In the snippet above you can see the event is unregistered when the first value change event comes through. That means any additional value change events in the event queue are discarded and the slaves may lose clicks if they are sent before the slave loops again and reregisters for the events.

Still, it's an interesting solution to a problem I know a lot of people have struggled with--including me, before I changed my approach. I might use this on prototype (i.e. throwaway) code but in general I prefer restricting control reads to a single loop and having it send the data to the other loops that need it.

My question is to know which solution is best

I don't know if one solution is inherently better than another. Depends on your needs for the specific application. Registering only once would prevent the missed button clicks I noticed.

and if it's bad to not unregister dynamic event.

No, there are no bad effects I'm aware of if you don't unregister a dynamic event.

[ for cleverness and ease of use, even though it encourages less optimal code separation.]