what is the counterpart in labview for VB Byte type

[menghuihantang]

A DLL, its return is BYTE type. tried to use the dll from labview, but the return type is either numeric or string.

So how to deal with this VB BYTE in Labview?

Here is the prototype of the VB function: function DESKWINRESET(var ComPort, TC, Mode: Integer): Byte

[ragglefrock]

I don't know anything about VB, but you could probably use a Numeric return type in your Call Library Function Node with the representation Unsigned 8-bit Integer. Generally it shouldn't really matter for simple data types with DLL calls what the exact data types are when passing data back and forth if the sizes happen to be the same.

[Francois Normandin]

QUOTE (menghuihantang @ Feb 11 2009, 03:26 PM)

A DLL, its return is BYTE type. tried to use the dll from labview, but the return type is either numeric or string.

So how to deal with this VB BYTE in Labview?

Here is the prototype of the VB function: function DESKWINRESET(var ComPort, TC, Mode: Integer): Byte

Ragglefrock is dead on: it is a 8-bit unsigned integer. See this http://msdn.microsoft.com/en-us/library/system.byte.aspx' rel='nofollow' target="_blank">link.

[menghuihantang]

QUOTE (normandinf @ Feb 11 2009, 03:24 PM)

Ragglefrock is dead on: it is a 8-bit unsigned integer. See this http://msdn.microsoft.com/en-us/library/system.byte.aspx' rel='nofollow' target="_blank">link.

Thanks much. I changed to 8-bit unsigned, but labview still crashed every time. That's why I think it is due to type mismatch which causes memory leak or something in the first place.

I attached an image of the VI, it's a simle DLL call. The dll function is relatively simple too, 3 interger inputs and returns a byte.

function DeskWinReset (var Comport, TimeConstant, Mode: integer): byte;

I have no clue what's wrong now. The dll file is corrupt itself??

[jdunham]

QUOTE (menghuihantang @ Feb 11 2009, 02:02 PM)

Thanks much. I changed to 8-bit unsigned, but labview still crashed every time. That's why I think it is due to type mismatch which causes memory leak or something in the first place.

I attached an image of the VI, it's a simle DLL call. The dll function is relatively simple too, 3 interger inputs and returns a byte.

function DeskWinReset (var Comport, TimeConstant, Mode: integer): byte;

I have no clue what's wrong now. The dll file is corrupt itself??

Make sure you double-check all the parameter data types, and then check C calling convention versus Pascal/WinAPI calling convention. You can try them both, and usually one will crash and one won't.

[Aristos Queue]

QUOTE (menghuihantang @ Feb 11 2009, 04:02 PM)

Thanks much. I changed to 8-bit unsigned, but labview still crashed every time.

QUOTE

function DESKWINRESET(var ComPort, TC, Mode: Integer): Byte

Comparing the picture you included against the function prototype, I'm pretty sure that you've got it configured exactly right. I would guess that the problem is more likely with the value of the parameters that you are passing in than with a problem with the types. It's pretty hard to mess up integers.

[Mark Yedinak]

What type if var Comport? I suspect that this is not simply an integer. This may be part of your problem.

[Aristos Queue]

QUOTE (Mark Yedinak @ Feb 11 2009, 06:34 PM)

What type if var Comport? I suspect that this is not simply an integer. This may be part of your problem.

"var" means variable. The way to read this is "declaration of three variables, named ComPort, TC and Mode, all of type Integer".

[Rolf Kalbermatter]

QUOTE (Aristos Queue @ Feb 11 2009, 06:33 PM)

Comparing the picture you included against the function prototype, I'm pretty sure that you've got it configured exactly right. I would guess that the problem is more likely with the value of the parameters that you are passing in than with a problem with the types. It's pretty hard to mess up integers.

He doesn't show the function configuration in the dialog but I strongly suspect a wrong calling convention. This will usually crash no matter what unless sometimes with functions that have no parameters at all.

I agree that the parameters look right and seeing them being just integers it is hard to see how there could be anything wrong with them. The configuration of the return value never will crash unless you tell LabVIEW it is a string while it is either void or Numeric.

Rolf Kalbermatter

[Mark Yedinak]

QUOTE (Aristos Queue @ Feb 11 2009, 09:37 PM)

"var" means variable. The way to read this is "declaration of three variables, named ComPort, TC and Mode, all of type Integer".

