LabVIEW
Using the right function in Call Library Function Node
I am trying to communicate with a Picoscope 4262 from Picotechnology. An SDK is available, which includes a dll with various functions to communicate with the scope. These functions can be called using Call Library Function Node. After selecting the library name, I am presented with a list of function names to select from. Each function name seems to have two versions: "Name" and "Name-2". For example, there is the function "ps4000OpenUnitEx" and "ps4000OpenUnitEx-2". I do not know what the difference between these two sets of functions is, and I'm not sure whether it is a LabVIEW issue that I can get help for here or if it is specific to the Picotechnology dll and I have to consult them.
I have attached screen clips of the Call Library Function for both cases. In the first case, the function prototype is "uint32_t _ps4000OpenUnitEx@8(int16_t *handle, CStr serial);" versus "uint32_t _ps4000OpenUnitEx(int16_t *handle, CStr serial);" for the second case. There is an additional "@8" in the first case. I'm wondering if this has something to do with compiler name mangling, which is something that I don't know much about.
Any insight on what the difference is between these two sets of functions and how to know which to use would be great!
The DLL interface was designed by Microsoft around the premise that C programmers can use it to call functions located in external libraries to their own code. Nothing less and nothing more. LabVIEW provides the Call Library Node to access them but can’t change the fact that you need to know everything that a C programmer would need to know to call this DLL and even a little more.
That means that you need to know how to program in C to call that DLL, what functions a DLL exports, the signature (parameters and their types) each function has and any extras such as memory management requirements for any non scalar parameter. Aside from some solid C programming knowledge you do therefore need a documentation for the functions in that DLL that explains all these things and you need to be able to understand it. Otherwise starting to try to create VIs to call a DLL is in the best case guesswork that results in a VI interface library that may after much heartache eventually seem to work (not crash anymore) but still be very far from being reliable and not crash under different conditions and/or cause corrupted values in your application.
Picoscope used to provide a LabVIEW library for their DLL in the past. The programmer of that library obviously had access to the library documentation but they had absolutely no idea about what proper memory management would mean in a multithreaded environment such as what LabVIEW is. They assumed that LabVIEW only runs single threaded and totally unmanaged except that they didn’t care about allocating their memory buffers as would be necessary in an unmanaged environment but used LabVIEW managed memory buffers like they were theirs anyways. It only could work in trivial example applications that executed everything in a single diagram, thanks to LabVIEWs lazy memory deallocation for performance reason.
@cbfsystems wrote:
What you said resonates with me. It sounds like we have had a similar experience with the code for the Picoscopes. It does seem like a bit of a "mess", but I mostly have it doing what I want. I have used the LabVIEW memory manager functions to transfer the data between the dll code and LabVIEW. Even though my code seems to be working, I have the sense that I don't completely understand what I am doing such as with the case of "ps4000OpenUnitEx" and "ps4000OpenUnitEx-2".
I don't use nor have a PicoScope. But I did look at their provided driver after users in the forum had troubles with it and almost threw up from that. It was horrible and violated pretty much every possible rule about properly handling managed memory buffers such as what LabVIEW arrays are. Also the VIs were a way to thin wrapper around the DLL functions to be safely usable for a LabVIEW programmer who isn't a real pro in C programming and read und understood the according PicoScope Programming Manual too.
I didn't attempt to fix it, just commented on what would be needed to make it kind of work and some user seemed to get it so far that it actually started to work without continuously crashing. Unfortunately this is the state of many LabVIEW drivers out there that interface to shared libraries, except the ones from NI of course and a few others. Most LabVIEW users want to believe that the job is done as soon as it doesn't crash anymore and/or return error 1097. Some even believe that that 1097 error is just a stupid annoyance and can be safely ignored as long as the computer doesn't explode or otherwise goes into flames. In reality every 1097 error means, that something went wrong, either the code caused an exception, or some memory was corrupted, no matter that everything still seems to work. And even if it doesn't crash and there is no 1097 error, this is absolutely no guarantee that the code is fully correct. The Call Library Node does all kinds of safety nets such as stack alignment correction, memory trampolines around buffers to detect buffer overflows and exception handling. Anytime it detects one of these things it generates this 1097 error and that simply means something got seriously wrong and it is basically not safe anymore to continue with anything in LabVIEW if you do not want to risk corrupted programs, data or even hardware problems.
But LabVIEW has only so many ways to detect that something went wrong during the Call Library call. There is an indefinite amount of possibilities that a DLL can create problems that LabVIEW simply can't even possibly detect, so even if all seems well it may still be a time bomb that will go off one day, unless you are able to review every single Call Library Node and verify that it actually does everything right, from correct calling convention, to correct parameter types, and correct memory buffer sizes and several more things.
