Appropriate use of Event Structure and Property Nodes

[brhanse]

Hi,

In the early to mid 90s I wrote several LabVIEW programs for characterizing solar cells.  I am now retired and old(76) and trying to keep a couple of brain cells working.  I have LabVIEW Community Edition and I wrote a simple program for comparing temperature scales.

My questions are:

1. Is my use of the Event Structure appropriate and is there a better method?
2. Is my use of property nodes better than local variables or some other method?
3. What other improvements could I make?

Back when I was programming I didn't have Event structures or Producer/Consumer or QMH so I don't know if those are appropriate.

Any suggestions, improvements or criticisms would be welcome.

Saved in LabVIEW 17  Windows 10 Pro

Thanks

[GerdW]

Hi brhanse,

---

@brhanse wrote:

My questions are:

1. Is my use of the Event Structure appropriate and is there a better method?
2. Is my use of property nodes better than local variables or some other method?
3. What other improvements could I make?

Back when I was programming I didn't have Event structures or Producer/Consumer or QMH so I don't know if those are appropriate.

Any suggestions, improvements or criticisms would be welcome.

---

1. The event structure is used correctly: you set up several events for your UI elements and execute them.

2. Don't use "value" property nodes just as an replacement for local variables (they are usually slower than local variables)! Don't use so many locals/property nodes at all!

On 3.:

There is so much duplicated code! In each event you call the PosOrNeg subVI three times! Why not place those 3 calls just once after the event structure!?

Why do you call TempConv once before the loop? It is called in the loop in each event!?

Example:

After moving the 3 PosOrNeg calls after the event and deleting all their instances in all event cases…

The next step would be to do the same for the Temp-Booleans: no need to set their locals/value-properties inside the events! (The Reset boolean text property can also be moved after the event…)

You also should look into using better data structures, like arrays or clusters. They will help you to simplify your code even more: your TempConversion could output a cluster containing 5 temperature values instead of 5 scalar temperature values and you could have a cluster on your main VI UI too…

---

@brhanse wrote:

In the early to mid 90s I wrote several LabVIEW programs for characterizing solar cells.  I am now retired and old(76) and trying to keep a couple of brain cells working.

---

Respekt!

Then you learned with LabVIEW version 3-5? There has changed a lot in those 25 years…

[altenbach]

A few more points:

• Your conversion subVI does not need to reset all inputs to NaN. They will not retain data if disconnected on the next call. It is sufficient to have the controls default at NaN, which you already have.
• The conversion subVI should only have one DBL input, but also an enum input that defines the units of the input. This enum can be connected directly to the case structure.
• To detect positive/negative and return color accordingly, you could just use the "sign" function, add 1, and index into an array of colors.
• All your LEDs belong after the event, with booleans exiting the event to each (mostly use default if unwired).
• Personally, I would use an array of clusters for all your indicators. Each cluster would have a string (currently your label), a numeric, and an colorbox (made to look like an LED!). Keep that array in a shift register initialized with your defaults and update the array indicator before the event structure. In each event, update the data accordingly. Many event can probably be combined.
• ...

[altenbach · Accepted solution]

Here's a quick draft (did not implement the text color and mouse enter, etc. Cluster and array containers could be made transparent. The unit labels could be centered. I did not bother with cosmetics).

(One property node for the boolean text and one local variable to update the control cluster. Zero value properties instead of dozens! Three event cases instead of eight! Note that the cluster only has the numeric enabled. The rest are disabled and act as indicators). See if this can give you some ideas at simplifications.

[brhanse]

GerdW and Altenbach,

Thank you so much for replying to my post.  There's so much I don't know about LabVIEW and it definitely showed in how you improved my code.  I especially like Altenbach's solution.  Very elegant.  The use of an array of clusters and enums simplifies it quite a bit.  One local variable and no property nodes makes it easier to follow.  With the use of an array of clusters I think all the text colors have to be the same.  I can't change them individually.  Is that true?

gerdW - I think it was LabVIEW version 3.1 that I used back then.  I remember having 14 3 1/2" floppies to install the program.

I must apologize for my late reply.  I am going through Radiation  therapy right now and the side effects are doing a number on me.

Thanks again

[altenbach]

---

@brhanse wrote:

With the use of an array of clusters I think all the text colors have to be the same.  I can't change them individually.  Is that true?

---

Yes, array elements share all properties except value. As I said, for a colorbox the color IS the value, so you could make the numeric background transparent and place the colorbox behind. Now you can have at least different background colors for each element. Here' show it could look like (rough draft)

[db_bh]

First off, to the original poster, hope you came out the other side of radiation therapy OK!

Secondly, this post might be the most enlightening I've seen and has sent me down a rabbit hole all afternoon:

<quote>Here's a quick draft (did not implement the text color and mouse enter, etc. Cluster and array containers could be made transparent. The unit labels could be centered. I did not bother with cosmetics).

(One property node for the boolean text and one local variable to update the control cluster. Zero value properties instead of dozens! Three event cases instead of eight! Note that the cluster only has the numeric enabled. The rest are disabled and act as indicators). See if this can give you some ideas at simplifications.

</quote>

I've had this topic in my mind for a while - that best practice is to avoid variables and property nodes and use wires wherever possible. This is the best example I've seen in implementing that (I have, in the last 6 months, gone through core1, 2 and the CLAD exam and not come across an example programmed in this way).

From what I can see you basically have a front panel cluster and a block diagram cluster that are constantly trading information where appropriate. These things are always a trade off, but is this generally considered best practice? There are obvious readability benefits, but you have two clusters in memory and effectively a third one because of the local variable. If you are in an application dealing with much more data, such as waveforms or large multi-dimensional arrays, do variables or property nodes ever become the more efficient option.

Last question: I have been playing around with frameworks trying to figure out a best fit for future projects. Does this style of programming survive with a queued message handler, and is it even possible in a JKI state machine which seems to have its own methods for initializing data?