Improving my code (displaying many indicators while saving data).

[deskpilot]

Hopefully this will make sense... Bear with me for a little background. LV2011, PXI and SCXI hardware.

I have been using an ever growing data acquisition program for a few years that gets adapted to many different tests. Lately, we have been running tests with ~120 thermocouple channels that need to be displayed. Obviously nobody is going to read 120 TCs at once, so we do things to make the areas of interest selectably easier to read, and then we update the background color of the TCs based on temperature. We are also writing everything to file, including many other channels, sometimes on different tasks and split up between finite and continuous acquisitions.

This all works well, but the path we have gone down to organize the data (using control references) has lead to code that is hard to maintain. I'm currently trying to clean the slate a little before adapting the code to my next test, and have been looking to see if there are any wholesale changes I can make to tidy things up.

The one idea that sticks in my mind even though it doesn't seem to be feasible is to bind each indicator to a global virtual channel while also logging the channel (TDMS log function). Obviously logging reserves the resource associated with the channel, but it appears that binding the indicator also tries to reserve the resource. The current methodology is to Read the data into the block diagram, split it up a few times for logical actions and display, and also split it off to a queue. The queue then transports the data to another loop for a TDMS write. Like I said, this works well, but has just gotten very messy as the code has grown.

Any schemes like this (or completely different) out there for elegantly distributing many channels to the front panel, while being able to act logically on the data, and also log it?

[taper]

How many data points are you trying to keep on screen per channel?  I've done a thermocouple logger with a few dozen channels and a 1000 or so points each.  I put everything into a master chart and the user could select which channels to graph on subcharts that pulled from the master.  It kept a lot of info in memory, which my system could handle.  If it did it again I'd look at logging straight to file and the charts pulling only the needed channels from that.  There's no sense in keeping more points in memory than can be displayed on screen(aka 2000 points on a 800x600 screen), but my program allowed viewing slices of history, not just the current data.

[tst]

One thing you can try is to completely separate the FP indicators from the data itself and update them programmatically. Here's one suggestion:

1. Create a non-reentrant VI with a lookup table of the channel name and its current data (personally, I like variant attributes as a lookup table, but two 1D arrays in shift registers also work.
2. Update the values from your reading/logging code.
3. Tie each indicator in the display to the channel. The easiest is to use the channel as the label, place the indicators in a cluster and then iterate over the Controls[] property and get the Label.Text property. I would suggest only doing that part on first call and caching the channel names<->control refs lookup in shift registers as well.
4. When you want to update, defer updates on the panel, iterate over all the controls, get the updated value from the lookup VI and push it into the control and in the end undefer updates.

This allows you to add new controls by simply putting them in the cluster and giving them a correct label. You can also have several clusters or put it in several VIs.

[deskpilot]

Taper,

I should have made it more clear that all of my indicators are numeric indicators displaying the current value, I have no charts and no history (if they want to see that, they can open up TDMS viewer). We have found that changing the color of the bacground of the numeric indicator based on the temperature of that particular TC is this the most useful way of presenting data real time. The TC indicators are overlayed onto a solid model of the test article, so that you can look at any spot on the article and know what the temperature is.

TST,

I need to reread your thoughts again, I'm not sure I understand exactly. It sounds like you are heading down the right path though, and it is not totally dissimilar from our current code. We place the indicators where we want them, and then match the channel order in the task to the tabbing order of the indicators that we have placed. The NI channel name gets pulled off of the data stream and applied to the indicator Caption (I could not get the Label to update programattically when I implemented this years ago, not sure if that has changed).

I think where your idea heads in the right direction is the lookup table. One instance where I run into a problem now is the following situation:

I have 120 TCs, but the first 20 channels are PTs, annemomers, etc... I update the TC bg color by indexing out the control refs at index 21, length 120, and then acting on those refs. After a few tests, we pull a PT because it is no longer useful. Since that was the 10th channel in the list, if I want to delete it, it changes the index and tabbing order of every indicator after that so I have to go through the code and find as many as 5 places where we have indexed out control refs for different reasons.

Then, I also adapt the VI to playback data through the front panel. So since the data gets shipped to indicators based on its index location in the waveform array, I have to adapt the playback VI (which actually becomes an EXE) to the different length waveforms. This, I haven't figured out how to do, so my practice has been to just leave the PT hooked up laying on the instrumentation room floor after it has been pulled from the test. Obviously not an elegant solution.

SO, I think what you are saying is to label the Indicator that is to display TC73 the same as the channel that is TC73, and then match channel index to the indicator ref in the lookup table? I'm not sure yet exactly what that looks like, but will think about it a little. The only part I don't like is that I think I will have to go through and type in the indicator labels to match exactly to the virtual global channel names, but maybe I can work around that too.

Thanks for the help and getting moving a little.

[tst]

---

@deskpilot wrote:

SO, I think what you are saying is to label the Indicator that is to display TC73 the same as the channel that is TC73, and then match channel index to the indicator ref in the lookup table?

---

Yes, exactly. The label (as opposed to the tabbing order index) links the indicator to the channel, so you set it at edit time. Basically, there should be no index values in your code - everything should work by name and the indexes are determined automatically at run-time.

As you've seen, you can't change the label at run-time (that hasn't changed and probably never will as long as the label is used as the indicator's "name"), but luckily, that doesn't mean that you have to type in everything manually.

You can change the label programmatically if you open a reference to the VI while it's not running, so you all need to do is open the VI, use the Open VI Reference in another VI and give it the VI's name and then use that to change the labels of all the controls based on their index (or whatever you want). Once you did that, you shouldn't have to ever do that again.

[deskpilot]

That is a very handy tip for setting indicator Labels. I am going to try a slightly more convoluted approach so that things can still be changed at run time (ref my other thread, Drag and Drop Question), but will keep the label option in mind.