LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Community Nugget 4/08/2007 Action Engines

Solved!
Go to solution


@jarrod S. wrote:
It seems to me the entire FG would constitute a class, since a class is not only stored data but the functions that operate on that data. The cluster in the USR is your private data, since it obviously can't be accessed outside the FG without accessor methods.

It depends on the use case. There is no one single answer or solution to this question. FG and AE are just means to achieve something. The actual use case defines how they can or should be used. In object-oriented programming there is a concept called design patterns. Design patterns are standard ways to solving problems of particular types. Even if the same programming technique are used in two design patterns the patterns are distinct if the underlying problem to solve is different. I think functional globals and action engines are there programming techniques. There is not standard way to use techniques pre se. There may be or rather may evolve standard ways to use action engines and functional globals to solve object-oriented programming problems of particular types. But then the technique to be used should be selected based on the problem to be solved. In some problems an entire class can be wrapped around an action engine. In some other problems action engines can be used just like you are using them now. Everything is possible and the problem to solve should determine the solution to use. What I'm trying to say that there are many ways to use each technique and there are no right or wrong ways just different ways that suit to different problems.

Tomi
--
Tomi Maila
Message 21 of 161
(10,862 Views)

Tomi wrote "The easiest way would be to follow my blog for some time. "

Why do I sense this reply is similar to the exchange:

----------------------------------------------------------------------------------------------------------------

Q: So what is so great about getting a tatoo?

A: That is a really hard question to answer, but if you try it you will understand. Smiley Mad

______________________________________________________________________

 

I hope LVOOP is really worth the pain.  Smiley Wink

Ben

Message Edited by Ben on 04-09-2007 01:53 PM

Message Edited by Ben on 04-09-2007 01:54 PM

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 22 of 161
(10,841 Views)

Why do I sense this reply is similar to the exchange:

----------------------------------------------------------------------------------------------------------------

Q: So what is so great about getting a tatoo?

A: That is a really hard question to answer, but if you try it you will understand. Smiley Mad
___________________________________________________________________


Perhaps it's just my inability to compress the required mindset to few sentences. I however think a more appropriate comparison would be the following:

Q: So what is so great about programming with LabVIEW?
A: That is really hard question to answer, but if you try it you will undestand. 😉

Tomi
--
Tomi Maila
Message 23 of 161
(10,808 Views)


I hope LVOOP is really worth the pain.  Smiley Wink



OOP has a proven track record among other programming languages but LVOOP is different in many respects from these other object-oreinted programming languages and the answer to your question remains to be seen.
--
Tomi Maila
Message 24 of 161
(10,803 Views)

Ben,

Nice one!  Thanks for taking the time to put this together.  For some dumb reason I never considered the sub-vi part. 

This almost makes up for the "disregard".  Smiley Very Happy

Message 25 of 161
(10,773 Views)
Aristos,
 
I am reading and will continue to read.
 
Everyone,
 
I am glad y'all are bringing up performance. AEs (when properly implemented) can work in-place for many operations. Since the USR's buffer can can be our "working data space" AEs can burn! Unfortunately I thought AE performance tips and techniques was beyond the scope of this Nugget. Smiley Sad
 
ohiofudu, Matt, others,
 
Thank you!
 
Kevin,
 
Exactly!
 
Anyone out there want to post an example of how to use the first call to force an init of an AE and then perfoming the selected action? Smiley Happy
 
Lynn,
 
That method is great for tracking a change. When ever a check queue status combined with ared does not fit the bill, an AE of the type you mentioned can be used AND add reciept confirmation while you are at it.
 
DF,
 
"If I have a chance, I will code it up and post it. "
 
OH yes please do.
 
Jarrod,
 
You were starting to make sense until ...
 
centerbolt,
 
The disregard thread was my first attempt at starting this thread. I could not post the entire Nugget in one post so I had to stop and rethink the format.
 
"Sometimes you get the bear and sometimes the bear gets you."
 
Ben
 
 
 
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 26 of 161
(10,172 Views)

I guess the desingnation "Action Engine" will stick around as an official term. We should formulate a simple glossary entry that describes the core concept in as few words as possible.


@Ben wrote:
"Sometimes you get the bear and sometimes the bear gets you."

Hey, now even you icon makes sense! 😄 (Fortunately a teddy is not a grizzly.) 😮
0 Kudos
Message 27 of 161
(10,148 Views)
Nice nugget Ben,

Data hiding, standard interface, loose coupling, tight cohesion.

All typical characteristics of component programming.

Personally, I tend much more towards component programming than to object-oriented programming.  Never did really understand the fuss about OOP myself.  Re-usable code can be made in so many different ways.  The introduction of a specific interface with hidden data (compartmentalisation) also makes it easy possible to use distributed systems (seperate CPUs, even seperate computers on a network) to work on certain code.

I've been working more and more in this direction in the last time.  Powerful stuff.

Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
Message 28 of 161
(10,126 Views)


All typical characteristics of component programming.

Personally, I tend much more towards component programming than to object-oriented programming. 

OOP and component programming can coexist and even often do coexist. Indeed OOP provides a way to implements components in a clean way.
--
Tomi Maila
Message 29 of 161
(10,137 Views)
Of course they can co-exist.  Many of the principles defining OOP are present in Component programming (abstraction through interfaces, data hiding and so on).

Some things don't translate well, such as inheritance.  I personally find inheritance an unneccessarily complex way to describe simple code re-use.

They are two different approaches to a problem.  They do not need to co-exist.  Components can be fully non-OOP, and OOP can be fully non component based.

I have to admit that my lack of formal programming training leads me to believe I may be missing some important points, but for me they are two separate approaches.

"Indeed OOP provides a way to implements components in a clean way".  Without wanting to be provocative, "clean" is a point of view.  If I have trouble understanding OOP, an OOP implementation doesn't seem "clean" to me.  I think it's important to make clear that OOP isn't the "be-all and end-all" of modern programming.  Everyone should pick the approach which works best for them.

Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
Message 30 of 161
(10,135 Views)