LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error Code 1097 Coming in DLL Calling

Solved!
Go to solution
Highlighted

Hi,

 

I am getting error code 1097 in DLL calling function. Please find the DLL calling function details for more information.

 

Function :  GetControllerListTest(controller *ptrControllertest,char *max_controller);

 

Controllertest parameter details:

 

define NO_OF_CONTROLLER  100
#ifndef CONTROLLER_STRUCT
 typedef struct
 {
  CString name;
  char status;
  CString blocked_by;
  char group;
 }controller;

 

Controllertest parameter data type is structure. In LabVIEW, I have configured parameter as a cluster.

 

name : String control

status : U8 Integer control

blocked_by : String control

group : U8 Integer control

 

Could you please confirm it, did I configured the datatype in correct way?

 

I am getting empty array output and Error Code from the DLL 1097. Can you please tell me where I am missing?

 

Thanks

 

Sivaramkumar.V

0 Kudos
Message 1 of 25
(18,509 Views)

The error you mentioned says:

An exception occurred within the external code called by a Call Library Function Node. The exception might have corrupted the LabVIEW memory. Save any work to a new location and restart LabVIEW.

 

If you are using LabVIEW version above 9.0, I recommend you to cross check the calling convention for your dll. It must be defined as"C" and not as WinAPI.

Second thing, you would also need to check your text based code by passing the same parameters you did in LabVIEW

-FraggerFox!
Certified LabVIEW Architect, Certified TestStand Developer
"What you think today is what you live tomorrow"
Message 2 of 25
(18,505 Views)
Solution
Accepted by topic author ramsinghsivaramkumar

How is the type "CString" defined?

 

If it's a C++ type, as defined here, then you cannot call this function directly from LabVIEW because LabVIEW cannot pass C++ types.  In this case you'll need to write a wrapper (in VisualStudio or another C++ programming environment) that takes a standard C string (character array) as an input, creates a CString from it, and calls GetControllerListTest.

 

If CString is defined as a fixed-length character array, then you need to replace the LabVIEW strings with clusters of U8 containing a number of elements equal to the string length (LabVIEW does not support fixed-length arrays).

 

If CString is defined as a pointer to an array of characters, you can pass the data to it from LabVIEW, but you need to call LabVIEW memory manager functions to allocate memory for the string and copy data into it.

Message 3 of 25
(18,494 Views)

Hi, Thanks For the Information. I have created the wrapper layer in dll...successfully done...

0 Kudos
Message 4 of 25
(18,482 Views)

Sir i am too facing the 1097 error and idont know how to create the wrapper. so please can you help me?

also if you can send me the wrapper code it would be a kind help for me.

0 Kudos
Message 5 of 25
(18,396 Views)

This link will help you to create a wrapper function:

http://zone.ni.com/devzone/cda/epd/p/id/4489

Message 6 of 25
(18,371 Views)

Hi Fragger Fox.  I am getting the 1097 error after moving from LabVIEW 8.6 to LabVIEW 2010 when calling a third party dll that worked fine under LabVIEW 8.6.  What I wanted to mention though is that I tried changing the clf node from Win API to C.  Now when I call the clf node, LabVIEW (I'm on 2010 now) crashes.  When I switch back to Win API, I again get the 1097 error but LabVIEW does not crash.  I also tried changing from Win API to C in some of my other VI's that contain clf nodes that call into the Windows API (kernel32.dll, user32.dll, etc.) and that was causing LabVIEW to crash as well.  When I set those back to Win API, those calls into the Windows API work fine (like they did under LabVIEW 8.6) - no error and no crash.  Just wanted to mention this, because it does not seem that your tip to use "C" instead of "Win API" in clf nodes works for me on LabVIEW 2010 (which is version 10.0 and is therefore above 9.0).

 

Thanks,

BB

0 Kudos
Message 7 of 25
(17,934 Views)

Call Library Node problems without the VI in question attached AND the complete C prototype of the function provided, AND preferably some documentation about the C function in question can be not diagnosed. These informations are paramount to get the Call Library Node configured properly since there is no way a calling application can retrieve the necessary information from the DLL itself. The DLL interface was never intended to be a self configuring interface and it was designed with the understanding, that the user of such an interface is a fully knowledgeable C programmer knowing both, how to read a header file definition as well as various details about memory buffer handling.

 

So show us your VI and the C header file, and we can start to help you. Otherwise all we can do is guessing in the way you have done with changing the calling convention randomly. You can of course try to shoot in the shooting range with a blindfold on, but the chances that you not only do not hit the target, but injure some other person instead is very high.

 

The only reason that the suggestion from Fragger Fox has any merits is the fact that LabVIEW used to have some heuristics that changed the Call Library Node automatically from C calling convention (the LabVIEW default) to Windows calling convention, if it recognized a certain pattern in the exported function name. This heuristic was removed in LabVIEW 2009 because it did prevent the Call Library Node to be able to call functions that were using C calling convention but happened to match the heuristic pattern. So changing a Windows calling convention to C calling convention when the code has "seemed" to work before is NEVER a solution.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
Message 8 of 25
(17,921 Views)

Hi Billy,

Post your C header file and the VI if its possible. Switching between calling conventions is not a solution. I mentioned it just to make the poster aware of this while switching between LV versions.

There are many reasons for this error, and we can't judge anything without having a look at the code structure. The error itself says that "An exception occurred within the external code called by a Call Library Function Node.", so we need to check the dll code first.

 

 

-FraggerFox!
Certified LabVIEW Architect, Certified TestStand Developer
"What you think today is what you live tomorrow"
0 Kudos
Message 9 of 25
(17,906 Views)

rolfk, respectfully.  The point of my last post (addressed to FraggerFox and not you by the way) was really just an FYI about LabVIEW 2010 crashing after changing from "WINAPI" to "C" calling convention in a clf node.  I was seeing this behavior in these cases.

 

1) A VI making a call into a DLL (via clf node) that was previously giving the 1097 error.

 

2) A VI making a call into a DLL (via clf node) that was previously working (no 1097 error or any error).  This case is observed with many such previously working VI's that I have been using regularly and that call into a DLL via a clf node no matter what the dll (kernel32.dll, user32.dll, or third party).

 

So the point was really the crash and not the 1097 error.  I did not include an example VI because, as I mentioned, I intended the post as just an FYI to FraggerFox about the crash and did not intend for anyone to try and debug any particular instance of my observing said crash.   I figured if FraggerFox wanted more information, he would ask for it.  And he has done so - in a respectful and professional manner.

 

Feel free to reply to my posts even if they are not directed to you, but please be respectful and professional. Being a LabVIEW Champion does not give you license to be snide.

0 Kudos
Message 10 of 25
(17,895 Views)