Complex Structure Problem in Calling DLL with Labview

[rolfk]

In each of the the three substructures, you have first an int that specifies how many double elements will follow!

I told you, after getting the MotomES Open function to work, the real fun will only start! Real C programming knowledge is not optional but mandatory to do this kind of things.

Basically if you can't write a C program to call these functions, you know not even remotely enough to be able to call this from LabVIEW. While the Call Library Node allows to call DLLs, the entire DLL interface was designed and build around the idea of calling it from C. Any other language offering DLL interfacing has to deal with that and can't give you magic code generation to "Just make it work" (TM).

[Freddy.]

Sorry, I didn't understand. I checked the Header file and found no parameter about the number of floating point values required to be input in the ESCartMoveData structure.

[rolfk]

A well, I looked at the comments on the diagram. But they seem to be from the .Net DLL, not the C header file.

Your problem is a different one and rather nasty. The ESCartMoveData structure is passed by value, not by reference. There is no easy way to do that in the Call Library Node. Basically it means that the entire structure is flattened out on the stack in 32-bit Windows. The only way to resemble that in LabVIEW is by correctly putting all the individual elements of the structure on the stack by passing them as parameters to the function and to be very very careful about alignment. All the int (or long) elements are their own parameter, each double has to be split into two uint32 and passed as such in the correct order. And yes, that parameter list will get HUUUUUUUUUUUGE. And to make things more interesting, it is entirely different for 64-bit Windows. Here any structure not fitting into a 64 bit slot will be passed by reference no matter if the asterisk is present or not in the declaration! Isn't programming fun?

[Freddy.]

Do you mean that I must pass in the parameters of all structures in ESCrtMoveData one by one as numerical values in the labview instead of using clusters? Is this too complicated..

By the way, in ESGetPosition, there is also an array in the structure. I split the array elements and passed them through clusters, which is complete without any problems, and I did not pass the array size parameter.

[Freddy.]

Good morning everyone!

I am trying to use the Call Library Node of labview to call DLL files, but there is a problem that has been bothering me for a long time:

The interface Function prototype needs to pass in a complex structure, but any way I use clusters to pass parameters in labview will cause the program to crash! I uploaded the DLL file, vi file, and function description file.

The prototype of its structure is:

public struct ESCartMoveData
{
public ESMoveData moveData;
public ESPositionData robotPos;
public ESBaseData basePos;
public ESStationData stationPos;
public void Init()
{
robotPos.Init();
basePos.Init();
stationPos.Init();
}
}

[Freddy.]

After flipping through a pile of materials, it seems that there is no issue with the alignment of C and LABVIEW bytes. My understanding is that the ESCartMove function needs to pass the structure value instead of the structure pointer, but it cannot be directly passed in labview.

[rolfk]

---

@Freddy. wrote:

After flipping through a pile of materials, it seems that there is no issue with the alignment of C and LABVIEW bytes. My understanding is that the ESCartMove function needs to pass the structure value instead of the structure pointer, but it cannot be directly passed in labview.

---

That is an accurate description. Alignment should generally not be an issue as the header explicitly uses #pragma pack 4 and all the elements in those clusters seem to be either int/long or double so should in fact never need filler bytes.

But the doubles will need to be split into two 32-bit values to be passed as parameters to the Call Library Node and only for 32-bit. In 64-bit you need to pass those structures by reference anyways even if the parameter is declared as by value, unless the entire structure has a sizeof() value of 64-bit or less.

The wonders of ABI specifications for a particular platform can be very “interesting”.

[Freddy.]

My system is 32-bit, and the development environment is also 2020 32-bit. Do you mean to split all double type data into INT32? But when I called the ESGetPosition function, his data prototype was:
Typedef struct
LONG dataType,
LONG fig,
LONG toolNo;
LONG userFrameNo
LONG exFig;
ESAxisData axesData
）ESPositionData
#Define Number_ Of Axis (8)
Typedef struct
DOUBLE axis [Number of Axis] 1ESAxisData
Member:<axis [Number of Axis]>Axis data of robot (Size=8)
The array data of axes is a Floating-point arithmetic number that I pass directly, so there is no problem.

[rolfk]

The ESGetPosition function passes this parameter by reference. It has to as the function needs to be able to return values in it. If it would pass it by value, the elements could never be read by the caller after the function returns (at least in 32-bit, not sure if 64-bit does mandate some shadow copy to prevent the function from being able to overwrite the values in the structure if it is defined to be passed by value).

The ESSetPosition function however passes this structure by value (you see the missing asterisk before the variable name?) and hence you will need to do the whole structure disassembly into individual 32-bit parameters there too!

Generally, APIs passing (especially large) clusters by value, may seem like a very clean and pure idea in terms of programming logic, but are in fact a resource hogging thing to do as the entire structure has to be copied onto the stack every time. That takes time as well as stack space, which is not unlimited at all.

[Freddy.]

So the only feasible solution currently may be to write another DLL to pass the structure……