Thanks. VB is one language that I haven't played with.

[menghuihantang]

Thanks much, everybody. I tried a few times again after reading through you guys' comments. It's not done yet, but at least I got somewhere. Labview doesn't crash now after I changed to "Pass by pointer", and I got a return value '205' which according to the DLL documentation is a DLL problem.

Anyway, one problem solved. But it raised another question. I don't know VB, but How do you tell whether should use passbyvalue or passbyreference given a prototype of VB function, like this one, "function DESKWINReset(var ComPort, TC, Mode: Integer): byte". It says nothing that those three integers inputs are pointers.

[Rolf Kalbermatter]

QUOTE (menghuihantang @ Feb 12 2009, 05:00 PM)

Thanks much, everybody. I tried a few times again after reading through you guys' comments. It's not done yet, but at least I got somewhere. Labview doesn't crash now after I changed to "Pass by pointer", and I got a return value '205' which according to the DLL documentation is a DLL problem.

Anyway, one problem solved. But it raised another question. I don't know VB, but How do you tell whether should use passbyvalue or passbyreference given a prototype of VB function, like this one, "function DESKWINReset(var ComPort, TC, Mode: Integer): byte". It says nothing that those three integers inputs are pointers.

Well didn't know that var would mean pass by pointer. Normally pass by pointer variables have the addition ByRef in VB. var means this in Pascal but maybe VB added that keyword to ease migration for Pascal users.

Rolf Kalbermatter

[Francois Normandin]

QUOTE (menghuihantang @ Feb 12 2009, 04:00 PM)

Thanks much, everybody. I tried a few times again after reading through you guys' comments. It's not done yet, but at least I got somewhere. Labview doesn't crash now after I changed to "Pass by pointer", and I got a return value '205' which according to the DLL documentation is a DLL problem.

Anyway, one problem solved. But it raised another question. I don't know VB, but How do you tell whether should use passbyvalue or passbyreference given a prototype of VB function, like this one, "function DESKWINReset(var ComPort, TC, Mode: Integer): byte". It says nothing that those three integers inputs are pointers.

You might need to call other functions to fill in some data in memory first and then call your DeskWinReset function with the pointers to those values. ComPort, TC and Mode are not data by themselves. Pointer being a reference to an existing data in memory, if DeskWinReset expects to find a certain data structure at pointer value ComPort but what it finds is random 0's and 1's, then you will most probably get an unexpected result.

For example, on Windows systems, there is a call to retreive the last error code. There is an other function to generate in memory a string for this error code. The output of this second function is a pointer that needs to be passed to a third function to display the message. You don't give the whole message as input for this last function, just the pointer to the string in memory. If the memory block is not initialized, you'll get an error.

I think you should check what's the structure of data at ComPort's pointer location. Is it a pointer to a string, a boolean, an integer, a cluster structure? Some functions can be tested by inputing null values instead of actual pointer values. A null is generally represented by "0" for integers (not always). Have you tried 0's? Do you get the same 205 return value?

EDIT: I see you input I32's. Does it work with U8? (It probably makes no difference, but Byte is U8...)

[menghuihantang]

QUOTE (normandinf @ Feb 12 2009, 10:04 PM)

You might need to call other functions to fill in some data in memory first and then call your DeskWinReset function with the pointers to those values. ComPort, TC and Mode are not data by themselves. Pointer being a reference to an existing data in memory, if DeskWinReset expects to find a certain data structure at pointer value ComPort but what it finds is random 0's and 1's, then you will most probably get an unexpected result.

For example, on Windows systems, there is a call to retreive the last error code. There is an other function to generate in memory a string for this error code. The output of this second function is a pointer that needs to be passed to a third function to display the message. You don't give the whole message as input for this last function, just the pointer to the string in memory. If the memory block is not initialized, you'll get an error.

I think you should check what's the structure of data at ComPort's pointer location. Is it a pointer to a string, a boolean, an integer, a cluster structure? Some functions can be tested by inputing null values instead of actual pointer values. A null is generally represented by "0" for integers (not always). Have you tried 0's? Do you get the same 205 return value?

EDIT: I see you input I32's. Does it work with U8? (It probably makes no difference, but Byte is U8...)

In Labview, a control of integer is a value of the integer itself or a reference to a memory location? I thought in Labview, everything is reference, because it needs to be referenced on both front panel and block diagram. It cannot be two copies of the same integer for front panel and block diagrem, right? I did not find an answer on ni.com to this.

