Highlight Execution code behaves differently

[jcswright]

Hello,

I have been playing around with the attached VI, just to confirm for myself how dataflow works.  I was curious to know whether the value of the indicator 'numeric duplicate' in 'Consumer Loop 2' would update if I changed the value of 'numeric' after the program had started.

What I don't understand is that if I do the following:

1. Run the program

2. Click 'Start Updating 1'

3. Change the value of 'numeric'

4. Click 'Stop updating'

I get different results depending on whether Highlight Execution is on or not.  If it's on, then 'Numeric Duplicate' gets updated with the value I put in 'numeric', but if highlight execution is off, it doesn't.

Please could someone let me know why that is?

Many thanks,

Jonathan

I am using LabVIEW 17.0 Base.

[JensG69]

In general: With highligthing activated the code runs much slower and perhaps even in another order than without since the dataflow has to be visualized.

Next general point: everything that can run in parallel will run in parallel.

That's an important point for your "lowest" loop without the highlighting activated, because the following will happen:

After "Obtain queue", the loop will start. It will read out the current value of "Numeric", make a copy of that value and hand that over the wire to the "input" of the case structure. At more or less the "same" time it will start the "dequeue element", which will then wait for a queue element. So when your press "stop updating", the value from the starting time of the loop will be copied and written to "numeric 2"

When you activate highlighting, things might be so slow that you get the currently displayed value of Numeric handed over to "Numeric 2".

Regards, Jens

[jcswright]

Thank you Jens, I understand what you're saying but I'm not sure that is the case here.

With highlighting activated, I was still waiting for the lower loop to reach a 'steady state' (all the data had flowed along all the wires) before I pressed the button to enqueue an element - after which surely all the data has to get to the case structure before it will execute anyway?

Without highlighting activated, the lower loop should just get to that same state faster, shouldn't it?  There is nothing in there that can have a different value if it runs faster than something else - in fact that 'numeric' wire doesn't interact with anything, it just sits against the case structure until an element is dequeued.

[altenbach]

Try putting "numeric" inside the case structure, right next to the duplicate indicator. This way the terminal read waits until the case executes.

Unless you press "start updating 2" at least once, the tunnel connected to the numeric has the value from when the program started, no matter how many times you change the control during the run.

[jcswright]

Hi Jens

I owe you an apology - the code was actually working fine (although as altenbach pointed out, it wasn't right in the first place which was because I was experimenting with something).

However, the bit that wasn't working was my head.  I ran the code with highlighting turned off first, then with it on.  The result I saw was just because I wasn't initialising any values - so the last values from the previous run were being used.

I wish there were a way to delete threads when you realise you shouldn't have asked the question in the first place!