LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Second instance of a subvi with an event structure runs incorrectly every other time

Solved!
Go to solution

I wrote a very simple vi that displays a selected message using an event structure to react to a button on the front panel. 

 

If I write an upper level vi that calls this subvi multiple times (one case in a state machine for instance), the first instance of the subvi behaves correctly and waits for the event.  But when the second instance gets called it blasts right through as if the event had already been triggered.  Out of curiosity I put a FOR loop around the second instance and for some reason it executes properly every other time.  If I set up for four loops, it skips on 1 and 3 and runs on 2 and 4.   If you run the attached file you can watch the vi open and close very rapidly on every other run.  It is open for maybe 100 msec.

Any hints?

 

The file called Double Event Skip is the upper level vi. Any hints would be greatly appreciated.

0 Kudos
Message 1 of 9
(3,224 Views)

Could this be an issue with the mechanical action of the button?

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 2 of 9
(3,214 Views)

Hi rimfire,

 

when I change the event case settings to "block UI until event case handled" and disable the event queue manipulation your VI works as intended (I guess)…

 

@Ben: The button is set to "latch when pressed" without any key binding, so it should be ok! (But it was also the first place I checked…)

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 3 of 9
(3,212 Views)
Solution
Accepted by topic author rimfire44

The problem is that the way your code is structured, it will generate 2 events every time someone enters a data: One event for the value change of "Controls" when the input string is entered (gets triggered when key focus moves away from "Input String), and the second when a button is clicked.  Since you only process one event in your dialog box, the second event remains queued up and gets handled immediately on the next call.

"If you weren't supposed to push it, it wouldn't be a button."
Message 4 of 9
(3,199 Views)

Paul,

I need some education. I am getting a hint of what you are saying, but I didn't realize events would get buffered from call to call.  What I am confused by if that is the case, is that if I use this vi just once in seperate cases of a state machine, I haven't see the problem. Whereas if I call it multiple times in a single case, it always happens as it does in the example.  If the events are carried over, why wouldn't I see the skip occurring no matter where the vi lives?

 

0 Kudos
Message 5 of 9
(3,160 Views)

Can you provide example code of the skip not occurring?

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 6 of 9
(3,149 Views)

Paul,

Now I have egg on my face.  I built the example of what I swore was working and of course it made a liar out of me.  It is going to take some digging in stuff that "I am sure is working" and see what little detail my old grey matter is overlooking. 

 

Thanks for your help. Now I just have to figure out how to fix it. Should be interesting.  

0 Kudos
Message 7 of 9
(3,136 Views)

Just change your event case to handle value changes of the buttons instead of a value change on the entire cluster.

"If you weren't supposed to push it, it wouldn't be a button."
Message 8 of 9
(3,097 Views)

Paul already gave you the fix.  I'll give you the little detail that escaped your grey matter.  So, I change a value of Cluster.boolean How many VC Events take place?  2 Cluster.boolean changes value and Cluster changes valueSmiley Wink

 

That would thow %90 of developers the first time it happened to them


"Should be" isn't "Is" -Jay
0 Kudos
Message 9 of 9
(3,084 Views)