LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Event conflicts & registering dynamic events. Also, convoluted and text-like code?

cebailey,

I do not know about your LabVIEW experience, but in my own case, I have been programming LV for about 4.5 years now, coming from a strong textual programming background. Up until a few months ago I never needed to use dynamic events in any of the code I wrote.

There is surely a simpler way to accomplish your task without having to think about dynamic events. Forget about them for now and concentrate on dataflow and getting your head around all the nuances with the normal event structure.
0 Kudos
Message 11 of 19
(969 Views)

Interesting points raised and answered.  I have a similar view of problems and use a template for most code.  The "Producer and Consumer (with Events)" template ( found from selecting File > New ... >> Frameworks >> Design Patterns ) creates efficient code to respond to user events.  To add a state machine to that pattern is fairly simply in the consumer loop.  When a user request is initiated,the event request initiates a state in the consumer state machine.  The consumer loop can sequence one or more additional states (in the consumer loop) to complete that request.

 

For cases that involve custom event handling, I agree with the suggestion to enable/disable FP controls.  Using a common subVI functional global variable to manipulate references to all the affected FP controls can simplify the main VI.  An example from the LV Intermediate course was a Display module.  The Display subVI is initialized with a cluster of control references.   Then, various 'calls' can customize the front panel's appearance.  My 'calling' enumeration has states like:

Initialize Refs
Disable All
Enable All
Operator Logon
Engineer Logon

 

This pattern is customized per application. 

 

Regards,

Kenneth  

0 Kudos
Message 12 of 19
(921 Views)

Thanks, all, for these suggestions.

 

I did not know if I was trying any of the right things, and it just wasn't working, and I kept using people's suggestions without knowing if I was getting closer.

 

TonP pointed out the bit about "Lock front panel", and when I unchecked it everything worked. Not that that was the only thing wrong at the start, but eventually it was.

 

Since then I have used dynamic events for several purposes. It seems to me that dynamic events are necessary if keystrokes are the best user input signals in some machine states but not in others. I don't know if it's possible to disable the keyboard, but so far it's never even been desireable. So, event handlers that sometimes catch keystrokes are easily turned off with dynamic events. Also, all my subvi's that respond to main front panel control events do so with dynamic event registration from references passed in, or with the dynamic event refnum itself passed in (that is, sometimes the registration itself should happen in the calling vi and sometimes in the subvi). Sometimes registration even needs to happen inside a loop, for example when there are alternating states of key down event handling and of the user typing text into a field.

 

In everything I'm doing, they work well, and once I had some examples working right it was easy to move on from them. So far, the sampling of customers for my code who are testing it say they like it. That's what it's all about.

 

Thanks again.

0 Kudos
Message 13 of 19
(910 Views)

I'm trying to understand Dynamic Events, and came across your example.  However, it works not because of dynamic events but because you have two event loops!  The behavior seems (to me) to be identical if you simply delete all of the "dynamic event" code going into and out of both event loops.

 

Back to the drawing board ...

 

Bob Schor

0 Kudos
Message 14 of 19
(818 Views)

Cebailey,

First let me see if I understood you correctly:

 

 - the core functionality is OK

 - but the user interface does not work the way you want it to

 - You want to have multiple FP controls for the same function,

      such as text box, up/down arrows, etc, but all of them together

      constitute one device control -- perhaps thinking of them as

      different views of the same control.

 

Is that what you are looking for?

 

Best Regards,

-- J.

 

 

0 Kudos
Message 15 of 19
(812 Views)

Glad folks are interested. These postings are now 0.7 years old, so I am not remembering details of where I was at the time, but I think this is what was driving it all:

 

My program mostly functions as a state machine. In one state it moves the test chamber around according to how people hold down the arrow keys (I mean the PC keyboard keys under the Delete - End - PageDown keys). In another state it lets people enter text into a comment field. The arrow keys are always there, and the comment field is always visible on the front panel, so if I have an event handler always catching the arrow key events, it would try to move the test chamber around when they are going back to edit the beginning of the comment line. Editing the comment line ought to be handled by LabVIEW's string control that the comment line is in; I'm not about to mess with its internal behavior. So, if I want the left arrow key to sometimes back the cursor up by one character, and sometimes move the test chamber toward the left end of the machine, I think I need to use an event structure and dynamically register the key down event so I can let it go when I leave the chamber-moving state.

 

Also, I need some of my subvis to handle events that happen in the main vi's front panel (the subvi's panel isn't visible, as is usually the case). AFAIK you need to pass a reference into the subvi and register for the event there, right? Can you use event structures in a subvi that handle an event happening in its caller's front panel without dynamic event registration? I don't think you can, but in any case you can by using one.

 

My project has over 300 subvis now, more than 65 of them are over 200 kB in size, and the largest is 1.5 MB. I don't know if there should be more division into subvis or less, but it sure would be awkward not to process any events inside of subvis.

 

Also, I have been meaning to try to figure the following out, but it's been busy here - there are ordinary old event structures, and event structures using dynamic event registration. Is there some intermediate situation where you use "static event registration", which is easier? Or is there no such thing? I guess I am not sure that I need my event registration to be dynamic, or if that is the only kind. My take on it was that, if I can call a subvi and have it register for the event by passing in a reference, or if I can get rid of an event registration so it doesn't do something when the left arrow key goes down, those are dynamic things I am doing with the event, but I don't know for sure.

0 Kudos
Message 16 of 19
(803 Views)

Forgot to say that the examples I post, in general, are simple examples to illustrate the function I am trying to use. Typically the examples don't have to be done that way, but I can't post enough of the real thing itself make it clear why I want to do it that way. It's much harder to post examples that illustrate the function AND make it impossible to do it some simpler way.

 

By the way, the "Value Change" event is misnamed. If the user edits a control but leaves the same value in it, I think the event fires. But, if the program changes the value in the control, no event fires. So this event really is a "User Edit" event, not a value change event. Is there a way to react to a value change, per se, other than polling it and comparing it with its previous state using a shift register?

0 Kudos
Message 17 of 19
(801 Views)

You are correct that "Value changes" is a slight misnomer.  This really means (as you realized) "the front panel control has been changed by the user interacting with it".  If you want to change its value programmatically, you can still get it to "fire", but you have to do it in a special way.  Instead of putting a value into, say, an indicator, or into a Local Variable, or even in a "Value" property node, you need to put the value into a "Value (signalling)" property node -- this will fire a "Value Changed" event for the indicator (or control).

 

Bob Schor

Message 18 of 19
(795 Views)

>put the value into a "Value (signalling)" property node

 

Wow, so THAT's what that does! Splendid, thanks!

 

Where in the docs can you find all the meanings of the possible items you can select in a property node? I'm not hunting for this in the right places.

0 Kudos
Message 19 of 19
(778 Views)