Hi,

I noticed that LabVIEW 8.5 ships an interesting XNode called GetValueByPointer.xnode under folder <vi.lib>\Utility\importsl\GetValueByPointer. Has anyone experience what is this node, how does it work and how should it be safely used?

Cheers,

Tomi

So, 8.5 can now handle (wrap) dll functions which
require as parameters, say, a pointer to a structure,
one of elements of which is a pointer to a variable
length data. Great! For this purpose the following
library is utilised by the DLL Import Wizard (that's
how I discovred it): \vi.lib\Utility\importsl

It has DSNewPtr.vi to create a pointer (and allocate
memory I would assume), DSDisposePtr.vi to (you
guessed!) dispose of the pointer (and deallocate
memory), InitStr.vi to write data to the memory to
which the pointer points and, the
GetValueByPointer.xnode (located in the
GetValueByPointer subfolder, can be dragged onto BD
from explorer, just like a VI, but you can't even open
its FP) to retreive the data from the memory location
the pointer points to.

No documentation though, even in the context help for
those top level VIs. So, Anybody has any idea what
PackType parameter of the GetValueByPointer.xnode is?

Well, what I said would be especially beneficial if on
its output wire GetValueByPointer.xnode really has the
reference to (address of) the data, not to a copy it
creates.


They apparently can be used to ensure that passing
of (large) data is done by reference (only the pointer
is passed around without moving/copying the data
itself) not only betweeen LabVIEW code and dll code but also
between any of your VI's as well.

Well, what I said would be especially beneficial if on
its output wire GetValueByPointer.xnode really has the
reference to (address of) the data, not to a copy it
creates.


Interesting: the default string for the InitStr.vi is
"Import Shared Library Tool in Jupiter." I wonder what
"Jupiter" is/was. My guess is it was the code name
for one of the LabVIEW versions.

This post has been edited by hviewlabs: Nov 21 2007, 12:44 AM

That would be LV8.5. LV8.5.1 -- if we decide that 8.5 warrants a bug fix release -- has been jokingly called LabVIEW Hale-Bopp... because it is a small adjustment to Jupiter.

Also interestingly LAVA interprets initstr.vi as a web address for a domain at US Virgin Islands...

Hey, it wasn't me!

Actually, I think that it's gmail that does this. I'll bet that hviewlabs copied and pasted that text from his web browser.

I guess the PackType parameter is refering to the member aligment (how the structures are packed into memory, 1byte, 2, 4, 8 or 16 bytes).

And the correct value is determined by what? Say, if we dereference the pointer to a location to which a dll function has written something and we have the definition of the data structure for that pointer in the .h file, how exactly do we choose the PackType? Does it depend on OS, language/compiler used to make the dll, some options set in the compiler?

The compiler. I think MS defaults their compilers to '#pragma pack 8' for 8-byte alignment. Although I'm not sure that all their internal data structures are done that way. We had this issue not too long ago. I was too lazy to write a wrapper DLL for a DLL written by another group in our company. There was one call that returned a structure. Reading it as a byte array and casting to a cluster wasn't working. It worked after adding some 'dummy' U8's into the cluster. When changes were made to the DLL we got them to compile with '#pragma pack 1', which is basically no byte alignment, so we didn't need the dummy controls. Eventually they just added a second call that returned the same data as separate values instead of a structure. Of course this isn't usually an option unless you have some sway with the DLL owner.

Pat

GetValueByPointer takes the C style pointer and the corresponding data type, which are generated by Import Shared Library Tool, as inputs and copies the value which the pointer points in shared library(dll/so/framework) to LabVIEW.

Input terminals:
Input Type: Input type is the LabVIEW data type to which you want to pass into LabVIEW. Input type can be Numeric, string, Array, Cluster . This VI returns an error if LabVIEW cannot convert the data wired to Pointer to the data type you wire to this input. If the data is integer, you can coerce the data to another numeric representation, such as an extended-precision, floating-point number.
Pointer: Pointer is a memory address represented by a 32-bit unsigned integer in LabVIEW.
Pack Type: Byte alignment information of the Input Type.

Output terminals:
Value:Value is the data copied from the memory which is pointed by Pointer and changed to the data type specified by Input type.

That node has an input that accepts just about any LabVIEW type including a cluster. For non-cluster types the packtype has no meaning. But for cluster types the node will align the individual elements to that packing alignment. This is also where the node is actually a bit complicated I'm sure. The extraction of linear arrays or skalars is a no brainer really. The fact that an xnode apperently can have an input parameter that can truely adapt to just about any LabVIEW datatype would be the most interesting aspect of that node, but according to NI there is no such thing like an Xnode and therefore no self adapting datatype input.


One interesting aspect of that node seems to be the fact that one can convert a pointer into a string or array. I can see that converting into a string should be possible when simply looking for the NULL termination character, but turning it in an array would suggest to me that the input pointer can not just be any possible pointer but must be one prepared by DSNewPtr.vi. Otherwise that node has no way of knowing how big the memory area the pointer is pointing too could possibly be. There is not even a documented DSPtrSize function, so I guess DSNewPtr.vi must do some internal magic to the pointer so that GetValueByPointer.xnode can make sure to never overrun the end of the allocated memory area.

Rolf Kalbermatter

The node apparently uses GetValueByPointer function from the LabVIEW 8.5\resource\lvimptsl.dll. There other 2 functions there: SetLVRTModule and SetStrDefaultValue.

Surely you can check it out. Add XNodeWizardMode=True into your LabVIEW.ini file, then right click on the XNode on a block diagram and select Generated Code from the what ever menu there is for debugging XNodes. Then simply check out the call specs...

Tomi