LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FP doesn't always update when value of a control is set with "Set Control Values by Index Function"

None of the CPU threads goes up significantly when this happens.

 

I'm sure it's a display issue as the values will display correctly later, when I interact with other elements.

This may either be a bug, or more likely I have built a defer panel race condition or something similar that I can't seem to find (setting defer panel to false after the write doesn't resolve the issue).

Switching to the property node value write might either circumvent the bug or change up timings enough to mask the race condition.

0 Kudos
Message 11 of 17
(845 Views)

There could be a lot of things going on... Still can't open LV21 VIs.

 

There's an option Clear indicators when called. Maybe there's a reinit to default, or other VI Server magic going on. Controls wired to the connector pane can potentially be reset.

 

The solution is usually to make things simpler. Either to find the problem\solution, or to keep it simple.

 

Defer panel updates can definitely have unexpected effects. Some functionality simply doesn't work properly (cursor updates, picture controls, just to name two I ran into recently). I wouldn't be surprised if Set Control Value by Index is a function that takes a back door, not considering panel graphics at all (or enough). This function is made for performance...

 

IIRC, defer panel updates in a subpanel does effect the main VI as well.

 

Do you really need defer panel updates? I'd hide the panel (so dynamic event registration on controls work), run the VI, when everything is up and running, let the VI put itself in it's subpanel. Ideally of course, things can get complicated.  

Message 12 of 17
(841 Views)

Update: If I put property node to read the value after writing per index, the control display updates to the correct value!

I had previously checked whether the value was correct by reading per index which does not cause the display to update.

 

"Clear indicators when called" is unchecked.

 

I only ever defer panel updates in the top level vi. I'm afraid it is necessary to keep the FP from looking messy while i move stuff around.

 

I currently cannot think of a simpler solution, but of course, as simple as possible is the paradigm. While this feature is made for performance it is still made to communicate with FP elements. It would be bad if it didn't reliably update the element's display.

 

I have attached the previously posted VIs saved for LV2020 (i hope).

0 Kudos
Message 13 of 17
(828 Views)

@Florian.Ludwig wrote:

I have attached the previously posted VIs saved for LV2020 (i hope).


I'd  make a map of control names vs control reference up front, and then use a simple value property to get\set the value.

 

The main reason (I expect) Set Control Values by Index is faster than Set Control Value, is because string to control ref is slow.

 

But if you do that up front, I don't expect Set Control Values by Index to be much faster than a Value property, although the help says it is faster. This might include overhead for finding the control...

 

How fast do you really need things to be? And why?

Message 14 of 17
(815 Views)

I'd  make a map of control names vs control reference up front, and then use a simple value property to get\set the value.

That's how we were doing it before switching to writing by index.

 

In my benchmarks the property node alone took around 50x more time to write than write per index alone.

I'd like the writes to be fast, because the application and its GUI are huge, and sometimes a lot of writes happen.

 

I think I have found a workable solution for now. After doing a bunch of writes I turn defer panel on and off - that updates the FP (either on or off alone doesn't).

I'd still like to get to the bottom of this, though.

0 Kudos
Message 15 of 17
(810 Views)

@Florian.Ludwig wrote:

I'd  make a map of control names vs control reference up front, and then use a simple value property to get\set the value.

That's how we were doing it before switching to writing by index.

 

In my benchmarks the property node alone took around 50x more time to write than write per index alone.

I'd like the writes to be fast, because the application and its GUI are huge, and sometimes a lot of writes happen.

 

I think I have found a workable solution for now. After doing a bunch of writes I turn defer panel on and off - that updates the FP (either on or off alone doesn't).

I'd still like to get to the bottom of this, though.


I'd usually turn defer panel updates on, update control by reference (value), turn panel updates off.

 

Without the defer panel updates, it can be slow for large arrays of references. This is because the property updates will synchronize with screen updates, makin git quite slow.

 

I wander how the speeds relate between Value property (with defer panel updates on) and Set Control Values by Index...

0 Kudos
Message 16 of 17
(804 Views)

Update in case someone stumbles upon this in the future:

Setting the preferred execution system to UI for the subpanel (which I am not sure I want to do for my application) fixes the issue.

Message 17 of 17
(768 Views)