race condition for front panel controls used as read/write causes loss of writes consistently, help

[dkeegan]

Hi all, first time poster here.

I've been working in LabVIEW for about a year, work was nice enough to put me through Core 1 and Core 2, and I've found a race condition (99% certain) that I can't find a good workaround for, so I'm posting here to ask for help.

In my MotorLabNext_v2.vi (block diagram is ~2x2 screens at 2560x1440, front panel is written for 1x1 of 1920x1080), in the Setup State, I am attempting to:

• allow user input to a Control array of clusters of booleans (Record and Remove) [problems here]
• show only the correct size of boolean cluster array as the Power Display Array (one instance of Record/Remove per Channel Cluster shown on the Power Display Array),  [this works]
• scroll the Record/Remove array of clusters when the Power Display Array is scrolled [this works]
• and lastly show the current Channel information after the master Channel Cluster Array is filtered for each data type (AI Voltage, AI Temp TC, ect). [problems here]

User Input for Remove? boolean works correctly (*the value passes correctly, but the display part of the code ignores the new setting), and the channel is removed from the display array (and the boolean array usually resizes to match, but not always).

User Input for Record? boolean re-sets to the previous display value and does not save the user input at all

Add Channel calls the AddChannelPopUp.vi, which does correctly pass the new channel string out (confirmed with Probes), but then it isnt reflected in the display, and is subsequently lost from the data stream (also confirmed with Probes).

So my question is mostly this: how can I write to the front panel control or indicator and still be able to read from it, without losing data in the race condition I likely created?

[wiebe@CARYA]

---

@dkeegan wrote:

