LabVIEW
Call library function to access a dll crashes labview 2020
Solved!
Well you see, it's nice to attach those drivers but I'm not gonna check them for misconfigurations and even less for bugs in the DLL The fact that it didn't crash in LabVIEW 2015 is no reason to believe that the problem didn't exist back then too. It only means that the memory layout was different and the corruption never happened in a location that crashed the program within a reasonable runtime. The fact that it still takes hours before it eventually crashes only is more proof to that. But with LabVIEW 2020 and on a newer OS, the memory consumption is considerably bigger and the chance to run into some problem sooner than before accordingly higher.
So this comes down to the point where someone who is really knowledgeable about C programming has to carefully check all the VIs for potential problems and if that still doesn't fix the problem its real debugging time, except that without the source code for those DLLs that is pretty much just a wet dream.
I did a quick look through the "drivers". Drivers stands between quotes since the BISS1SL driver can hardly be called a LabVIEW driver. It's a literal 1 to 1 translation of the DLL interface to LabVIEW! Which is simply outright stupid and useless.
A typical case of: Start the Library Import Wizard, hack around until all important APIs can be imported, et voila, there is a LabVIEW driver. NOT!!!!!!!! EVER!!!!!!!!
I'm specifically referring to functions like:
- BISS Read Slave Register
- BISS Write Slave Register
- BISS Save Register
- BISS Load Register
They all either write LabVIEW arrays or read them. And also have a parameter that defines the length of that array. Except that the array is in integer elements but the length parameter is in bytes if I should believe the name of that parameter.
LabVIEW arrays have an inherent length parameter already with the array, so there is really not only no reason to wire that length parameter out to the API of such VIs but it is even wrong, as it makes the caller responsible to write the correct value to this parameter that corresponds with the actual array length. And most LabVIEW programmers have no idea about such details or might simply wire the array size output to this parameter and BUMM!
Instead driver VIs should make this translation themselves. The read function should only contain an input control specifying how many values/registers should be read, the VI internally allocates an array of the correct type and size, wires this to the correct DLL parameter, calculates the right size to pass to the pulNumberOfBytes parameter (probably 4 times the number of registers specified), does NOT inherently resize the buffer to the size of the pulNumberOfBytes parameter inside the Call Library Node, as that one is in Bytes, while our array is in unsigned int's, then after the Call Library Node call, it divides the returned pulNumberOfBytes by 4 to get back the number of actually returned registers and resizes the array to that size. That IS how a proper LabVIEW driver VI for the BISS Read Slave Register function should look like.
And the BISS Write Slave register should not have a pulNumberOfBytes parameter at all as input, instead the VI should calculate that from the length of the passed in array and the Call Library Node should again NOT configure the pulRegisterContent parameter to be resized to the pulNumberOfBytes parameter value but simply use the passed in array and the VI should make sure to calculate the right pulNumberOfBytes value itself. The VI can return the pulNumberOfBytes value after the call but should probably adjust it again by dividing it by 4 and call it "Number of Registers Written" or something.
And I'm sure there are many more such discrepancies and while these specific ones in the Read and Write Slave Register shouldn't cause memory corruptions, they surely cause lots of unnecessary memory reallocations and saddle the user of these "driver" VIs with C programming trivia that most LabVIEW users would never have any idea about. In that sense it is not a LabVIEW driver at all!!!!
With such a driver it is not only guessable but in fact a pretty safe assumption that the programmer who did them may know about C programming but has simply no idea at all about LabVIEW programming. And the user of that library needs to both know about C programming and DLL specific trivia such that the pulNumberOfBytes parameters are in bytes while the arrays are in integers but that those two need to correspond together. A totally unnecessary requirement to the user of this library. With such programming visible in the driver it is almost safe to assume that some of those VIs will actually contain code that will pass wrongly sized buffers to the DLL that will make the DLL corrupt memory when returning data to the caller and such corruptions will eventually lead to the application simply quitting, with or without crash dialog.
