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

[Florian.Ludwig]

Hi community,

I am having difficulties implementing "Set Control Values by Index Function.vi".

I have a programm that has to do a lot of communication to the FP and I have migrated to setting and reading the values by index. I have created a sub vi to set values (see attached Beschriftung nach Wert schreiben per Index.vim and its sub vi).

It seems to work fine for the most part - but some boolean controls don't display their value correctly after being set.

I know they have the correct value set, because I can read it back after writing it.

The elements will update their display when they are read later.

I am positive that I am not defering panel updates when this happens.

When I have the code running in highlight mode I see that the FP does not change when the value is set, so I am also sure that it is not overwritten immedeately with the wrong value, because it couldn't happen that quickly in highlight mode.

Unfortunately I cannot share the surrounding code that exhibits this behaviour. I'd appreciate any help offered despite this.

Best regards,

Florian

Edit: forgot to mention that the same code seems to work flawlessly if I replace the attached sub vi with a property node to write the value.

[Gregory]

Hi Florian, can you share the other code where you create your reference table?

[Florian.Ludwig]

Here you are.

AE_Indizes.vi handles this.

The reference table is created/edited in the "Init" and "Hinzufügen" cases.

Init is executed once in the top level vi, Hinzufügen can be used in other vis in the hierarchy. Wire to MAIN-Panel the panel reference of the vi you want to add.

Again stripped of some logging functionality.

[wiebe@CARYA]

Can't look at your code (still in 20), but Set Control Values by Index is tricky.

IIRC, Set Control Values by Index only works if the VI is in run state (e.g. not bad or idle). Not sure if it actually needs to be executing, but I don't think so.

This gives very weird behavior. Using the function on a static VI reference will probably work, as the static ref will put the VI in run mode. But opening a ref with Open VI Reference will not work, as this doesn't put the VI in run mode. Once you put the VI in an unused case, it will work, as the VI is in run mode.

The use cases for Set Control Values by Index are limited by this. Looks nice at first, but is impractical except some corner cases.

[Florian.Ludwig]

Thanks for the input.

The VI that owns the controls is definitely running. It is displayed in a subpanel, and I can interact with the running code.

[Gregory]

Nothing is jumping out at me, but maybe a couple more things to look at.

- Do any of your controls have the same name (label)? It looks like that would cause problems since everything is referenced by the label.

- Why does the "Element Hinzufugen / Ersetzen" have a different cluster? I would make that cluster with your references / control index a typedef and make sure it is used throughout the code.

[Florian.Ludwig]

Thanks for taking the time.

You are right, lables have to be unique. I have made sure of that.

Also the elements in the subpanel in question are added only once at startup - so if they had gotten overwritten the value wouldn't change at all, and not some time later.

Thanks for pointing out the bug in "Element Hinzufugen / Ersetzen". That is a currently unused case - but that could have come back to haunt us later!

[stevem181]

Does the issue only show up in SubPanels?

I have used "Set Control Values by Index" extensively since it came out in 2013 and haven't seen this behavior.

As a data point, I don't use SubPanels (yet). I tend to lag behind the current LabVIEW version (currently using 2018)

because I use this feature and some toolkits that are not mainstream. But I'm planning to migrate to 2021 soon.

Not until SP1 though. 

I suggest you check your CPU utilization (probably an unlikely problem since you said highlight mode also had issues).

Be sure to look at Logical Processors not Overall CPU Utilization (the default). A 16 thread CPU can show 12.5 %

utilization with the UI core running at 100%. 

steve

[paul_cardinale]

---

wiebe@CARYA wrote:

Can't look at your code (still in 20), but Set Control Values by Index is tricky.

IIRC, Set Control Values by Index only works if the VI is in run state (e.g. not bad or idle). Not sure if it actually needs to be executing, but I don't think so.

This gives very weird behavior. Using the function on a static VI reference will probably work, as the static ref will put the VI in run mode. But opening a ref with Open VI Reference will not work, as this doesn't put the VI in run mode. Once you put the VI in an unused case, it will work, as the VI is in run mode.

The use cases for Set Control Values by Index are limited by this. Looks nice at first, but is impractical except some corner cases.

---

A static VI ref will put the referenced VI in run mode only if the reference is strictly typed.

[Florian.Ludwig]

Yes, this happens in subpanels only - but the whole GUI is in subpanes, so I have no comparison.

Will have a look at CPU utilisation toworrow.

Can't wait for that SP1.