Error 1097, but unfamiliar with code and programming

Question

USB device (Hantek DSO-2090 USB Oscilloscope) came with .dll and sample Labview file.  It wasn't working until I applied a path constant to each Call Library Function Node, yet the largest one always seems to yield Error 1097.  Not sure why, but I'll include everything.  Please help!
Attachments:
DSO2090.zip ‏85 KB

Answer 1

Actually wrong calling conventions quite often crash instead of causing error 1097. Error 1097 can have lots of causes but one of the most common is that the programmer has not preallocated array or string buffers used as output data before calling the C function. Most LabVIEW programmers are so used to LabVIEW handling array and string resizing automatically, that they don't even think about that this could be different when dealing with the Call Library Node. But here the external C code has normally no way of resizing such arrays to whatever size it needs and LabVIEW has no way of knowing what size the C function requires for the buffer. So there needs to be the programmer who deduces that information from function documentation, intuition, experience and sometimes simple trial, error and crash exercises to make this explicitedly.
I took a quick look at the VI in the OP and I was truely appaled by it's lack of structure and architecture. This is not a LabVIEW example to show off for sure. Nevertheless, based on the claim of the OP that the LARGEST node causes the error, (talk about clearness in communication caused by such a spaghetti diagram) I assumed he meant the  dsoGetChannelData() CLN and that indeed has two array inputs that are meant to be filled by the function. They are connected to two hidden array controls containing 30000 elements of default data each, so as long as the function does not try to return more than 30000 samples for each of the two channels, this should not be the problem. But I'm not sure if this oscilloscope will ALWAYS return exactly 30000 values for each channel, or if this number can be adjusted somehow. It's however the only thing I can say based on the claim that the largest node causes the error. And digging into this deeper requires the DLL documentation and lots of time, which I don't plan to invest in such a poor piece of software.
The reason that he needed to define the path to each node is that the DLL clearly is not located in a standard nor fixed location. Windows will never search any directory in the Program Files directory for DLLs, unless that directory happens to be listed in the PATH environment variable. And the Program Files directory path can change based on Windows bitness, system administrator configurations and more. In order for LabVIEW to find the DLL on any system, the DLL has either to be:
1) in the same directory as the VI or project file
2) in the executable directory (where labview.exe is or yourapp.exe for a built application)
3) in the $(System) directory
4) in the $(Windows) directory
5) in a directory that is listed in the PATH environment variable
But moving around DLLs without knowing what you are doing can make the DLL unloadable as it may be missing dependencies that way.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions