03-23-2018 07:10 AM - last edited on 04-02-2018 08:23 AM by Kristi_Martinez
Hi,
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
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)
03-23-2018 09:10 AM - edited 03-23-2018 09:11 AM
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.
03-28-2018 12:02 PM
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)
03-29-2018 04:01 PM
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
03-29-2018 04:31 PM
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.
03-29-2018 05:08 PM
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).
03-30-2018 04:55 AM
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).
03-30-2018 06:04 AM
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.