LabVIEW
Creating a DLL to work on 2D Arrays
Solved!
@Gregory wrote:
Can you check if I have the MoveBlock or the call to the built DLL defined incorrectly?
It seems to everything OK with your code. I just opened it, recompiled in LV 2024Q1 without any changes, and it seems to be functional:
LabVIEW version should be not problem, of course. Typical issue - during work you copy DLL and source in different locations and calling "wrong" DLL version. OR sometimes LabVIEW is opened, but DLL cannot be written at this moment, etc. Check again. Sometimes I using this trick during debugging: LabVIEW Call Library Function Node Not Unloading a DLL After VI Execution, this will allow to recompile DLL while VI is opened. And one more trick - you can launch two copies of LabVIEW (I don't remember INI key, usually I simiply copy LabVIEW.exe into LabVIEWTest.exe, in one develop DLL and in another one laucht and test DLL. This will "isolate" memory spaces and when something gets wrong with pointers and LabVIEW will crash (may happened), then your dev environment with source will be still OK.
Interesting, I'm finding some inconsistencies with the "MoveBlock" function calls.
PC1 / LV 2016 32-bit : Running "Test Inc Image (ptr).vi" returns all zeroes, Error_Code = 0 (no error).
PC2 / LV 2016 32-bit : Running "Test Inc Image (ptr).vi" returns all zeroes, Error_Code = 1 (error!).
PC2 / LV 2016 64-bit : Running "Test Inc Image (ptr).vi" returns all incremented array as expected., Error_Code = 0.
I went back to the "MoveBlock" function calls. The pointer inputs that were defined as "pointer-sized integer" show an "sz" on the function node, and when I create a control it creates an I64. I made a new function "Inc Image (ptr32).vi" and changed the pointers to be U32. This works on all 3 PC / LV combinations above! But, I feel like I'm asking for trouble defining the pointer as a U32 instead of a pointer-sized integer...
I think your allocatable memory has a 64 bit range on a 64 bit machine. I think you were just lucky that your allocated memory pointer fits into U32.
Could be that the CLN doesn't adapt to bitness after creation regarding pointer size definition.
@Gregory wrote:
Interesting, I'm finding some inconsistencies with the "MoveBlock" function calls.
I went back to the "MoveBlock" function calls. The pointer inputs that were defined as "pointer-sized integer" show an "sz" on the function node, and when I create a control it creates an I64. I made a new function "Inc Image (ptr32).vi" and changed the pointers to be U32. This works on all 3 PC / LV combinations above! But, I feel like I'm asking for trouble defining the pointer as a U32 instead of a pointer-sized integer...
I just didn't catch that you working with both 32- and 64-bit. I using 32-bit very rarely novadays.
Unfortunately such "mixed" build is not very convenient in LabVIEW. If we working with C/C++ dev environment like Visual Studio, then usually we have both build specs shared in one projects and can perform batch build, using preprocessor directives to switch between 32/64 bit in the source if needed. But in LabVIEW you should bulld project in the same bitness.
In general pointer-sized integer should be OK for both 32-bit and 64-bit. In 32-bit LabVIEW it works (strange, the coercion dot shown, but works).:
It is designed in this way exactly for the purpose when MoveBlock called from 32 or form 64 bit and you don't need to change parameters which switched from one dev environment to another or avaoid using conditional compilation. It looks like you will need two build specs - one for 32-bit and another for 64 bit, and with code duplication if you will have separate wrappers it will work. The only question how to avoid code duplication in elegant way, may be conditional compilation will help, something like that:
And in two different build specs use different controls as parameters.
@Quiztus2 wrote:
I think your allocatable memory has a 64 bit range on a 64 bit machine. I think you were just lucky that your allocated memory pointer fits into U32.
Could be that the CLN doesn't adapt to bitness after creation regarding pointer size definition.
Yes, sure it can, but your "problem" is that you using this in unusual "opposite" direction where DLL created in LabVIEW and you have front panel control involved, which can't adapt so easily.
Let me explain, how it work in "usual" way.
For example, you have DLL with two functions — allocate() and deallocate():
unsigned short* allocate (int size, unsigned short fill)
{
unsigned short* image;
image = (unsigned short*)malloc(size * sizeof(unsigned short));
if (image) for (int i = 0; i < size; i++) image[i] = fill;
return image;
}
void deallocate(unsigned short* image)
{
free(image);
}
It is not the best design pattern, but I would like to use MoveBlock to demonstrate.
Now I will compile these two into 32-bit and 64-bit DLLs.
One side note — in buld spec I will append '32' to the 32-bit DLL and '64' to 64-bit, in CVI (you will see below why):
and
Now I will call both from LabVIEW:
I will put both in the loop to ensure and demonstrate that we have no memory leakage at all:
Here two important points.
First one, the DLL called as following:
When opened in 32-bit LabVIEW, then '*' will be repalced with 32, and when 64-bit, then with '64'. This is documented behaviour, described in Configuring the Call Library Function Node.
Second, all pointers are declared as following:
Now when opened in 32-bit LabVIEW, the MyDLL32.dll will be loaded and all pointers will be 32-bit, and when opened in 64-bit, then MyDLL64.dll will be loaded and all pointers will be still OK as 64-bits.
So, I have "universal" sources from both sides and don't need to add any extra code to handle different bitness.
Behind the scenes not only different type on pointer parameter, but also the way how parameters passed to DLL in 32-bit and 64-bit. On 32-bit they passed via stack, and on 64-bit - via registers (the first four). That was a reason why "wrong" bitness on LabVIEW control worked for 64-bit (when here wrong 32 bit type was used) and doesn't work on 32-bit DLL when 64-bit type was used. When 32-bit pointer passed to 64-bit dll, and allocated below 4 GB range, then upper part of register remains unused and everything worked (by the way, typical trouble on migration 32-bit projects to 64 bit), but in opposite direction when to 32-bit DLL occasionally the 64 bit paramater passed, then stack get misaligned - caller expected 4 bytes per parameter, but callee takes data from 8 bytes touched wrong stack area and everything worked not as expected.
And just one more thing - as you can see, when memory is allocated with malloc(), the allocated space needs to be deallocated with free(), otherwise, in the loop, we will have memory leakage. But this is not the case for LabVIEW's Build Array; just think about this. In general, this is also a kind of allocation, but we don't need to deallocate LabVIEW's arrays; they will be deallocated or reused automatically. This is how memory management works in LabVIEW. However, when you try to 'spread' allocation and usage into different DLL functions created in LabVIEW and manipulate the data externally, LabVIEW will have no idea how they are passed over the calls, and you may have a situation where LabVIEW's array gets deallocated unexpectedly. One of many possible ways to avoid this is to start a resident 'daemon' VI with a while loop at the first DLL call, which will hold the allocated array in a kind of functional global, but this will add some additional complexity. On the other hand, I haven't thoroughly tested this scenario..
There's been some speculating and guessing here over the long weekend and I struggle to collect all the points that were somewhat misleading or inaccurate.
About Python open_cv, it uses internally numpy arrays for its image data. These are indeed allocated as single block of memory in 2D (monochrome) or 3D (color channels) organization.
The LabVIEW DLL builder allows to configure 1D arrays to be exported as data pointers, but insists on 2D and higher dimensional arrays being exported as LabVIEW array handle. The main reason is that 2D data can be represented in several different ways that are memory wise completely incompatible. In C and LabVIEW (and Python if you use numpy or by extension open_cv), it is usually a single block of memory where the different dimensions are interleaved in the memory buffer. C++ and pure Python applications tend to often use vectors of vectors for that since that makes them easier to handle for the programmer. It is however a relatively complex way for the processor to handle and also is memory wise not as performant, since the memory manager has to create many blocks of memory for a single 2D array.
The export of function variants with actual pointers in LabVIEW is not really very handy. As you have found it has the problem that LabVIEW wants to treat pointers as 64-bit entity on the diagram (and according front panel controls) to be compatible in both 32-bit and 64-bit. But that creates the problem that the function exports this parameter as 64-bit value, since the DLL export configuration does not support to define the actual type to anything else than the LabVIEW type that is used on the front panel. It wouldn't make much sense to support that for random datatypes but in the case of a 64-bit control it may be useful to allow specifying that this is really a pointer sized parameter.
On the other hand there is no real difference in terms of the Inc Image (1D).vi function and Inc Image (ptr32).vi or Inc Image (ptr64).vi in terms of what is exported, except that the ptr32 and ptr64 variants are bitsize specific. The exported function for 32-bit is exactly the same for Inc Image (1D).vi function and Inc Image (ptr32).vi and the same applies in 64-bit for Inc Image (1D).vi function and Inc Image (ptr64).vi. So those ptr32 and ptr64 variants are simply superfluous.
In terms of what a C compiler creates as assembly construct for passing a parameter, uint16_t ArrayIn[], uint16_t *ArrayIn, and void *ArrayIn are absolutely the same. For 32-bit uint32_t ArrayIn is also the same, and for 64-bit uint64_t ArrayIn is the same. So just forget about the two ptr32 and ptr64 variants they only complicate your DLL interface. You can simply use the Inc Image (1D).vi version. You can change the header file prototype to void IncImage1D(uint16_t *ArrayIn, int32_t NumRowsIn, int32_t NumColsIn, uint16_t *ArrayOut, int32_t *NumRowsOut, int32_t *NumColsOut, int32_t lenIn, int32_t lenOut).
The only kind of ugly thing is that LabVIEW absolutely wants to get the two len values for the passed in arrays, to make sure that the limits of the memory buffers are not overrun in any way. Your user could call this function with an array of length 100 and specify that it contains 10 by 50 elements. If he correctly specifies that the array was allocated with 100 elements LabVIEW will basically create a new buffer of 10 by 50 elements at the Resize function, copy the 100 elements from the input array in there, process it and only copy as many elements in the output array as the second len indicates. It may feel superflous to the user and that is likely the reason you tried to create those uptr32 and uptr64 variants but that only creates additional problems that the exported functions now require two different VIs for 32-bit and 64-bit DLL compilation.
Another mentioning that struck me as misleading, was the comment that LabVIEW arrays will not need to be deallocated as LabVIEW will do that automatically. If that refers to the use of functions like the exported AllocateUint16Array(), then that statement is definitely wrong. The general consensus is that whoever allocates an array should also deallocate it. But that does not hold true for managed environments when using their native managed datatypes. If a LabVIEW function returns an array or string handle the caller of that function automatically gets the owner of that handle and either has to pass it on to someone else for use or properly deallocate it with one of the LabVIEW memory manager functions (or the exported convenience function DeAllocateUint16Array() in the case of this specific DLL). Otherwise you create a memory leak!
