02-15-2022 02:19 AM
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.
02-15-2022 02:55 AM - edited 02-15-2022 03:01 AM
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.
02-15-2022 03:35 AM
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).
02-15-2022 08:24 AM
@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?
02-15-2022 09:16 AM
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.
02-15-2022 10:17 AM
@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...
02-17-2022 02:21 AM
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.