Showing results for 
Search instead for 
Did you mean: 

LabVIEW RT Incorrect Function Execution Scheduling


I have the following BD from a VI running on a real-time system (cRIO-9035) using LabVIEW 2015 SP1f10. I noticed that the bottom For loop was not executing the code from the TRUE case even if input boolean array contains only TRUE elements (see the probe window).

I think I know why this happens but I don't believe it's the correct behavior: LabVIEW sees that "MC Configured" array is to be modified using Replace Array Subset function and so decides that a copy will not be needed. However, it does not schedule the bottom For loop to be executed before the upper loop so the values indexed in bottom loop will be already modified. If I force the execution of the bottom loop to be executed first, the problem is solved.

LabVIEW help says that if you use an Index Array and Replace Array Subset function wired to the same array without forcing the execution order, the compiler will schedule the Index Array function to be executed first to avoid a copy of the array. I don't know why in my case this is not working. Any ideas? I could not reproduce this on Windows.

The values of the counters inside the For loop are: FL Ctr=4, Send msg ctr=0


RT CTRL VI edited.pngProbe window.png

Edit: I managed to reproduce it on Windows as well and executed on 2 computers: on one computer, "Send msg ctr" is 1, on other is 0.(LV15SP1)


0 Kudos
Message 1 of 8

I ran this in 2017 SP1 and saw the same thing.


If I remove the shift register, it works correctly (FL Ctr=4, Send msg ctr=4).


Definitely seems like unexpected behavior to me, you'll probably want to execute your top loop after the bottom one as a workaround.



0 Kudos
Message 2 of 8

This is the biggest bug I ever encountered in LabVIEW. So a wire can have 2 different values in the same moment (probe 1 and 12)

0 Kudos
Message 3 of 8

I'm running the program and getting 2 as the output for "Send msg ctr." How strange... I'm going to investigate this further here at NI and see if a corrective action report needs to be made. I will keep you updated!


Francine Penikis

Applications Engineer

National Instruments



Francine P.
Applications Engineering
National Instruments
Message 4 of 8

Hi Lucian,


Interesting problem ! Were you able to reproduce it with another VI or is it the same VI that causes the problem over and over again ? Does it happen all the time ?


I tried to recreate your VI from scratch and I can't reproduce this phenomenon. And weirdly enough, setting the boolean constant to TRUE and back to FALSE seems to solve the problem. Might just be a "minor" corruption of your VI.

CLAMaxime -- Kudos are a great way to say thank you
0 Kudos
Message 5 of 8

I just tried a Force Recompile (ctrl+shift+Run) of the VI and the VI still didn't run.


There are definitely several workarounds for this issue (force execution order, recreate the VI from scratch).

0 Kudos
Message 6 of 8

To overcome this bug is not a problem. As I said, I force the execution of bottom loop to be done first and the problem is solved. It remains a problem of the environment that, in my opinion, should create a copy of the boolean array in this case or at least display a warning.

Thanks Francine for looking into this!

ML927, I was able to reproduce the behavior in a different VI running on Windows that was attached in the first post. In the meantime I created a different VI from scratch and obtained the same behavior. It happens all the time and I tested on 3 computers (all LV2015 SP1):


It seems that if you move the boolean array outside of the cluster and work only with the array, the problem is gone or I could not reproduce it (yet).

Message 7 of 8

Thanks for the info. I wonder if it comes from the cluster being changed ? It would be interesting to check if it happens with something else than an array.

CLAMaxime -- Kudos are a great way to say thank you
0 Kudos
Message 8 of 8