Robust data array to cluster technique

[Worle]

I often have DAQ systems outputting an array of data which I then need to display on the UI in a cluster, normally overlaid on a P&ID.

I tend to have an enum defining the order of data in the array which I use for extracting data from the array where necessary.

This conversion between the array of data and the cluster only happens once but has caused no end of problems for me in the past when it comes to adding channels at a later date, changing channel names or orders etc

My question is: Does anyone have any advice on what the most robust way is of converting data from the array to the cluster so that it is as robust as possible to channel changes or additions. I would always prefer a compilation error if I have managed to wire things in wrong (Eg the wrong data is being displayed on the UI). This seems to be a reccuring problem, and nothing destroys confidence like the wrong data been displayed in a box because I have added a channel.

I tend to use one of the three methods attached. All work but I was hoping someone had a neater way of doing them.

[wiebe@CARYA]

---

@Worle wrote:

This conversion between the array of data and the cluster only happens once but has caused no end of problems for me in the past when it comes to adding channels at a later date, changing channel names or orders etc

There's no way around this, except make it as transparent as possible where\when in the code and how this works.

The moment you try to 'automate' this, for instance by getting the channel names from the DAQ setup, you're tide to strings. Strings means typos. Using an enum makes sense (if the setup is fixed). But has to be some conversion somewhere, and this will always require programmer's input. And there will always be potential for mistakes.

---

@Worle wrote:

My question is: Does anyone have any advice on what the most robust way is of converting data from the array to the cluster so that it is as robust as possible to channel changes or additions. I would always prefer a compilation error if I have managed to wire things in wrong (Eg the wrong data is being displayed on the UI). 

---

I'd abstract thins ASAP. Put the data in a databus of some sorts. A FGV, a DVR (wrapped in a VI or class), a by value class, anything. As long as the data is fixed, and the interface is clear.

I think that is as good as it gets.

You either have 'flexible' setup, using strings and anything can be 'automatically' coupled based on strings (control\indicator labels, HW setup from config file, etc), or you go from array data to defined static data using enum as index, cluster with elements, etc.

Even if you could get your DAQ to produce a cluster, at some point this will need programmer interaction, with potential mistakes.

All 3 options you've show are valid, but they should all be abstracted in a unit\module of some sort, that is easily understood, maintained and last but not least can be tested.

[Worle]

When I actually implement this it is abstracted, I have just shown it all together so that it is easy to explain my thought process.

You are right, there is always at least one place where the programmer has to get it right (e.g. making sure that order of channels in the data array matches the enum order). What I am trying to ensure is that is the only place that the programmer can make a mistake, or if they do one of the following things happen (In order of preference):

- compilation error where they can't even run the software and LV takes them straight to the source of their stupidity

- Run time error

- Rely on unit tests to check what they have done

As you said, the methods I have shown work and I tend to lean on option 2 quite heavily but it relies on the cluster element label matching the enum element text. I don't always want this for various reasons which makes it totally fall over.

Edit: options 2 and 3 also fall over if I have more than one data type in my cluster (e.g. pict rings for value states and numerics for sensor values) To use options 2 or 3 I need multiple clusters with transparent backgrounds which then becomes a royal pain to edit.

[wiebe@CARYA]

Clusters are terrible for P&IDs.

If you have a cluster of outputs (indicator), and a cluster of inputs (control) you're in trouble once the indicators need any form of interaction. The control will at some point cover the indicator...

I usually use labels to look up the data value in a databus (with run time error checking). Not ideal, but you'll notice mistakes very fast.

I think it's just not possible to get compile time errors based on strings.

Unless you want to dump everything in shared variables, and link the controls and indicators to them using data binding. That would still not get you compile time errors, but it will eliminate typos. At the cost of adding a bloated mechanism that obfuscates everything to make it 'easier' (IMHO 😊).