LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VI Reference Mismatch - Passing Static VI Ref into PPL SubVI - "Asynchronous Function" reference type?

I've run into this situation a few times and I'm hoping someone can point me in the right direction.

 

The connector panes match. With the image below you can see the red subVI, which is in a compiled PPL, has a vi reference control as an input and near as I can tell it matches the callback I created just fine. I use this model all the time and already have other callbacks that I use as message handlers that get registered with the same class the red subvi on the right is from.

 

The only difference I can see between the two references is that the static reference shows as "asynchronous function" while the subvi control is simply "function". I'm not even sure how that difference happens. Other callback references that I've created don't list them as asynchronous when I put them in static reference nodes. All I did to create this VI was right click on the containing library created a new VI. Execution properties haven't been changed and are still set to non-reentrant.

 

viref.png

0 Kudos
Message 1 of 4
(2,559 Views)

From what I can tell it has nothing to do with that asynchronous function listing in the context help. A callback I create in the original library shows up as asynchronous and wires in just fine. Which leads me to thinking there's some issue in the PPL compilation?

0 Kudos
Message 2 of 4
(2,556 Views)

Aaaand I've just noticed that the URL Info type def isn't being namespaced to the lvlibp (So easy to miss that single 'p' absent from the context help). So definitely a PPL compilation issue?

 

The callback reference has HalComm.lvlibp:Endpoint.lvclass:URL Info.ctl whereas the compiled PPL VI that's supposed to accept the callback registration is just HalComm.lvlib:Endpoint.lvclass:URL Info.ctl

 

VI Ref Issue.png

0 Kudos
Message 3 of 4
(2,554 Views)

My current workaround is I changed the callback definition to accept the plain URL string instead of the URL Info cluster. I then call the same Parse URL function that's called to determine the protocol for the URL within the callback; a duplicated effort but passable for now.

0 Kudos
Message 4 of 4
(2,539 Views)