So how labview represents its data type? I know for an image, it's always a reference to memory;but what about other primitive types, like integer, double and boolean?

[Rolf Kalbermatter]

QUOTE (menghuihantang @ Feb 13 2009, 01:43 PM)

In Labview, a control of integer is a value of the integer itself or a reference to a memory location? I thought in Labview, everything is reference, because it needs to be referenced on both front panel and block diagram. It cannot be two copies of the same integer for front panel and block diagrem, right? I did not find an answer on ni.com to this.

So how labview represents its data type? I know for an image, it's always a reference to memory;but what about other primitive types, like integer, double and boolean?

LabVIEW internally does a lot of different handling. While data is in general of course always some memory location the term by reference or by value does not apply to the diagram or front panel at all since LabVIEW uses strict data flow programming.

But the Call Library Node does have a configuration dialog for a reason. Here you tell LabVIEW how the DLL function expects the data and LabVIEW will take care to pass the parameters accordingly indpendant how it uses them internally itself. If LabVIEW would simply pass data in whatever format it uses internally you would not be able to call most C functions.

Rolf Kalbermatter

[LAVA 1.0 Content]

QUOTE (menghuihantang @ Feb 13 2009, 06:43 PM)

So how labview represents its data type? ...but what about other primitive types, like integer, double and boolean?

See the 'http://zone.ni.com/reference/en-XX/help/371361D-01/TOC32.htm' target="_blank">How LabVIEW Stores Data in Memory' knowledge base article.

Ton

[menghuihantang]

QUOTE (rolfk @ Feb 13 2009, 01:30 PM)

LabVIEW internally does a lot of different handling. While data is in general of course always some memory location the term by reference or by value does not apply to the diagram or front panel at all since LabVIEW uses strict data flow programming.

But the Call Library Node does have a configuration dialog for a reason. Here you tell LabVIEW how the DLL function expects the data and LabVIEW will take care to pass the parameters accordingly indpendant how it uses them internally itself. If LabVIEW would simply pass data in whatever format it uses internally you would not be able to call most C functions.

Rolf Kalbermatter

NO offense, Rolf, but that is a little confusing. You are saying LabVIEW does one more step of processing before passing data into the Node?

For instance, how do you pass a string by value in LabVIEW? In the configuration window, if a string type of input is chosen, only pointers available for string type. Now how LabVIEW converts this pointer string into a value string?

[LAVA 1.0 Content]

LabVIEW is preparing the data fed to the Call Library Node so that it matches the datatype the Library is expecting.

For instance if it is given a U8 and the function needs a Pointer to an U8, LabVIEW will setup some memory space exclusively for that Library Call and sent the memory location (32-bit) to the Library.

For strings the same thing happens, only for C-strings they remove the upper four bytes (the size) and terminate the string with a NULL byte. Then the starting memory address (eg. pointer) is sent to the Library. (at least that is what I think is happening, Rolf will be of much more value)

Ton

[Rolf Kalbermatter]

QUOTE (Ton @ Feb 13 2009, 05:33 PM)

LabVIEW is preparing the data fed to the Call Library Node so that it matches the datatype the Library is expecting.

For instance if it is given a U8 and the function needs a Pointer to an U8, LabVIEW will setup some memory space exclusively for that Library Call and sent the memory location (32-bit) to the Library.

For strings the same thing happens, only for C-strings they remove the upper four bytes (the size) and terminate the string with a NULL byte. Then the starting memory address (eg. pointer) is sent to the Library. (at least that is what I think is happening, Rolf will be of much more value)

To the original poster: A string (or array) can't really be passed by value since they are always pointers.

To Ton: You are certainly right. Only for strings (or array) it is actually even easier than that. No new allocation of memory or copying of data is really necessary since LabVIEW can simply pass the pointer to the data portion inside its handle to the DLL. For strings there is however one extra step. Before passing the pointer, LabVIEW resizes the string handle (but does not change its internal character count) to make sure it is one byte longer than the actual string data and then sets this extra byte to 0. Now the data portion of of the LabVIEW string handle can also be interpreted as zero terminated C string. On return from the C function, LabVIEW will scan the returned string buffer for a zero character up to the passed data length and then set the character count of the string handle to only contain the characters up to and excluding the zero character.

Rolf Kalbermatter