Hidden Primitives

[hooovahh]

So I had a thought.  There are primitives in LabVIEW that aren't exposed, just like there are VIs in the vi.lib that aren't on the palette.  But the thing about vi.lib VIs is I can navigate the the directory and find the VIs on disk.  My question is how does one find primitives not exposed?

 

I've seen a few instances where someone will post a VI with a primitive I've never seen before and I wonder how people find these, other then finding them on the block diagram of another VI.  A few examples I can think of are the Text to UTF-8/UTF-8 to Text, and Coerce to Type.

 

Again I understand the reason why these may not be exposed, and I understand the reason why someone would not want to use them.  But I can't help but wonder, where are primitives on disk?  Where is their information stored (VI description and help path for example).  And how can someone find primitives not on the palette?

[Rolf Kalbermatter]

So I had a thought.  There are primitives in LabVIEW that aren't exposed, just like there are VIs in the vi.lib that aren't on the palette.  But the thing about vi.lib VIs is I can navigate the the directory and find the VIs on disk.  My question is how does one find primitives not exposed?

 

I've seen a few instances where someone will post a VI with a primitive I've never seen before and I wonder how people find these, other then finding them on the block diagram of another VI.  A few examples I can think of are the Text to UTF-8/UTF-8 to Text, and Coerce to Type.

 

Again I understand the reason why these may not be exposed, and I understand the reason why someone would not want to use them.  But I can't help but wonder, where are primitives on disk?  Where is their information stored (VI description and help path for example).  And how can someone find primitives not on the palette?

 

Primitives are not stored as an entity on disk, but are directly created by code residing in LabVIEW.exe. The LabVIEW menu palettes then hold links to those pirimitives. Creating primitives not made availabe through the menu palettes is a function of the Create Object primitive that is part of the scripting palette extension. This node has a ring input that contains all the primitives and controls, the LabVIEW executable contains internally.

[Daklu]

Creating primitives not made availabe through the menu palettes is a function of the Create Object primitive that is part of the scripting palette extension.

 

For kicks and grins I poked around a bit (2012) and found a pair of vis that looks interesting...

 

 

 

My first thought was that it would be useful for situations where one dynamically launched vi creates a DVR and sends it to a second dynamically launched vi.  When I put together a few quick tests to see play around with it I was surprised the DVR didn't automatically deallocate when the reference to the first vi was closed.  (Nope, I don't dynamically call stuff very often.)

 

 

As I recall, we're told references are automatically deallocated when the vi that created it "goes idle."  I've always interpreted "idle" as meaning the vi is not locked because another vi is running.  So, either I'm wrong about what it means to go idle or the DVR already has the functionality of these prims built into it.

LeakReference.zip

[drjdpowell]

References deallocate when their owning VI hierarchy goes idle.  When calling by reference synchronously, as your doing, the dynamic VI is running under the hierarchy of its caller.  When one uses the asynchronous methods (“Run VI” or ACBR Fire-and-Forget) then that creates a new VI hierarchy.

 

Added later: using ACBR Call-and-Collect also creates a new hierarchy (I’ve not used it before); the following mod causes the reference to deallocate.

 

You can figure out what hierarchy a VI is running under by using “Call Chain”.  With the original version, the call chain of “ThrowDVR.vi” showed it to be running as a subVI of the calling VI.

[GregSands]

There's a couple of others I found here: http://lavag.org/topic/15895-new-vi-objects/

[Djed]

Daklu,

You are in the ballpark on those hidden prims but I have to sadden you with the news that we never finished them. You're lucky if you don't immediately crash the second you try to run a VI with those nodes on the diagram. Sorry these aren't going to be useful nodes to play around with. I'd be shocked and fall out of my chair if you found these used in ANY vi in vi.lib.

[Daklu]

You are in the ballpark on those hidden prims but I have to sadden you with the news that we never finished them.

 

I guess that explains why it only accepts a DVR wrapped double and no other wrapped data types.

 

 

 

You're lucky if you don't immediately crash the second you try to run a VI with those nodes on the diagram.

 

Count me lucky then.  I don't think LV ever immediately crashed, though it always did end up crashing at some point.  For all I know your dev team is looking over the crash logs at this moment and wondering what the heck I was doing...