Community Nugget 4/08/2007 Action Engines

[jfalesi]

Action engines strike me as inside-out objects, especially when used with wrappers. In fact, in use, a wrapped-up AE is virtually indistinguishable from an object's "method VI". Should AEs be filed under "The lengths to which LV developers will go to avoid OOP"? 

[Gregory]

An action engine contains global data. An object is not necessarily global.

An action engine prevents data manipulations writing over each other. Forking an object wire does not.

[rolfk]

---

@jfalesi wrote:

Action engines strike me as inside-out objects, especially when used with wrappers. In fact, in use, a wrapped-up AE is virtually indistinguishable from an object's "method VI". Should AEs be filed under "The lengths to which LV developers will go to avoid OOP"? 

---

First an AE is usually a singleton as it uses an unitialized shift register in most cases. As such it is a very special object and one you need to go to a bit of lengths to create in LabVIEW OOP. With standard value based LabVIEW OOP it will be hard to create a singleton with.

And for not to complicated situations where a central singleton is needed, the AE is quicker to create than an OOP based class especially if you have over 25 years of LabVIEW programming experience. 

[Ben]

---

@rolfk wrote:

---

@jfalesi wrote:

Action engines strike me as inside-out objects, especially when used with wrappers. In fact, in use, a wrapped-up AE is virtually indistinguishable from an object's "method VI". Should AEs be filed under "The lengths to which LV developers will go to avoid OOP"? 

---

First an AE is usually a singleton as it uses an unitialized shift register in most cases. As such it is a very special object and one you need to go to a bit of lengths to create in LabVIEW OOP. With standard value based LabVIEW OOP it will be hard to create a singleton with.

And for not to complicated situations where a central singleton is needed, the AE is quicker to create than an OOP based class especially if you have over 25 years of LabVIEW programming experience. 

---

Excellent observation!

That was my opinion (inside out) when I first saw LVOOP.

AE's predate LVOOP so old code written after LV 5 (when LV went multi-threaded) but before LVOOP was introduced was a great way to share a single copy of a data set and allow multiple threads to act on the data.

Ben

PS: Surprised to see an 11 year old thread bubble back to the top.

[jfalesi]

---

@Ben

---

Excellent observation!

That was my opinion (inside out) when I first saw LVOOP.

AE's predate LVOOP so old code written after LV 5 (when LV went multi-threaded) but before LVOOP was introduced was a great way to share a single copy of a data set and allow multiple threads to act on the data.

Ben

PS: Surprised to see an 11 year old thread bubble back to the top.

---

Hahaha, I guess it's a matter of perspective - I learned about OO before I learned about LabVIEW. Are there use cases for AE's other than singletons and global data? Not just cases in which you CAN use AEs, but cases in which it's best-practice?

For example, is a GUI Control AE preferred over a GUI object, or vice-versa?

[Ben]

---

@jfalesi wrote:

---

@Ben

---

Excellent observation!

That was my opinion (inside out) when I first saw LVOOP.

AE's predate LVOOP so old code written after LV 5 (when LV went multi-threaded) but before LVOOP was introduced was a great way to share a single copy of a data set and allow multiple threads to act on the data.

Ben

PS: Surprised to see an 11 year old thread bubble back to the top.

---

Hahaha, I guess it's a matter of perspective - I learned about OO before I learned about LabVIEW. Are there use cases for AE's other than singletons and global data? Not just cases in which you CAN use AEs, but cases in which it's best-practice?

For example, is a GUI Control AE preferred over a GUI object, or vice-versa?

---

Now it is my turn. I will answer your question by quoting you where you wrote;

" I guess it's a matter of perspective "

My shop uses LV for a lot of applications across almost every engineering and scientific discipline. Few of the developers that work here have any exposure to LVOOP aside from what I put them through. They are a bunch of smart people but few of them are deep into LVOOP. Call us "LVOOPid" if you want. (smiley-wink).

