Jump to content

Subroutines and Inline VIs


Recommended Posts

Hi gang, it's been a while.

I'm trying to squeeze performance out of one of my consumer loops which is being outpaced by it's producer and came across this little ditty:

subroutine inline.png

Full error text: Subroutine priority VI cannot call a non-subroutine priority subVI.

The rub here is all the SubVIs called are inline accessor methods, but LabVIEW won't have any of it since they're not explicitly given the subroutine priority. The errors clear if I assign the inline VIs to subroutine priority. Is this intended?

TL;DR: It would seem the inline code preserves its priority setting independent of the caller. Or it's a bug.

I get that inline code doesn't quite act the same as if you'd dropped the same code onto the calling diagram. There's an implicit context at play, as if you had slapped a single frame sequence structure around your code. If I have an inline VI that simply rotates an array for example and call it from another VI we effectively get:

caller.png

The sequence frame must be implicitly added to preserve order of execution (I'm not implying an actual sequence frame is added, this is just how to visualize what's happening). What I don't expect is for the sequence frame to have it's own execution priority. I'll argue an inline VI should be usable in any context since the code contained becomes part of the calling context and should inherit the relevant context properties (priority, preferred execution system).

I'm even more alarmed that the inline code may preserve the preferred execution system. If I use an inline VI which has a different execution setting, am I at risk of introducing unexpected context switches in my code? This would contradict the very reason to make a VI inline to begin with!

Edited by mje
Link to comment

I'm not quit sure what you are getting at here. You start off with sub-routines and are worried about inline priorities at the end (which I'm pretty sure is ignored and not sure how you tested it wasn't).

An answer to the obvious question though is: Yes it is intended and has always been so. It is a restriction on use in the same way that class methods can only be "Shared" reentrant and not preallocated.

Link to comment

Fantastic, thanks jacobson.

Shaun, the issue was a subroutine VI can't call inline VIs unless those VIs were also set as subroutine priority. The priority of an inline subVI should make no difference (nor should the execution system for that matter).

Since there's a CAR that describes this, it would be a bug so there's no worry. If it had not been a bug there would be some serious ramifications.

Link to comment
8 hours ago, mje said:

Fantastic, thanks jacobson.

Shaun, the issue was a subroutine VI can't call inline VIs unless those VIs were also set as subroutine priority. The priority of an inline subVI should make no difference (nor should the execution system for that matter).

Since there's a CAR that describes this, it would be a bug so there's no worry. If it had not been a bug there would be some serious ramifications.

Yes. I think the confusion is that subroutines aren't really a priority, rather another type of VI. I suppose I know that intuitively so didn't see the relevance when you talked about in-lining and priorities.

Quote

It is important to understand that subroutine classification is not a true priority. “Subroutine” denotes that this VI is no longer a standard VI and that its execution and compilation are radically different from other VIs. Subroutine priority Vis do not have a priority associated with them, and they are never placed into the run queues of LabVIEW. Once all inputs for the subroutine are available, the subroutine will execute immediately, bypassing all run queues. The subsystem associated with the subroutine will stop processing tasks until the subroutine has completed execution. This might sound like a bad idea, but it is not. Having a routine complete execution ASAP is going to get its operation over as quickly as possible and allow ©2001 CRC Press LLC LabVIEW to do other things fairly quickly. Subroutines are a bad idea when very time-intensive tasks need to be done because you will block the run queue for a subsystem for an extended amount of time

Source Chapter 9.9

We should try and get that document int our wiki/blog/articles or whatever-it's is the definitive guid to LabVIEW under the hood.

  • Like 2
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.