LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Asynchronous Nodes

I was updating some code from my LabVIEW 2014 library to 2016, and strangely I got an error on something very simple.

Broken.png

 

This Demo of my VI works well in LabVIEW 2014 when the VI is set to Subroutine Priority. However, when upgrading to 2016 (or 2015) it returns a broken error with the following error:


Delete Data Value Reference: Subroutine priority VI cannot contain an asynchronous node

This VI has subroutine priority selected in VI Properties»Execution. It may not use an asynchronous node on its block diagram. Asynchronous nodes allow other VIs to execute in parallel, which a subroutine should not do.


I understand it's a very easy fix. But I'm more interested in if this a bug with the 2015/2016 builds or perhaps we should be informed in documentation what are asynchronous nodes or why Delete DVR can't be in a subroutine, but the Create DVR can?

 

Certified-LabVIEW-Architect_rgb.jpgCertified_TestStand_Architect_rgb.jpg


"I won't be wronged. I won't be insulted. I won't be laid a-hand on. I don't do these things to other people, and I require the same from them." John Bernard Books

Message 1 of 11
(3,504 Views)

I tested your example in LabVIEW 2014 and 2015. If I change priority to Subroutine I always get an brocken error and the error message: "This object is not allowed in a VI on which you enable inlining. Disable inlining or remove this object." for both, "New Data Value Reference" and "Delete Data Value Reference".

 

0 Kudos
Message 2 of 11
(3,476 Views)

I'm not inlining, that is completely separate issue. I'm just converting the VI to subroutine priority. I'm not changing anything else on the execution properties screen.

Certified-LabVIEW-Architect_rgb.jpgCertified_TestStand_Architect_rgb.jpg


"I won't be wronged. I won't be insulted. I won't be laid a-hand on. I don't do these things to other people, and I require the same from them." John Bernard Books

0 Kudos
Message 3 of 11
(3,463 Views)

Sorry, I misunderstood your issue.

0 Kudos
Message 4 of 11
(3,454 Views)
I have a feeling that the delete DVR is actually asynchronous - I wonder if the compiler just tells the LV memory manager / garbage collection that it is marked for deletion and may/may not actually get deleted immediately.

LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 5 of 11
(3,450 Views)

The asynchronous part is not that the actual deletion may happen later, but rather that there may be a wait until the DVR is available to be deleted.  This wait is asynchronous, instead of blocking the original thread waiting for access to the DVR, a separate thread is launched and it is blocked while waiting.  This allows other nodes to execute in the original thread.

 

Subroutine SubVIs are single-threaded so these nodes are not going to be allowed.  In the past, perhaps the Delete DVR node was not asynchronous but simply blocked until it could access the DVR.

Message 6 of 11
(3,429 Views)

@Darin.K wrote:

The asynchronous part is not that the actual deletion may happen later, but rather that there may be a wait until the DVR is available to be deleted.  This wait is asynchronous, instead of blocking the original thread waiting for access to the DVR, a separate thread is launched and it is blocked while waiting.  This allows other nodes to execute in the original thread.

 

Subroutine SubVIs are single-threaded so these nodes are not going to be allowed.  In the past, perhaps the Delete DVR node was not asynchronous but simply blocked until it could access the DVR.

 

 


 


Alternately,  The practice of changing the priority of code calling these nodes to "subroutine" without "Inlining" was unanticipated (as in, "Who would do that?- it could cause issues") and, the error was not correctly flagged yielding some rather unsual behavior on extremely rare cases found "In-The-Wild."


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 11
(3,407 Views)

@JÞB wrote:


Alternately,  The practice of changing the priority of code calling these nodes to "subroutine" without "Inlining" was unanticipated (as in, "Who would do that?- it could cause issues") and, the error was not correctly flagged yielding some rather unsual behavior on extremely rare cases found "In-The-Wild."


Execution speed. In some cases the overhead of calling a VI in a tight loop is substantial. For a small VI subroutine priority can make a big difference. Of course it should be used with care since it has other consequences.

What definitely doesn't make sense it "subroutine" combined with "inlining", since the execution priority is ignored when a VI is inlined (it runs in the caller context).

 

On this specific case, though, I'm not sure. I'd expect you'd want to set a simple write subVI which runs in a tight loop to subroutine, but not a subVI which deletes the DVR.

0 Kudos
Message 8 of 11
(3,393 Views)

I'm specifically looking for information on how it's expected for the user to know what asynchronous nodes are. I've not seen that documented anywhere. Also, why the change from 2014 to newer?

 

So, I'm expected either a CAR for a bug, for documentation the node to be asynchronous or explain asynchronous nodes, or  to change the error description.

Certified-LabVIEW-Architect_rgb.jpgCertified_TestStand_Architect_rgb.jpg


"I won't be wronged. I won't be insulted. I won't be laid a-hand on. I don't do these things to other people, and I require the same from them." John Bernard Books

0 Kudos
Message 9 of 11
(3,288 Views)

If you "won't be insulted", I hope you don't live in the U.S., you might find our ways unacceptable.  Here we have freedom if speech, and anyone may insult anyone else with impunity.

 

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 10 of 11
(3,280 Views)