Running dll file on RT target

[rolfk]

---

@AnthonV wrote:

problem in more detail?  Is the garbled function name 'double ?DummyFunction@@YANH@Z(int32_t arg1);' a clue? Where does this garbled name come from?

---

This garbled name comes from the fact that your Visual C project treats this file as a C++ file. You use a cpp fileending? In that case Visual C automatically assumes that you want to run de C++ compiler on the source file and this compiler will garble all global symbols by default.

You can disable that in the source file by creating a function declaration somewhere before the function implementation as such:

extern "C" double DummyFunction(int32_t arg1);

You also can change in the project settings for that file that Visual C should use the standard C compiler (or C++ compiler) for a specific file despite of the file ending.

[dkfire]

My bad, sorry. I misunderstood the product page. 

[AnthonV]

Thanks guys for the assistance so far.  The latest news is that I found a copy of VisualStudio6 SP5 and an XP machine to install it on.  The DLL created with VS6 works on the RT PXI!  So please if anyone can assist me to get the compiler up to 2010 or even better 2017 to work - this would help me a lot.

I have checked and the Microsoft Visual Studio 2010 Runtime Support 1.1 is installed on the PXI.

I will next try to force 'c' functions as mentioned above in case that helps, however I am travelling to Botswana for the next 2 days so won't be able to test until Friday.

[rolfk]

Well Visual Studio 6 will work of course as it does not use use a version specific C runtime library but links directly to the Windows NT standard C runtime library msvcrt.dll. And this is part of the Pharlap ETS kernel.

All later Visual Studio versions use their own version specific C runtime library but that is so tightly coupled with core NT kernel functions that you can not simply install the according distributable on a non-Windows system, which Pharlap of course is. So NI acquired the right from Microsoft to create their own version of a C runtime library based on the source code that Microsoft ships with their Visual Studio software and to distribute it for their RT targets. However this is not just a simple recompile of the sources with different system libraries but instead requires a careful review of all functionality and replacing various system calls in the Microsoft source code with functionally equivalent Pharlap ETS system calls. A rather tedious process, and the testing afterwards is also quite time consuming. So NI naturally has not done this for every Visual Studio version but instead only for the versions they used themselves to develop their own driver libraries for the Pharlap ETS systems.

These are the versions they support:

- MSC 7.1 aka Visual Studio 2003 .Net (msvcr71.dll )

- MSC 9.0 aka Visual Studio 2008 (msvcr90.dll)

- MSC 10.0 aka Visual Studio 2010 (msvcr100.dll)

Depending on the various drivers you install on the RT target some of these will be automatically installed as they are dependencies of those drivers. You have to make sure that the runtime library for your Visual Studio version is installed, if you want to put a DLL on the RT target that you have developed yourself.

There are various aspects that can change this to some extend. For instance you can choose in the project settings to compile the runtime library into your DLL instead of the link library for the C runtime DLL. This makes your DLL bigger but makes sure that it does not depend on the version specific C runtime DLL being installed on the target. However this will usually not work for newer Visual Studio versions as the C runtime calls Windows APIs that were undocumented or even completely absent in Windows NT 4 and 2000 days, which is basically the Windows API that Pharlap ETS supports as far as it is useful and possible to implement in an RT system. Even if your DLL does basically nothing, the startup stub that Visual C will create for the DLL when it is loaded will call various C runtime APIs for initialization and those in turn will call Windows NT system calls, and Microsoft likes to make those C runtime functions call new and shiny system APIs whenever possible even if that would be technically not always required.

And since IntervalZero, which owns currently the rights on Pharlap ETS has discontinued Pharlap ETS as a product including any support for it, NI is stuck with the latest version 13.1 of Pharlap ETS, which came out around 2008. As such they still use and maintain the product for their existing RT platforms but do not incorporate new features into the kernel themselves. They obviously have also not ported any of their own drivers for Pharlap ETS to newer versions of Visual Studio after 2010 and they are not likely to do that anymore. For that reason it is highly unlikely that there will ever be a MS C runtime distribution from NI for their Pharlap targets that supports any later version after VS 2010.

