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

[SmorgAsu]

mostly just having trouble troubleshooting the cause of this. 

I keep getting this error but I cant tell what ISNT being allocated. Is there a way to do that? It happens when calling my init function at first, then happens for all of the calls (if i keep pressing continue). 

Within my init function, i am initializing a bunch of robot positions ( eg. double homePos[7], prePres[7] etc)

do those need to be initialized in labView too? I never output them nor input them from the callDll node. I only input speed, movement strings, and a created pointer for the robot. Those are all initialized as global labview variables. 

[nathand]

Please provide more detailed information: your VI (or at least how you've configured the Call Library Function Node) and the C header file (.h) or function prototypes for the functions you need to call. There is no way for us to understand what you mean by "keep pressing continue" nor to know what your init function does without that information.  If those 7-element arrays that you describe are parameters to functions that you call, then yes, you need to initialize them in LabVIEW before passing them to the DLL.

[SmorgAsu]

attached are my VI and the two headers in the .sln file. 

The robot movements work 95% of the time and I get an unreplicatedable error 1097 (that is, it doesnt always happen at the same time, sometimes just at the beginning of the experiment, sometimes an hour in. Sometimes i just have to ignore it, sometimes it crashes labview entirely.)

[nathand]

Sorry, no way I can figure out what's going on in that VI - my monitor isn't big enough.  Also, there's probably no need for the sequence structure, nor the local variables (particularly for the UDP connection ID).

Did you write the DLL, or is it supplied by some outside vendor?

It's a bit weird that you do an init-command-destroy each time; I don't know about your DLL, but normally you would do an init one time when the program starts, hold on to the object handle throughout the program, and destroy it at the end.

Do you know which DLL call causes the problem?  If not, in ALL of the Call Library Function Nodes, set the Error Checking level to Maximum and see if you get a more helpful error message when the error occurs.

[SmorgAsu]

I know, its a little ridiculous to troubleshoot. Lots of scrolling. Unfortunately, both the DLL and the VI are inherited code. Ill turn on the maximum error checking and try to reproduce the error. the udp stuff is necessary for the communication between a different machine for other purposes. 

would the 1097 error come up if the objHandle is not destroyed properly? Im not sure why he structured it that way, but it seems to be a common theme among the code ive read of his. 

[nathand]

I wasn't saying the UDP stuff is unnecessary, I'd just suggest using a wire instead of a local variable to carry the connection reference.

Error 1097 is pretty much a generic error that says the DLL failed in an unexpected way, and could have corrupted memory.  It's possible that failing to destroy the object handle, or alternatively accidentally destroying it again after it's already been destroyed once, could cause that error - there's no way to know, at least without access to the DLL code and a debugger.

[SmorgAsu]

hmmm. debugger recommendation? im not much of a c++ programmer, soooo. 

[nathand]

Can't help much there, that's outside my expertise.  You'd at least need a debug build of the DLL and probably the source code for it.  "Debugging DLL Projects" from MSDN might be a good start, if you're using Visual Studio to build the DLL.

[rolfk]

---

@SmorgAsu wrote:

hmmm. debugger recommendation? im not much of a c++ programmer, soooo. 

---

Well, I use the built-iin Debugger of Visual Studio. But without DLL source code and the according project file for your version of Visual Studio, you would be put into the disassembled assembly code listing of the DLL which is several magnitudes harder to debug than plain C (and if your code happens to be written in C++ the assembly is very hard to follow through the code flow).

As to the rest of your VI:

1) please use subVIs! Almost every Call Library Node should be in their own subVI with the parameters passed through the connector pain. Add an error cluster in and out to each and you can forget just about all sequence structures, as data flow will determine the right execution order.

Now, if your DLL changes in some ways and a function prototype has to be modified, you have to go through your entire program and find each occurrence of that Call Library Node and fix it. If you use subVIs you can fix it in one place and are in most cases done.

2) I would convert the command string early on in an enum and use that instead. Get rid of all locals as much as possible.

3) void *objPointer is a pointer sized integer passed by value, not an in32 sized integer. The int32 will only work as long as you don't move to LabVIEW for Windows 64 Bit and an according 64 Bit DLL. While this may possibly seem unlikely at this point for you, one of the next versions of Windows will be 64 Bit only and then LabVIEW will soon follow suit.

4) You mention about the functions that require arrays as parameters but your VI doesn't seem to use them anywhere. You are right that you would need to allocate those arrays in the LabVIEW diagram. C functions generally can't allocate memory on behalve of the caller since it is totally unmanaged.

5) Those DLL functions all return an integer, supposedly an error indication of some sort. Use it!!! Init() could for instance return 0, indicating an error during initialization and your other functions, might or might not actually check for that situations, possibly causing an access violation. Almost all other functions return an integer. Not sure if they would indicate 0 on error or success but reading the doc will tell you that, and using that error indication to put an according error into the error cluster of your  subVIs would be proper error handling.

6) internal diagram logic is terribly involved and repeats many things unneccessarily.

7) Your outer loop has a timing of 1ms. This is unneccessary low and will NEVER be reached. The loop as you have programmed it will be timed by the UDP Read VI already and if it is operating by the inner move loop. So get rid of the timed outer loop altogether and make it a normal loop.

😎 Get rid of all those locals, fast! the "Read Cnx ID" and may others are totally unneccessary and should be wired through the diagram instead. "Task Success", "Bad Sound", "HoldPadSuccess" deserve a honnorable mentioning for a very ingenous way of creating Rube Goldberg code!

9) The repeated Init(), Destroy() cycle in every loop iteration is most likely a bad idea. I have no idea how the DLL is implemented but it is at least a time consuming thing to do, and possibly could cause some of your problems if its internal resource management isn't 100% perfect. I'm pretty sure that any C code using that library would only Init() once in the beginning and then

10) Last but not least: Controlling robots remotely through shared variables may seem cool, and I have no idea how big and possibly destructive that robot could be. However using shared variables for transmitting such commands sounds to me somewhat less than 100% safe unless the worst that can happen is a small play robot running into a wall.

11) I haven't checked every single Call Library Node for correct configuration, but I couldn't see something glaringly wrong in them. Are you sure your DLL is absolutely up to snuff and doesn't somehow cause internel errors by trying to read uninitialized variables or such? Error 1097 means usually that the Call Library Node user has forgotten to allocate necessary buffers to pass to the function, but it can just as much mean that the DLL is simply buggy (although that is usually a lot less likely for released DLLs, in comparison to the chance for the Call Library Node to be configured and called wrongly by the LabVIEW programmer.

[mael_lam]

HEllo everyone !

am bringing back this topic because this error poped for me too.

I do not understand why. I put a 8bits array (from a picture thanks to the vision picture-to-array VI) inside my dll (That I joined here) an int named "Cut", an int named "threshold" and it is supposed to return 4 int values mean1 mean2 mean3 mean4.

This is the function declaration inside the dll:

_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);

When I trigger the dll inside labview it goes fine, it finds the function inside the dll, I ass my differents inputs/outputs. But I have this error. Help please !!

thanks a lot !