In my MotorLabNext_v2.vi (block diagram is ~2x2 screens at 2560x1440,

---

Pretty sure that's not what they teach you in core 1 and 2. Or is that lesson core 3?

It should fit one screen, and if you really (really) need more, make it either 1XN or NX1. At least you'd be scrolling in one dimension.

---

@dkeegan wrote:

So my question is mostly this: how can I write to the front panel control or indicator and still be able to read from it, 

---

Locals and Value properties do that.

---

@dkeegan wrote:

 without losing data in the race condition I likely created?

---

That's going to be hard to tell without the hole picture. The metaphorical 'hole picture', not a screenshot. A VI would be best.

You might need to synchronize the property nodes with the read of Rmv\Rcrd Power.

There is some weirdness in your code, but it's hard to tell if it's causing the problems. It's hard to tell what it should do in the first place.

Why is nonTC Channel View inside the for loop? That suggests it can change during iterations.

Why is the disable property node of nonTC Channel View in the for loop? That will update for each iteration, but only the last one will stick (use last value tunnel on the for loop).

Why write Power Display Array and then read it again? Simply use the wire.

In general if you want to respond to actions, you'd use an event structure.

But that's probably core 3 material...

[dkeegan]

---

wiebe@CARYA wrote:

---

@dkeegan wrote:

In my MotorLabNext_v2.vi (block diagram is ~2x2 screens at 2560x1440,

---

Pretty sure that's not what they teach you in core 1 and 2. Or is that lesson core 3?

It should fit one screen, and if you really (really) need more, make it either 1XN or NX1. At least you'd be scrolling in one dimension.

You're correct that not using large screens is suggested. I typically prototype code additions in larger screens, and then create and save subvi's from working code. Once I have created the subVi's and verified everything still works, then I remove excess whitespace. I agree that scrolling in only 1 direction is optimal, if one must scroll a block diagram.

---

---

@dkeegan wrote:

So my question is mostly this: how can I write to the front panel control or indicator and still be able to read from it, 

---

Locals and Value properties do that.

I showed that I'm aware of this in the code I attached to my post.

---

@dkeegan wrote:

 without losing data in the race condition I likely created?

---

That's going to be hard to tell without the hole picture. The metaphorical 'hole picture', not a screenshot. A VI would be best.

---

I provided my entire code base as an attachment to my post. That should give you the whole picture.

I'm not fond of creating event structures for each and every item from multiple arrays of clusters - there should in theory be a better way to do it.

---

You might need to synchronize the property nodes with the read of Rmv\Rcrd Power.

There is some weirdness in your code, but it's hard to tell if it's causing the problems. It's hard to tell what it should do in the first place.

---

Yeah, I'm aware this is not the best way to do this.... that's why I'm asking for help. The intent of this section of code is to display the array of channel data clusters, and remove items from that array in near-real-time when the Remove Boolean associated with that cluster is marked True (User Action). The removal happens due to a SubVi that is off-screen from the screenshot. Once the user is satisfied with the on-screen settings for all displayed clusters, I pass it to the next state in the state machine (not shown in screenshot, not completed in posted code) for splitting the data out to the appropriate DAQmx data collection structures.

---

Why is nonTC Channel View inside the for loop? That suggests it can change during iterations.

---

Correct

---

Why is the disable property node of nonTC Channel View in the for loop? That will update for each iteration, but only the last one will stick (use last value tunnel on the for loop).

---

In a previous line of thinking, the user would have been able to edit the Cluster data in real time on the front panel. This did not work out for me. The disable property is a holdover that hasn't been removed/accounted for.

---

Why write Power Display Array and then read it again? Simply use the wire.

---

If I do as you suggest, I cannot interact with the data on the front panel at all - using the wire ignores any user interaction.

---

In general if you want to respond to actions, you'd use an event structure.

But that's probably core 3 material...

---

Yes, I'd love to take Core 3, but that's not currently an option. If you have time to look through the code I posted and provide a more complete reply, I'd really appreciate it.

[wiebe@CARYA]

---

@dkeegan wrote:Once I have created the subVi's and verified everything still works, then I remove excess whitespace. 

---

As long as it's on the agenda!

---

@dkeegan wrote:I provided my entire code base as an attachment to my post. That should give you the whole picture.

Did I miss that or did you add it? Not sure if that's even possible, doesn't really matter now anyway.

---

@dkeegan wrote:I'm not fond of creating event structures for each and every item from multiple arrays of clusters - there should in theory be a better way to do it.

You should never create more then one event structure in one VI.

You don't even need to create more then one event case, it can handle multiple events.

---

@dkeegan wrote:

---

Why is nonTC Channel View inside the for loop? That suggests it can change during iterations.

---

Correct

---

Why write Power Display Array and then read it again? Simply use the wire.

---

If I do as you suggest, I cannot interact with the data on the front panel at all - using the wire ignores any user interaction.

But the for loop will execute very fast, so nobody will be able to actually deterministically change values between iterations.

Same for the write\read action. This will execute in ns, how can someone change the value between the write and read?

I hope others will pick up, it's weekend for me.

[dkeegan]

---

@dkeegan wrote:I provided my entire code base as an attachment to my post. That should give you the whole picture.

Did I miss that or did you add it? Not sure if that's even possible, doesn't really matter now anyway.

---

I had it in the post, but didn't call it out in the post. You're correct, doesn't matter now.

---

---

@dkeegan wrote:I'm not fond of creating event structures for each and every item from multiple arrays of clusters - there should in theory be a better way to do it.

You should never create more then one event structure in one VI.

---

Correct, poor word choice on my part. I'm not fond of creating an event case for each item.

---

You don't even need to create more then one event case, it can handle multiple events.

---

This I apparently need to learn more about, thanks for pointing out that it's possible.

---

---

@dkeegan wrote:

---

Why is nonTC Channel View inside the for loop? That suggests it can change during iterations.

---

Correct

---

Why write Power Display Array and then read it again? Simply use the wire.

---

If I do as you suggest, I cannot interact with the data on the front panel at all - using the wire ignores any user interaction.

But the for loop will execute very fast, so nobody will be able to actually deterministically change values between iterations.

Same for the write\read action. This will execute in ns, how can someone change the value between the write and read?

---

Turns out that it does change the value for about 1 while loop cycle, which is enough time for the Remove function to act. You're correct though that it does ignore any user input, in either case, that takes more than 1 loop cycle to input (cause it wipes the front panel during the Write).

---

I hope others will pick up, it's weekend for me.

---

Have a great weekend, thanks for helping me poke at my code! I'm thinking that my short-term workaround might need to be a pop-up similar to my AddChannelsPopUp.vi that does the Remove Channels thing outside of the loop, but I'd love to hear from others if they can get something working in a more in-line fashion.