How does an AE (Action Engine) terminate

[CarmineS]

All,

I looked at an example AE for the forum. It does work.

My question is what stops the AE when it is hard coded with a Boolean (True)?

Thanks

[smercurio_fc]

The obvious answer is that logic stops it. The while condition is "stop when true". And you're wiring a True. Ergo...

An AE (aka functional global) is designed to run only once each time it's called. The AE is basically a functional global on steroids. Functional global variables were "invented" before LabVIEW had built-in global variables (i.e., before LabVIEW 3). They leverage the fact that uninitialized shift registers "remember" their contents from call to call as long as they are not unloaded. So, put a while loop that's guaranteed to run only once, and voila, you have a "functional" global variable.

[Ben]

---

@smercurio_fc wrote:

The obvious answer is that logic stops it. The while condition is "stop when true". And you're wiring a True. Ergo...

An AE (aka functional global) is designed to run only once each time it's called.

---

I'll read that as "iterate only once" which gives me the chances to pose the philosophical question;

If it iterates more than once can it still be called an AE?

I have many "THINGIES" in my application that can iterate more than once. An example is a "Safety Thingie" that will do safety checks before allow the selected operation to proceed. I implemented it inside a pseudo-AE framework to force other thread to wait while the check is completed.

Anyone care to comment on that idea?

Ben

[Yamaeda · Accepted solution]

---

@Ben wrote:

---

I'll read that as "iterate only once" which gives me the chances to pose the philosophical question;

If it iterates more than once can it still be called an AE?

I have many "THINGIES" in my application that can iterate more than once. An example is a "Safety Thingie" that will do safety checks before allow the selected operation to proceed. I implemented it inside a pseudo-AE framework to force other thread to wait while the check is completed.

Anyone care to comment on that idea?

Ben 

---

Performing a more advanced function could fall into the "Action" category, but then what differs it from a ordinary sub-vi?

1. Since AE is a FG on steroids we must deduct that some memory based on shift registers is involved

2. "Action" part means that we can have several functions (typically atleast Init, Get, Set). Nothing really limits these individual action from using loops and sub-vi's, e.g. a "Get Medians".

3. However, if these actions chain we suddenly have a State-machine!

Thus an AE must be a single run state machine with memory storage functionality. 

/Y 🙂 

[crossrulz]

I know where Ben is going with this.  I wrote many instrument drivers initially on the AE framework, but then they morphed into state machines as well.  But I still have those uninitialized shift registers to hold my references, states, limits, etc and the enum to say which action to perform.  Maybe an Action Machine?

[CarmineS]

Thank you to all that replied and the insight gained.

I first looked at the True and thought it was "continue", my mistake. But I also learned a lot more.

[Ben]

---

@CarmineS wrote:

Thank you to all that replied and the insight gained.

I first looked at the True and thought it was "continue", my mistake. But I also learned a lot more.

---

You are welcome.

Posting to forums like this one always has be wondering if I have said that before or similarly did they see that before but in the event you have not seen this yet...

I wrote a Nugget on Action Engines found here.

The follow-up conversation for that nugget was a learning experience for me. If you have seen that laready then please forgive the distraction.

Ben

[SteveChandler]

Post that link far and wide! Even if the OP did see it, there is always the lurker out there who did not. This nugget has helped more people than anybody can know and belongs in every thread that asks a question about AEs. It also belongs in many threads that do not. Of all the threads I have read, that one was by far the most useful 🙂

[Ben]

---

Steve Chandler wrote:
Post that link far and wide! Even if the OP did see it, there is always the lurker out there who did not. This nugget has helped more people than anybody can know and belongs in every thread that asks a question about AEs. It also belongs in many threads that do not. Of all the threads I have read, that one was by far the most useful 🙂

---

Thank you Steve!

You have brought tears to my eyes.

Thank you!

Ben

[johnsold]

Ben,

I like your food for thought.

I think there may be a place for an AE with OCCASIONAL need to run more than one iteration.  I would make a different distinction than Yamaeda did.  I would restrict the simple FGV to always iterate once. However, something like your "Safety Thingie" seems like a reasonable extension of the AE concept to include multiple iterations. If this is done, it needs to be clearly documented that the loop may iterate multiple times for one call of the VI, under what conditions it does so, how many iterations or how much elapsed time or what conditions will stop it, and why this is the appropriate place to do this.  As you point out this should only be used when blocking all other threads which call the AE is necessary and acceptable.

Lynn