Is it possible to have an indicator show how old its value is?

[VictorClaessen]

Hi,

I am building a control system where I get data from hardware and other software at irregular intervals. I would like to show the user how old the data is that is currently shown in an indicator. My idea was to use the background color of an indicator to show the age, white meaning the value is very recent, and an increasing red color would mean that the value hasn't been updated in a while. My idea was to create a custom indicator that would monitor the age of its own value and adjust its own background color. So the main program would set the value and forget about the indicator.

I have made an example VI (attached) of the kind of behaviour I'd like to see.

Do you think this is at all possible?

Best regards,

Victor

[0utlaw]

Hello Victor,

My recommendation is to take a look at XControls:

Tutorial: Creating New Front Panel Objects with LabVIEW XControls

http://www.ni.com/white-paper/3198/en/

I like to think of XControls as a subVI for your front panel- they allow you to define the behavior of a control from the ground up.  They do require more work up front to get them doing what you want and impose some limitations (most "normal" properties/methods won't be directly accessable without setting them up for the XControl), but If you're planning on using more than a few of these color-coded indicators you'll probably want to consider them as they'll make reuse and scaling your application much, much easier.

Regards,

[tst]

It certainly is possible. As mentioned, one option is XControls, but you should be aware that XControls aren't built to run things in parallel. You can't simply add a timeout to the event structure of a facade VI and use that. Instead, you will need to use some kind of daemon to handle it for you. You could launch it from the XControl and give it the reference of the internal control you want to modify and then send an update to it when there's a value change event. The actor framework is useful for creating such daemons, although you can also do it using other means. You could also use a single daemon which will keep an array of reference and simply manage all the XControls.

Another option is to generalize the whole thing. Instead of writing to the indicators directly, mark the indicators somehow (the label is practical) and use a more generic engine to update their values (basically iterate over all the controls and get their label, then use that info to know how to update them). This can be very useful if you have a lot of indicators and a tag engine. If you do that, then you simply add the color code into that update engine.

[Ranjeet_Singh]

Why not using time which will be updated when indicator updated. Rename time indicator as last updated on. 

[PaulG.]

---

@Ranjeet_Singh wrote:

Why not using time which will be updated when indicator updated. Rename time indicator as last updated on. 

---

My first thought. Why go through all the effort creating an xcontrol? Tell the user exactly how old the data point is. You can take a time measure when you get the data then subtract that value from the current time.

[VictorClaessen]

Hi all,

Thanks for your suggestions.

• The XControl way seems very flexible, but also a lot of work.
• The second suggestion, if I understand it correctly, is to append the indicator caption with the age of the data. So if the caption now reads "Tank 1 level", it would become "Tank 1 level, as it was 10 seconds ago". I suppose the the disadvantage of that taking up a lot of space on the front panel can be overcome by abbreviating it to "Tank 1 level (10s)". However, I don't feel that this would be quite as informative as changing the background color. It will take the user a lot of eye-scanning to read the data-age for all indicators, whereas with a color code it would be immediately obvious for the entire front panel. Please understand that I do not mean a front panel with a few indicators, but rather a panel with dozens of indicators.
• The 'daemon' idea seems the most practical at the moment. I could store the last-updated timestamp in the non-visible caption [i.e. not the visible label] of the indicator and use that to determine the age for every indicator every time the main program loops.

Ideally, I would incorporate this logic in the indicator [of a custom version of an indicator] itself, but so far I haven't heard anything to make me believe that that is possible.

[camerond]

---

@VictorClaessen wrote:

Ideally, I would incorporate this logic in the indicator [of a custom version of an indicator] itself, but so far I haven't heard anything to make me believe that that is possible.

---

What's wrong with the way you're doing it now? Looks pretty straightforward to me. Just make a subVI out of it and then you can even use it in a for loop to modify all your similar indicators at once.

Cameron

[VictorClaessen]

Hi Cameron, thanks for thinking along.

I'm not really sure what you mean with "the way you're doing it now". If I make a subVI out of this indicator.vi as it is [in the first post], and place that in parent.vi then

1. the front panel of parent.vi won't show anything
2. parent.vi loses control of the execution as the loop in indicator.vi is running forever and never returns to parent.vi once called.

But perhaps I'm not completely following you?

[camerond]

Not your exact VI as you posted, but using that method. The snippet below is called an Action Engine, it runs through the while loop exactly once. (Don't ask me about that "DigNum Refnum", the property node was supposed to be hooked up to the indicator.) Just wire the appropriate controls and indicators onto your subVI's connector pane.

You could also bundle your indicator and the last update time indicator as a cluster for output, and unbundle them as your first step in the subVI, then you wouldn't have to remember to pass two things to and from the subVI every time.

Cameron

[VictorClaessen]

Sounds good, but you've lost me. So what you are showing now is the subVI. (The bundling remark I get.)

The best I've come up with so far is that you want me to to call this subVI, from the main loop of the parentVI, for all the indicators I have on the front panel of the parent? [by passing them as a reference?] But then the parentVI will have to check wether the value has been updated? Why not do that in the subVI?

BTW Would it be possible to attach your VI to this post? I'm using 2011 so I can't import your snippet as is.