Community Nugget 4/08/2007 Action Engines

[crossrulz]

---

@billko wrote:

#2 is a "modern" pet peeve, isn't it?  I think that in LV 2 that was your global?

---

Yeah, but that was back when I was learning my multiplication tables.  Very few remember the days before Global Variables.

[crossrulz]

---

@Chris_Cilino wrote:

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.

---

Just happened upon the Wikipedia article on LabVIEW and there is a table for the most common design patterns.  Perhaps we could expand that.

[rolfk]

---

@Blokk wrote:

Beside wires, local variables, property nodes etc., there is another option could be considered, the "Set/Get Control values by Reference". This method is said to be fast, but I do not really use it personally (most often I am lucky and I have limited number of indicators/controls, so I just use wires; or try to go for Arrays/clusters in order to limit the number of FP/BD objects).

Here is an example of this technique:

https://forums.ni.com/t5/LabVIEW/Make-BD-space-for-indicators-trick-FOR-loop-Case-structure-combo/m-...

---

It's fast in comparison to the Set/Get Control Value by Name method, but definitely shouldn't be faster than a Value Property. As to the timing "benchmarks" posted by wiebe, "I don't trust benchmarks unless I faked them myself!" (Or altenbach reviewed them )

Generating a random number should NOT take longer than updating a control on the screen, unless NI changed in a recent LabVIEW version the random number generator to use a highly supercharged version that satisfies pretty high cryptographic requirements. But I really doubt that. The one used in earlier versions of LabVIEW was definitely not relevant in any way even for cryptographic requirements of the last century but that is also not the purpose of the random number generator in LabVIEW. For simulating numbers for measurements, its randomness is good enough. For cryptographic uses any stock random number generator is in 99% of the cases not the desired one and you have to go and look for a specific variant that satisfies your specific needs anyhow.

[Ben]

I do not have a lot of time to offer to this discussion but I will share a thought.

There isn't a single program that will do every job so as we try to determine what architecture is correct for any application we are going to develop, we have to find a balance between the hardware capabilities and the project goal.

Projects that require high performance to keep up with high data rates and projects that only react to user interactions have very different requirements. So focusing only on performance is OK for the former but not the later.

My point is that knowledge of the features and drawbacks of different approaches allows us to find architectures that solve the problems and allow for simple support going forward.

Two examples come to mind.

1) A production control program that automates a factory floor could be implemented using DSC tags associated with 300 I/O points that need only be checked a few times a second.

2) A engineering test station that has to convert a pair of DI lines at 400 Mhz, convert to analog and then compute the FFT on the fly.

Example #1 may have hundreds of controls and indicators while example #2 may only have a handful.

So when the query started with mention of the GUI controller when this thread was resurrected, that approach is valid for #1 where managing 300 controls and indicators in a single event structure would be a nightmare. If the parts of the production floor can be grouped into logic groups, multiple sub-VIs can make use of Dynamic events and handle the need of parts using just enough events to make part of the main GUI work as required.

Summarizing;

As architects we have to asses the demands of an application and decide when performance is a concern and balance the various design options to meet the challenge at hand.

"It depends"

Ben

[wiebe@CARYA]

---

@rolfk wrote:
Generating a random number should NOT take longer than updating a control on the screen, unless NI changed in a recent LabVIEW version the random number generator to use a highly supercharged version that satisfies pretty high cryptographic requirements. 

I think what happened was that I updated controls by reference. All 400 updates might fit in one refresh rate. But putting the random number in that loop, might just make it not fit in one refresh rate. So with the 400 random numbers it's 120 ms, without 40 ms, but indeed it's not the random number.

[wiebe@CARYA]

---

@crossrulz wrote:

---

@Chris_Cilino wrote:

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.

---

Just happened upon the Wikipedia article on LabVIEW and there is a table for the most common design patterns.  Perhaps we could expand that.

---

A wiki on LabVIEW, and not a single image... Go figure.

[jfalesi]

---

@Blokk

---

What you have to learn and apply here is a State Machine, and using Shift Registers (plus if needed, one or more parallel loops). The code which you inherited was done by a "programmer" who probably had little knowledge in LV, but had some text based programming language background. The most common sign for this when someone abuses local variables, and Flat Sequence Structures. Here is a good read which can give you more hints: http://www.ni.com/newsletter/51735/en/

---

You're right, the inherited code was done by an engineer in my lab who was relatively inexperienced with LabVIEW. I am a big fan of queued state machines and event handlers - I just haven't convinced myself to re-architect this application yet.

That's a great article.

[Blokk]

---

@jfalesi wrote:

---

@Blokk

---

What you have to learn and apply here is a State Machine, and using Shift Registers (plus if needed, one or more parallel loops). The code which you inherited was done by a "programmer" who probably had little knowledge in LV, but had some text based programming language background. The most common sign for this when someone abuses local variables, and Flat Sequence Structures. Here is a good read which can give you more hints: http://www.ni.com/newsletter/51735/en/

---

You're right, the inherited code was done by an engineer in my lab who was relatively inexperienced with LabVIEW. I am a big fan of queued state machines and event handlers - I just haven't convinced myself to re-architect this application yet.

That's a great article.

---

I feel your pain, been in the same shoes! And actually in case of a couple of LV code which was written by myself a few years ago! 😄

[drjdpowell]

---

@rolfk wrote:

---

@Blokk wrote:

Beside wires, local variables, property nodes etc., there is another option could be considered, the "Set/Get Control values by Reference". This method is said to be fast,...

---

It's fast in comparison to the Set/Get Control Value by Name method, but definitely shouldn't be faster than a Value Property.

---

It's Set/Get Control Value by Index that is a method much faster than a Value Property.   It acts on the VI reference, rather than control reference, and I believe it changes the terminal rather than the control itself.  Thus it doesn't need the UI thread and can be faster.  Requires caching of the control's index, so is not so user-friendly.  One can use it, for example, if one had 300 controls to set via received messages.  Instead of 300 cases, one has a single case that uses a lookup table to find the index and sets the control by index.

[jfalesi]

---

@rolfk

---

Value properties do not solve the problem of race conditions per se in comparison to local variables. It could be that the use of value properties can seem to solve it if you use the error cluster from them and in that way force a specific serialization of execution. But that is really driving out the devil with beelzebub, but not a solution.

---

+1 for the response

+1 for "driving out the devil with Beelzebub", which is my new favorite phrase.