LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview VI error while executing DLL functions

Solved!
Go to solution

Hello NI Developers!

 

I have windows application driver created by Jungo WinDriver program for PCI-E board.

 Application works fine. I edited and compiled the project as DLL following manuals.

 

I can successfully read PCI-E board's resources information such as memory bars, it's size, interrupt functions etc.

 

Next step I need to perform DMA transfer. The application supports these functions and works.

I follow function by function and see if my code works correctly and returns to Labview information - about function successful execution.

 

First of all is strange that every time I close VI I receive error message:

"LabView.exe has encountered a problem and needs to close. We are sorry for the inconvenience"

 fDebug: 0       Offset: 0083002e

 

 Exception Information

Code: 0xc0000005 Flags 0x0

Record 0x0   Address 0x0000000000c3002e

......................................................................

......................................................................

 

But when I build EXE application from VI - this error do not occur.

 

Maybe someone can help me or point on string where I did incorrectly manage LabView and C resources?

 

Sometimes LabView crashes after few seconds after successfull execution of VI. 

 

The code attached below:
 

 

 

0 Kudos
Message 1 of 8
(4,246 Views)

Hi there

 

Do you pass a string allocated by LV with sufficient length to the char *msg_ptr parameter of the DLL functions?

Best regards
chris

CL(A)Dly bending G-Force with LabVIEW

famous last words: "oh my god, it is full of stars!"
0 Kudos
Message 2 of 8
(4,242 Views)

 

Hi,

 

No.. actually I don't know how to allocate space for it..

 

 

If It it a case of problem, I should count every single character in those messages?

 

Best Regards,

 ACiDuser

 

0 Kudos
Message 3 of 8
(4,239 Views)
Solution
Accepted by topic author ACiDuser
If a application calls a DLL which writes to a given buffer the application has to allocate the buffer and free it afterwards. This is the case for all languages, not only for LV. To create a char buffer one way would be to create a array of U8 with sufficient size and to convert this array to a string using the "Type Cast" function. See the documentation for the DLL for the minimum size of the buffer. Maybe the DLL returns an error code if the buffer size is to small. If you can get the maximum size of the char messages, than add 1 (for the terminating NULL character) as the U8 array size and you should be on the safe side. Same thing for other parameters, especially for arrays.
Best regards
chris

CL(A)Dly bending G-Force with LabVIEW

famous last words: "oh my god, it is full of stars!"
0 Kudos
Message 4 of 8
(4,221 Views)

thanks for the tips.

 

Is it possible to dynamically allocate memory for LV array from DLL ? 

0 Kudos
Message 5 of 8
(4,214 Views)

To dynamically allocate memory for LV inside the external code you have to use the CIN memory manager functions (for documentation see attachment), but that's a little bit cumbersome and quite old school. Also you may get in trouble when calling the DLL with applications not written in LV.

 

I suggest to use 2 DLL functions, or to call the same function twice with different parameters. The first call returns the size of the needed memory (e.g. the number of array elements or the number of characters), then allocate the memory in LV by creating an array or string with the given size and then pass the pointer to the allocated memory to the second function call. There should be no reallocation or resizing of any memory inside the DLL functions, otherwise the application may crash.

 

If you're handling with rather small memory allocation (e.g. strings smaller than some 100 characters) passing a constant puffer with sufficient size also should do the work, that would make the programming easier. In any case the DLL functions should check the external buffer for sufficient size (e.g. with strlen(char* buffer) or by passing array dimension sizes as additional function parameters) and catch buffersizes that are to small, otherwise the application may crash.

Best regards
chris

CL(A)Dly bending G-Force with LabVIEW

famous last words: "oh my god, it is full of stars!"
0 Kudos
Message 6 of 8
(4,208 Views)
There are two strings. First - returns error messages or messages describing successful operations, The second string returns - data. For the second string - it is easy to specify size from LabView before running VI. For the first string - I could simply count characters or set a bit more then is needed. I think it's not so good - to run those functions two times, because DLL accesses works with driver, which accesses the hardware, and second time different error could occur or vice versa. As for VI crash, I wired two unsigned byte arrays through "Byte Array to String" nodes to the Call Library Function Node's inputs and specified both "Dimension size" to 500. That solved my problem. Thank you very much for provided tips!
0 Kudos
Message 7 of 8
(4,168 Views)

If you create an array in LabVIEW this IS dynamically allocated and disposed as soon as LabVIEW deems it unneccassiry (meaning the wire stops being run through the diagram). Then you configure the apropriate CLN parameter to accept an array or string and configre this to be a C Array Pointer or C String and your DLL will see a simple memory pointer it can use to write its information into.

 

And after the return from the CLN you have the data back into proper LabVIEW wires to work on them. If you use the CLN to call LabVIEW memory manager functions you really just get a pointer (uInt32) and after returning from the DLL will have to do additional LabVIEW manager calls to actually get the data into the diagram.

 

Also this DLL will continue to work with other callers than LabVIEW as it uses common C data pointers as memory buffers instead of proprietary LabVIEW data types.

 

So why making your life more complicated than necessary? 

 

Rolf Kalbermatter 

Message Edited by rolfk on 10-24-2008 08:59 PM
Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 8 of 8
(4,056 Views)