Error 1097 when passing array from C++ DLL to LabView

[nathand]

Your function prototype has the parameters in a different order than you configured in the call library node. In the prototype the "spl" parameter is first; in the call library node configuration, it's last. Which is correct?

If the parameter ordering isn't the problem, attach your LabVIEW code and the correct function prototype. I'm certainly not about to run some random DLL you uploaded, and anyway it wouldn't help much with knowing how you're calling it from LabVIEW.

[rolfk]

Please compare the function prototype you provided in your post with the one LabVIEW shows you underneath in the Call Library Node configuration dialog based on the parameter configuration you made! Do you find the difference?

What you said your function looks like:

_declspec(dllexport) void calcint(const real_T spl[8100], real_T Cut, real_T threshold, real_T *mean1, real_T *mean2, real_T *mean3, real_T *mean4);

What you told LabVIEW to do when calling the function:

void calcint(int32_t Cut, int32_t threshold, int8_t mean1, int8_t mean2, int8_t mean3, int8_t mean4, int8_t *spl);

You have managed to make more differences than there are parameters which is in fact quite an accomplishment!

- the datatype of all the parameters according to your prototype should be real_T. This is not a standard C datatype so you will have to find out what it means but most likely it is either single or double precision floating point.

- the array is the first parameter in your prototype but the last parameter in the CLN

- the 4 mean values are output values and hence passed by reference. but you configured the CLN to pass them by value

- the function expects an array of 8100 "real_T" values. You will somehow have to convert the IMAQ array data to "real_T" values and make sure that the length of that array is 8100. Since it is a 2D array the multiplication of width * height should be therefore 8100.

- you don't show the configuration of the CLN function itself and have not included the VI either, so I can't say anything about if the calling convention is right but make sure that you configured it for stdcall calling convention

[mael_lam]

Hey guys,

Thanks for your fast reply !

In fact I'v done many test and that's why the function was so messy inside the dll block in labview. Even with double floating and the right configuration it does the same error. I haven't my 4 'means' as it is supposed to be.

I really don't get why. That's why I joined my VI.

Will do some more test to try and see the array I have at the entry but I think he is 8100 long.

[rolfk]

You know the DLL call wasn't just a mess, it was simply wrong. A mess doesn't crash a, a wrong parameter configuration does!

 
Just thinking that the array is long enough is definitely not enough! "I thought the safety switch was activated. Sorry that the guy got killed from the High Voltage"!

And now you changed two points of the 5 or so I mentioned and you wonder why it still crashes!! Read my previous post again and check that all points are correct then we talk further!

[cb0023]

I am also having trouble with a 1097 error. I'm working with DLL code that was mostly provided by the manufacturer and I admit I'm novice with C++ at best. The 1097 is most common with the "Cyton Labview Move" VI. I attempted to write a very crude error handling that would resend the command until the robotic arm accepts the move command which temporarily worked but after a one month break for other work I've come back to this project and now it is crashing after 1 or 2 iterations. I usually use the below labview code and "run continuously" until I've either taken enough measurements or the robotic arm has traversed too far away from the region of interest.

The idea for the program is supposed to be:

1) Initialize robotic arm

2) Read position values from Excel

3) Move the robotic arm to the position (1097)

4) Measure the magnetic field

5) Write new position values and respective magnetic field information to Excel

6) Shutdown robotic arm

7) Run continously

I have attached what I think are the relevant documents, please feel free to ask for more information or any questions. I'm hoping to resolve this ASAP because I have been hung up on this for ages.

*Also if anyone has the time to browse the rest of the .cpp and .h files for other errors that might arise in Labview that would be much appreciated. I have had problems with the "init" function also in particular!

[cb0023]

Another relevant file that I didn't have room for (probably should have just zipped it all together in hindsight...)

[nathand]

There's a lot to dig through here, and yet you haven't included the VIs that actually call the DLL so it would be very difficult to help you. Can you reduce the problem to a single VI where the error occurs?

Your LabVIEW code should never rely on Run Continuously. It's a mode that's useful for debugging a subVI that's called repeatedly. It can cause problems when used to keep a top-level VI running continuously as you're doing, especially when you're calling a DLL that opens and closes a resource. You should open or initialize only once, then do all the work involving the DLL, and finally close it at the end. Restructure your LabVIEW code to eliminate the sequence structures and local variables, and put the main portion of the code in a while loop so it runs until you click a stop button on the front panel (NOT the abort button on the toolbar).

[cb0023]

My apologies for not attaching the correct files. I did not look closely when adding the VI I wanted reviewed, it is now attached here.

The run continuously strategy was a result of trying to escape these 1097 error messages. In loops they would constantly crash but running it as one iteration repeating in run continuously solved this problem (temporarily). Also the sequence is necessary because I want those actions to occur sequentially in that order so I'm afraid to some extent the sequences will be remaining. All that said any feedback regarding the 1097 I'm receiving from the below attached VI would be greatly appreciated!

[rolfk]

If you get 1097 errors you are corrupting memory somehow!! There is no other explanation.

Either because the function parameter configuration doesn't match the actual function parameters, or you forgot to explicitedly allocate output buffers to pass to the functions where the DLL function wants to write information into, or there is a bug in the DLL, writing to illegal memory addresses. Any attempt to solve a 1097 error other than by checking these areas is at best useless, and a lot worse possibly hiding the problem to come hunt you when the application is installed in the field, preferably in a location where you first have to make a ride on a sleigh for 200 km to get there when having to debug it.

So when getting a 1097 error, find the root cause or stop doing anything! If you can't find it, get someone involved who understands the problem and can find it for you! And that might often mean professional help.

From the header file you posted and the VI in your last post, the only possible problem in that VI could be the calling convention. Everything else seems to match the header file declarations. The calling convention is not visible from the header alone. It can also be set in the compiler parameters when compiling the DLL. If Visual C was used the default would be cdecl, as you configured your function, but the person who compiled the DLL could have changed this setting in the DLL project. Other compilers might even use a different default.

But using the undname tool from Microsoft which is part of the Visual Studio installation, the decorated name in your CLN evaluates to:

char* __cdecl  Cyton_LabVIEW_move(int, float, float, float, float, float, float)

So this matches exactly what your CLN is configured. This means the error must be somewhere else than in this CLN configuration or its LabVIEW diagram. How many other DLL calls do you have in your LabVIEW program?

And tell the programmer that passing back strings as function values is a rather awkward way of designing a function interface!

[cb0023]

I'm positive the 1097 is coming from the Cyton Move VI, I have maximum error checking on and it doesn't appear until it attempts to execute the move command.

There are several DLL calls in the program because the robotic arm I'm using works with a C++ API so I have compiled the DLL from the .cpp code and header posted above. It has about 10 functions that all succesfully import into Labview and I use 5 of them at some point or another for the program. I compiled the DLL myself in Visual C++ 2010 Express so I'm almost positive it was set as the default cdecl. Any other ideas on where to check for errors? I can't really find anything wrong on the Labview end and I'm not knowledgeable enough with C++ to really determine any faults with the code.

Thanks for all of you guys help and advice!