Error Code 1097 while calling C++ DLL

[Dr.Nuke]

Hello everyone,

I recieve Error 1097 while calling a C++ DLL for communication with a controller of a telecentric measurement system, because the parameters are being passed are probably not correct.

 

VI (LabVIEW 2019); .DLL; header file; description of the function and parameters and screenshots are attached in a .zip file.

The return values of functions that communicate with the controller are always ReturnCode type (the enum
definition of error code).
In the header file ReturnCode is defined as:

enum class ReturnCode
{
RC_ERR_NONE = 0x0000,
RC_ERR_COMMUNICATION_NONE = 0x1000,
RC_ERR_CHECKSUM = 0x1001,
RC_ERR_LENGTH = 0x1002,
RC_ERR_VERSION = 0x1003,
RC_ERR_COMMAND = 0x1004,
RC_ERR_TIMEOUT = 0x1005,
RC_ERR_UNABLE_TO_EXECUTE = 0x2001,
RC_ERR_PART_FAILURE = 0x2002,
RC_ERR_OUT_OF_BOUND = 0x2003,
RC_ERR_INVALID_PARAM = 0x3001,
RC_ERR_INVALID_OPERATION = 0x3002,
RC_ERR_NOT_FOUND = 0x3003,
RC_ERR_INVALID_TARGET = 0x3004,
RC_ERR_ALREADY_EXISTS = 0x3005,
RC_ERR_MEMORY_ALLOCATION_ERROR = 0x3006,
RC_ERR_NO_SPACE = 0x3007,
RC_ERR_SDCARD_NOT_FOUND = 0x3008,
RC_ERR_WRITE_PROTECTED = 0x3009,
RC_ERR_READ_ONLY = 0x3010,
RC_ERR_HEAD_NOT_FOUND = 0x3011,
RC_ERR_FAIL = 0x3012,
RC_ERR_OUTPUT_ERROR = 0x3013,
RC_ERR_OVERFLOW_IMAGE_MEMORY = 0x3014,
RC_ERR_NO_USB_HDD = 0x3015,
RC_ERR_USB_WRITE_PROTECTED = 0x3016,
RC_ERR_BUFFER_SIZE = 0x5000,
RC_ERR_UNKNOWN = 0xF000,
};

Import of the DLL functions with Import Shared Library Wizard is not possible, because the following smybols are not defined: ReturnCode.

 

So I tried to call a simple function (Connect via USB with controller) only with return code and without parameters beeing passed.

The Format of the function for Connecting USB communication is:

ReturnCode TMXIF_OpenUsbCommunication();

 

My Call Library Function:

int32_t TMXIF_OpenUsbCommunication(void );

I also tried different return types, but always recieve Error 1097.

So I found this article about Wrapper DLL.
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PA8QSAW&l=de-DE 

Do I need to write a Wrapper DLL because of the ReturnCode of the function?
I have absolutly none knowledge about C++ and couldn't find any examples how to write a Wrapper DLL.

I would be very thankful for any help or explanation how to start writinh a Wrapper DLL.

Kind regards,
Kevin

 

[raphschru]

By looking at your header file "TMXIF.h", it looks like ReturnCode is actually a C++11 "enum class".

I think only standard C types can be passed to and from a Call Library Function Node, as discussed in this other topic:

https://forums.ni.com/t5/LabVIEW/Linking-C-DLL-into-LabVIEW/td-p/3242395

It mainly comes from the fact that LabVIEW does not have an equivalent for all C++ more complex types likes classes.

So you'll either have to modify your original dll by replacing the class enum by a plain enum, or write a wrapper dll that defers the class enum to a plain enum, so that the functions you call in LabVIEW only have C-compatible types in their prototype.

[rolfk]

---

@raphschru wrote:

By looking at your header file "TMXIF.h", it looks like ReturnCode is actually a C++11 "enum class".

I think only standard C types can be passed to and from a Call Library Function Node, as discussed in this other topic:

https://forums.ni.com/t5/LabVIEW/Linking-C-DLL-into-LabVIEW/td-p/3242395

It mainly comes from the fact that LabVIEW does not have an equivalent for all C++ more complex types likes classes.

So you'll either have to modify your original dll by replacing the class enum by a plain enum, or write a wrapper dll that defers the class enum to a plain enum, so that the functions you call in LabVIEW only have C-compatible types in their prototype.

---

The Import Library Wizard likely can’t parse the class aspect of the enum. But it’s simply a normal enum so should be possible to be treated as an integer when you configure the Call Library Node yourself. The only possible problem is the size as C compilers are effectively free to choose if they use a default type, usually (u)int32_t, or rather the smallest possible type that can still represent the maximum numeric variable for the enum items. I would start with an uint32 in LabVIEW and refine if I see weird results returned that don’t match any known enum value.

But error code 1097 is seldom caused by a misconfigured return value. Rather checkout the actual parameter configuration and calling convention. Also if you pass a buffer/pointer to the function to have it write information into you better make sure you allocated enough memory space for that parameter. Unlike with LabVIEW native functions who allocate memory as needed, the C functions in the DLL can’t do that and LabVIEW can’t know or guess that that parameter needs to be allocated and how big.

[zou · Accepted solution]

You are calling TMXIF_CLR.dll.  Is it a standard dll, or a .NET assembly?

Your configuration looks correct, but try to call TMXIF.dll instead of TMXIF_CLR.dll,

or try to call TMXIF_CLR.dll as a .NET assembly with a Constructor Node, instead of a CLFN.

[Dr.Nuke]

Since the integration of the DLL via "Call Function Libraray Node" did not work, I also had the idea of ​​calling the functions via the ".NET constructor".

Unfortunately, I didn't know which is the right constructor (large selection of objects and constructors in the assembly).

I have now received the correct constructor from the manufacturer [TMXIFClass()].

Everything works perfectly now, I've already read in the first measured values.

VI for connecting via USB with the controller and reading the DLL version is attached for people who are also interested in the solution.
However, without a controller the error "RC_ERR_COMMUNICCATION_NONE" will always appear.