Calling external Dll crashes labview

[Joshuatronics]

Hi, I want to link a DLL from of a driver of a CAN BOARD, and I need to use the functions in the DLL.

I´m using LABVIEW 7.1 and I tried using the Call Library Function Node but somtimes it crushes specially when i copy and paste some code after i've executed the program.

The function that causes the error is defined in C as:

DWORD HiCOCANGetErrorString (DWORD ErrorCode, TCHAR *Puffer)

Where,

DWORD = unsigned long

TCHAR = char

*Puffer = Pointer to the beginning of a buffer with a size of 100 characters, where the error code is to be entered.

i attached two VIs, the first one makes crushed labview after executing the program.

the i read in a post that inicializing an array and casting it it solved the problem, it worked at the beginning but when a try to copy-paste some code, labview crushes anyway.

is the anysolution??

THANKS

[bsvingen]

There is a PlxApi.dll missing (on my computer at last) so I cannot test it. But you are using WINAPI calling convention, is this correct? The alternative is C calling convention.

[Rolf Kalbermatter]

QUOTE (Joshuatronics @ Feb 25 2009, 02:20 PM)

Hi, I want to link a DLL from of a driver of a CAN BOARD, and I need to use the functions in the DLL.

I´m using LABVIEW 7.1 and I tried using the Call Library Function Node but somtimes it crushes specially when i copy and paste some code after i've executed the program.

The function that causes the error is defined in C as:

DWORD HiCOCANGetErrorString (DWORD ErrorCode, TCHAR *Puffer)

Where,

DWORD = unsigned long

TCHAR = char

*Puffer = Pointer to the beginning of a buffer with a size of 100 characters, where the error code is to be entered.

i attached two VIs, the first one makes crushed labview after executing the program.

the i read in a post that inicializing an array and casting it it solved the problem, it worked at the beginning but when a try to copy-paste some code, labview crushes anyway.

There is no obvious reason for this to crash. According to the doc the 100 character input buffer for the error string should be enough.

- Maybe try to make that buffer 1000 for a trial.

- Maybe the error VI is supposed to only be called when not NULL.

- WINAPI calling convention if not right would certainly crash this VI every single time.

- Are you sure it is the error function and not one of the other VIs that crashes? There are enough other functions that get called. While WINAPI convention would badly crash if the number of parameters was not right it might be the actual value passed to the Open or Start function.

Rolf Kalbermatter

[Joshuatronics]

QUOTE (rolfk @ Feb 27 2009, 05:06 AM)

There is no obvious reason for this to crash. According to the doc the 100 character input buffer for the error string should be enough.

- Maybe try to make that buffer 1000 for a trial.

- Maybe the error VI is supposed to only be called when not NULL.

- WINAPI calling convention if not right would certainly crash this VI every single time.

- Are you sure it is the error function and not one of the other VIs that crashes? There are enough other functions that get called. While WINAPI convention would badly crash if the number of parameters was not right it might be the actual value passed to the Open or Start function.

Rolf Kalbermatter

Thanks to both, suddenly it stops crashing. I didn't do anything. Let's hope it continue.

I'm sorry for not including the other library i have it.

[Rolf Kalbermatter]

QUOTE (Joshuatronics @ Mar 6 2009, 10:21 AM)

Thanks to both, suddenly it stops crashing. I didn't do anything. Let's hope it continue.

I'm sorry for not including the other library i have it.

A program not crashing is absolutely no indication that everything is alright. Calling functions that take a buffer to return some information where the buffer is not allocate large enough, can cause anything from no problem at all until you do something else, crashing on exit only, crashing at a point much later than where the actual corruption occurred to crashing at the moment the memory corruption happens, but it could also have more subtle problems such as overwriting actual data used elsewhere in your program so that some subVI suddenly seems to return wrong results. This could theoretically go as far as corrupting some non crashing information in a VI or other file in memory and then after you save the file to disk you have a corrupted file on disk, that might not even be loadable anymore.

So unless you did something you can securely attribute to having caused the lack of crashes now, I would be very uneasy about the fact that the application is not crashing anymore.

Rolf Kalbermatter