Changing cluster values in while loop and in the front-panel simultaneously

[DennisBengs]

Hello.

I have a small problem in a test program I'm working on. I'll try to simplify it as much as possible. I have a cluster control containing two controls A and B. I Wish to:

1. Update the value of control A in a while loop
2. Allow the user to change the value of control B through the front-panel while the loop is running

To change the value of control A in the while loop I first get the cluster from the cluster control, update the value of control A using Bundle By Name, and finally write the cluster back to the cluster control.

The problem is that if the user changes the value of control B while control A is in the middle of updating, the new value for control B is lost since it was read before being updated in the front-panel. Is there any way to get around this?

[GerdW]

Hi Dennis,

use two numeric controls/indicator A & B on your front panel. In the BD you can combine both values in a cluster…

What you describe is a RACE CONDITION. There are techniques to avoid them - read the LabVIEW help!

[DennisBengs]

Hi GerdW.

Thank you for your suggestion. The reason why I use a cluster control on the front-panel instead of just the A and B controls is because I will be using an array of identical controls, ie an array of cluster control with A and B controls.

I read up on how to solve race conditions. One suggestion was to use semaphores. However, I haven't found any documentation how you can use semaphores to restrict acces to either a block or the front-panel.

Another VI I found which I thought may be useful was the Wait For Front Panel Activity VI. But I'm not sure how.

[GerdW]

Mind to attach your VI you talked about in message #1? (LabVIEW2011 preferred)

The main point is: you are writing to a cluster while the user may do the same (even when your VI and the user change different elements of the cluster). So you will have a race condition anyway - and you need to prevent that. Easiest solution: independent controls.

You should make a difference between data storage in your VI (array of clusters) and FP presentation (maybe individual controls). This may help in preventing race conditions and could also impove UX…

[DennisBengs]

I haven't created the example yet, and the test program I'm working on is rather noisy.

But the basic idea is this: Loop(Read cluster control > Bundle by name > Write cluster control).

I don't know how to prevent the race condition with the front-panel when the user edits the cluster at the same time.

Edit: Yes. If there is no other way I will have to seperate the controls into seperate arrays. I was hoping to avoid that due to the number of controls and indicators related to the clusters (they represent data channels).

[GerdW]

Hi Dennis,

here's a simple example using the event structure…

[crossrulz · Accepted solution]

---

@DennisBengs wrote:

1. Update the value of control A in a while loop
2. Allow the user to change the value of control B through the front-panel while the loop is running

---

Then they don't belong in the same cluster.  They are obviously disconnected enough that they do no belong together.

Where this can get really tricky is you are talking about the user and code changing the same cluster.  That is very dangerous and extremely hard to manage.  You might be able to get there with an Action Engine.  But tread lightly, my friend.

[DennisBengs]

Thanks again GerdW. Although it doesn't solve this problem, I didn't know about the events structure before and it will be very useful in the future.

crossrulz: That is what I feared. If putting all the controls in one cluster doesn't work I will have to put my boolean values in a seperate array of controls and my graph indicators in another array.