Bug Report: VI is broken in executable but not in development system

[shb]

Attached is a VI which is broken in a built executable but runs in development node.

Please let the development system also show a broken VI or let the Runtime Engine accept this VI.

The problem is that the VI has subroutine priority and contains a static reference to a VI with another priority.

To reproduce include the VI in a build. (The VI can even be the only startup VI). Building passes but the executable reports an error after starting.

Tested LabVIEW Versions: 8.6, 2010 SP1, 2011

[G-Money]

shb,

CAR#337010 is about an IMAQdx VI that times out during aquisition. It is related to your discussion forum here (http://forums.ni.com/t5/Machine-Vision/Error-1074360293-IMAQdx-Timeout-after-running-acquisition-for... To me, it doesn't appear to be the same issue here that a VI is broken when built into an executable. Are you sure that CAR#337010 was filed for this bug report? Thanks!

[shb]

No, I'm not.

This confirms Problem #4 of Jack's suggestion for a tracking platform. I got the answer to something different than I wanted to ask for... This bug and the mentioned SRQ were mixed up.

[G-Money]

Moving your attached Failing VI from subroutinue priority to normal allows me to build and run it as an executable. Does this happen for you as well? I'll try and dig into the issue when I have time this afternoon but I am using LV 2011 and I see the same issue you have in 8.6.

[G-Money]

In your Failing VI you attached, there is a static VI reference on the block diagram for MD5Checksum string.VI. If you right-click on that static reference and select Open Front Panel it will open the MD5Checksum string.VI. If you open the VI Properties (File>>VI Properties) on this VI, you will see that it is set to run in normal priority. You can only call subroutine VIs from within subroutinue VIs. If you change MD5Checsum string.VI and the 3 subVIs on it's Block Diagram to run in the subrountine priority as well and save everything, you should be able to build and run it as an executable. Do you see this behavior?

[G-Money]

Forewarning, I haven't found an answer yet as to why this would work in the development environment and not the run-time but I am looking into it. I just wanted to report what I was tracking down as the issue and see if that was correct on your machine as well.

[G-Money]

I traced the issue down to that LabVIEW was allowing a Strictly Typed VI Reference that is a subroutine priority to call non-subroutine priority subVIs from within it. This shouldn't be allowed. If you change the VI Reference to not be Strictly Typed (right click on the VI Reference on your block diagram) then you should see the VI break in the LabVIEW development environment. What we were seeing when the VI broke in the run-time environment was actually proper. I have filed CAR#337788 for this issue.

[G-Money]

Moved to CAR database. CAR#337788

[shb]

I confirm the behaviour you described on 02-09-2012 for 8.6 and 2011.

In development mode, this breaks a SubVI with subroutine priority:

   

But this only breaks a VI with subroutine priority in runtime environment but not in development environment.

In words:

Calling a VI (with normal priority) by reference breaks a VI with subroutine priority. (first images)

Containing a typed and static reference to a VI with normal priority only breaks the VI in runtime. (last image) Why should this break the VI?

Thanks a lot for digging into and for moving it to CAR.

By the way, should the discussion go on somewhere else?

(And I regret not being able to give several kudos to Jack's Idea. I still failed to report my first bug by the official channel. )

Greetings,

shb