Latched boolean and multiple Events

[GraemeJ]

Is it possible to use a latching mechanical action front panel switch, and have the switch correctly reset, when it is used in more than one event case?

Any help would be appreciated.

Regards,

GraemeJ

[GraemeJ]

Is it possible to use a latching mechanical action front panel switch, and have the switch correctly reset, when it is used in more than one event case?

Any help would be appreciated.

Regards,

GraemeJ

[Dan DeFriese]

QUOTE (GraemeJ @ Nov 20 2008, 11:08 PM)

... used in more than one event case?

Please clarify what you mean by this. Can you post an example of what your trying to do?

[jgcode]

QUOTE (GraemeJ @ Nov 21 2008, 02:08 PM)

Is it possible to use a latching mechanical action front panel switch, and have the switch correctly reset, when it is used in more than one event case?

Any help would be appreciated.

Regards,

GraemeJ

If you are using the Mechanical Property "latch" the you can not use a local variable or the write to it's value property.

Using an event structure with the boolean placed in the loop is used to refresh the button when a value change occurs.

But some more info would help...

[crossrulz]

I would just put the terminal of the boolean inside the "Value Change" event. That is the only one you should ever care about resetting the boolean. None of the other events should care about the state of the boolean. Now if you are using mulitple event structures, the changed value event will register for all event structures with that "Value Change" event. Therefore, it doesn't matter which event structure you put the terminal in. As soon as that terminal is read, the latch will reset. For instance, in the picture below, when the stop button is pressed both event structures will tell their respective while loops to stop. The top loop will reset the latch value of the stop button.

[GraemeJ]

As noted by several posts, I need to explain the question more fully.

The issue arose in an application which allowed the user to cancel a prior operation using a (latched) front panel switch. The point of cancellation could be arrived at from a number of conditions and the cancellation of the operation required different code depending on the prior condition.

As in the attached example, the 'quick and dirty' approach would be to use a separate cancel switch for each condition, allowing the latched terminal to be inside each event case, and therefore able to be reset.

In the example, could the two cancel switches be replaced by just one switch?

[Dan DeFriese]

As jgcode pointed out... using the "latched" variety of mechanical operation settings prohibit the use of local variables and reading of the value in property nodes. When these settings are used, the control will only be unlatched when the block diagram code reads from the control's terminal. Thus, it can only be used in one place.

Of course, there are many ways to achieve the behavior you're looking for (or at least what I think you're looking for). My approach would be using what is called a functional global (FG). Basically, this concept uses the static (or persistant) property achieved when you don't wire the outer-left terminal of a shift register. Search "functional global" on LAVA, NI.com, or your LabVIEW Help for more details.

I've attached some example code for you play with. Instructions are on the FP. Let me know if this helps or you have further questions.

[GraemeJ]

QUOTE (Dan DeFriese @ Nov 23 2008, 06:38 AM)

I've attached some example code for you play with. Instructions are on the FP. Let me know if this helps or you have further questions.

Thanks Dan. Your example was a great help. However, I would like to have one thing clarified, particularly since latched switches and multiple events are the topic, and that is the latched stop switch. In your example, a latched stop terminal in one event is detected in the other stop events, and each event operates simultaneously (and with some different extra code put into each, produces a different stop output). The switch then resets.

In my original post, this same response of the stop button was what I was trying to achieve, the difference being that the events occurred in different parts of the program. Does it work in your example because the events are concurrent?

[Dan DeFriese]

QUOTE (GraemeJ @ Nov 23 2008, 09:42 PM)

Thanks Dan. Your example was a great help. However, I would like to have one thing clarified, particularly since latched switches and multiple events are the topic, and that is the latched stop switch. In your example, a latched stop terminal in one event is detected in the other stop events, and each event operates simultaneously (and with some different extra code put into each, produces a different stop output). The switch then resets.

In my original post, this same response of the stop button was what I was trying to achieve, the difference being that the events occurred in different parts of the program. Does it work in your example because the events are concurrent?

Yes, I believe that the only reason this works is the concurrency.

I always thought using events this way was considered BAD PRACTICE by NI. A week ago, I wouldn't have even tried this because I was under the assumption it would result in dead-lock, regardless of concurrency. However, crossrulz suggested this was possible in his reply... so I thought I'd try it. Normally, I would have used a separate FG to control the application's run state.

In this case the example works... Perhaps the rules have changed? Perhaps they haven't and we just got lucky? Most likely though, I probably just misunderstood the caveat list 4.5 years ago when I last read them and for cases in which all event structures being concurrent, this is perfectly acceptable.

[GraemeJ]

QUOTE (Dan DeFriese @ Nov 25 2008, 02:17 AM)

Perhaps the rules have changed? Perhaps they haven't and we just got lucky?

Thanks again Dan. I'll stick with 'lucky' - until that runs out.

[mike_spacex]

Interesting discussion... but I think I'm missing the point. Why not simplify GraemeJ's examples with just one event structure with one cancel button (shown in attachment)

Download File:post-4721-1227629692.vi

If you have multiple events whose actions depend on multiple conditions, still just use one event structure but hold the conditions in shift registers (or functional globals if you must!).

Download File:post-4721-1227635074.vi

All the concurrent loops and event structures are dangerous and difficult to understand or document. If this is an exercise in communication between concurrent structures with events, then I suggest creating a user defined event and registering it with each structure. Otherwise, keep it simple.

[mike_spacex]

Here's an example of the suggestion I made at the end of my last post. I think it's generally a good practice, if you must have multiple event structures, to designate only one for handling UI events. This way, you can keep your booleans latched AND you can easily pass relevent information to the other event structures registered to your user event without the need for functional globals or even local variables.

Download File:post-4721-1227636898.vi

[Dan DeFriese]

QUOTE (mike_nrao @ Nov 25 2008, 10:24 AM)

Interesting discussion... but I think I'm missing the point. Why not simplify GraemeJ's ...

I think I did too!

My example was not intended to be practical with respect to the usage of event structures. The parallel loops were only intended to simulate different parts of an application in order to demonstrate that how different parts of which could be used to unlatch the FG. I thought the intent was to have a temporary condition that would be unlatched when read. (Note the latched behavior of by Cancel boolean with respect to your submission.)

However, this evidently wasn't what the original poster had in mind, but appears more interested in the behavior of the stop button. Which I just implemented as an experimentbased on crossrulz reply... go figure.