Subroutine VIs should accept inlined subVIs

[SteenSchmidt]

Hi,

Currently if a VI is set to subroutine priority you can only call subVIs within that which are also subroutine priority (to prevent priority inversion I guess).

It would be great if it was possible to also use inlined subVIs inside subroutine VIs.

As inlining basically defeats a VI's priority setting an inlined subVI would just "inherit" the subroutine priority of its caller. I configure many of my very small reuse VIs  as inlined (most of those in the GPower Error & Warning toolset from v2.1 onwards for instance), since they typically perform much better than subroutine that way. But since they are configured as inlined, this effectively prevents them from being (re)used inside subroutine VIs.

Cheers,

Steen

[GuenterMueller]

I like it. If you insert a VI that e.g. contains a call to an asynchronous node this would just break the subroutine VI. So there would be no behaviour change to LabVIEW.

[AristosQueue (NI)]

Ha. Good catch, Steen. I think that use case just flat out got missed in the test matrix. I'll pass this along to the team who own those features to see if they can coordinate. 🙂

[SteenSchmidt]

Superb 🙂

What does it mean anyway, when a VI is both inlined and set to subroutine? I think the inlining setting is ignored in this case, but if so shouldn't the inlining option be grayed out in the Execution settings page when 'subroutine' is selected?

/Steen

[CMal]

---

@SteenSchmidt wrote:

What does it mean anyway, when a VI is both inlined and set to subroutine? I think the inlining setting is ignored in this case, but if so shouldn't the inlining option be grayed out in the Execution settings page when 'subroutine' is selected?

---

It's actually the other way around.  If a VI is both inlined and subroutine, the subroutine setting will be ignored and the VI will be inlined into its caller's code.

[SteenSchmidt]

---

@CMal wrote:

It's actually the other way around.  If a VI is both inlined and subroutine, the subroutine setting will be ignored and the VI will be inlined into its caller's code.

---

But if both inlining and subroutine is selected, that VI will no longer accept subVIs that are not themselves set to subroutine. So inlining does not defeat subroutine priority entirely. There's something amiss there as well.

/Steen

[CMal]

---

@SteenSchmidt wrote:

But if both inlining and subroutine is selected, that VI will no longer accept subVIs that are not themselves set to subroutine. So inlining does not defeat subroutine priority entirely. There's something amiss there as well.

---

If both settings are enabled, then the VI will be compiled and executed as if it were only inlined, but the editor will behave as if it were only set to subroutine.  I agree that this is strange, which is why I think this is such a good idea.  Ideally, I think LabVIEW should somehow tell you that the subroutine setting will be ignored when both settings are enabled.

[SteenSchmidt]

10-4.

The editor should perhaps gray out all the non-functional controls (such as 'Priority') in the Execution page of the VI Properties dialog, when inlining is selected?

/Steen

[smithd]

Hey All,

I tend to use this combo a lot and have filed a series of bug reports late last year and early this year. You can look for these numbers with each LabVIEW release to see if the issue has been fixed. 

390021--This specific idea.

383301--If you have this situation and use edit>>create subVI it will cause weird things to occur...so be careful 

338991--more along the lines of the second point, that the dialog itself has confusing information when you enable inlining and subroutine.

In case someone out there decides that 390021 isn't actually a bug I kudo'd this too 🙂

Thanks,

Daniel