LabVIEW
C++ dynamic library problem with Numerical Recipes (ADVANCED!!)
It is a LabVIEW question, more precisely how to write an external code shared library that LabVIEW can interface to. But my C++ knowledge is not good enough to be of much help here.
@StevenA wrote:Is this a LabVIEW question? Try positing this to the Measurement Studio for VC++ board
Most likely you are doing something bad with the LabVIEW array handle that gets entered as mag_array. Not sure if your Spline2D object copies the entire data from the array into itself or if it tries to simply hold a reference to it. In the second case you are doing something very bad. That LabVIEW handle is only guaranteed to be valid for the duration of your call. After that LabVIEW simply assumes that it has gotten full control of it and will deallocate it, resize it, change it, clobber it or simply eat it, whatever it's mind is up to at that point.
So unless your c = NRmatrix<double>(m, n, (*mag_array)->elt); or at least the new Spline2D_interp(a, b, c); call does create a full copy of the original handle (or does not need to reference that data later on) your array is only by great exception going to survive between your two Call Library calls and if you should happen to try to write into it your going to overwrite sooner or later vital LabVIEW internals since LabVIEw has deallocated that handle long ago and reused that memory for something else since.
Rolf Kalbermatter
Message Edited by rolfk on 06-13-2008 10:59 AM
Yes you misunderstood at first what I was trying to say. This here is more precisely what I had in mind but which I might have not been able to express as clearly as I would have wanted to do. LabVIEW does not interfere with memory you allocate yourself at all but it considers handles it passes to the DLL to be generally owned by itself and will accordingly do with them as it pleases as soon as your DLL function returns control to LabVIEw. So storing a reference to a LabVIEW handle passed in as function parameter into a structure to use later will be doomed to fail.
@dgholstein wrote:
Rolfk; I just re-read your post, you indicate that it isn't the data allocated in the DLL that is suspect, that it may be C++ code is storing pointers to the LabView data, which is then clobbered between calls. I'll try building/allocating a new structure and copy all the necessary data into that, then build the splines and work from that. ...I'll let you know
If you want to do that you would really have to pass that handle by reference (Pointer to LabVIEW Handle) to your DLL, store that handle somewhere and replace the value in the parameter with a handle that you allocated with LabVIEW memory manager calls such as for instance NumericArrayResize(). Basically you take in that way ownership of the handle passed in from LabVIEW and give LabVIEW a different handle back. There is also an optimizing shortcut for empty arrays (which might be not very well documented) where a LabVIEW NULL handle is treated as empty handle too. So instead of allocating an empty array you can simply NULL out the referenced value of that parameter and LabVIEW will consider it an empty handle. This is especially handy if the right side of that parameter is not connected since that will cause LabVIEW to deallocate that handle immediately so that it makes no sense to allocate a memory location to hold an empty array to have it deallocated immediately by LabVIEW later on.
However don't forget that you now own that handle and need to deallocate it explicitedly using DSDisposeHandle() when you destroy your handle (object).
Rolf Kalbermatter
Message Edited by rolfk on 06-13-2008 08:51 PM
When I said LabVIEW handles I meant parameters like your TD1Hdl one. This is a pointer to a pointer to a memory area where LabVIEW stores the array data (and its dimension sizes). Such handles need to be allocated, resized and finally deallocated using LabVIEW memory manager functions.
@dgholstein wrote:
Rolfk;
Again, thanks for the input -- these are not easy things to program and I don't work with anyone who programs at the same level. An acquaintence at a national lab, who is not familiar with LabView but has programmed similar problems with Python, was able to point out the same things as you did.
One interesting difference between what you describe and how I program. I've been allocating to a pointer, then return that pointer to LabView as an unsigned int, I then typecast that to a reference (for the correct looking wires) and do the opposite when I need to pass it back to my DLL (which I C/C++ typecast back to a C/C++ pointer). I was told that I shouldn't use LabView handles since those are very well-defined for file handles and TCP connections etcetera -- and that I might hurt myself.
BTW: I bundled all the information into one C++ structure and use that pointer (typecast to reference) within LabView, it seems to work now.
...Dan
What you refer to as handles are generally handles in C programming but LabVIEW calls them refnums.
I do sometimes use datalog refnums to pass around my private data handles. Dropping in an enum with a single enum value specific to your handle type will basically refuse to allow anyone to wire something else to that connection pane parameter than my own private handle type.
You can wire a refnum wire directly to a Call Library Node parameter configured to Adapt to Type. LabVIEW will pass that "handle" then always by reference.
Rolf Kalbermatter
Message Edited by rolfk on 06-13-2008 10:46 PM
