LabVIEW
Error 1097, but unfamiliar with code and programming
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.
@jbCCNY wrote:
Thank you Rolf, your response does seem to give much more insight than other places I have searched. As I mentioned, this .vi was included with the installation CD for the device and, after browsing the web for solutions, I saw that many people had trouble with the .vi locating the .dll, and before I created the path constant I had to load it 13 times for each of the nodes. I created the constant as a quick solution although I'll try relocating the .dll and see if that helps.
As far as the getChannelData() node, I do see the hidden array controls. I'm not sure if changing them would fix this problem but I suppose it won't hurt to try.
My only other option is to use this device as a VISA, which I have the controls for, however the manufacturer did not include any of the string commands which the device reads (ie. ID query). I would need to find those and if I succeed, I already have a program set up for VISA control.
Any advice on finding these commands? (Besides contacting the manufacturers in China who have yet to respond to my email).
The only advice I have is to use a device with better and more professional support. I know China is cheap, but here as with most other things, the rule applies: you get what you pay for.
