Community Nugget 4/08/2007 Action Engines

[billko]

---

@Gregory wrote:

---

@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!

---

SOLID programming optional.

[crossrulz]

---

@jfalesi wrote:

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. 

---

Actually, Stephen Loftus-Mercer and Allen Smith saw a recurring pattern during a code review and the went the OOP extreme with it.  Stephen then made the AF in his own time and eventually convinced his management to include it in LabVIEW.

---

@jfalesi wrote:

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?

---

The problem with that is that every situation is unique and you won't get people to agree on even more than 60% of the cases.  It just takes experience to know what works well in a situation for your particular team and abilities.

Now for my HAL, I am using an AE to hold my objects.  This makes it simple when used with TestStand since I can just supply a lookup string and the AE finds my exact object.  TS never sees an object since it can't handle the dynamic dispatch directly.  So, AEs and OOP can mix.

[crossrulz]

---

@billko wrote:

Ain't that the truth!

---

SOLID programming optional.

---

*rolling eyes and shaking head*
 

[rolfk]

---

@billko wrote:

---

@Gregory

---

SOLID programming optional.

---

You guys need to stop right now! 

You just gave NI marketing a new slogan besides "No programming needed!"

[Ben]

---

@crossrulz wrote:

---

@jfalesi wrote:

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. 

---

Actually, Stephen Loftus-Mercer and Allen Smith saw a recurring pattern during a code review and the went the OOP extreme with it.  Stephen then made the AF in his own time and eventually convinced his management to include it in LabVIEW.

...

---

While I am sure I was not alone but I did submit a project that I had developed because of a bug that was my version of an "Active Object" since there was no such thing in LV. That code will not longer run in LV since I did some stuff that was never expected and it had to be stopped. I used a different approach than what was used in the AF because I did not want the top-down-up messaging. But that was just me fumbling around in the early days of LVOOP.

---

@crossrulz wrote:

---

@jfalesi... 

---

@jfalesi wrote:

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?

---

...

---

In a documented form?

Not that I am aware of at this time. I make a living doing that for my place.

Re Design

I wrote a bit about design in this thread and offered some example designs.

Re: OOP or not

Years ago I decided that OOP was like jazz. Variations on a theme. From what I can gather reading from a lot of the LabVIEW Champions is that if you work in a shop that is working on the same product for years, LVOOP fits well since you can build on the previous classes. If however you work in a shop like mine where every project is different and the terms and conditions of the contract dictates the customer own the rights to all of the code produced, etc. (typically military and fortune 500 companies) then the wind-up of LVOOP drives up costs and can complicate a straight forward solution.

So I am back to "It depends".

Ben
 

[Chris_Cilino]

---

@crossrulz

 The problem with that is that every situation is unique and you won't get people to agree on even more than 60% of the cases.  It just takes experience to know what works well in a situation for your particular team and abilities.

Couldn't agree more with you! I've found that approaching a problem by first identifying requirements and then selecting the tool with the corresponding capabilities has solved many problems for me. We have many tools in our tool belts as software developers and LabVIEW programmers. AEs and OOP are a good example of two tools. Knowing the capabilities, advantages and disadvantages of each helps us to match the tool to the job. I wonder if it wouldn't be helpful to start a documents like:

Action Engines

Capabilities (objectively what does "it" do):

1. Protect data interactions through encapsulation
2. Follows a singleton pattern
3. Enables global access to the data through an API.

Strengths (careful... a strength in one application of the tool may be a weakness in another application of the same tool)

1. Uses elementary syntax to implement the solution (uninitialized shift register, non-reentrant VI)
2. Presents "tasks to accomplish" using a data set vs procedural execution on disorganized data.
3. Couples the data to the actions

Disadvantages (careful... a weakness in one application of the tool may be a strength in another application of the same tool)

1. Slightly cryptic \ non intuitive syntax (uninitialized shift register means what? You wouldn't know unless you tried it \ read about it)
2. No native "Access Scope" to the data.

Common Comparisons

 AE vs LVOOP

[a table comparing capabilities]

AE vs LVOOP wrapped in DVR

[table comparing capabilities]

AE vs Global Variables

[table comparing capabilities]

I would love to see us, as a community, create and maintain a series of documents for common tools and patterns, where we discuss capabilities, advantages and disadvantages. 

Would this sort of community documentation be generally helpful?

What sorts of tools \ patterns do you think would have the highest ROI to discuss and document? (in other words where do we begin)

I would love to see documentation on the DQMH, Actor Framework, Queued Message Handler, State Machine, Global Variables, Local Variables, LVOOP

PS. There's I think this presentation is capturing some of what I'm intending to convey: https://www.ieee.li/pdf/viewgraphs/labview_design_patterns.pdf

[Ben]

I like that idea Chris.

Please let me split a hair and offer some more thoughts.

In a blog I contribute to found here ...

I wrote about exploiting LV libraries to wrap-up Action Engines in this blog entry. I included a table like the one you suggested.

Now time to "split hairs"

NONE of my AE's use shift registers anymore. Feed back nodes and a case structure.

Ben

[Chris_Cilino]

---

@Ben

In a blog I contribute to found here ...

---

Perfect! I'd love to consolidate "G Wisdom", similar to what you've shown into a central repository of sorts so that anyone out there would "obviously" go to the "one repository to rule them all" for major questions like the ones we are discussion in this thread. I love the diversity of knowledge and experience of our LabVIEW community. However, sometimes it feels like we need more structure for major topics so that we don't all write variations of the same material over and over. There's a lot of great info "out there" but finding it can be super hard and sometimes the data feels "contradictory". 

Thanks so much for pointing me to that website!

[rolfk]

---

@Ben wrote:

NONE of my AE's use shift registers anymore. Feed back nodes and a case structure. 

---

Feedback nodes or uninitialized shift registers is really just an optical difference for the most part. Yes, Feedback nodes offer in recent LabVIEW versions more options in how to initialize them but other than that they are the same as a shift register in a loop set to only execute once.

When Feedback notes were first added they were substantially less performant than a shift register since the guy who implemented them did implement them mostly from ground up again without the various performance improvements that shift registers had gained over the years. This was remedied in the next LabVIEW version by basically using exactly the same code generation under the surface than what already existed for shift registers. For LabVIEW both are really the same thing! 

[jfalesi]

---

@rolfk

When Feedback notes were first added they were substantially less performant than a shift register since the guy who implemented them did implement them mostly from ground up again without the various performance improvements that shift registers had gained over the years. This was remedied in the next LabVIEW version by basically using exactly the same code generation under the surface than what already existed for shift registers. For LabVIEW both are really the same thing! 

---

Rolf,

I'm curious about (1) why the guy who developed feedback nodes did it that way, and (2) how you know this!