Execute order of an event trigged by other event

[John4191]

Example attached!

[altenbach]

---

@John4191 wrote:

Example attached!

---

No, that's just a useless flat image. We cannot run it, we cannot see what's in the other cases, and you even have a popup covering a diagram constant. There are hidden wires everywhere. You don't even show the "write" or "read" events triggered by the signaling properties. In general, burying an event structure inside a case structure is asking for trouble because the event can only fire if the case is correct. How do you guarantee that at all times?

Looking at it once more, your two while loops have different magnification, so these are not parallel while loops, but just different views of the same while loop. Again, if the events should fire immediately, the event structure needs to be in a parallel structure, ready to fire. Currently, they execute in the queued order once the "user event" state is reached. (It is a really bad idea to randomly name something "user event", because that term has a very specific meaning in LabVIEW, and this is not it)

Can you attach the VI instead? How do you determine in what order things actually execute?

[mcduff · Accepted solution]

Think of events as triggers, once one occurs, it is hard to insert something before it.

Another way is a FIFO buffer, once in the queue you cannot change order.

That being said, you can create User Events which are not attached to the Front Panel; these type of Events you can add to the back of the queue or the front. (It is the priority input)

You can also flush the event queue and remove events using the Flush Event Queue primitive. So there is some control over Events.

UI events, like button pushes, are an unique event to consider. Think about what you are asking. I press button B then button A; but I want it to appear that I pressed button A first then button B. The UI logic seems strange. A person pressing button B expects B to occur before A.

I think the issue is terminology. Think of LabVIEW events as triggers to do something, not states.

Cheers,

mcduff

[John4191]

@altenbach: I think it's very clear!. Sorry, you could wait...

😞

[John4191]

@mcduff: I got it and thank you. Again, you're the most reasonable one around here. LV was so confused for these cases! What a Logic!

[Mancho00]

---

@John4191 wrote:

@altenbach: I think it's very clear!. Sorry, you could wait...

😞

---

I think I understand your confusion.  The Val(Sgnl) is not executing last. It does exactly what it is supposed to.  It is setting the value of the control/indicator and sending a value change signal to any event structures registered to the event.  But the way you have it organized, your event structure will only react to events when you get to your 'user event' state.  Since you only enter that state after your 'transmit' state, that is when it will respond to exactly one event until the next time it enters that state.

[mcduff]

On last thing that I forgot to mention.

Note sure what version of LabVIEW you are using, but current versions have a tool called "Event Inspector Window"; it is located under the View Option in the menu bar.

So if you have that tool running when your VI is running you can create a log of Events so you can view how your Events are Fired and at what time they occur; it is a useful tool for debugging.

mcduff

[John4191]

@Mancho00: tx_event(button)--->transmit(case)-->go back and wait for event. Got it?

[Ben]

---

@John4191 wrote:

@mcduff: I got it and thank you. Again, you're the most reasonable one around here. LV was so confused for these cases! What a Logic!

---

Some of the reaction you are getting is  because knocking LV on this forum is like telling someone their "mother wears army boots".

You can do what you want but just not the way you have tried to do it.

First I suggest you watch the code in execution highlighting mode (turn on the light bulb) to see what happens in what order.

With your existing code you are firing (triggering) the event when the ValSignaliing node executes but sine the evnt you are triggering is in a different case of the single event structure, the triggered event can not be handled until you have completed all of the action in the current event.

You can do what you are trying IF

You create a separate loop for each type of event you want to fire and have an event structure in each of those separate loops.

With each loop having a single event and doing nothing else they will be free to handle the vents as you fire them off.

Again watch the diagram in execution highlighting to see that you can fire any event in any order.

What you have taken to be short-coming of LabVIEW and the data flow paradigm is in fact its strength. Once you grasp how to structure a LV program you will find that it takes care of the tedious work of ordering operations and it will schedule code to run based on dataflow.

So the code you have shown us glimpses of is actually artificially handicapping LV. You have tied the two back legs of a horse together and are judging it based on how it runs.

Again try;

One loop to fire events.

One loop for each event that you want to fire in parallel.

Give it a try, it will work.

Ben 

[altenbach]

Here is a simple example (LabVIEW 2012) that shows my suggestion of using a separate event structure. Things execute in proper order, even if all things are very fast. (Some tweaks might be required for a bulletproof version, but that should get you started). Note that a signaling property also works with indicators and fires even if the new value is the same)

(Still, there are probably better ways to do that. ;))