[AnthonV]

Thank you Rolf for the detailed background.  I will be happy with 2010.  My next task thus is to eliminate the error code 7 from the call library vi when using the DLL built in 2010.  I will check that msvcr100.dll is present on the pharlap system.  If it is already loaded, I will need help to know what else then is causing the error 7.

[AnthonV]

I am happy to report that my simple DLL created in VS2010 now runs on Pharlap.  I created a new Win32 DLL project in VS2010, added the old cpp and h file to it, selected 'Release' and pressed F7 to build.  Keeping fingers crossed I copied the DLL to C:\ni-rt\startup\Data on my windows PC and ran it successfully.  Then I copied the DLL to the PXI to the folder ftp://10.10.10.14/ni-rt/startup/data/ , changed the target of the VI to this remote PXI and it deployed and ran without issues.

I cannot say exactly what changed that it now works, but I am glad it is working.  I didn't add the extern 'C' to remove garbled names (as mentioned above) nor did I set the linker to link the dependencies into the DLL.  Where could I check whether the new VS2010 project possibly links the dependencies into the DLL?  

Slightly off topic but still related and possibly useful to anyone trying to run a Matlab generated DLL in Pharlap: I still can't run a DLL built with Matlab's Coder SDK as the DLL still returns an error 7 when I call it in Pharlap (even though the DLL Checker passes it and it works in Windows).  So to bypass that problem I do the following:

1) Generate the c and h file using Matlab coder sdk (don't bother creating a DLL)

2) Copy the function and function declaration from the Matlab generated c and h file into my Visual Studio 2010 project.

3) Change the function declaration from the default Matlab generated:

#ifdef __cplusplus
extern "C" {
#endif
  extern void myMatlabFunction(const double u[2], float y[2]);
#ifdef __cplusplus
}
#endif

to what seems to work:

__declspec(dllexport) void myMatlabFunction(const double u[2], float y[2]);

4) Build (Press F7).

5) Remember to close LabVIEW completely (including welcome screen) when you update the DLLs as otherwise it still keeps the old DLL in memory and you would not be calling the new DLL but rather the previous version.

Thank you for the help.

[TyVo]

Hi Anthon,

After some research, it looks like there are 3rd party programs for checking dll dependencies. take a look at this stack overflow forum post asking a similar question. https://stackoverflow.com/questions/7378959/how-to-check-for-dll-dependency

Best regards,

Tyler Vonderach

Applications Engineer

National Instruments

866-275-6964

support@ni.com 

[sanju254]

hello,

when I am running my dll on LabVIEW it works fine. but when I started to run on a myrio platform with LabVIEW getting an error and not able to run the code in real time. I am generating the 32bit dll from Matlab. I want to execute my models in real time. please help me out regarding this how to run this dll files in real time. any video tutorial is helpful a lot.

Please do the needful.

[rolfk]

The myRIO platform uses an ARM CPU and runs NI Linux RT. A Windows DLL is for that system as useful as a pile of trash to get your car running!

You need to have an ELF shared library compiled with GCC together with the compatible headers for the NI Linux RT system. Does Matlab coder even support a Linux target? Even if it does you are still miles away from a working shared library for this system. I’m convinced that it is possible to do but it may require either a full computer degree in computer programming on Linux or a very persistent hacking mentality with a good fundamental knowledge about both C compilers and  Linux.

[sanju254]

ELF shared library? what exactly ELF shared library. matlab coder supports linux as a cadence incisive (32 bit linux)

but my LabView is running in windows and for windows .dll is supporting but how i have to work with myrio and am very new to Linux and how to generate supporting .so file and implementation in myrio.

if any tutorial is there is helps a lot.