Showing results for 
Search instead for 
Did you mean: 

Calling a C++ DLL on RT PXI

Go to solution



We have an ticket # running with NI support regarding this, but I figured I would try the forums as well.


We are trying to package a C++ dll of ours so that it can be use on a PXI Real-Time system.


However, we are experiencing problem when trying to call it from a VI in LabVIEW running on the target device.


When trying running everything on the local pc, it works as expected.

The numeric on the VI display `43' which is the test return value we expect from our DLL.


However, when running on the RT target, we get the following:



We have build the C++ DLL strictly following the instruction here (using MSVC 2010), and validated it using the utility from that same page.


I have included both the project of our DLL as well as the VI in which we are trying to use it.


What could be wrong ?



Thank you very much for any help,


Kind regards,




0 Kudos
Message 1 of 10

We had some issues with a RT (cRIO) dll, where LV would deploy the Windows DLL to RT, in stead of the RT DLL, despite the fact that the cRIO DLL was used in a conditional disabled case. It seemed like the dll dependency was determined before switching the conditional disabled case to RT...


Not sure if it's relevant. I'd make absolutely sure, at least during testing, that the correct dll is called. For instance by specifying a path on the diagram, in stead of hard coding a path in the CLFN.

0 Kudos
Message 2 of 10

Have you made sure the Visual Studio 2010 C Runtime support is installed onto the target?

Also you claim you are using Visual Studio 2010 but the PlatformToolset property in your vcproj file says v90, which corresponds to VS2008. VS2010 would be v100.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
0 Kudos
Message 3 of 10

Thank you so much for Rolf for your reply!


Well, I intended using the VC2k8 runtime, the v90 dll being what I found on the target system.




I don't think you can use VS2010 tk since there is no msvc{r,p}100 DLL on the machine

I did have to install VS2008 in order to simply compile for that toolset in VS2010.


I can try again ...

0 Kudos
Message 4 of 10

Ok: I finally understand Rolf's post,


Yes: I will install the MSVC2k10 RT on the target and retry with that toolset.


I also just came across this one suggestion,  thank you so much as well ! 🙂

I will try making sense of it and check it against my case as I suspect it has to do with the problem,


Although, in our case, I think we actually deploy a Windows DLL: It's just that it's built in a specific way that makes it compatible.

I *think* that part is different because we have Phar Laps OS and cRIO probably has something else.



Thank you once more,

Kind regards,

0 Kudos
Message 5 of 10

You got it mostly right. The DLL is not build in a special way really. There are two conditions to let a DLL run on a Pharlap ETS system:


- It can not use Windows APIs that are not implemented on Pharlap. That includes anything that has to do with COM/Active X (and by extension of course .Net), Unicode string handling, APIs that work on ACLs and other security features such as login sessions etc, and just about any other Windows API introduced  since Windows NT 4.0. That's right, anything after ~Windows 1996 is basically not supported.


- It must be compiled with a C compiler for which NI provides a C Runtime Installer. For Visual C 6.0 this is a given since it dit not use any special C Runtime but the runtime was simply part of the msvcrt.dll that was part of the Windows kernel. Pharlap ETS supports that. After that Microsoft decided to release a new msvcrtxx.dll with each new Microsoft C version. There are various reasons why Pharlap could not support them like that so those compilers were basically out of question to create code for Pharlap ETS which was a problem for NI. They then went and licensed the C Runtime code from Microsoft to create a msvcrtxx.dll for their realtime targets. You can't install the standard Microsoft C Runtime on Pharlap since those DLLs like to make use of new and shiny Windows APIs that don't exist on other systems. It often would not have been necessary to do that but why should Microsoft bother, they only had to support their own Windows versions and that was hard enough and there was of course no incentive to also support competitors too.


NI did not port the C runtime for every Visual C version but only the ones they used themselves for development of LabVIEW RT and its drivers.


So you can use the compilers I described here. Anything else is setting yourself up for headaches.


As to Pharlap on cRIO, no that is basically exactly the same as on the PXI controllers. Sure there might be differences inside the kernel to adapt to the actual hardware that is present in the system and a PXI system very likely uses different chipsets than a cRIO but that is not something you should yourself concern about. Your work is on the user level of the Pharlap OS and as far as that goes they should be identical. The only difference you might see here is if you use different LabVIEW versions. Each Pharlap OS installation is specific to a certain LabVIEW version and there are subtle differences even in the number of Windows APIs they support as IntervalZero did maintain the Pharlap OS until around 2008 with regular bug fixes that sometimes included support for a new Windows API functon because of popular customer demand. After that NI has also made small improvements to the underlaying Pharlap OS as they found bugs in it so the Pharlap OS in a LabVIEW 2008 installation is likely slightly different than the Pharlap OS in a LabVIEW 2018 installation but for all practical purposes that shouldn't really matter for normal use.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
0 Kudos
Message 6 of 10

Thank you so much for the additional details, Rolf.


So I:


  1. installed MSVS 2012 runtime on the PXI
  2. changed the project's platform toolset to v100
  3. changed the character set (in `code generation') to `Multi-Byte Character Set' (I had it set to Unicode.)

But still no cigar (and same results.)


There are so many settings that I feel could be set wrong that I don't see another way than having a working, even minimalist example project and work my way from there by adding my code to it. Smiley Indifferent

0 Kudos
Message 7 of 10

Hmm. I hope you were just mistyping but you talk about MSVS 2012 runtime being installed in step one. There is no MSVS2012 C runtime from NI to install AFAIK and the Microsoft provided won’t work.


I have also no idea if changing the toolset version is enough in order to get fully working  DLLs. It’s definitely better to use the MSVS version you want to target rather than changing the toolset version.


Unicode while potentially a problem later on shouldn’t really matter for the moment as long as you don’t have any strings in your sourcecode.and try to call APIs that work with those strings.


And I can’t help you with a MSVS 2010 example. my workflow for RT compilation still uses VS6 to create DLLs. Saves me another bothering about having the correct runtime installed on the target.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
0 Kudos
Message 8 of 10
Accepted by topic author lechapelaing

Yes, I meant VS runtime 2010,


The problem seems to have been over the path specified for the DLL in the C Library Functon Call node.  😐



After that, we seem to have had an issue where, with the name we meant to specify for the DLL, we can't seem to be able to update it. (I.e., subsequent code changes are not reflected on the behavior of the dll when we retry our VI.)

Yet if we use another name for it, then the DLL is correctly updated on the target at each code compile.


After restarting it seems alright.


Crazy NI

0 Kudos
Message 9 of 10

@lechapelaing wrote:


Crazy NI

Not really. Just because something quacks like a duck and waggles like a duck it does not mean that it is a duck. Some about Pharlap ETS doing as if it was Windows.

It's different. Once your RT application has started it loads up and loads any dependencies and stays in memory until you restart the system. You can replace the DLL on the drive as often as you want but in order to get it to replace the copy in memory you need to restart the controller.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
0 Kudos
Message 10 of 10