LabVIEW
Error 1097 shows up when calling DLL
I am trying to read the data(DllVersion) from DLL.
After execute, The Data such read successfully but the error code 1097 shows up
How can i improve this problem? Thanks!
Thanks!
Unless the DLL itself is buggy there are two likely reasons why you get this error.
1) Calling convention: Try to change that. You use now stdcall but I can't see anywhere in the project files that you have changed the default calling convention which even in Visual C is actually cdecl.
2) Output buffer allocation: Unlike with LabVIEW nodes, a C DLL does not automagically allocate an output buffer. You have to do that yourself either by passing an array or string into the Call Library Node that is long enough or using the minimum size parameter configuration. You do use the minimum size configuration to allocate a 24 byte string BUT from the UI the String already contains at least 24 visible characters. Since this is a C string the underlaying function will at least attempt to copy in an additional NULL termination character and BAM you have a buffer overrun. So read the documentation for your DLL you are calling. Most likely this buffer is supposed to be longer, maybe 32 bytes?
Look, what you expect here is similar to showing a few photos of a car and asking a mechanician to tell you why it doesn't work. Totally impossible unless you crashed the car in a wall!!
Your second image does show the error function which passes in an empty string constant. So unless the Call Library Node is configured to use a minimum size for this parameter, this is certainly a problem, but from the pic this is not possible to see. And if this is the problem I would very much suspect that the library contains many more such errors. This is basic C programming knowledge and the developer of these VIs obviously has no idea about such things, so it would be a miracle if this was the only place with this problem.
If you really want any more than this, you really will need to attach the actual VIs (backsaved at least two versions) and any documentation and header files you have about the DLL.
@WIILE wrote:
I am trying to read the data(DllVersion) from DLL.
Looking at the assembly code of the lower level DLL you wrap here, it expects to be able to write up to 0x80 bytes into this buffer.
But I'm not sure why you wrap this DLL like this, as you basically simply write C functions that call the actual functions in the lower level DLL dynamically 1:1. Lots of work for no gain at all.
![`RI_E`0B]}WKOFP7UIFXV`W.png 133 KB](/ni/attachments/ni/170/1099315/2/%60RI_E%600B%5D%7DWKOFP7UIFXV%60W.png){kind=link}
@YumingSu wrote:
Really thanks for your reply!I really appreciate it.
I attached some VIs here I got from the company.The VI named CHI600eCA was bulit by myself.The error occured in the VI called run_experiment.
Thanks a lot!
There is no 1097 error in the image you show in your last post. What seems to happen is that the run_experiment function returns a value of 0 which seems to indicate that something went wrong. What that could be is anyones guess. Could be an invalid parameter value in one of the earlier functions or whatever.
LabVIEW uses the convention that 0 is not an error and anything else is. As you can see this is a convention and other software can and does use other conventions. The Windows API is even worse as some APIs return 0 to indicate an error while others indicate TRUE and again others return FALSE and lots of them return 0 to indicate succes. It simply is whatever the programmer of a software system fancied that day when he wrote the program. And when he has a headache the next day he may choose to use the opposite convention that day for some APIs. Whoever wrote that API shared library seemed to think that returning 0 in error case is a very good idea. Nothing you or I can do about that than to adhere to that convention when calling this software 
The API (and many other APIs including lots of measurement instruments) clearly use the configure/commit paradigma. In this paradigma you set up various parameters such as sample rate, triggering, buffer sizes etc. etc. and then execute a function to start the measurement. Your run_experiment function sounds perfectly like such a start function. On issue of the start function all the settings are commited and then the operation is started. During this committing the parameters are usually verified to make sense both in itself as in combination with other parameters that were set. If during this verification something appears to be wrong, the start simply fails, since the settings are inconsistent. It could also be that the start fails because of an error in the device itself, could be a hardware error or a setting that applies to a hardware component that is not present or disabled. This is the real error that you need to fix somehow. Where you got the 1097 error is totally unclear from what you posted so far if you even got it. All we have is your claim that you have seen this error. It could have happened of course as a followup error when calling some function to retrieve the error cause. As this function usually wouldn't be called, it is possible that it contains an error in the Call Library Node configuration since it was never really used before. The error handling in the VI is anyhow questionable but the function that retrieves an error string seems to be configured at least correctly.
One thing that is definitely not quite right too is that there is no data dependency between where you set the cluster with values from the individual controls to where you apply this cluster to the settings in the device. It is absolutely possible that by the time the code executing the setting of the parameters in the device, this cluster has not been properly initialized yet so that you write 0 values to some (or all) of the settings!