For the most part they have accepted AE's but few have taken the deep dive into LVOOP. Those that have, have left behind some LVOOP applications that may be perfect implementations of LVOOP but to the rest of us we read the code and mutter "what were you thinking man?"

So for non-computer scientists AEs are easier to understand.

Next I find them easier to troubleshoot since there is not much guessing at which over-ride VI when single-stepping. But if you have some formal Domain diagrams of your LVOOP application then it may not be so bad.

Now as far as the "GUI Object"  goes...

I once tried to do a complete project in LVOOP bottom to top and it seemed that the closer to the GUI I got the more cumbersome the code got.

But this is not to say that we do not do any LVOOP. We have some in-house libraries that are used in most of our applications that are developed in LVOOP. If you were to look at our code your reaction may be the same as the head of GE Software engineering reviewed the State Diagrams I put together for an application I developed for him "A little Mealy, a little Moore".

Where does LVOOP out-shine AEs?

Dynamic Class instanciation.

But if you are nota familiar with the details, "God help you!" when it comes time to create an executable.

I hope that answers your question.

Ben

[jfalesi]

I have a related observation/question: Reading some of the "patterns are anti-patterns" rhetoric on LAVA (https://lavag.org/topic/11603-labview-anti-pattern-action-engines/?page=2#comment-125006) and criticisms of design patterns on wikipedia (https://en.wikipedia.org/wiki/Design_Patterns), there seems to be the sentiment out there that patterns point out deficiencies in programming languages - in the sense that if you find yourself repeating a sequence of steps to implement particular functionality, maybe the language should be able to do that sequence for you. I mention this in regard to the Actor Framework <ducks rocks, stones, GoF bobbleheads>.

It seems to me that NI recognized the recurring use of queued-event-driven state machines with consumer/producers and addressed the issue by designing a framework around them. However, mentioning OO in the presence of LV developers - let alone AF - is often met with groans, pained expressions and projectiles. So the options seem to be: (1) The traditional perspective that if you think you need some of that OO stuff, you just haven't learned enough LabVIEW tricks yet (a.k.a. "you can do anything OO-like without OO in LV"); (2) Use OO patterns like the GoF intended and be grateful that they imparted their wisdom upon the masses; (3) Use the AF because it represents the lessons learned from repeated use of design patterns. 

Is there a repository of guidance somewhere that can walk one through the architecture process to determine if one requires a non-OO LabVIEW pattern, an OO pattern or the AF? Like, maybe a decision tree flowchart type thing?

One final thought: When it comes to architecture, LabVIEW is in a sense its own worst enemy - the language makes it so easy to just "start coding" and accomplish something useful that it almost seems antithetical to step back and think about architecture. But without an architecture, complexity can overwhelm utility. Anticipating when this is likely to happen seems to be the key to whole thing.

[jfalesi]

---

@Ben

Dynamic Class instanciation.

But if you are nota familiar with the details, "God help you!" when it comes time to create an executable.

---

Thanks for the feedback. Dynamic class instantiation is the one use case that I've used objects for. I was writing an application that had to interface with a number of devices that all used the same protocol (ANT+, for what it's worth). I didn't want the code to have to know which device it was communicating with when it started. I also used objects for ANT+ API messages, because we didn't want to implement all of them - just the important ones. I figured it would be easier to add messages later if they all inherited from an abstract message class*. Then I realized that I needed parallel threads with asynchronous communication and started looking into AF. That application has been sitting on the shelf for a couple of years as other projects have flared up, but I think it was a pretty good candidate for OO/AF.

-Jamie

[Gregory]

---

@jfalesi wrote:

One final thought: When it comes to architecture, LabVIEW is in a sense its own worst enemy - the language makes it so easy to just "start coding" and accomplish something useful that it almost seems antithetical to step back and think about architecture.

---

Ain't that the truth!

[jfalesi]

---

@Gregory

---

Ain't that the truth!

---

I don't know - I'm long on opinions and short on experience!