Local variable value not same as indicator

[jbphili]

I am using Highlight Execution to debug a problem. I noticed that while the Front Panel is showing the boolean as True, in Highlighted Execution it is showing as false.

Why would such thing happen?

My application is based on the Continuous Acquisition Template. The problem I am trying to debug is that somehow my application is not ignoring the sequence error when I want it to. I thought it isa race condition, but with highlighted execution I'd expect to see it happen and I don't.

I attached the screen show and the vi. I'd really appreciate any help.

Thanks.

[tyk007]

---

@jbphili wrote:

I am using Highlight Execution to debug a problem. I noticed that while the Front Panel is showing the boolean as True, in Highlighted Execution it is showing as false.

Why would such thing happen?

My application is based on the Continuous Acquisition Template. The problem I am trying to debug is that somehow my application is not ignoring the sequence error when I want it to. I thought it isa race condition, but with highlighted execution I'd expect to see it happen and I don't.

I attached the screen show and the vi. I'd really appreciate any help.

Thanks.

---

The problem with race conditions is that timing is everything. Using execution high-lighting affects timing - therefore you have no guarantee that the race condition would be exposed.

Looking at your screenshot I would suggest your guess of a race condition is probbaly on the money. Easy to happen if local variables are over-used.

[crossrulz]

As many places as you are writing to that local, and in multiple loops, you very likely have a race condition.  Maybe you need to modularize your code some more and come up with a better communication scheme than a local variable.

[jbphili]

Wouldn't using highlight execution slow everything enough that I can see the timing problem? This variable is only set to True when buttons are pressed. While it is possible that it got reset to False after the button is pressed (which is my initial assumption), the indicator on the Front Panel does not show it is False. So if it is a racing problem I'd expect to see the indicator on the front panel accurately represent the value?

[tyk007]

---

@jbphili wrote:

Wouldn't using highlight execution slow everything enough that I can see the timing problem? This variable is only set to True when buttons are pressed. While it is possible that it got reset to False after the button is pressed (which is my initial assumption), the indicator on the Front Panel does not show it is False. So if it is a racing problem I'd expect to see the indicator on the front panel accurately represent the value?

---

Short answer - no. Long answer - Race conditions exists because, logically, you can't predict the order in which of two or more actions occur that cause different out-comes. Execution high-lighting will force your code to execute in the single UI thread (colloquially) but will not prove or disprove that you have a lack of control over the order of the events in your code. Do not forget that LabVIEW permits free parallelism of your code but provides no guarantee as to the order of those parallel activities since - by definition - they are in parallel.

You shuld modularise and control the access to your shared states as suggested. It will save you grief in the long run.

[Dennis_Knutson]

And while you are giving the local variable problem, get rid of the stacked sequences. They were removed from the top palette for good reasons.

[jbphili]

I know highlight execution does not disprove racing condition does not exist, but I was hoping as I can see the error occuring slowing the execution down would at least let me see what exactly is going on and confirm racing condition, since I am pretty new at LabView programming.

Sounds like it's somehow expected if the values of the local varilable may be different as the display value as the indicator? That's really what's perplexing me the most.

Modularize sounds great but I am not exactly sure how to do it as this point. Same for stack sequence, it was the best way I can think of to control sequencial execution at the time.

I'd feel better if I can confirm it'll indeed fix my problem before I spent all the time doing so.

[altenbach · Accepted solution]

Whatever that little "F" near the structure tunnel shows is the value that the local variable had the last time it was read. the "F" will not magically change to something else until the next time the local variable is being read, and that entirely depends on the loop rate of that loop. When you do execution highlighting, the loop rate is very slow and since many other places write to that indicator via local variables, there is no way of telling from the diagram what its value at any given time. Only the front panel will show the current state, that's what the front panel is for. 😄

[jbphili]

Thanks. I guess I don't have much control over when a variable is read.

I added a semaphore and everything worked. Thanks.

[altenbach]

---

@jbphili wrote:

I guess I don't have much control over when a variable is read.

---

Yes, you can have full control. Just use proper dataflow and a well designed state machine. 😄