Selecting "inline subVI" seems to be disabling constant folding

[crossrulz]

---

@JÞB wrote:

---

@crossrulz wrote:

---

@JÞB wrote:

Something is definatly not right.

---

Did you notice that your parallel FOR loop finished IN THE PAST!!!  Yeah, I'd say something got screwed up there.

---

YUP.  That's when I went and hid.  

Then before Dr. K could arrive and make me look foolish

---

That's right.  When in doubt, always copy...

[InfiniteNothing]

How does forcing a copy make a difference? Is that part of the weirdness?

[crossrulz]

---

@InfiniteNothing wrote:

How does forcing a copy make a difference? Is that part of the weirdness?

---

No, it just means NI's compiler is screwing up.  The compiler tries to reuse data buffers whenever possible to keep memory low.  Every once in a while, we find a case where the compiler messes up and the simple cure is to force LabVIEW to make a data copy.

[Hooovahh]

---

@InfiniteNothing wrote:

How does forcing a copy make a difference? Is that part of the weirdness?

---

Shall I add it to my list of LabVIEW band-aids?

http://forums.ni.com/t5/LabVIEW/Waveform-palette-quot-What-quot-s/m-p/2900134#M841136

[Darin.K]

There is definitely a bug in play here.  Back in the early days of inlining, no compiler optimizations were performed inside structures (Diagram Disable or Flat Sequence Structures for example).  Inlining a VI places the contents inside a virtual Flat sequence structure to maintain timing.  In LV10 I would call this expected, but by LV12 I think  these optimizations take place even inside structures.  This is a throwback to the old days, and not a pleasant one at that.

As to the Always Copy, the preferred solution would be to move the wire branch outside of the FSS.  Optimizing across node boundaries is difficult and there are many ways in which LV screws it up.  Usually the screw up is an extra data copy here or there, but sometimes like in this case you get aliasing.  Get used to minimizing tunnels:  branch inputs inside a loop/structure, branch outputs outside.

[crossrulz]

---

Darin.K wrote:

As to the Always Copy, the preferred solution would be to move the wire branch outside of the FSS.

---

I did try that and it still didn't work.  I event tried the Always Copy outside of the FSS and still got a negative time value.  To which I went "Well, that's weird.  Crap, I need to get this project done!"

[Hooovahh]

---

@crossrulz wrote:

I did try that and it still didn't work.  I event tried the Always Copy outside of the FSS and still got a negative time value.  

---

On a few occassions LabVIEW would do something so strange, and unexpected that it made me question all I know about data flow and graphical programming.  Getting negative time might be one of those cases where I just go home for the weekend.

[Darin.K]

This is totally crazy so I wished I could run out and test a few things but I do not have LV13 going right now.  I will make a few crazy guesses.

My guess is that aliasing is fooling the second FSS into thinking its inputs are ready way too early.

Test 1:  Put the Always copy on the orange (or blue) wire between the For Loop and the last FSS.  My guess is that will fix it.

Test 2:  Remove the Always Copy.  Super crazy, but if my guess is correct, or at least in the ballpark then it should get very interesting.  Insert a new FSS into the orange wire between the For Loop and the FSS.  Inside the FSS put a msec wait with a large value 10, 100 or even 500 msecs.   If my aliasing guess is correct then you should still see a violation of causality, only this time it should be obvious.  Unless of course adding the FSS has a similar effect to Always copy.

If the VI takes a second to run but the time still shows up negative, that would be cool.

[JÞB]

Once always copied and compiled. The ac can be safely removed as I found at work... I have no idea how reproduceable that is or where or what targets... It makes an interesting side note.

[JackDunaway]

---

@Darin.K wrote:

This is totally crazy so I wished I could run out and test a few things but I do not have LV13 going right now.  I will make a few crazy guesses.

My guess is that aliasing is fooling the second FSS into thinking its inputs are ready way too early.

Test 1:  Put the Always copy on the orange (or blue) wire between the For Loop and the last FSS.  My guess is that will fix it.

Test 2:  Remove the Always Copy.  Super crazy, but if my guess is correct, or at least in the ballpark then it should get very interesting.  Insert a new FSS into the orange wire between the For Loop and the FSS.  Inside the FSS put a msec wait with a large value 10, 100 or even 500 msecs.   If my aliasing guess is correct then you should still see a violation of causality, only this time it should be obvious.  Unless of course adding the FSS has a similar effect to Always copy.

If the VI takes a second to run but the time still shows up negative, that would be cool.

---

So, after doubting my own sanity for a while, then doubting LabVIEW, a search for "labview parallel for loop constant folding bug" leads here.

@Darin.K, your hunch is correct. Here is a minimal test case that shows code following a Parallel For Loop is not scheduled properly. The snippets are in LabVIEW 2014, and I have confirmed the bug still exists in 15.0 32-bit.

Here's a variation with the same result, yet is a bit more surprising -- unlike the first test case, here we get rid of the loop invariance:

Here's a variation of that, but with indexing:

And finally, to ensure no funny business with optimizing away a single-iteration For Loop, here's the same undesirable behavior with a Control for the Iterations input:

Cue CAR.