Successive run - Event Structure

[dan07]

Hello...

I have a simple question. Sometimes we want to use Event Structure and put only a piece of the code in each case. The problem is that a case might have only math code, without any control, indicator or array. Because of this, this case will not have any "thing" that can trigger its execution. 

To avoid this and allow me to control in arbitrary form the execution of the cases, I created a simple code where I can specify which case will be runned after a especific case.

Attached there is a example just to show how it works.

My question, is there a better way to do this?. I mean, specify that after one specific case runs, another specific case will run.

Thanks in advance.

Dan07

[AdnanZ]

When you want to include events that don’t occur on the front panel, you will need to register a dynamic event. Using dynamic events will allow your Event Structure to react to code happening anywhere on your block diagram. Have a look at:

labview\examples\general\dynamicevents.llb

---

My question, is there a better way to do this?. I mean, specify that after one specific case runs, another specific case will run.

Thanks in advance.

Dan07

---

I know you have posted an example VI which might not be what you are trying to do, but in your VI, you can create a notifier to trigger off a state machine.

Message Edited by Adnan Z on 02-14-2009 01:07 PM

[jdpowell]

That's what I do, have an event trigger other events through Value(signaling) property nodes. If necessary I make a boolean control used just for triggering the next event.

-- James

BTW, your example seems unnecessarily complicated; what's the shift register for, for example? 

[dan07]

jdpowell...

You are right about the shift register. I removed the shift register from the cases and the code is working very well. I think that the easiest way to trigger a specific case after a specific case, is using hidden booleans and use the property node (signaling).Thanks for your sugestion with the shift register.

Take a look on the new code attached.

Dan07

Message Edited by dan07 on 02-14-2009 11:46 AM

[dan07]

Adnan Z....

I took a look on the example, it is very interesting but I think that using hidden booleans and use property nodes (signaling) its easiest to do this. What do you thing, I need to implement state machines or use the hidden booleans?

In another reply I attached a new code with some modifications.

Thanks

Dan07

[jdpowell]

How about this as a simpler version with no hidden booleans. I use your indicator booleans to trigger the events.

-- James

[dan07]

jdpowell....

Your idea is good, but in my real code I don't have these indicator booleans. I just added them to this example to show that the successive cases are running one after another.

I think that I will use the booleans hidden to trigger the cases. I don't know too much about state machines, but this mechanism that I am using I think that it is much more simple to use. What dou you think?

Thanks

Dan07 

Message Edited by dan07 on 02-14-2009 03:00 PM

[Jarrod_S.]

There are various problems with trying to use the event structure itself to be the case selector for a state machine:

• You can't guarantee that cases will execute in a particular order, because other registered events could fire during a sequence and interrupt the intended chain of events. For instance, if a user presses a button while the event structure is in a sequence where it triggers itself repeatedly.
• It takes a lot of effort to create these hidden controls that only exist to fire value change events. And it makes the code confusing because they serve no real purpose. Yes, User Events are the preferred solution to this problem, even if they require more wiring and control, but they don't solve the first problem in the list.

A better solution might be something along the lines of a Queued State Machine architecture. It's a mix inside one loop of an event structure and an outer case structure. It's a little difficult to explain in words, but there's a good template free to download from JKISoftware that also has a tutorial video about it that you can learn more about here. I've recommended this before, but I promise I don't work for them or anything 🙂 It's just good technology and a lot of thought has gone into it. JKI didn't invent the paradigm, but they've implemented it pretty it well.

It seems to solve a lot of the problems you have. It allows for user interaction through the event structure, and it allows you to trigger a sequence of cases not related to controls or indicators that have events registered for them. And it solves the two problems listed above. The architecture is inherintly self-documenting and clear, and it avoids the pitfall of allowing user interaction to unintendedly interrupt import sequences of events.  The downside is that it's not the simplest of architectures, but it's also not the most complex. Check it out!