LabVIEW
Error 1097 calling dll
Solved!
I second nathans post. Error 1097 is almost always an error in configuring the Call Library Node right. And in some cases there is no right way to configure and you need a wrapper DLL to convert between what the Call Library Node allows and what your DLL requires. The reason that it sometimes works and other times not, is in fact that it never really works, but sometimes the error that gets caused can not be detected by the OS and LabVIEW does not get an according exception. This can change depending on LAbVIEW version, runtime or development system and even recompilation of the code after small seemingly unrelated changes to the application.
@jak888 wrote:
The thing is:
I don't have many options left to configure e.g.: there's one function called void initialize (uint_16t nDevNo) so I call it configuring it accordingly. The only thing I could change is the calling convention. When I set it to C I got the 1097 error. When I set it to stdcall I think it destroyed the dll. I had to replace it to make the VI start again.
When I looked at the dll before I baught the grabber card, I paid attention if there were any "funny" variables, like unions, structs or Arrays of pointer to union of struct, because I had Problems with stuff like that before. The dll is really simple basically, so I don't quite get why it shouldn't work. As you said: the reason it sometimes works and sometimes not is because it never really works...
Today I am going to send back the frame grabber and order another one that's supposed to work with DirectShow... Hopefully that turns out better.
Well a frame grabber surely has more complex functions than "void initialize(unsigned short)". How would you get otherwise the grabbed image in LabVIEW. If this function alone already bombs (sorry for the old Mac reference), well then this DLL surely is worthless. It could be that you need to pass a valid device number of course, but such a simple function that attempts to corrupt memory when passed an invalid parameter is simply rubbish.
Usually the problem starts with other functions. And it's not only the problem with the complicated data types. A simple byte array can cause that error too. Lets assume you have instructed the frame grabber to return an image of 1024 * 800 pixels in RGB 8 bit format. When you call the grab function, it will want to write the image data into a memory buffer. And someone needs to provide that buffer. And LabVIEW not having mind reading capailities can not do that for you. So you need to know how the function will try to store the image data in the buffer. Each pixel would require at least 3 bytes. Maybe 4 if they store it in RGBx format, since that is easier to align in memory. Then the grabber may also add a border around the image. This could be anything from 0 to several pixels on each side. And last but not least it may add a header with image information before the image pixels.
So you get x + (1024 + y) * (800 + y) * 3 or 4 bytes. This buffer needs to be allocated by you on the diagram and passed to the DLL function.If you happen to not allocate that buffer or make it a few bytes to small the DLL function will attempt to write into memory that has not been allocated for that purpose. It could not be allocated at all for the current process in which case the CPU will raise an exception, and LabVIEW will report the 1097 errror or it could be allocated for something else in LabVIEW and sooner or later LabVIEW trips over that corrupted memory and does something weird or crashes, causing itself an exception that could cause the 1097 error. Sometimes the error only makes itself apparent when you close LabVIEW and it tries to properly deallocate all its memory blocks, stumbling eventually over some corrupted memory pointer your DLL has caused.
A frame grabber may support different image formats so your grab function would also need to be flexible enough to account for that too.This all is why writing a frame grabber interface for LabVIEW (or any other programming language) is usually a much sought something but seldom gets done by anyone in a way that really works.
Unless the OP wants to use some digital interface, there is no NI hardware anymore, that is recommended for use in new applications. NI has discontinued all analog frame grabbers or at least put them into "not recommended for new applications".
