Are local variables comparable to the value property of a control or indicator?

[Dark Hollow]

I've been using control buttons / switches with mechanical latching action, event structures and local variables to track the status of my switches.  I used local variables with indicators, too.  Now I see that this might be done via the property node of a switch or indicator.  Should I use property nodes in stead of local variables?  Should I use "switching" mechanical action and control the state of the control buttons / switches?  I used latching mechanical action since it auto reset when it is read, but that pushed me into using local variables.

I know that property values fit the data flow model, whereas local variables might have to be placed into a sequence structure to assure order of execution.

I'm just don't want to switch over my entire program unless this is the correct approach.

Thanks,

DH

[Mark_Yedinak]

You should avoid using both. Property nodes and local variables are useful in certain circumstances but from your post I gather that you are simply using them to pass data around. If this is the case you should use wires and shift registers to pass the data. The controls and indicators should only be there to actually interact with the UI. They are not intended to be "variables" in your code. If you need to pass data between parallel tasks then you should look at using queues or action engines.

Property nodes are not goos to use since they force the code to the UI thread. They will impact your performance. Their use should be restricted to only UI tasks. It is also best to separate your UI processing to its own task (read it's own loop). If you MUST access data by using a local variable or a property node the local variable is the prefered method. However, as mentioned neither is the preferred method for data exchange.

Using local variables and property nodes can lead to race conditions in your code which can be difficult to track down. Using wires to pass data significantly reduces this since you can control the flow.

[Dark Hollow]

Well, I'm trying to change UI properties in my state machine.  For example, when a START TEST button is pushed, I want to disable and grey that button and enable the STOP TEST button.

Another example... I've got a couple of dozen LED indicators on the front panel to show TEST PASSED.  If I wire each one, my state machine block diagram gets messy.

I've yet to see a good example of a front panel design used in conjunction with a state machine.  Can you point me to one?

DH

[Ben]

Ditto marks comments.

This post may help.

Ben

[Mark_Yedinak]

Since you are actually doing UI stuff then you will need to use property nodes. That is the only way you can enable/disable controls.One thing you can do is to separate out the UI updates to a separate task from the actual state machine. The state machine runs through its porcessing and doesn't touch the UI itself. Rather, it posts messages to your UI task using a queue. These messages would indicate what action you want to occur such as enable/disable control, update value, or whatever other task you need. A simple and generic protocol can be created to accomplish this. Your messages can be a cluster of a string or ENUM identifiying the command and a variant. Each comman will know what data and its format it needs. For example, the enable button command could would have a command ID (ENUM or string) such as Enable Control. The variant data would be the control name. When you first start your application you could initialize a table that links your generic control names which are uised in the state machine with the actual control name used on the front panel. Your state machine will always use the same identifier for the items it wants to control The UI task is the one that actually links these generic names with the specific controls/indicators on the front panel. This type of architecture allows you to completely change the front panel UI but leave your state machine in tact and unmodified.

[altenbach · Accepted solution]

---

@Dark Hollow wrote:

Well, I'm trying to change UI properties in my state machine.  For example, when a START TEST button is pushed, I want to disable and grey that button and enable the STOP TEST button.

---

Don't over-engineer things. In this case you could use a single button and label the FALSE case a "Start Test" and the TRUE case as "STOP TEST". No extra code needed at all. At the same time you only use half the panel space! (and 10% of the diagram space!)

---

@Dark Hollow wrote:

Another example... I've got a couple of dozen LED indicators on the front panel to show TEST PASSED.  If I wire each one, my state machine block diagram gets messy.

---

Define messy! In my mind, code that is not held together by wires is much messier because it is impossible to determine execution order and thus program logic. A wire is a small 1D object. A property node is a significant 2D object. 20 wires are much less messy than 20 property nodes, especially since each property nodes still needs to hook to a wire one way or another!

In order to reduce the number of wires, use more appropriate data structures. Instead of a couple dozen LED indicators use a single array of LEDs. Only one wire! Keep the array in a shift register and update any single LED as needed using "replace array subset".

[Dark Hollow]

Lots of good advice (and edification), but Altenbach's comments about arrays and ON/OFF button text really strike a chord with me.  Best fit for my application, I believe.

Thanks to all,

DH

[KathrynB]

The other alternative to an array which does take up more space, but helps with the self-documenting aspect if you have a FINITE number of tests (and it isn't going to change dramatically over time as far as you can tell) would be a cluster, as you can update the value by name. But the choice of array or cluster is based on how many, how you're updating, what future changes might be (could tests number 2 and 3 swap places, will there be more tests, new tests added part way through), what labelling/documentation you need...

[Mark_Yedinak]

---

@altenbach wrote:
Don't over-engineer things. In this case you could use a single button and label the FALSE case a "Start Test" and the TRUE case as "STOP TEST". No extra code needed at all. At the same time you only use half the panel space! (and 10% of the diagram space!)

---

While I do agree that the KISS principle is good I do believe that when it comes to the UI it is well worth the effort to learn and develop sound strategies for building your applications. Over time you develop a library of reusable components and learn techniques that will truly make your application work well, be user friendly and look like a polished finished product then simply some controls and indicators thrown on the front panel. If your role will be to develop and distribute applications learning good UI develop techniques is worth the time and effort. In addition, you can create a template that can be used as a starting point for all of your applications. This saves time and effort and allows you to deliver a polished product.

The template we have sets up framework for the application to have command line arguments, custom menus, configuration files and log files. We have also developed generic methods for allowing our processing code to interact with the UI and vice versa. It does take some time up front but the payoff down the road is well worth it. If you do have limited time you can always take the approach of adding one new trick to your bag of tricks with each application.