Jump to content
Sign in to follow this  
Tomi Maila

GetValueByPointer XNode in LV 8.5

Recommended Posts

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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... :D

Tomi

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.