File not found when trying to call a dll on LabVIEW Real Time machine

[adams156]

I have a dll called "DLLRTTEST" that I've written, and have succesfully called on my host machine.  I'm now attempting to call this dll from a vi that is located on my real time computer.  Currently I get an "Error 7 occurred at Call Library Function Node in DLLRTTEST.vi." message upon execution

In the attached screenshot I'm trying to ensure that the vi I'm running is in fact located on the real time system.  I then use a "Check if File or Folder Exists.vi" to confirm that the dll that I'm about to call does exist on the real time system as well.  However, I still receive an "error 7 file not found" error from the Call Library Function Node.

Any help is appreciated.

[nathand]

Is it possible that your DLL is trying to reference some other DLL that is not available on the real-time system? What type of real-time system are you using? If you can connect a monitor to the real-time system, do you see any helpful error messages?

Does this thread help with your problem? http://forums.ni.com/t5/LabVIEW/Loading-a-DLL-on-RT-Missing-export-DecodePointer-from-Kernel32/m-p/1...

[adams156]

Thanks for the reply.  I don't think that the problem comes from referencing a different vi because my error message is generated by my Call Library Function Node.  I just probed the error lines going into and coming out of the library call, and saw the error on the output.  My real time system is LabVIEW Real Time 12.0 running on a standard desktop pc.  I'm not seeing any error messages on the real time system's monitor, but that could be because this error was not necessarily catastrophic.  It just prevents my dll from running.

I was actually having the error that's solved in that link, but I was able to resolve it a while back.  When I run the vi from the screenshot, I'm just running it interactively rather than making a build.  Is there something I have to do to make sure the dll is include din my project?  I've never had to do that when running a dll on my host machine.

[nathand]

---

@adams156 wrote:

Thanks for the reply.  I don't think that the problem comes from referencing a different vi because my error message is generated by my Call Library Function Node.

---

Right - is the DLL trying reference another DLL? If so, you could get that error.

[adams156]

Oh, no it shouldn't be.  The function being called from the dll is just a blank function that does nothing.  I'll make sure I don't have any strange includes in there though. 

[adams156]

I just checked, and my dll has only one file called main.cpp and it has only the following code in that file:

_declspec (dllexport) void testing()

{

      return;

}

[nathand]

It may not matter what's in your DLL. Again, look at the topic to which I linked earlier. When you build the DLL, it includes parts of the C runtime, which may link to other DLLs. What build environment are you using for the DLL? Try using depends.exe to see whether your DLL depends on any others.

[rolfk]

As nathand already mentioned, depending on your C toolchain your DLL will depend on other DLLs. Usually the according msvcrtXX.dll that matches your Visual C version, if you use Visual C, other runtime DLLs if you use a different C environment. These runtime DLLs are even necessary if you do not call anything in any of your functions, since the DLL makes various initialization steps when it gets loaded and that references some C runtime functions nevertheless. Compiling and linking the DLL with static C runtime is usually also not a clean solution since the linked in C runtime will then reference Windows APIs that are not available on LabVIEW RT.

Depending on your version of LabVIEW RT you will have some mscvrtxx.dll files in your system directory but it will be an older one than from the latest Visual Studio version. If you can compile your DLL with that Visual Studio version then you should be fine, but could possibly run into new problems if you later upgrade to a newer LabVIEW RT version. Installing the C runtime distributables from newer Visual Studio versions is unfortunately also not a solution, since it references many (undocumented) Windows API functions that are not available in LabVIEW RT.

[adams156 · Accepted solution]

Thanks again for all the replies.  As I stated earlier, I had already encountered and solved the problem identified in the link provided by Nathand.  I had to downgrade to Visual Studio 2008 in order to get past that particular error, after which the real time dll checker app reported that my dll should successfully run. 

I just got off the phone with NI support though, and it turns out that I simply needed to compile my dll in release mode.  By downgrading to VS 2008 I got the right version of dll (msvcr90.dll), but since I was compiling it in debug mode, I ended up using msvcr90d.dll (d for debug) which my real time computer does not have.