Clearing Event Sequence Triggers / Queue

[NToombes]

Hiya

yeah, not nice I know but the problem with value change is the fact that the depress action is stored as well and then executed on the next time the software resets and starts again. 

[johntrich1971]

---

@NToombes wrote:

Hi John

Yes, thats why I changed it to a "Mouse Down", I remember now as the false to true action is logged for that iteration of the process but then when it gets back to the same point in the software again the true to false change is also logged.

I need to somehow get the code onto here to upload as its on a standalone machine in LV20 and this machine only has 19 on it, I have attached an image of the screen though, not that i guess its much help.

I am just looking for a solution that waits for a button press and then ignores that button again until its awaiting it to be depressed again.

Neil

---

So are you saying that you're not using a latching action on your Start button? With a latching action there is only one event - there's not an event for when it changes back.  Set it to a latching action. Use a Value Change event. Inside the Event structure disable the Start button. Enable the Start button when you're ready to start waiting for the Start button again. The user should not have to turn the Start button on and then off. 

[NToombes]

Hi

I think I am using a non latching action button from what I remember, but fully understand what you are saying.

I will do the enable/disable suggestions you suggested, sounds like a good solution, thankyou. Will give it a try later when the system is free and report baack.

Thankyou

Neil

[LLindenbauer]

---

I am just looking for a solution that waits for a button press and then ignores that button again until its awaiting it to be depressed again.

Neil

---

Hello!

This all sounds like You are making life hard on Yourself by working "against the grain". Event structures really work best when they sit inside a while loop, routing time critial events to somewhere else. It seems that You want the button event to react differently, depending on the state of the machine - if it is off, start it. If it is already running, ignore the button.

So a possible solution would be to turn Your architecture inside out: Put a case structure inside the event and check if the machine is already on, then act on this information.

If this is not possible and You must use this structure, then a "User Event" might be the way to go. You can wire the button to a user event registration, which you then wire into the user event of your event structure. Inside the event structure, You catch the user event and immediately deregister the event registration when the event occurs. I have not tried this myself, but am very confident that this also clears the queue for this particular registration. However, this feels very much like working against the tools instead of the way they work best.

Best, Leo

[johntrich1971]

---

@LLindenbauer wrote:

---

I am just looking for a solution that waits for a button press and then ignores that button again until its awaiting it to be depressed again.

Neil

---

Hello!

This all sounds like You are making life hard on Yourself by working "against the grain". Event structures really work best when they sit inside a while loop, routing time critial events to somewhere else. It seems that You want the button event to react differently, depending on the state of the machine - if it is off, start it. If it is already running, ignore the button.

So a possible solution would be to turn Your architecture inside out: Put a case structure inside the event and check if the machine is already on, then act on this information.

If this is not possible and You must use this structure, then a "User Event" might be the way to go. You can wire the button to a user event registration, which you then wire into the user event of your event structure. Inside the event structure, You catch the user event and immediately deregister the event registration when the event occurs. I have not tried this myself, but am very confident that this also clears the queue for this particular registration. However, this feels very much like working against the tools instead of the way they work best.

Best, Leo

---

What you are saying does not at all match up to the problem as stated. The problem is that if the button is pressed twice then a new event is queued up. The event structure is not reached while the event is running, but if the button is pressed another event is queued up. He just needs to prevent a new event from being queued up until he is ready for a new event. I agree that his structure is a bit unusual, but from what I've seen there is no reason that it shouldn't work.

[NToombes]

Hi

Thanks for al the advice guys, Ok, maybe I should ask differently and I am by no means dismissing anyone suggestions.

How would you guys and girls solve this issue, want a button press to start a process and that button press to only be "active" when awaiting for it to be pressed.

[johntrich1971]

---

@NToombes wrote:

Hi

Thanks for al the advice guys, Ok, maybe I should ask differently and I am by no means dismissing anyone suggestions.

How would you guys and girls solve this issue, want a button press to start a process and that button press to only be "active" when awaiting for it to be pressed.

---

That depends on a LOT of factors. I would likely have a queued message handler structure and would enable/disable buttons as appropriate. I think that your design will work fine as long as you enable/disable your buttons as previously discussed, but it is a less scalable approach.

[LLindenbauer]

---

@NToombes wrote:

Hi

Thanks for al the advice guys, Ok, maybe I should ask differently and I am by no means dismissing anyone suggestions.

How would you guys and girls solve this issue, want a button press to start a process and that button press to only be "active" when awaiting for it to be pressed.

---

Hello!

I appreciate the rephrasing of the question and will try to rephrase my previous post.

The description of what the program should do (react differently to user input dependent on the state of the thing/pump/device) calls out for a mechanism to keep track of the state of the thing, so that user input is interpreted correctly. All architectures I am aware of that provide such a mechanism out-of-the-box put the event structure on the outside. Such an architecture would receive both clicks as soon as they happen and then immediately discard the second one as invalid input for the state the thing is currently in.

Changing the architecture of a program that is already in use is a daunting task at best. It may even be impossible depending on Your requirements. If this is the case and You are looking for a quick solution, I would recommend trying to dyamically register and deregister the event, such as described here: https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/dynamic_register_event/

I do not have access to LabVIEW right now to provide code, but the process would be like this: In the screenshot provided in this post:

• Put the "Start" button outside the event structure
• Wire the button as a source for Register for Events
• Select your preferred mouse event in the drop-down menu for the event source (it is up to your taste. "Value Changed" should work just fine)
• Display the dynamic event input (see item 3 in the description of the event structure)
• Connect RfE node to the dynamic event input of the event structure
• Configure the evnt structure to listen for the selected event as described here
• Connect an Unregister for Events structure to the dynamic event output of the event structure

The complete structure then should look like the example here: https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/dynamic_register_event/

The UfE description says that

---

"Event structures that use this event registration refnum no longer receive any dynamic events."

---

I would thus expect Your new dynamic event to function like this:

• Your program enters the "Wait for Start"-State
  • The Start button is registered as an event
  • The event structure begins to listen for this event
• The Start button is pressed
  • The event structure receives the associated event and executed the contained code.
  • The Start button is pressed again while the event structure executes the contained code
  • The event structure completes its execution
  • The button event stays in the event queue of the event structure
    
  • The dynamic event is deregistered. The button will no longer create events when pressed
  • The event queue is destroyed and the still queued button event with it
• During the rest of the execution, the Start button is pressed again while the button is not registered for events. No events are created.
• Your program enters the "Wait for Start"-State again, as from the top, without lingering button presses.

Trying out this fix should be reasonably quick. However, while saving You the rewrite for now, the underlying architecture might still brook improvement. That all being said, depending on the requirements, a polling solution will get the trick done as well.

Best, Leopold

[NToombes]

Hi

Wow, thankyou so much for your time on this one, its appreciated! I am away on holiday from today so I dont want to make any changes today incase there are other issues and they wont be able to use it whilst I am away or I will have to return from holiday.

Fully understand your solution though, register for events is something I have never played with but hey, its all a learning curve.

Seems mad its so complicated just to wait for a button press, maybe the event structure needs a way to not have a queue of events as such, just act the once and then ignore any further presses / no queue and only listen once the event is "active"again.

Will definatly look at implementing your solution though.

Neil

[drjdpowell]

I did not read the whole thread, but disabling the button inside the Value Change event will prevent a second Value Change (assuming the event case is set to "lock front panel", which it is by default).  It won't stop Mouse Down, but why would you be using Mouse Down for a simple button.