LabVIEW
Call library function to access a dll crashes labview 2020
Solved!
First, there is no attachment.
Second you say there is a problem with Take Measurement. The name of this method would indicate that this function will return data and then there is a very high chance that you made the error of so many trying to venture into the Call Library Node to call a DLL. EVERY memory buffer passed to a DLL function normally needs to be preallocated before calling the function. So if you need to pass an array or string buffer to the function so it can fill in the measurement data to return to your program you need to make sure to allocate that buffer properly with the correct size before calling the function!
Please make a Save for Previous Version for the Self Test Oscilloscope.vi for version 2018 or older.
But the website for ZTEC doesn't exist anymore. Seems that company is gone and I wonder if you really want to invest any effort to get this working with hardware that seems totally unsupported and obsolete.
All I can say is that the DLL calls seems to be configured to use C calling convention. Depending how it is compiled this could be very wrong, and as the LabVIEW library seems to be in LabVIEW 2011 format and likely developed in even earlier format before 2010 so it may have worked back then but not anymore since LabVIEW 2010 and newer does not automatically detect if a DLL uses stdcall or cdecl and simply uses whatever is configure in the CLN node.
I can't check as with the company side gone I can not find documentation nor a download for the DLL itself.
The original problem had to do with code that worked in previous versions of LabVIEW and now fails. Is your case the same?
What you describe seems quite different and the problem with crashes when calling DLLs is that there are a zillion possible reason. While bugs in LabVIEW are not completely possible to exclude I have in my many years of calling DLLs from within LabVIEW never really had a clear LabVIEW bug that would cause it. It was always caused by badly configured Call Library Nodes and/or bugs in the DLLs itself. This leaves a lot of potential issues to be checked before you can point at something specific. The first question would be, who write the LabVIEW VIs to access those DLLs? What is their C programming expertise? If this was not done by a real C programmer, you definitely have your task carved out to first start checking every single Call Library Node to be properly configured according to the header file data types and buffer allocation requirements. After that the next step would be to isolate the DLL calls to create a test application that only does the critical calls and try to get it to crash too. Then you have something more specific to look into and even post here.
Obviously neither me nor any LabVIEW developer is going to check your huge application for any such problems. That's potentially many days or even weeks of work and not part of my job description as forum volunteer nor part of the job description of any LabVIEW developer at NI. 😀
And yes your first argument is likely but it works for hours fine before it crashes therefore it can't be a Call Library Node misconfiguration! All I can say to that is: this is a wrong assumption. Not every misconfiguration has to crash immediately. It can go on for a long time corrupting at every call some memory before the problem gets so grave that someone somewhere stumbles over the corrupt memory location in a way that causes a crash. Often such errors only get apparent when you shutdown your application and LabVIEW and LabVIEW dutifully goes and tries to deallocate all the different resources and then stumbles over the corrupted memory pointers.
