12-31-2023 02:03 AM
Dear LabVIEW community,
I am currently working on a project that requires implementing control of a DMD chipset through LabVIEW. The goal is to put the DMD in slave mode and project specific images at specific times controlled by an external trigger.
Our team has purchased a V-9501 DMD chipset from a company called Vialux. This chipset comes with a programmable FPGA and onboard memory that can be configured to store and execute a particular sequence of images.
The company has provided us with a C++ DLL library that has various commands for interfacing with the device. However, the C++ library functions expect to receive pointers as inputs instead of numbers or arrays. I am facing difficulties incorporating them into the LabVIEW environment, which does not natively handle pointers.
My biggest problem is how to upload an image to the device using LabVIEW. The DLL function that should execute the upload the sequence expects to receive a pointer to an 8-bit image as input. I have tried to write a new C++ function that takes a string specifying the image path and outputs a pointer to this image, but I am struggling with the implementation. There are multiple differences in conventions, for example LabVIEW strings not being null-terminated C-style strings so the path is not understood correctly by the C++ function.
Is writing a C++ function and using the Call Library Function node the right approach to solve this problem , or is there a simpler solution? If using a C++ function is the way to go, are there any specific libraries that I can use? Since I'm relatively new to both LabVIEW and C++, I would appreciate any advice, documentation, or implementation examples for similar problems that you may have encountered.
Thank you in advance,
Anastasiya
12-31-2023 05:20 AM - edited 12-31-2023 05:31 AM
Your claim that LabVIEW doesn’t provide NULL terminated C style pointers is already wrong. If you configure a Call Library Pointer as String, Pass as C Data Pointer, the Call Library Node will actually append a NULL byte at the end, then pass the internal pointer of its string handle to the DLL function and if you wired the right side terminal of that parameter, it will also scan the C String for a NULL byte (up to the original passed in length of the buffer) after the function returns control to LabVIEW and adjust the string size accordingly.
And when you configure a Parameter as Array of any C scalar type, Pass as C Data Pointer, LabVIiEW will pass exactly a pointer to the array data area to the DLL function.
This should be already enough to solve most APIs. LabVIEW itself does not provide pointers on the diagram level since they are poison in a data flow programming language that allows concurrent execution of its nodes purely limited by data flow. But the Call Library Node is special as LabVIEW assumes that parameters passed to it have to be considered taboo for the duration of the Call Library Node call (unless you enable the “is constant” check box for that parameter), but your function better treats that parameter as really constant (no attempt to modify anything in it at all) or things can go quite wrong sooner or later.
if you really need to pass pointers between Call Library Nodes you have to configure the according parameter as Integer, Pointer sized and as this is simply a scalar number as far as LabVIEW is concerned, you or your DLL functions are 110 % responsible for fully managing the memory for them. LabVIEW has no idea if this is really a pointer, nor to what it points and what memory management contract it has!