How does an AE (Action Engine) terminate

[altenbach]

I have long eliminate the while loop from most of my action engines and I am using globally initialized feedback nodes instead.

First of all, they eliminate the disfunctional pseudo while loop, whose only function is to to act as a scaffold for shift registers. 😮

The global initialization also provides a convenient way of initialization checks, often eliminating a "first run?" primitive.

In some cases, I have retained the while loop for AEs that sometimes need to do more than one iteration. You can easily think of a scenario where in some cases several modes should be combined, and instead of calling it twice in a row, you could call it with a combo mode that executes two existing functions in a row (one per iteration) before returning. This would be an AE with a mini state machine built-in, but it is still an AE at heart. It is still "single run" from the viewpoint of the caller, but with more elegant design, eliminating duplicate code. For example if there are two states "clear A" and "clear B", we could add a state "clear all" that would sequence both in one call. This is fine as long as the loop is always finite and the AE returns quickly and without user interaction.

In addition to Yamaeda's list, AEs need to always be non-reentrant.

[Ben]

---

@altenbach wrote:

I have long eliminate the while loop from most of my action engines and I am using globally initialized feedback nodes instead.

First of all, they eliminate the disfunctional pseudo while loop, whose only function is to to act as a scaffold for shift registers. 😮

The global initialization also provides a convenient way of initialization checks, often eliminating a "first run?" primitive.

In some cases, I have retained the while loop for AEs that sometimes need to do more than one iteration. You can easily think of a scenario where in some cases several modes should be combined, and instead of calling it twice in a row, you could call it with a combo mode that executes two existing functions in a row (one per iteration) before returning. This would be an AE with a mini state machine built-in, but it is still an AE at heart. It is still "single run" from the viewpoint of the caller, but with more elegant design, eliminating duplicate code. For example if there are two states "clear A" and "clear B", we could add a state "clear all" that would sequence both in one call. This is fine as long as the loop is always finite and the AE returns quickly and without user interaction.

In addition to Yamaeda's list, AEs need to always be non-reentrant.

---

Using the While loop with SR lets me quickly adapt to the multi-iteration version if I find something while deploying the app.

In a more traditional langauge they end up being nonreentrant sub-routines that have multiple entry points.

Re:Lynn's comment that I should clearly document...

I will resist the tempation to plug the SDE again.

Ben

[Ben]

---

@johnsold wrote:

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

---

In house we do have a method of making it clear we are looking a Multi-Iteration AE (MIAE) and which action invoke multple iterations.

In the normal AE, a SINGLE constant is wired to the condition terminal.

In the MIAE version the condition terminal originates in the case structure.

Flipping through the various cases shows the False constant on actions that invoke another and of course terminal actions have a false.

Ben

[altenbach]

Not to be confused with the "Missing In Action Engine" that beginners tend to sometimes write. 🙂

[Darin.K]

---

@altenbach wrote:

I have long eliminate the while loop from most of my action engines and I am using globally initialized feedback nodes instead.

---

I have long eliminated the Shift Register from my FGV and use the globally initialized feedback nodes instead.  The While Loop can come and go as necessary.

And with the awesome feature to add FN automatically into cycles writing them is a breeze.

[Ben]

---

@Darin.K wrote:

...And with the awesome feature to add FN automatically into cycles writing them is a breeze.

---

That is "Arghhhh Option" #2 after "Auto-explode" that I shut off.

Should I be reading that as sarcasm?

You guys wearing masks are sometimes hard to size-up.

Ben

[Darin.K]

Definitely not sarcasm, more along the lines of hyperbole. As the lonesome dissenter I have to be a bit assertive. My feelings are summarized here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/quot-Auto-insert-Feedback-Node-in-cycles-quot-should-b...

[Ben]

---

@Darin.K wrote:
Definitely not sarcasm, more along the lines of hyperbole. As the lonesome dissenter I have to be a bit assertive. My feelings are summarized here:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/quot-Auto-insert-Feedback-Node-in-cycles-quot-should-b...

---

Yikes!

Well I still like you anyway.

Ben

[altenbach]

I am with Ben here, but I have "autoinsert fn" enabled, simply because I don't like to stray too far from the default settings (I mostly customize fonts and palettes).

Just yesterday during an editing session, I got a barrage of feedback nodes autoinserted that made absolutely no sense. Part of this is due to my technique to often temporarily short out wires creating multiple sources, then delete the undesired connections later. Sometimes LabVIEW sees loops and throws a burning FN in the mix, breaking even more wires. 😮 Of course two fingers are always on the ctrl+z, so no big deal. 😉

[Darin.K]

To be clear, there is a BIG difference between off and off by default. Very few things are turned on since they are effectively hidden, but annoyances are often turned off. Off by default kills this feature IMO. I feel that I have offered two very reasonable alternatives, pop up dialog that allows you to change the setting and be done with it, and to only insert the FN when wires are not broken as a result.