Event Structure with local variables vs. data flow

[Christian_Sch]

Hello everyone,

my question is unfortunately not very specific. Normally I'm using the event structure as an interrupt handler for user inputs and/or for a state machine, while the main loop is measuring signals. In the main loop I'm using the property node value (signaling) to jump in the event structure to change the behavior of the machine. For this I'm using local variables to transfer data from the main loop to the event structure and back to the main loop. Most of the tasks in the event structure only need one or two variables, so I don't want to put all of them into a cluster, send them to the event structure and select those variables that I need for the event. For me this doesn't sound like a good resource management and I want to have my interrupts as short as possible. But I also can't wire all of the variables because than I won't see anything else.

But I also want to respect the concept of dataflow and so I came to my question

What is a good way to implement interrupts in a dataflow model?

Best regards,

Chris

[altenbach]

Too confusing for me:

• Typically, the event structure is in the main loop. You have it reversed.
• An event structure itself does not use data. Are you talking about code inside event cases?
• What are "variables"?

It would be great if you could attach a simplified code skeleton so it is more clear what you mean.

[BertMcMahan]

I think I follow what you're doing based on your description. I'd recommend flipping your thought process around. Consider your "main loop" to be the one that the user interacts with and contains the GUI, and have your other loops do your data processing and signal acquisition.

A message-based architecture is a great way to do this. I use both queues and user events to do this depending on the situation. Basically, instead of taking your variables and adjusting them in real-time on the fly, send a message to your loop saying "do this thing". For example, if you want to zero out a signal by storing the current value, then subtracting that from subsequent measurements, don't just do that thing in the event loop. Have it send a message to the loop that contains the other variables and let THAT loop decide how to handle the message.

[Christian_Sch]

Good morning,

I added a small example. The example is about charging/discharging a capacitor. The idea is to measure the voltage and if a defined voltage is reached, the machine should change the mode.

I hope it is clear and thanks for the quick response.

[Christian_Sch]

Sorry I did not followed my own rule. This example should be clearer.

[altenbach]

Sorry, did not have 2020 on my regular computer and need to sleep, so just a few quick comments:

You diagram comment is wrong. The true case only executed on a FALSE-TRUE transition, not "if there was a change". Do you want to execute if there is any change or not?

For a TRUE-FALSE transition , here's equivalent, but simpler code:

I really don't understand the value change events for the voltage. What happens in these cases? Why not put the control terminals in the lower loop instead of the locals? They are getting polled anyway. If you need the new value in the event for something else, get it from the "NewVal" event data node.

It just does not feel right. The entire architecture is like the tail wagging the dog. The event structure should focus on user interaction. Can't you just put the needed code in the case structures directly?

There are also potential race conditions. There is no hard guarantee that the locals on the left get written before the locals in the loop get read. The two LEDs are indicators so all you need to do is check the "VI properties...execution... clear indicators when called" after setting proper default values. No need to set them with locals at the start.

If you would show the digital display of the chart, you don't need that extra indicator.

Your two LEDs are 100% correlated, i.e. knowing one also fully determines the state of the other. You could even replace them with a single radiobutton control (replace the inner controls with LEDs and make it an indicator)

Here's a quick draft showing some of the ideas. Of course I don't know what elses belongs into these event cases but I think most of it can happen in the lower loop, which you spin anyway. Please verify correct operations.

[Christian_Sch]

Thanks for your comments and have a nice sleep, I'm sure we're living in different time zones.

You're right, the comment was not exact. Only on a "FALSE-TRUE transition" the event should happen and thanks for your simpler code, I'll definitely use it.

And now we came to my missunderstanding of LabView closer.  "Why not put the control terminals in the lower loop instead of the locals?" Exactly. Why? The element 'min Voltage [V]' is an object. Why should I poll a whole object in a loop if I only need one parameter? In my opinion, storing a variable in the computer memory and only change it if the user wishes to, should be much faster.

The race conditions are definitely a problem. For most of the events I can prove that the events are much faster than the data acquisition like in my example with a digitial machine. But I have a real machine in front of me. Therefore I have to respect the communication protocol and speed of it. Some of them are extremly slow and thus I want to execute them only once from time to time.

"If you would show the digital display of the chart, you don't need that extra indicator." Depends from which region you are. I prefer to have both.

In this example yes, but it is not just an boolean correlation.

However, the machine should run on their own and fortunately they do so. I just want to improve my LabView skills.

[altenbach]

---

@Christian_Sch wrote:

And now we came to my missunderstanding of LabView closer.  "Why not put the control terminals in the lower loop instead of the locals?" Exactly. Why? The element 'min Voltage [V]' is an object. Why should I poll a whole object in a loop if I only need one parameter? In my opinion, storing a variable in the computer memory and only change it if the user wishes to, should be much faster.

---

Be very careful with terminology. The word "object" has a very specific meaning in LabVIEW  and this is not it. Yes, it is a "front panel object", not quite the same. That's probably what you meant. 😉

So instead of polling the terminal of the control, you are polling a local variable of that same control. That's definitely more expensive because of additional buffers and such. Then you need to arm the event structure, etc. You are spinning the lower loop anyway, so polling can be done very inexpensively in the same swoop! Scalars are very cheap and you should never worry about them. Compared to maintaining and displaying the 1024 point history buffer of the chart, the voltage controls, LED indicators and stop button are peanuts anyway. Most computers have multiple CPU cores and the UI can be handled in parallel.

If I would remove the 100ms wait and measure the loop time, I get 400 nanoseconds, so that's all LabVIEW needs. Your loop time is 100ms, or 250000x slower! Plenty of spare time! For computers 100ms are eons! Even if your front panel was 1000x more complex, nothing would really slow down.

When I started LabVIEW there was no event structure (and no "undo"!) and polling is all we had. I had a significantly more complex LabVIEW 4.0 program running for 20 years 24/7 on a 100MHz Pentium and very little RAM and nobody ever complained about sluggishness. 😄

Yes, it was 2am when I wrote my reply above. 🙂 Also note my diagram comments about "probably needs refinement" because just toggling is insufficient to guarantee correct operations if the voltage shift register is initialized outside the range (e.g. -2V) of if the user randomly changes the limits to unreasonable values during the run. 

[Christian_Sch]

Thanks to your answer. My background is programming 8-bit µ controller and to pull something was always the worst concept. Maybe there are even worse ideas how to program something but I don't care.

It is hard to switch from a low level computer language (Assembler, C) to LabView. It seems that LabView works parallel with multi core computers, but then why I should pack everything in one loop? For me this makes no sense. I do parallel computing with massive and horrible math equations and I have to think about it, is it better to put it into the cpu or the graphic card. The concept of trusting VIs is relatively new to me. But I also have no clue about the compiler of LabView. So I started this question and I have known that getting an answer is tricky. However, in the end I want to have a clean code, that I can reuse.

By the way an example is an example. I have read many post and the people discussed about the example instead of talking about the topic. So I want to be more specific.

Is it faster to poll a front panel object than the corresponding item value?