Weird behaviour with inlined SubVI's

[vekkuli]

Every now and then I've ran into some serious weird behaviour where I've eventually traced it down to some inlined subVI. It has seemed as if the values used inside the inlined subVI don't match what the calling VI is feeding into its inputs. I haven't been able to consistently reproduce this issue so I apologize for the vague description, but since I felt I should finally address this and I couldn't really find anything similar by searching, I'll do my best to describe it and we'll see what turns up.

As I mentioned, the issue certainly doesn't occur consistently. I use inlined subVI here and there and most of the time there are no problems whatsoever. I ran into the issues randomly I think four times now, first three of them were on LV2013 and this last time on LV2014. In all cases I have been using AF and I think the first times were actually with an actor class. At the time I thought it might have been related to the AF, and it still might, but now the last time it wasn't the actor class itself but a data member of one. So far all of the problems have occured with class methods, and I think the "corrupt values" have been the object private data, but I can't confirm this.

This time the inlined subVI was a static dispatch method with contents shown below on the left and the calling on the right.

I'm showing the calling just to point out that when I was investigating the problem and I probed the object wires before and after the inlined subVI the values (Calibration.X Step and Calibration.Y Step) were OK, but the result of the VI (Point out) was some insane value as if the actual division inside was performed by corrupt data. I think that the output value wasn't Inf, though, so the divider might not have been a default value such as 0.

Other notes:

• I checked that the wires are connected to the inputs and outputs
• As I mentioned, the projects have always been relatively large AF setups, the problematic method has been an actor method or a method called by an actor somewhere down the chain. I have no reason to assume AF is the culprit, I'm just pointing this out, just in case
• The problem seems to occur quite randomly but once it "starts" it doesn't go away until I find which inlined subVI it was and change it to a normal VI call
• The problem might not even be specifically inlined subVI related but for example pre-allocated VI related instead
• I don't know whether the problem would occur in a built executable as well, so far I've only ran into them while testing while developing and fixed them there
• Looking at the "Known Issues" related to inlined subVI's I don't know if this related to them. The other one deals with execution systems, which I haven't touched to my knowledge, and the other one says "An Inline public methodVI calling a private-scope method VI, inlined into a non-class caller may give a runtime error when trying to call the private method from the inlined code in the non-class caller."
• LabVIEW version is 14.0.1 (2014 SP1 32bit) on Windows 8.1

Yep, reading through this post I gotta say I'm not expecting much, what a mess, but it would be great to find out if anyone else has ever ran into similar problems or has a clue what's going here.

[mikeporter]

I don't even understand the code. The wires are heavy and orange (1d array of floats), but they are wired to LabVIEW objects and inside data is being extracted with an unbundler?!?

Mike...

[vekkuli]

Oh it's just a customized wire appearance, by GOOP maybe, I use both GOOP and the native LVOOP tools a lot.  The red thick wire is an object.

[Lirat]

Hi vekkuli,

Since it's being a while you didn't get an anwser, were you able to find out any solution or can we have an update on the current state ?

In order to better understand your application and have a better view on what could cause this issue, can you please provide us a larger scope of your application ?

Your descriptions is unfortunately not enough to catch this random behaviour.

Thank you.

Lirat MULAJ
Applications Engineer
National Instruments

[vekkuli]

No, I didn't pursue it any further. I changed the VI execution to default as usual. I understand that this description had very little to work on. Perhaps the only hope would've been if anyone else had ever run into similar issues; we could've started looking for some common ground. But if not, I doubt it's worth investigating much more, besides I wouldn't even know where to start. It's a project of hundreds of classes and thousands of VI's, everything works just fine then suddenly I start getting funky results that I ultimately find is caused by one single inlined VI that seems to for some reason use totally different values in it than what's actually wired into it.

[Intaris]

Just for the sake of your sanity, I've seen "funky" behaviour with inlined VIs also, but on Real-Time targets.

I've never been able to narrow down the exact problem but it seems to be related to changed made to inlined VIs not being reflected in the compiled code od VIs which call them.

I've reported it but without code which can actually reproduce it, it cannot be fixed.

[Sam_Sharp]

Have you tried a force recompile (Ctrl+Run / Ctrl+Shift+Run) on the SubVI/calling VI? Does that fix the issue?

[Intaris]

For me forcing a recompile on the VI which calls the inlined VI (or almost ANY VI above it in the hierarchy) did the trick and has become standard for me to avoid this problem.

[vekkuli]

I suppose a sort of VI compilation problem might explain the inconsistency of it. I can't remember for sure if I tried recompiling specifically, but I'll make sure to try next time I get it. I'll report back here then. Thank you for the input.