Using call library function on a dll file created in an old version of labview

[imagetable]

So I'm trying to update an old labview program to work in labview 2012. Everything converted over just fine but labview will always crashoverwrote some while using a  library function in a DLL that was compiled using labview 8.5. Labview exits, stating that it vital memory area. It passes an array of data to the library call and an empty array for output. I thought I could get around this problem by changing my code to initialize the array being passed in so that it would be large enough to hold all the expected output. Now instead of overwritting areas of memory it shouldn't, I get a pop up message that says:

fatal internal error

memorymanager.cpp line 406

8.5.1.f5 

So it appears because I don't have the ability to recompile the DLL file it runs off of the 8.5 runtime instead of the more recent one. Is there any thing I can do about this?

[imagetable]

So I've been trying to figure out a way around this on my own while waiting on a response. From what I'm reading, a dll created in one version of the labview runtime can't be used by a different labview runtime. Am I correct in this? I feel like I must be mistaken since that's basically the opposite of how a dll should work. If nothing else works I have access to the original code for the DLL but it requires the control and simulation toolkit. I would like to avoid having to recompile the DLL since it was put in to a DLL to avoid the need for the toolkit to begin with. 

[Esteban_B]

Hi rjpierce,

If I understand correctly, you had your VI’s in LabVIEW 8.5 and you builded your DLL from those Vis, then you used to call that dll from a different program in LabVIEW.

Now you are trying to do the same with a program in LabVIEW 2012 but you get the crash when changing the way you call the DLL.

It seems that the problem is related to how the memory is managed by the dll, more than if it is loaded with LabVIEW 8.5 or 2012. Could you provide us more information?

Regards,

[Dennis_Knutson]

---

@rjpierce wrote:

So I've been trying to figure out a way around this on my own while waiting on a response. From what I'm reading, a dll created in one version of the labview runtime can't be used by a different labview runtime. Am I correct in this? I feel like I must be mistaken since that's basically the opposite of how a dll should work. If nothing else works I have access to the original code for the DLL but it requires the control and simulation toolkit. I would like to avoid having to recompile the DLL since it was put in to a DLL to avoid the need for the toolkit to begin with. 

---

No, just like an exe requires the same version of the runtime that was used to create it, a LabVIEW dll requires it's own specific runtime. You can have multiple runtimes installed. Did you try installing the 8.6 runtime?

[nathand]

I don't have your versions of LabVIEW available, but I just did a quick test and could call a DLL built in LabVIEW 2009 from a VI in LabVIEW 2012 with no errors. Make sure your Call Library Function Nodes are configured for "Run in any thread." Also, try setting the Error Checking level to maximum and see if you get a more helpful error message.

[rolfk]

---

@rjpierce wrote:

So I've been trying to figure out a way around this on my own while waiting on a response. From what I'm reading, a dll created in one version of the labview runtime can't be used by a different labview runtime. Am I correct in this? I feel like I must be mistaken since that's basically the opposite of how a dll should work. If nothing else works I have access to the original code for the DLL but it requires the control and simulation toolkit. I would like to avoid having to recompile the DLL since it was put in to a DLL to avoid the need for the toolkit to begin with. 

---

Your problem most likely is that you try to pass native datatypes to the DLL function? That only can work if the caller and callee use the same LabVIEW runtime engine. Otherwise the memory block created in the memory manager of the caller will be accessed by the memory manager in the callee and bad things happen. Instead you should define the DLL function to use standard C datatypes (Pointer to C array) and also make sure to allocate the according buffer in the caller for all output array parameters.

An even more elegant way would be to completely abandon the DLL approach and call the according functions directly in LabVIEW. Then you won't have the problems about mismatched runtime engines. Passing C array pointers to a DLL is less performant than passing native datatypes, but if you use native datatypes you have to make sure the DLL is compiled in the same LabVIEW version as the one you call it from.

[imagetable]

Yeah That's essentially what I figured out, you've just worded it much better than I have. This is my first time working with labview and it was supposed to be a simple project. I was just updating some report generating vi's we were using completely independant of the part of the program that even uses the dll call. I'm currently trying to use the function directly in my labview project using an evaluation copy of the control and simulation toolkit. I was just hoping to avoid the expense of purchasing a copy of it. The only thing we currently do with the simulation loop is use it as an ODE solver. I noticed the full version of labview has an ODE solver vi. Does anyone know what the difference between the ODE solver vi in labview and the ODE solver in the control and simulation toolkit? I don't know if I should open up a seperate thread to ask that or not.