From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Python calling LabVIEW dll: Fatal Internal Error When Accessing Output String Cluster

Solved!
Go to solution

Hi,

 

 

We have built a LabVIEW DLL (TestError.dll) and tried to call it from Python.

TestError.dll includes 2 functions:

1. TestError: 1 string cluster input, 1 string indicator

2. TestError2: 1 string input, 1 string cluster output

 

What we are trying to do in Python is actually something like this:

1. Supply values to Controls in the DLL functions.

2. Call the DLL.

3. Get the values of the Indicators.

 

 

What we observed are:

1. Write/Read operations on Controls/Indicators of normal data types (string, numeric) are OK

2. Write operation on String Cluster Input is OK

3. Read operation on String Cluster Output is Not OK. The following error is always prompted:

    - "Fatal Internal Error: "MemoryManager.cpp", line 437. LabVIEW version 8.6..."

 

Have also attached TestError.prj and the python code.

 

Appreciate if someone can help to explain why we are getting this error, and how to overcome it?

 

 

Thanks,

howmean

 

Download All
0 Kudos
Message 1 of 3
(3,158 Views)
Solution
Accepted by topic author howmean

 


 What we observed are:

1. Write/Read operations on Controls/Indicators of normal data types (string, numeric) are OK

2. Write operation on String Cluster Input is OK

3. Read operation on String Cluster Output is Not OK. The following error is always prompted:

    - "Fatal Internal Error: "MemoryManager.cpp", line 437. LabVIEW version 8.6..."

 

Have also attached TestError.prj and the python code.

 


 

It's very logical that this doesn't work, and the bad news is, it can't really be made to work reliable from a non LabVIEW process.

 

LabVIEW strings (and arrays) are very special species. They are so called handles, which are pointers to a pointer to a memory block. If you have such a control or indicator on its own, the Prototype configuration allows you to configure this parameter as a C data pointer. LabVIEW, when creating the DLL, will create C stubs for every exported function, and in there place code to make the translation between the passed in C data pointer and the needed LabVIEW data handle. For strings and arrays inside clusters there is no such configuration option and the DLL expects to be passed a structure with native LabVIEW data handles in there.

 

You may say that creating the necessary data handles in your calling process would be enough to trick LabVIEW. For input variables this actually MIGHT sometimes work (but is a tricky and generally unsafe way of handling this). For output variables there is no way to make it work. LabVIEW will try to resize the handle to fill in the data it wants to put in. This resizing is done using the LabVIEW internal memory manager functions. This will only work if that handle was allocated by EXACTLY the same memory manager instance. Otherwise it will refer to a different memory heap and catastophally fail. The only way to make this work maybe, with lots of luck, holding your heart and praying to the Gods, is to call into lvrt.dll to allocate any handle you need to pass to the DLL. Yet locating the right lvrt.dll, that will execute your LabVIEW DLL is a challenge of the highest order.

Rolf Kalbermatter
My Blog
0 Kudos
Message 2 of 3
(3,141 Views)

Hi Rolf,

 

 

Thanks for your reply. Looks like we'll have to drop the idea then.

 

 

 

howmean

0 Kudos
Message 3 of 3
(3,126 Views)