Event Structure Triggering Questions: Local Variables, Value & Value(Signaling) Property Nodes

[BertMcMahan]

---

@rwunderl wrote:

 Every event structure in the VI will queue the events it is registered for, no matter how long ago it happened. That's why it is always the best advice to never have more than 1 event structure in a VI.

---

I disagree with your second sentence. It's good advice for those new to event structures, but it's not *always* the best advice. In fact, I very frequently use multiple event structures in a single VI with no issues. The real thing to remember is to not have more than 1 event structure in a loop. When you have multiple event structures, they need to be registered for separate things and they need to be running different loops. I've made MANY a producer-consumer programs where both the producer and the consumer loop have their own event structures that communicate with each other via user events. This method works very well.

I do agree that the OP is probably a little inexperienced to use multiple event structures well, and I *definitely* think this application shouldn't use any statically registered events.

[garretw]

GerdW,

I was using the 'Status' indicator outside of the case structure but then it wouldn't update on the front panel until after that case had been completed, so I moved it inside for more of a real-time response. Is this what you were thinking or is there a way to have it outside the case AND immediately update the front panel? 

When you say to use shift registers for variables like 'Sequence #' do you mean to add it to my existing shift register for the state machine, i.e. create a state that handles only the sequence count? OR is there a way to represent variables in shift registers somehow that I am not aware of? Just a little confused what you meant.

The LED control for the interlock is just me strong-arming what will be a physical input representing multiple safety features for now, so you're right, not very intuitive.

Your input is very helpful.

Bert,

With dynamic event registration are you suggesting my state machine stays, sort of, the same, with the event structure and the Dynamic event registration inside the case structure?

This sounds a little like QMH and I have researched that but it seemed a little over my head and the examples being used were complex.

I will experiment with this, thank you for breaking it down and explaining.

Thank you both!

[BertMcMahan]

---

@garretw wrote:

Bert,

With dynamic event registration are you suggesting my state machine stays, sort of, the same, with the event structure and the Dynamic event registration inside the case structure? I admit I haven't looked at your full code, only the pictures, but it sounds like yes.

This sounds a little like QMH and I have researched that but it seemed a little over my head and the examples being used were complex. Dynamic event registration used this way has nothing to do with a QMH. It's just "turning on" event structures one at a time, instead of the way you have it where they ALL listen for ALL events ALL the time, from the instant you hit the Start button to the end of the program. That is called "statically registering events", but in your case you explicitly want different event structures to "go live" at different points in your code. You ***cannot*** with statically registered event structures, you MUST use dynamic registering and unregistering. Again, I have only looked at the pictures you uploaded, so I could be misreading things.

I will experiment with this, thank you for breaking it down and explaining.

Thank you both!

---

[rwunderl]

---

@BertMcMahan wrote:

It's good advice for those new to event structures, but it's not *always* the best advice.

Well I am speaking to this case, where we should be suggesting to keep things as simple as possible.

@BertMcMahan wrote:

When you have multiple event structures, they need to be registered for separate things and they need to be running different loops.

These were the words I wanted to say. I do sometimes require a separate loop and event structure to detect the Panel Close? filter event if my main event handler loop is not run unconditionally. This prevents panel lock-up due to the filter event never getting a chance to execute in the main loop for some situations in those VI's.

@BertMcMahan wrote:

I've made MANY a producer-consumer programs where both the producer and the consumer loop have their own event structures that communicate with each other via user events.

Different strokes for different folks, I guess. Sounds like a mess to me. Dynamic event registration just seems too involved for this application.

Why not just do this with a classic polling-style state machine if that means it is easier to understand and debug? That was the point I was trying to make.

[garretw]

Classic polling style state machine like your 'back to basics' VI?

Similar to the simple state machine that LV provides in the 'Create Project' section?

[BertMcMahan]

---

@rwunderl wrote:

---

Different strokes for different folks, I guess. Sounds like a mess to me. Dynamic event registration just seems too involved for this application.

Why not just do this with a classic polling-style state machine if that means it is easier to understand and debug? That was the point I was trying to make.

---

I'm not sure what you mean sounds like a mess- two separate loops with user event communication is super easy and is barely more work than two queues, so it's not messy. Adding dynamic registration to THIS application is indeed a mess 🙂 I just thought it MIGHT be a way to get it working quicker than a full rewrite. I didn't look at the full code, so I don't know for sure.

And we're in total agreement on your second point- a polling state machine is a far more scalable and usable architecture for this application. I didn't mean to contradict your overall point, I was just disagreeing that multiple event structures was "always" a bad idea, as it's not a bad idea in a properly designed application. This is definitely not the case for multiple event structures.

To summarize: OP, you might be able to band-aid this with dynamic registration, but a better solution would be a rewrite using a polling timer in a state machine, as @rwunderl said much earlier. Please take my comments to him as more of a general discussion of event structures, not a specific recommendation that dynamic registration is the BEST way to go here. It just might be one way to go, though it's probably best to just make a state machine.

[rwunderl]

---

@garretw wrote:

Classic polling style state machine like your 'back to basics' VI?

Similar to the simple state machine that LV provides in the 'Create Project' section?

---

Yes, exactly. I was just trying to show how easy it could be to slap one together. I even back-saved it to LabVIEW 8.5 since it uses nothing fancy (I tried to go back further, but the Subtract primitive couldn't handle it).

OP, I would highly recommend using the Create Project button in the LabVIEW launcher or the New... option in the File menu to explore architectures and design patterns that NI already provides for you. Specifically, look in the New... VI\From Template\Frameworks\Design Patterns folder for some simple one-VI examples of common patterns. Note in the Producer/Consumer (Events) example, there's nothing preventing you from having the consumer loop enqueue events to itself.

You mentioned earlier that a QSM might be a bit over your head, but using NI's examples and sample projects makes it quite easy. And those examples all have decent documentation to help you get started. I know when I started using LabVIEW many years ago, it took me a while to find these two different sources of starting points for projects.