From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Create User Event vs Value(Signaling)

Solved!
Go to solution

I'm trying to determine the best way to trigger an event structure case programatically. I'm still a bit of a novice (studying for the CLAD) and have been using Value(Signaling) up to this point to simulate a user's interaction with the front panel in order to trigger an event.

 

Having just recently come across the Create User Event functionality, I'm a bit confused as to which I should be using. Creating a user event seems to allow the transfer of data into an event structure, which as far as I'm aware cannot be done with the Value(Signaling) property node.

 

However, if I am not trying to transfer any data (just trying to trigger an event), which method would be considered 'best practice'?

 

Thanks!

0 Kudos
Message 1 of 4
(3,817 Views)
Solution
Accepted by topic author anodeanna

@anodeanna wrote:

 

Having just recently come across the Create User Event functionality, I'm a bit confused as to which I should be using. Creating a user event seems to allow the transfer of data into an event structure, which as far as I'm aware cannot be done with the Value(Signaling) property node.

 Sure it can!  You get both the "Old Value" and the "New Value" of the variable whose Value you changed!

However, if I am not trying to transfer any data (just trying to trigger an event), which method would be considered 'best practice'?

Invoking a Value(Signaling) Property forces the User Interface code to run (as I understand it).  If you are not doing critical processing, you might not care, but it does seem to be significantly slower than other methods.

 


Bob Schor

Message 2 of 4
(3,801 Views)

They're used for different things. Value(Signaling) is for when you need to programmatically change the value of a specific control, and it'll fire the event case associated with that control's Value Change event- exactly the same as if the user changed the value. The program cannot tell if it was a programmatic Value(Signaling) event or if the user changed something on the front panel. If you're simulating users interacting with the form, this is a simple way to do it.

 

User Events aren't for simulating button presses- they're for making an event that exists outside of a particular control. Let's say your main program has a UI loop that handles button presses and some other loop that reads a voltage. Your UI loop would have an event structure in it with various cases that fire when a user presses a button. Let's say the acquisition loop needs to somehow let the UI loop know when a threshold was passed- say, it read a value over 3 volts, so light up an LED in the user interface and change a string control to display the time. You could use a User Event to communicate from the consumer loop into the UI loop. You'd use a "Create User Event" function to make a reference to this entity called a "User Event". You'd use the Dynamic Registration terminals and the Register For Events nodes/functions outside your Event loop, and register that loop with your new User Event. You can then right click the Event Structure and add a new event for this new User Event the same way you do it with control value changes.

 

Next, you wire that same reference created by Create User Event down to your acquisition loop. It chugs along monitoring the voltage, and when it detects the voltage changes, have that loop call Generate User Event. You can send data along with it as well- it can be as simple as a True boolean or it can be a complicated LabVIEW Object or Cluster or whatever; it can be anything. Now, your upper loop had previously "registered" to listen on that User Event wire, so when a User Event was generated on that wire, the Event Structure fires the specific frame you created earlier to handle that Event.

 

The cool thing with this is that you can put the Event Generation code inside of a subVI, and wire the reference to it. Now your acquisition loop can sit there and do what it needs to do inside of a subVI, and you can plop that inside of several different user interface VI's. The acquisition loop just fires the event- it doesn't actually DO anything, it just sends an event along the registered channel.

 

Basically: if you need to simulate a user interacting with the panel, use Value(Signaling), but if you need to send some generic message to the same loop, use a User Event. I know they seem similar, but they really serve two different purposes. The name is a bit confusing- it's a "User [defined] Event" not a simulation of an event caused by the user. The "User" in the name refers to the developer, not the end user of the code.

Message 3 of 4
(3,777 Views)

User events can be helpful even if you aren't necessarily looking to transfer any data with the message. A simple use case might be that you want your event structure to do something when a queue times out. You could pass data I suppose but you wouldn't necessarily need data if your message is "This Operation Timed Out".

 

If you can't think of any great use cases for your application I wouldn't worry about it too much but if you are ever creating an indicator that you are placing off-screen and its only purpose is to provide a value change event that you can capture, know that there is a better way.

Matt J | National Instruments | CLA
0 Kudos
Message 4 of 4
(3,763 Views)