Jump to content

Solution for propagate latched boolean between loops


Recommended Posts

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.

post-5178-0-64162100-1318581593_thumb.pn

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.

post-5178-0-66301000-1318581907_thumb.pn

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

Eric

  • Like 1
Link to comment

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.

Link to comment

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.

Link to comment

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.

  • Like 1
Link to comment

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.

Link to comment

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.

Link to comment

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

post-7603-0-00361600-1319168617_thumb.pn

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.

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.