GetValueByPointer XNode in LV 8.5

[Tomi Maila]

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

[hviewlabs]

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 LV 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.

[hviewlabs]

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 LV 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.

[Aristos Queue]

QUOTE(hviewlabs @ Nov 20 2007, 06:30 PM)

I wonder what

"Jupiter" is/was. My guess is it was the code name

for one of the LabVIEW versions.

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

[Aristos Queue]

QUOTE(hviewlabs @ Nov 20 2007, 06:30 PM)

I wonder what

"Jupiter" is/was. My guess is it was the code name

for one of the LabVIEW versions.

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

[Tomi Maila]

QUOTE(hviewlabs @ Nov 21 2007, 02:30 AM)

Interesting: the default string for the http://initstr.vi/' target="_blank">InitStr.vi is

"Import Shared Library Tool in Jupiter."

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

[Tomi Maila]

QUOTE(hviewlabs @ Nov 21 2007, 02:30 AM)

Interesting: the default string for the http://initstr.vi/' target="_blank">InitStr.vi is

"Import Shared Library Tool in Jupiter."

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

[Michael Aivaliotis]

QUOTE(Tomi Maila @ Nov 21 2007, 12:28 AM)

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

Hey, it wasn't me! :ninja:

[Michael Aivaliotis]

QUOTE(Tomi Maila @ Nov 21 2007, 12:28 AM)

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

Hey, it wasn't me! :ninja:

[Jim Kring]

QUOTE(Tomi Maila @ Nov 21 2007, 12:28 AM)

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

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

[Jim Kring]

QUOTE(Tomi Maila @ Nov 21 2007, 12:28 AM)

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

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

[cosmin]

QUOTE(hviewlabs @ Nov 21 2007, 02:30 AM)

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?

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).

[cosmin]

QUOTE(hviewlabs @ Nov 21 2007, 02:30 AM)

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?

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).

[hviewlabs]

QUOTE(cosmin @ Nov 22 2007, 12:43 AM)

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?

[hviewlabs]

QUOTE(cosmin @ Nov 22 2007, 12:43 AM)

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?

[lavezza]

QUOTE(hviewlabs @ Nov 21 2007, 12:19 PM)

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

[lavezza]

QUOTE(hviewlabs @ Nov 21 2007, 12:19 PM)

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

[Godpheray]

QUOTE(Tomi Maila @ Oct 30 2007, 01:34 AM)

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

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.

[Godpheray]

QUOTE(Tomi Maila @ Oct 30 2007, 01:34 AM)

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

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.

[Rolf Kalbermatter]

QUOTE(hviewlabs @ Nov 21 2007, 12:19 PM)

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?

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.

QUOTE(Godpheray @ Nov 26 2007, 09:48 PM)

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.

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

[hviewlabs]

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

[Tomi Maila]

QUOTE(hviewlabs @ Nov 28 2007, 10:10 PM)

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