Update xcontrols in hidden fronts panels

[albe225]

Hi guys,

I'm developing an application for my company. In my application, there is one VI (we'll call it VI_A) which read datas on a machine then stream some of these data with an event. These data are used by 3 other VI, one of them (we'll call it VI_B) show this data in a xControls (i have to use a xControl because my client wants to see these datas in a synoptic). VI_A and VI_B are never stop while the application is open, I only hide their front panel.

My issue is that when the front panel of VI_B is go from invisible to visible, i can see my xcontrols on the front panel being updated many times per seconds, whereas i configured the update cycle time to 5 second. A few second after my front panel appears, my xcontrols are correctly updated with a period of 5 seconds. 

Can someone explain me why this behaviour happens ? Is it possible that my event are not fully consumed when the front panel ?

Also i use references and the property "value" to update my controls, i use reference because i update my xcontrols one by one, so i have an array of reference. Maybe my way to update my xcontrols is not the best one ?

Thanks you for giving me some answers

[Ben]

---

@albe225 wrote:

Hi guys,

...

My issue is that when the front panel of VI_B is go from invisible to visible, i can see my xcontrols on the front panel being updated many times per seconds, whereas i configured the update cycle time to 5 second. A few second after my front panel appears, my xcontrols are correctly updated with a period of 5 seconds. 

...

---

That sure sounds like the updates are not being handled when the control is written but are being buffered until the screen is made visible.

See if you can simplify your code to a small example to share with the others here and post it here.

Wild guess time!

For each location where that XControl is being written, try to use a "Defer.FP.Updat" set true PRIOR to the update of the XControl and then use the same FP property to un-defer the FP updates.

The thought is that by deferring the FP updates, LV can resolve all of the pending updates without updating the FP itself. Once the deferring is set false, LV will resolve the final state of the FP and THEN update the GUI.

Note, I did declare it a wild guess!

Ben

[albe225 · Accepted solution]

Thanks for your answer,

I solve my issue. The problem is the way i updated my xcontrols. I used a reference and a property node to change the value because I wanted to have a clear diagram.By using local variable, I dont see any perfomance's issues.

On my front panel there are 16 xcontrols and I managed my xcontrols's cluster (the data in) in an array. For me the best way to code this was to use an array of reference so I would be able to select easily the xcontrols I want.

I think changing the value by property node add every data in a kind of stack, and every data in will be treated and showed, thats why it seems to slow. Local variables seems to only update the data to be showed.

PS : In my case, Defer.FP.Update doesn't help.

[wiebe@CARYA]

Reading and writing values with a property node forces each read\write to synchronise with screen updates. This is the same for all controls and indicators, not just XControls. Each locals create an additional copy of the data, and when updating the screen, the last written copy is used to display.

[albe225 · Accepted solution]

I made a very simple VI to compare performance between local variables and property node. My VI write 100 times my xcontrols in a for loop. I use the index of my loop to increase an indicator in my xcontrols so i can see something vary.

First i used property node to change my data, when i run my VI, I saw the indicator in my xcontrol increasing after my VI finished to execute. This indicator was still varying for 2 or 3 seconds.

Then I used local variable and the data i saw at the end of my execution correspond to the last iteration of my for loop.

[wiebe@CARYA]

Another reason for me to stay away from XControls...

[Ben]

Would you care to share your XControl so that we can review it?

It is starting to sound like it may have a performance issue that we may be able to help you with if you were able to share it.

Take care,

Ben

[albe225]

Hi Ben, 

I'm sorry i can't share this code because there are many dependencies and i don't want to share the full project (i will have some troubles with my company if I do that xD). My xcontrols use some tools VI and type def controls.

But like I said using local variables doesn't create a perfomance issue.

[MIG]

Do things work correctly if you use the "Value(Signaling)" property rather than the "Value" property?

I've run into a similar issue in the past where an XControl wouldn't respond to the "Value" property being written to when the FP containing the XControl was hidden, but would respond to the "Value (Signaling)" property.

I think this behaviour is documented under the "Data Change Event" topic in the help:

"LabVIEW does not call the Facade VI on every write to the terminal or local variable. LabVIEW calls the Facade VI when the XControl requires an update. You cannot build an XControl that logs data written to its terminal because not every value is reported to the Facade VI. Use the Value (Signaling) property to write values if you want the Facade VI to update on every value written to the XControl."

[albe225]

Using value signaling raise an event in the VI calling the xcontrol (its the same behaviour for every controls), so it will degrade the performance.