Event structure: Problem with data transfer

[michaelboiger91]

Hello everybody,

since three days i'm troubleshooting a problem in LabView with event structures. I really hope someone can help here, as i didn't find anything on the whole WWW.

I got six equal input clusters in a VI, each containing five enum controls (among others) where the user can specify some measurement config data. What i want the program to do is: to recognize if any of those enum values has been changed, and if yes, then submit the values of the containing cluster into a sub-vi which then calculates wiring and assigns hardware ports. Also, i need to submit the number of the enum element that was last modified, so the program is able to clear user inputs in case of a violation (e.g. if the user sets two counter inputs to enum control 1 and 2 of cluster 1, and then tries to set a third counter input at port 3, the program displays a message and clears the third input as the number of counter inputs is restricted to 2 per cluster).

To solve this, i used an event structure with 6x5 cases (cluster 1 enum 1 value change, cluster 1 enum 2 value change .... and so on until cluster 6 enum 5 value change). 

The problem is, that if the user changes a value, the event structure reacts and executes the correct case; however the VALUES of the cluster the user changed are only submitted the SECOND time an event occurs. This is some kind of a "n-1" situation. For example, if all five enum controls of cluster 1 are "Disabled" first, and the User sets enum 3 to "Counter Input", the event structure executes but submits the previous values to the SubVI (all enums "Disabled"). When the user does the second change, let's say switch enum 1 to "Analog Input", the event structure executes again and passes the values of the FIRST user modification towards the SubVI, so then the SubVI gets the data data "enum 3 counter input and all other enums disabled".

In easier words: If i have new values on my cluster "Kanal 1" (left side of screenshot) and execute the event structure, at the right side at "Kanal 1 indicator" i get the previous (n-1) values.

My event structure is in a while loop. If i create a timeout each 10 ms, and a loop waiting time of 250 ms, i got a chance of 80% that the recent changes are transferred to the SubVI correctly, in the other cases i have a delay of 1 step as mentioned above. It seems to be directly depending on the time i specify the while loop to wait - however i can't explain this, and i neither can accept a chance lower than 100% to transfer the correct data, nor can i accept waiting times of several seconds for each loop run. If i indicate timeout -1 (infinite) i get the values delayed by 1 step in every case.

When i specify event cases to react on "all elements value change" the event structure behaves correctly - but then i can't manage to indicate which element has been changed last, as the CtlRef output in the event structure does not specify "enum 1, enum 2..." but only "cluster 1".

Does anybody have a solution to this? This is definitely a problem with the event structure, but i can't figure out what to change.

Thank you so much in advance,

M. Boiger

[RavensFan · Accepted solution]

It's because the terminal is read before the event structure executes.   Terminal is read, event structure waits for an event.  The value change occurs.  The event case runs, but the value coming in is the old value.

Put the terminal inside of the event case.

Or, you can show the connector called "New Value" on the left side (stretch down the border of the "CtrRef" node).  Use a wire coming from that.

[michaelboiger91]

Hello,

I would never had thought about that the event structure might read and buffer those values until an event occurs, i thought the values were grabbed only upon execution. This also explains why the combination of timeout and loop waiting time led to different results as the structure sometimes could not execute before the new parameters were set.

As i need to transfer the whole cluster data, and not just the "NewVal" element, i used a PropertyNode > Value element for each cluster inside of the event structure to read the values exactly when i need them. This works fine, apart from having lots of elements, but for that, one can use the "Duplicate Case" function.

Thank you very much for your quick and precise answer. I hope that this thread will help others, too.

Greetings,

[Norbert_B]

Learn using shift registers. That code you display is not well designed. GET RID OF THESE PROPERTY NODES!

And learn that you can use the same event case for multiple events!

Norbert

[crossrulz]

DO NOT USE THE VALUE PROPERTY NODE!!! (yes, I am yelling there)

Why not just move the terimal to be inside of the event case?  If that is not an option, use a local variable.  Property Nodes are 1000+ times SLOWER than a local variable with all of the same issues.

[michaelboiger91]

Hello,

i got six clusters, and about 40 event cases - if i placed the terminals themselves inside the event cases, i would get, let's say, 6x40 input clusters..? Or have i misunderstood something here?

When i was being introduced to LabView i was told that using property nodes / references is faster because the memory where the variable / data is stored is directly adressed. I was told to use as few local/global variables as possible because they need to be polled upon access, and multiple write commands from different sources can cause wrong data. This is also what i read in a reference book. I'm quite new to LabView, and only learning by doing right now.

Actually i know what a shift register is and how to utilize it - but i can't imagine what i should do with it in here, or how this would help to speed up the program. And i definitely know that i can use an event for multiple things - but i definitely got to know what element has been changed last by the user INSIDE of that specific cluster, and with an event not heritating from specific enum control change, i can't manage to get this information. So no "All Elements value change" is possible here.

In this part of my software it does not really matter how fast the program executes as it is just a setup procedure initiated by the user (and while it is running the user is the only one the program waits for, no important background processes until this VI has finished its operation).

However, maybe it's time to figure out which procedure is faster (local variables or property nodes). I'll gonna check that and use the best solution for the VIs with more critical timing expectations.

Thanks for your stimulus,

[natasftw]

---

michaelboiger91 wrote: 

Thank you very much for your quick and precise answer. I hope that this thread will help others, too.

Greetings,

---

I hope nobody will ever see this thread and copy that behavior.  Out of all the ways to interpret the advice you were given, "create property nodes" wasn't one of them.  They're slower.  They're pointless.  You've created a graveyard of terminals just sitting there unwired.  You've hidden the new value node on the event structure.

Why?

[Norbert_B]

---

@michaelboiger91 wrote:
[...]

However, maybe it's time to figure out which procedure is faster. I'll gonna check that and use the best solution for the VIs with more critical timing expectations.

---

As i said: use shift registers for unmodified data, terminal for reading modified data. Also note that the event structure provides you with old AND new data in its event data node.

So there is 0.0000% reason to use any property node or variable.....

Norbert

[crossrulz]

---

@michaelboiger91 wrote:

When i was being introduced to LabView i was told that using property nodes / references is faster because the memory where the variable / data is stored is directly adressed.

---

You were lied to on every level here.  Getting the value from a property nodes still makes a copy of the data, just like with a Local Variable.  Like I said before, the Value Property Node has ALL of the disadvantages of a Local Variable (race conditions, memory copy, etc) plus the property node forces a thread swap to the UI thread and forces the panel to be redrawn (which is a very expensive thing).

---

michaelboiger91 wrote: I was told to use as few local/global variables as possible because they need to be polled upon access, and multiple write commands from different sources can cause wrong data. This is also what i read in a reference book.

---

The idea here is to use DATA FLOW.  Avoiding Local/Global Variables does not mean to use Property Nodes instead.  Use wires whenever possible.

[RavensFan]

The event structure also provides you with the Control Reference of which ever control fired the event case.  That is what comes out of the CtlRef node.  You can just wire that into your subVI and you don't need the Control Reference constants in the event case at all.