LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Execute order of an event trigged by other event

Solved!
Go to solution

Let's say I have an event structure with 2 events A and B. From front pannel, I set up 2 (switch not latch) booleans for each event. Inside the event B, I used the "signaling value" property on boolean A to trig the event A as needed. It works! but the problem is that event B is always executed FIRST before the event A regardless of how you arrange it (put them in the flat sequence, errors connections daisy chain, etc). How could you make the event A execute first? Note, this is the only set up that work for my application. Can't alter to other method. Is there a way?

 

0 Kudos
Message 1 of 63
(3,637 Views)

The entire event frame needs to execute before beginning another frame. Think of there being a queue of events in the background and each time the event structure executes, it will dequeue an event and execute that frame.

 


@John4191 wrote:

 

Note, this is the only set up that work for my application. Can't alter to other method. Is there a way?

 


I would be interested in why this is the case. My first thought would be to have the event enqueue an array of states for another loop to execute. That would let you enqueue the states in whatever order you want.

Matt J | National Instruments | CLA
0 Kudos
Message 2 of 63
(3,626 Views)

"I would be interested in why this is the case"

 

Well, my state machine design has several events and 2 of them are write and read.

I later discover that I must read the values first, alternate them, and then write it back to the flash. Actually, I don't want to repeat the read code in the write event therefore I use the signaling value as described. And that is the reason

0 Kudos
Message 3 of 63
(3,623 Views)

Jabcoson: Thank you for the info.

 

For my current situation, I guess that I have to repeat the read code in the write event. There's no choice. As I thought, Labview has its strong/weak points period!

0 Kudos
Message 4 of 63
(3,600 Views)

This is not a weak point of LabVIEW.  It is a weak point of your logic.

 

What triggers the Write Event?  A button press?

 

If you want the read event to trigger first, then don't do it inside the write event.  Do it before the loop starts.

 

If you need a Read then a write, why have two separate events at all?  Just have a single event that first does the read steps, then does the write steps.

 

If you need the read code in two different events, then turn it into a subVI that you then call from both events.

Message 5 of 63
(3,597 Views)

: "This is not a weak point of LabVIEW.  It is a weak point of your logic."

In general of a SW (not specifically LV) programming, once it's declared as an event, it'd fire at the way program written with no limited.

"What triggers the Write Event?  A button press?"

Yes

"If you want the read event to trigger first, then don't do it inside the write event.  Do it before the loop starts."

Why not? per your suggest, LV seems to be limited. And yes, I plan to take the 'Write' outside of event loops today... if this is not weakpoint of LV then what?

 

"If you need a Read then a write, why have two separate events at all?  Just have a single event that first does the read steps, then does the write steps."

Again, this is a weakpoint of Labview. So limited...

 

"If you need the read code in two different events, then turn it into a subVI that you then call from both events."

Yes I do have the SubVi for both w/r, how about all the parameters of subvis that needed to be converted from one form to another (Hex string->hex arrays, listbox-->strings, etc...) you know what I refer to.

 

Yes, with LV, you can correct the problems in the ways of LV logic  NOT with the USERS' logic...

 

0 Kudos
Message 6 of 63
(3,560 Views)

LabVIEW follows a pretty standard event handling methodology. That being said....

 

If you're so sure of your interpretation that it's LabVIEW which is limiting your creativeness in this regard, how about you post your code so that we can all benefit from the insight you have which we are obviously lacking. I'm always very eager to learn and expand my horizons.

Message 7 of 63
(3,557 Views)

The code shown inside the frame of the Event Structure is the event HANDLER for that event.

 

You want the event handler A to call some code B to execute before the event handler A executes, and that code B which should pre-empt the event handler A is another event handler B residing within the same thread as A?

 

I fail to see how this arrangement can pass even the most basic of logical tests.  You cannot have a piece of code call code to pre-empt itself because it can't have already called it if the other code comes first..... It's a logical impossibility unless you are thining in terms of GOTO or sub-routine calls. But those are NOT event handlers.

 

If you want a branching or asynchronous event handler, then program one.  It's not what you show in your image.

Message 8 of 63
(3,549 Views)

: "You want the event handler A to call some code B to execute before the event handler A executes, and that code B which should pre-empt the event handler A is another event handler B residing within the same thread as A?"

 

That 's limited of LV. For example, in orther text programming languages, you can change ordering by detaching all handlers, and then re-attaching in desired order using List<EventHandler> in a loop!

 

Not at all, I also said that LV has its strong points too... OK

0 Kudos
Message 9 of 63
(3,528 Views)

@John4191 wrote:

: "You want the event handler A to call some code B to execute before the event handler A executes, and that code B which should pre-empt the event handler A is another event handler B residing within the same thread as A?"

 

That 's limited of LV. For example, in orther text programming languages, you can change ordering by detaching all handlers, and then re-attaching in desired order using List<EventHandler> in a loop!

 

Not at all, I also said that LV has its strong points too... OK


Your logic is hopelessly flawed because you're not re-ordering the handlers at all, you're serialising them. You're making one handler call another. That's NOT the same thing as re-ordering them.

 

If you want to dynamically register the events and swap out the event registrations at run-time, that's totally do-able in LabVIEW and will achieve what you seem to be mentioning here. It seems your event registration requires re-ordering, not your event handlers.

 

Are you aware of the dunning-kruger effect? I don't mean to be nasty, but I don't think you're anywhere near knowledgeable enough of LabVIEW to make claims about the inherent limitations in a post like this when you apparently don't understand the basics.

 

PS I've created recursive event handlers with guaranteed event ordering over multiple branching hierarchies, so I kind of know what I'm talking about.

0 Kudos
Message 10 of 63
(3,526 Views)