Dealing with lots of indicators on a actor's front panel

[BillMe]

I have an actor (call it Actor A) that displays about 40 or so pieces of information to the user, in this case sensor data. The bit packed (raw) sensor data is acquired through hardware and sent to Actor A (different sensor data packed into blocks of 16 bit words). Actor A then sends the raw data to a decommutator (Actor B) and a logger. Actor B unpacks the bits, applies any scaling factor and then sends the "readable" data back to Actor A for display, one sensor per message essentially.

I'm looking for efficient ways to manage the references to all the indicators. I've come up with these options:

1. Cram references for all the indicators into Actor A's private data. Write the data to the indicator via a property node in the method that handles the message.
2. Use a functional global to hold the references to the indicators. Pull the reference from the functional global. (Don't really see this as "better" than option 1).
3. Bind a network shared variable to each indicator. Write the data to the shared variable in the method that handles the message (the ONLY place that would write to the variable).

Anyone have other suggestions?

[stbe]

currently, I use your option 1.

however, I have a nice way to initialize all the references:

old style - takes a lot of manual effort (and space!):

"my" method:

I read the Control/Indicator's Label and assign the proper reference dynamically. (of course, you still need all references in the private data)

cheers

[Titho]

Hi,

I'm using Events to update my indicators on FP, so I don't have to keep indicator references inside class.

Events are generated in Actor Core, after message was handled. After that event structure in user interface loop handles incoming event and updates selected indicator.

One thing to notice : I'm updatating my indicators occasionally with small data, so events can handle this.

[wrkcrw00]

I too use user events. The two commonly accepted ways to get data back to an actor front panel are events and control references, as in your option 1. I use events for the most part because I can add other logic inside the event if needed (ex, change text color if the value is outside some bound).

I would also suggest breaking apart actor A. Have one actor handle the hardware data collection (call this actor C, to prevent confusion from the already established A and B). It sends the raw data for processing to actor B. B can log it (or even send to a new actor D to log) and forward the data for veiwing to actor A. It's best to have UI actor do ONLY UI stuff. It may seem like a lot more work, but it's not that bad, and adding capability later will be easier.

[jon_mcbee]

As an alternative you should look at Control Value Indexes, here is a blogpost I wrote on the topic.  They are much more efficient than value property nodes and I think will be less work than using events.

[CaseyLamers1]

Thanks for this post Jon.

A couple of things I do.

1. I have a "UI" actor that receives data.

2. The UI actor communicates the data to 1 or more facade actors.

3. The facade actors override actor core and this is what a user sees, I open the front panel of Actor Core.

I had been using a user event to communicate from the UI actor to the facade actors. Have the UI actor create a user event and then hand it off when launching facades. Facades can then register for the event.

My most recent UI needs a lot of indicators (32 channels of temperature data) with background color change for "alarm" levels, etc. This was going to make my case structure for the data user event HUGE. I wanted to break it up. So I made the switch to storing a bunch of control references in the private data and I made a message from the UI actor to the facade to "Receive Data". I was already keeping track of the facades using pub/sub for another task "changing user access level" so now I just use that list of launched facades to send the Receive Data message.

Looks like all I need to change now is that I store the index rather than the control reference.

[BillMe]

The hardware acquisition is done by a different actor so I'm good there. I'll take a look at user events. And I understand control indices but I'm not clear on how the public method would know what index to use unless it's hardcoded in the method. That might work better if I bundle sets of indicators into clusters (with hidden borders) and then update the entire cluster all at once.

[AristosQueue (NI)]

I generally prefer option 1.

The only reason why this is better than option 2 arises when you have multiple copies of the same actor -- the functional global doesn't get cloned correctly, whereas the private data does.

[drjdpowell]

BillMe wrote:

Anyone have other suggestions?

You can deal with the controls references entirely dynamically.  Use the Pnl.Controls[] method to get all control and populate a Variant-attribute look-up table.  Then have a single User Event containing a Label and a (Variant) Value; in the Event Case just look up the reference by label and set the value by variant.  Once you set this up you can add new indicators without needing to add any actual new code to the Event Structure.  Just drop a control of the right type and give it the right name.   One can also extend this to use Control-Value Indexes or to add features like colour-change alarm levels. 

[BillMe]

A question regarding handling of messages where an Actor Core is overriden to include a front panel: In what thread do the message handling VIs run?