05-27-2020 05:06 AM
Dear all,
I'm surprised to be unable to do this simple task: I have a cluster that I want to update.
This cluster is intialized outside a while loop.
Then inside the while loop, I have a event loop.
When I change the control to change the cluster value, the control is not updated, even with the shift register...
Here, I put an example of putting one of the value of the cluster (the boolean) to a certain value.
The local value (here, I put an Indicator just to show that its value is the one I expect) is updated but not the control. Could you help me please and sorry for this trivial question.
thanks.
Séb
Solved! Go to Solution.
05-27-2020 05:35 AM
First of all there is no such thing as a "shift register control." As such it is unclear what you are really wanting. Were you expecting to change the value inside the loop and it would change the value of your control that you are using to initialize the shift register? That's not how it works. To see that the shift register is working properly move your indicator into the Timeout case and connect a small timeout (200 ms is fine). Remove the 200 ms wait that you have in the loop as the event structure will handle that.
05-27-2020 05:39 AM
I can't read the VI as I only have LV2015, but do you have a Timeout case in the event handler (or any other cases) where the cluster is not wired across and the output terminal is set to use default?
Also, not sure what the Wait (ms) is there for.
PsyenceFact
05-27-2020 06:31 AM
Sorry, I built this example a little too fast.
Here is what I want to do:
1: use a control which is a cluster
2: change the values inside the cluster
3: when I want, use the current values of the cluster, make some calculations and then update the values of the control.
In this example, I can do more or less what I want except the update of the control after changes applied not directly on the control but after calculations and put into the bundle.
05-27-2020 07:13 AM
05-27-2020 07:16 AM - edited 05-27-2020 07:26 AM
In that case, you need to read and write values to and from the control. With your current VI, once the value of the control has been read and used to initialise the shift register, it is never touched again. You can use a property node to read or write the control value when required.
<Edit: adding VI snippet.>
05-27-2020 07:35 AM - edited 05-27-2020 07:37 AM
@MAILFERTSeb wrote:
Sorry, I built this example a little too fast.
Here is what I want to do:
1: use a control which is a cluster
2: change the values inside the cluster
3: when I want, use the current values of the cluster, make some calculations and then update the values of the control.
In this example, I can do more or less what I want except the update of the control after changes applied not directly on the control but after calculations and put into the bundle.
I've made a couple of updates to your code. First I moved your indicator into the timeout case and added a 200 ms timeout (this shows you the values that are in the cluster wire). Next I added a local variable to update the values of your control.
One additional recommendation - use Unbundle by name and Bundle by name. This makes reading the code much more clear, and you don't have to unbundle every element of the cluster to just get the one that you need.
05-27-2020 11:22 AM
Dear Johntrich (and all the people who reply),
thank you.
As I followed some NI courses where they ask us to avoid to used local variables (or property nodes) but prefer to use wires, I was lost.
OK, that's exactly what I did before, use local variables to change the status of a control when needed.
Now, I should be aware to your suggestions.
Thank you all.
Sébastien
05-27-2020 12:02 PM
CIML,
The courses are not wrong at all, this is a good recommandation. When you can, avoid locals and property nodes. One of the danger is often to update the control from different places, possibly almost at the same time and it creates a race condition. Here you update only at one place so you're good.
If your application makes it possible, you can still initialise the cluster with a constant and use the terminal itself instead of the local variable. (Like in the exemple I posted earlier).
Yddet
05-27-2020 03:01 PM
CIML, as Yddet said the courses are not wrong. Local variables should be used sparingly. Even with my modification there is a potential race condition, but it's likelihood is miniscule. It is not impossible that the user presses the button, then changes the value prior to the new values being written. As I said this is unlikely in the example given, but if you included code that took some time to execute you might want to disable the cluster control while you're doing your calculation.