LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Is there a way to modify a single value of an array without rewriting to the other elements?

I'm seeing the same problem.  In my mind the issue occurs when the user clicks a boolean in the time between when the control is read and when it is re-written using the local.  I've tried a few things to shorten that time as much as possible, but I still observe the same behavior (although at a much lower rate).

 

Based on the code I would expect that the boolean where the line is sweeping would be correct and at worst the user's click would get ignored.  However, that isn't what's happening.  Instead the boolean where the line is sweeping doesn't get updated and who knows what happens to the boolean that the user is clicking.

 

I'm not sure how to fix this.  This is really bizarre.

 

-DR2

0 Kudos
Message 11 of 18
(672 Views)

It is not bizarre, it behaves exactly as expected from the current code.


LabVIEW Champion Do more with less code and in less time
0 Kudos
Message 12 of 18
(663 Views)

So I am also noticing some weird behavior, but only when using the local variable to write back to the array.  If I used a Value Property Node to write to the array everything works as expected.  If you spam one of the booleans like mad while the bar is moving along and you are using a local variable the inversion switch will work most of the time, but not all of the time.  What is the difference between local variables and property nodes that could cause this difference in behavior?

0 Kudos
Message 13 of 18
(654 Views)

The front panel updates asynchronously, so a local variable just updates the transfer buffer. a value propeprty node executes synchronously, forcing a thread switch, thus the performance impact.

 

You simply need to deglitch the operations by keeping more state information.

 

If you hammer some other boolean, you run into a typical race codition. If you change the value right before the local variable is written, you get the value of the local variable instead of the user entry. All this can be solved.


LabVIEW Champion Do more with less code and in less time
0 Kudos
Message 14 of 18
(649 Views)

altenbach,

 

I understand the race condition you are talking about.  I posted a quick video of the behavior I am seeing.  I am spamming the second from left boolean on/off multiple times as fast as I can.  When the decoration bar comes around the second time watch the 4th from left boolean.  Instead of going False -> True -> False it just goes False -> True and then moves on to the next one.  Is this the behavior that you are also referring to as expected and can be fixed with additional state information?

0 Kudos
Message 15 of 18
(632 Views)

Yes


LabVIEW Champion Do more with less code and in less time
0 Kudos
Message 16 of 18
(629 Views)

@altenbach wrote:

If you hammer some other boolean, you run into a typical race codition. If you change the value right before the local variable is written, you get the value of the local variable instead of the user entry. All this can be solved.


This still seem odd to me because it does not appear to be the local variable written out (which in my mind should return the array element to true because we are modifying the array in this way) but rather the user entry seems to overwrite the other.

 

Either way, in your opinion would the extra coding/computation associated with keeping more state information be more or less of a performance impact than using a property node to force the synchronous behavior?

 

If keeping more state information is less of a performance impact, do you have any pointers to help me along that path. I really don't have a clue what you mean by that.

 

You wrote earlier "All you probably need is another shift register holding state information" I thought that maybe that’s what I was doing with the hidden control and local variable, as well as other ways I have tried storing it (such as an additional array element at the end that was not displayed) but these seemed to have the same problem. Maybe because it had the same asynchronous situation? I will see if using a specific shift register for that bit does it (I was about to try this at one point and thought stuffing it onto the end of the array would be a bit cleaner).

 

Thanks again for your help.

 

 

0 Kudos
Message 17 of 18
(595 Views)

No luck. I tried using a shift register to hold the old value of the bit being programmatically changed but still saw the undesired behavior.

 

I guess I still don't know what you mean by keeping more state information.

Any help is still greatly appreciated.

Thanks

0 Kudos
Message 18 of 18
(586 Views)