How does an AE (Action Engine) terminate

[DFGray]

I feel like the lone dissenter, but I really don't use action engines much any more.  I consider them part of my toolbox of tricks, but they don't scale well (adding new functions or data), so I typically use data value references with a collection of subVIs instead.  This usually gives better performance.  The real solution is not to use either, but use local shift registers and messaging architectures to embrace the dataflow (e.g. new actor framework architecture).  Data by reference breaks data flow and opens up all sorts of interesting issues.

A couple of other interesting points:

1. Feedback nodes are not necessarily faster than WHILE or FOR loop implementations of the action engine.  The LabVIEW compiler recognizes the action engine design pattern and optimizes it.  In some versions of LabVIEW the WHILE loop implementation is faster than the feedback node.
2. Action engines can be re-entrant.  This is a neat way to get a multi-instance data set.  The down side is you have to use VI server to launch and interact with the engine VI.  This is another reason I stopped using action engines.  Using the data value reference model allows trivial multi-instance data sets.

<shameless plug>

If you happen to be in Austin in October for the LabVIEW user group meeting, I plan to speak on this subject at that time.

</shameless plug>

[Ben]

---

@DFGray wrote:

I feel like the lone dissenter, but I really don't use action engines much any more.  I consider them part of my toolbox of tricks, but they don't scale well (adding new functions or data), so I typically use data value references with a collection of subVIs instead.  This usually gives better performance.  The real solution is not to use either, but use local shift registers and messaging architectures to embrace the dataflow (e.g. new actor framework architecture).  Data by reference breaks data flow and opens up all sorts of interesting issues.

...

---

When we write something, we have a target audience in mind.

If we are developing code that we or our peers are going to maintain then the more exotic code patterns can be used.

If we are developing for graduates of LV Core, LVOOP solutions can be confusing for them.

So the "Real solution" depends on the audience as much as it depends on the theory.

Ben