Compile Real Time dll in MSVS 2008

I'm trying to compile a dll which is supposed to run as the startup dll on a LabVIEW RT target. For starts, I took code that works fine in LabWindows/CVI (i.e. it compiles, and the resulting dll runs on the RT target). I created a new project in MSVS using the LabWindows/CVI Project template, as dll. I copied the code from the LabWindows project, and all compiles well. However, when I copy the resulting dll onto the RT target and set it as startup dll, I get an error message ('cvirte.dll not found').
I assume this is because I don't iclude the RT runtime dlls correctly; how would I achieve this?
Thanks,
Jonas
Jonas Zimmermann, PhD
Neuroscience Department
Brown University

As a matter of fact, I have. However, that is not my problem. My problem is that I'd like to compile a library for use on a LV/LW Real-Time target. If I link against cvirte.dll (and copy it on the target), I run into other dependency issues, as this uses functions not supported by the RT system.
I got (what I think is) a step further, making sure my code is not linked against default libs (/NODEFAULTLIB flag in MSVC++). However, I still get unresolved external symbols (__fltused, __ftol, __RTC_CheckEsp, __RTC_Shutdown, _RTC_InitBase, ___security_cookie, @__security_check_cookie@4, and @_RTC_CheckStackVars@8).
Is there a sample MSVC++ project for a 'Hello World' dll that compiles for and runs on a real-time target?
Jonas
Jonas Zimmermann, PhD
Neuroscience Department
Brown University

Similar Messages

CRIO: error while compiling real-time application

My code can be run when the cRIO is connected to PC with Ethernet cable.
But when I want to compile (build) my code, I get the following massage.
Also the picture of the massage is shown below.
Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:
Error 6 occurred at Copy in AB_Targetfile.lvclassostBuild.vi->AB_Application.lvclassostBuild.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller
Possible reason(s):
LabVIEW: Generic file I/O error.
E:\2013_05_23a_research\2013_05_27a_Richard's\exercise\2013_07_07_exampleFinder_1DMAFIFO\examples\CompactRIO\Module Specific\NI 9234\builds\NI 9234 Getting Started\NI-cRIO9024-UConn\My Real-Time Application\c
Solved!
Go to Solution.

Hi Cashany,
What version of LabVIEW Real-Time are you working with? What cRIO are you deploying to? What version of the NI-RIO Drivers are you using?
Behind your error dialog you have a Load Save Warnings dialog. What is the full expected path that LabVIEW is expecting to find this VI at? Have you tried correcting this conflict by moving the file to the expected path or changing your project to expect it from the new path?
Also I notice that the paths that are listed are rather long. Is it possible that your problem is related to this KnowledgeBase, Error 6 Occurs at Create Folder When I Build my Real-Time Executable?
Miles G.
National Instruments
Applications Engineer

How do I generate a compiled app with a user interface running real-time?

Hi everyone,
I've developed a simple application that uses a PXI chassis to run. It toggles some discretes and does some simple things, but it doesn't really have any "real-time" requirements. We're just using the PXI chassis because we have it and we need the discrete I/O.
My question is this - how can I convert this application to a compiled real-time app and yet maintain the front panel on the local PC. LabView appears to simply do this for me. I am connected to the real-time target via ethernet. When I compiled the program, it puts it in the target's startup directory, but how do I run the front panel from the local PC?
Thanks,
Jason

Hi Jason,
Below are some links that should get you started with deploying an application onto your real-time target and then controlling it from a PC that does not have the LabVIEW Development environment:
http://digital.ni.com/public.nsf/websearch/C90410C685CFF89786256C24005AC027?OpenDocument
Launching code on the RT target:
http://zone.ni.com/devzone/conceptd.nsf/webmain/7D7CFAFF379531B086256AC70058812B?opendocument&node=1...
Deploying and launching a real-time app:
http://zone.ni.com/devzone/conceptd.nsf/webmain/9ac4955881bd7b4d86256d0b0061dd1c
Application Builder and RT PXI controller:
http://zone.ni.com/devzone/conceptd.nsf/webmain/81b6674f3556599b862568cf005d26c6
RT good programming practices (use RT communication wizard for easy implementation):
http://zone.ni.com/devzone/devzoneweb.nsf/Opendoc?openagent&E4C4DCD9C00295A186256B5100665BF5
RT Communication Wizard:
http://zone.ni.com/devzone/conceptd.nsf/webmain/a6f17ee4adcab99686256d5e0053e210
I would suggest going through these tutorials and documents, they should provide you with what you need to get started. Please don't hesitate to ask any questions that you have a long the way.
Bryan Snarr
Field Engineer
Northern California
National Instruments

Real-Time Application doesn't run; source code works fine

The short version is I'm programming a cRIO and apparently the RT code isn't running after being deployed and I can't figure out why. This is further complicated that I'm doing all this remotely and I don't have direct access to the unit since I'm 500 miles away. I'm working through a couple of other guys who know some LabVIEW, but neither works at the site so they have to explicitely travel out there every time I have a bright idea.
I was out there a few weeks ago. During this time I created a simple cRIO code, since I'm new to cRIO, that allowed the user to move a control and change a graph. It worked fine, but I should note it did not have an FPGA component. After that I worked on the real code, which reads some sensors, displays the results on a UI and logs the results. This did have FPGA. I used it in the LabVIEW environment and it worked fine, but I ran out of time before I could complete a release version and deploy the RT as a compiled application. I sent them the release version later, my contact deployed it but got network stream errors when running the UI.
After hours of looking at network problems and sending over debug versions, I tried creating a log on the RT level so I could see what was going on. The log doesn't even open, even if it's the first command in the code. I pored through the forums and found http://forums.ni.com/t5/LabVIEW/cRIO-Troubleshooting-creation-and-deployment-of-startup/td-p/1956475... which took me in a new direction.
I had my contact use the RT debug console and when he pulls up the RT front panel, it shows a broken run arrow. He clicks it and nothing happens -- no running, no bug list. If he pulls up the bug list manually, it's empty. Again the RT works fine if you run it through LabVIEW and not as a compiled real-time application. He also noticed that the Open FPGA VI was grayed out on the block diagram. No other icons are.
So the problem appears to be that the compiled RT application is getting some kind of error but not telling me what it is, and it seems to be related to opening the FPGA. I've recompiled the FPGA and RT. I've had him recompile the RT himself, but not the FPGA because it would take hours. He's downloading everything correctly to the cRIO. The RT is set to run automatically. He's rebooting the cRIO every time he deploys the RT. They have LabVIEW on a computer there but it doesn't have the right drivers to run the code from the LV environment. I'm resisting having them install the dirvers because downloading big files is complicated there due to security restrictions and a lousy network connection at a remote site. Besides that doesn't solve the problem of the RT executable not running the same as the source code, which according to the thread above appears to be a thing.
The latest thing I'm trying is that I sent him instructions for how to build a source distribution from the project I sent and try deploying that to the cRIO. Even if that works I'm not sure that's an acceptable solution because I assume running the VI rather than the EXE is slower, and they need speed on this project.
I simply have no idea where to go from here. I probably need to get direct acess to the cRIO and I might be able to convince them to ship it to me so I can figure this out, but I'm not sure where I'd even start other than the standard voodoo debugging of "try stuff at random until something works". I'm open to suggestions if anyone has managed to solve this before.
Code snippet of the first part of the project is attached, though I'm not sure how much good it will do. I'm really stumped and the client is getting frustrated with how much of the budget is going to fix this.
Solved!
Go to Solution.
Attachments:
RTMainSnippet.png ‏623 KB

Have you checked the cRIO error log? Usually I'd access it through the LabVIEW project (right-click on the target, don't remember the exact menu options and I don't have the RT toolkit installed on this machine to check), but it must be stored somewhere on the cRIO as well, although I don't know if it's in a human-readable format.
Which cRIO are you using? What exactly do you mean by "debug console"? (This may be related to the cRIO - the newer ones have video out, although I don't know if that's what you're referring to.) With a broken run arrow, you won't get an error list unless you're running in the development environment.
Have you confirmed that the software installed on the cRIO matches the version you're using for development, including patch level? Get someone to connect to the cRIO with Measurement and Automation Explorer, and get a list of the software installed on the cRIO.
Sounds like the ability to connect with a remote debugger would be helpful here, if you can get the right drivers installed on the machine with LabVIEW that's connected to the cRIO. Make sure all driver versions match what you're using. Any chance you could then do a remote desktop connection from your work site to the remote LabVIEW machine?

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

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.
Solved!
Go to Solution.
Attachments:
DLL_Call_Screenshot.png ‏61 KB
DLL_Call_Screenshot.png ‏61 KB

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.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

More than 1 ms MOMO digital IO 7358 in LabView Real-Time 8.5, error downloading EPOS dll file into RT

Hi all,
I have several problems here, I tried to google but still I could not solve the problem.
Here are my questions:
1. I tried to download an example program of EPOS which require to download a DLL file into the RT, but it failed, here's the error (I attached the picture) 01/02/2008 13:29:50.511 [error] LabVIEW:
Failed to load shared library EposCmd.dll:_VCS_GetProtocolStackName@16:C on RT target device.
From the NI.com forum,
I found a similar problem and it said by installing Network Variable Engine and Variable Client Support into the LV-RT, and I did, but still failed. Any one can help me about this?
2. I posted a question also in lavag, I think this section is more appropriate. "I
am trying to use the digital IO of the motion controller of 7358, but then I realized the delay is more that 1 ms (I checked using the oscilloscope), I attached the code (MOMO = Must On Must Off). Is this real, I mean the hardware delay between on-off is as big as this? Anyone knows the solution for this?"
Note: I am using LV-RT 8.5, PXI-7358 Motion Controller, EPOS 70/10
Thank you for any help
Message Edited by bono02 on 01-02-2008 05:47 AM
Attachments:
maxon-rt3.JPG ‏120 KB
momo1.JPG ‏55 KB

Hello bono,
1. From what I have seen, this error is usually caused by one of two things. The first is the Shared Variable software components not being installed, which is covered in this Knowledgebase. The other is due to a corruption of the ni-rt.ini file on the Real-Time controller. You can follow the steps layed out in this Knowledgebase, which gives three possible remedies. You could also try reinstalling the software (firmware) or create a PXI Uninstall disk from Measurement & Automation Explorer by selecting Tools»Remote Systems»RT PXI Disk Utilities»Create PXI Uninstall Disk. Boot the PXI Controller from the PXI Uninstall Disk, which will erase the ni-rt.ini and ph_exec.exe on the target. However, you will need to reconfigure the controller after doing this.
2. Due to the nature of the digital I/O on motion controllers, it is not surprising that you are seeing around a 1ms delay. It deals with the fact that it must update the motion controller with the new value on each control loop. This Knowledgebase gives a little more clarification regarding the 7350 specs.
Carlton
CLD

Cannot run Simulink dll at the same time as running real-time target VI

Hello
What I am trying to do is run a model dll created in Simulink to control some servo's through a CompactRio 9014.
At the moment I have managed to create three VIs
1) In the FPGA target that performs the PWM on a desired channel
2) That takes the value of a network variable which contains the position required and feeds that to the 1st VI
3) A VI that runs on the host computer that modifies the value of the network variable to change the position
I can get these three VIs working and the servo controlled, but when I try to update the value of the network variable using the simulation, by deploying the simulation to the RT target and running it, it says
'Access denied: This target is already in use by another project or host computer.'
I assume as this is because the project is already connected to the cRio, so I disconnect and am able to deploy the model files.
However when I try to run one of the VIs in the RT Targer along with the simulation I get the error:
'This VI is downloaded on the target but is not present in the project you are attempting to deploy. All VIs on the target will be closed unless you choose to add the missing VI to the project.'
With a large number of missing VIs...
Would I be doing this wrong, i.e. is there a much simplier way to control the FPGA inputs using the simulation, or is there something I could have missed?
Thanks
Geoff
Solved!
Go to Solution.

Hi Geoff,
It seems that you are on the right track except for some concepts that I
want to review:
A CompactRIO or cRIO has 3 different components:
1)
Real-Time controller (in your case a 9014)
2)
FPGA backplane (this could be a 9102, or a 9103, 910x,
etc)
3)
I/O modules (like a 9401, 9263, etc)
When you write an application for cRIO you usually have three different VIs:
1)
Host VI – This VI is used as a user interface and runs in
Windows (under “My Computer” in the LabVIEW project) This VI is optional because
you might want to run the cRIO headless.
2)
RT VI – This is the VI that runs in the cRIO controller
(in your case the 9014). This VI lives
under the cRIO target in your LabVIEW project.
3)
FPGA VI – This is the VI that runs in the cRIO
backplane like a 9102. This lives under
the cRIO >> FPGA target in the LabVIEW project.
The ONE application that I was talking about in my last post is for the RT
VI. There can only be one RT VI that
gets deployed. If you want to run
multiple VIs in the cRIO RT, then you need to run those VIs as subVIs of one
top level VI.
LabVIEW Simulation Interface Toolkit (SIT) has a tool called the SIT
Connection Manager that creates two of these three VIs for you (the RT and the
Host VIs).
Please refer to the following link about the SIT Help. Go to the How To section. It is organized in a kind of step by step
tutorial.
http://zone.ni.com/reference/en-XX/help/371504D-01/
In your case it is going to be a bit more difficult because of two things:
One, you are using a VxWorks target.
Two, you want to use your own FPGA VI.
Let’s address each one of them:
1)
VxWorks target- To use the SIT Connection Manager you
need to use a DLL not an OUT file, even though you need the OUT file for the cRIO VxWorks target. The reason is
that this tool needs to read the compiled model to know what the
parameters, signals, inports and outports of your model are. Because the tool runs in Windows you cannot
open an OUT file (meant for a different OS) so you need to give it a DLL.
For this reason you will need to compile your model file into an OUT
file and a DLL. Once you give a DLL to
the Connection Manager and you select your cRIO as the execution target, keep
doing the rest of the steps as the help says.
LabVIEW will identify that you are using a VxWorks target and will
download the OUT file to the cRIO.
2)
Custom FPGA VI – LabVIEW SIT has some FPGA bitfiles
(compiled FPGA VIs) that it can use.
When you open the SIT connection manager and go to the Hardware IO
mapping section it asks you to select the bitfile. If you want, you can select one of the
shipping bitfiles but iIf you
want to use your own, then you will need to do some changes to your FPGA VI , recompile it and
save the bitfile in a specific location with a specific name.
Please refer to the following link for
instructions on how to create your custom FPGA VI:
http://zone.ni.com/reference/en-XX/help/371504D-01/lvsithowto/sit_h_custfpga/
What I would suggest is that you start with a very simple example and using
one of the shipping bitfiles. Look into
the following path for a very simple Sine wave generation example:
C:\Program Files\National Instruments\LabVIEW 8.6\examples\Simulation
Interface\Sine Wave
Because you are running a VxWorks target you will need to recompile this
example model sinewave.mdl to an OUT file.
To get a better understanding of what SIT does you might
want to check some quick videos. Go to
http://sine.ni.com/nips/cds/view/p/lang/en/nid/11763 and under the
resources tab there are two videos called Demo - <something>...
Hope this helps and let me know if you have more questions.
Ricardo
National InstrumentsSystems Engineering

How to get last Build date of a dll in the real time target

Info On My Project
I am working on LabWindows CVI 12.0 for development . This project is a real time application for hardware, which is having Phar Lap ETS as RTOS...
I am facing some problems while checking Build date of my Application file( .dll)
I have tried to use GetFileDate API. But it is not supporting for realtime Target..
So i have tried __DATE__ macro.. That also having some problems..
How to get last Build date of a dll from the real time target ??
Please Help to solve this....
Thanks
Vaishakh A K

Please reply if any one have suggestion...

Why can't Real Time Workshop create a model DLL?

When trying to create a model DLL in Real-time Workshop I get the flowing error:
Error using ==> RTW.makertw.make_rtw
Error using ==> tlc_c
Error using ==> tlc_c>InvokeTLC
Error File: C:\SimulationInterfaceToolkit\ModelInterface\basic.tlc Line: 388 Column: 45
Attempt to call a non-function value: SLibGetBlockPath
Installed software : LabView 7.1, Matlab release 14 s1. Real-time Workshop 6.1, and Visual Studio Pro 6.0

This is a new install and I�m only trying to get things setup properly. The MDL file is a simple MDL created to test out SIT. It was taken from the example in the SIT User Guide. I have installed the following software:
Operating System: Microsoft Windows XP Version 5.1 (Build 2600: Service Pack 2)
MATLAB Version 7.0.1.24704 (R14) Service Pack 1
MATLAB Version 7.0.1 (R14SP1)
Simulink Version 6.1 (R14SP1)
Real-Time Workshop Version 6.1 (R14SP1)
Microsoft Visual Studio Pro 6.0
LabView 7.1
LabView Real Time 7.1
Simulation Interface Toolkit 2.0.3
I will include the MDL file. Is there something in the setup I might have missed?
Attachments:
SineWave.mdl ‏17 KB
SineWave.vi ‏265 KB

How to programmatically set the real-time CVI startup DLL?

Dear NI Support Engineer:
I'm part of a team of software engineers working on a real-time aerospace app at Honeywell (Coon Rapids, MN campus). We're using LabWindows/CVI 9.0 and three LabView 8.6 real-time modules.
Up until now, we've been using the CVI debugger to launch our real-time apps or just copying the app DLL to C:\ni-rt\cvi on the real-time box and setting it as the default startup DLL.
What we need to do now is create our own directory structure at the root of C: on the real-time box (which, by the way, is using the Reliant file system).
In fact, we have created directory ug7500 at the root of C: on the realtime box, and two subdirectories (one for data and one for results) directly under directory ug7500. We'd like to place all of our app DLLs in the ug7500 directory and have the ability to change the default startup DLL programmatically.
We've been using your LabWindows/CVI Real-time File Copy Utility to set the startup DLL whenever we're not using the debugger. That was just fine for the first stage of our development.
At this stage, however, we need be able to set the startup DLL programmatically. We have not been able to find out how to do this from reading the real-time module documentation.
Can you either point us at some documentation on programmatically setting the default startup DLL, or e-mail us the instructions, or give us a phone call and explain what steps we must take.
Thank you very much.
Vic
763-957-4168

Hello All,
For the reference of anyone else trying to do this, you can modify the INI file to change the startup DLL. Using the INI instrument that ships with CVI (C:\Program Files\National Instruments\CVI90\toolslib\toolbox), you can find the StartupDLLs tag and replace the last value with your startup DLL, such as:
#include "inifile.h"
#include <cvirte.h>
static int status;
static IniText myINIFile;
int main (int argc, char *argv[])
if (InitCVIRTE (0, argv, 0) == 0)
return -1; /* out of memory */
myINIFile = Ini_New (0);
status = Ini_ReadFromFile (myINIFile, "c:\\ni-rt.ini");
status = Ini_PutRawString (myINIFile, "LVRT", "StartupDLLs", "c:\\NI-RT\\system\\cvi_lvrt.dll;c:\\ni-rt\\system\\nidevldp.dll;nisysapirpc.dll;niorbp.dll;c:\\ni-rt\\system\\mxsemb.dll;c:\\ni-rt\\system\\nipxism.dll;c:\\NI-RT\\cvi\\myStartup.dll;");
status = Ini_WriteToFile (myINIFile, "c:\\ni-rt.ini");
return 0;
Right now, there are some caveates with using CVI 9.0 to manipulate an INI file to be used on an RT target. The INI functions currently add line breaks automatically for large tag values and adds quotes around the values. For many INI files this is ok (such as TestStand INI files), but it will not work on an RT target. To remove these features, modify the following lines of the inifile.c file located in the same directory as the INI instrument:
1. On line 38, change the default value of INI_NUM_CHARS_PER_LINE from 80 to a large number such as 8000.
2. Comment out line 953 (newEntry->addMarkerQuotes = addMarkerQuotes;
Now you should be able to programmatically change the INI file of your target machine and, therefore, change the startup DLLs.

VI on LabVIEW real-time is loading and running a DLL which has been deleted from the machine

OK, this is a weird one (at least, to me :-) )
I have a small real-time demo application VI that I am writing, using some new VIs I just created. My new VIs are wrapper functions for a DLL, using Call Library Function Nodes.
In the process of debugging, I decided to delete the DLL and run without it, to confirm that I am actually loading and using the DLL (since it seemed to have stopped doing something it had successfully done just a little while earlier).
The VIs that use that DLL still run, and at least some of them actually do what they are supposed to do. But the DLL does not exist on the real time machine! Not only did I delete it, reboot the machine, and check that it was gone, but through my ftp program I searched the whole hard drive for that DLL and did not find it (the search succeeded in finding a different DLL which did exist on the system, so the search-via-ftp is working).
How could this happen? What am I missing? Could this somehow be the result of a corrupted VI or is there some more logical explanation for the phenomenon?
Thank you.
Batya

Nathan is right at least for the Phrlap ETS based RT systems. For VxWorks you have to (or maybe used to have) to download the shared library to the controller before you could deploy an executable that makes use of them. For Pharlap ETS systems if you deploy a VI library dynamically to a machine it will download everything including shared libraries to the the RT target memory and run it from there. Only if you create an executabel and "install" it to the target and run it from there will it use whatever VIs are in the executable and also use the shared libraries that have been installed onto that system (at least for Pharlap ETS RT targets. As mentioned before for VxWorks targets, the deploy process even for executable installation did for some reasons not take care about moving the according *.out library to the target together with the rtexe).
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

When I use Call Library Function Node in real time, is the DLL loaded once for all or load every time it is called?

When I use Call Library Function Node in real time, is the DLL loaded once for all or load every time when it is called?
I have a time critical real time application, in which I use a piece of DLL function developed by C++. It is OK? Could any senior developer assure me?
Thank you in advance.
Solved!
Go to Solution.

qing_shan61 wrote:
When I use Call Library Function Node in real time, is the DLL loaded once for all or load every time when it is called?
Once
qing_shan61 wrote:
I have a time critical real time application, in which I use a piece of DLL function developed by C++. It is OK?
OK
Be sure that all DLL calls are thread safe (do not perform calls in UI thread).
Also for real-time application you need real-time OS.
Andrey.

Linking C++ with Real-Time

I have created a dll using Microsoft VC++ 9.0 (2008) to be linked in real-time. Unfortunately when I try to check this dll using LabviewRT DLL checker I am getting a message that "DLL is bad. Check the imports." and the bad imports are from msvcr90.dll.....My dll is working perfectly in the windows environment but the DLLchecker says that it is bad. I have tried using the example codes from the tutorials for creating such "dlls using Microsoft VC++ 5.0 / 6.0", but those examples seem to have the same problems as well with the latest VC++ version. Unfortunately I don't have these old version VC++ compilers. Is there any other way that I can create a c++ dll and link it to real-time?
Thansk for your help in this regard.

National Instruments currently does not support Visual C++ 9.0. However, you still might be able to use this compiler by taking a few extra steps. You will need to include the runtime (mscvr90.dll) and all necessary pieces statically in the DLL as support files passed to the RT target. Please be aware that this may result in a very large DLL. Let me know if you have anymore questions, thanks!

How to create a c++ shared library (.so) for linux real time (for myRio) with Eclipse to use in LabView?

I tried already these Tutorials and Advices but I didn't find a solution:
- http://www.ni.com/tutorial/14625/en/
- http://www.ni.com/tutorial/14690/en/
- http://forums.ni.com/t5/LabVIEW/Shared-Library-on-myrio-Linux-Real-time-system/m-p/2842540/
- http://forums.ni.com/t5/LabVIEW/How-to-create-shared-library-for-linux-real-time-target-in/m-p/28218...
- and some more
I want use c++ codes on linux real time. For testing reasons I want to have a function that adds 2 values and gives the result.
I've done these steps:
1. writing a c++ file in Eclipse (see screensot 2)
2. building a shared library (.so) from my c++ project in Eclipse (with Cross GCC)
3. putting this file on myRio (path: /usr/local/lib/)
4. creating a VI that calls this library from Labview with a "Call Library Function Node" (see screenshot3)
5. Setting the properties for the "Call Library Function Node" (see screenshots 4-7)
After I run this VI i get this error message: LabVIEW: (Hex 0x627) The function name for the ... node cannot be found in the library. To correct this error, right-click the Call Library Function Node and select Configure from the shortcut menu. Then choose the correct function name. (see screenshot1)
I've tried a lot things to solve this problem but I couldn't find a solution. Would be very happy if anyone can help me. I guess that I have to edit my c++ code to export my function (symbol). But I have no idea how to make it. I also tried it with a dll file in the same folder but it didn't help.
Perhaps someone can send an example which works on myRIO.
Thanks!
screenshot1
screenshot2
screenshot3
screenshot4
screenshot5
screenshot6
screenshot7

can see it in the screenshot8 there is a function called "_Z8AddierenddPd" instead of "Addieren". I copied this name to Labview (see screenshot9) and it worked.
I'm sure that there is a way to compile the shared folder with gcc without decorations (mangling). But I don't know how. If someone has a recommendation I would be very glad!
Prepend each function declaration that you want to be available without name decoration with
extern "C" <your function declaration>
Or if you have multiple functions you want to export you can in the header file where you declare your functions simply use:
#ifdef __cplusplus
extern "C" {
#endif
<all your function declarations>
#ifdef __cplusplus
#endif
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Real Time kernel questions

I decided to compile myself a new kernel using a PKGBUILD from AUR, which contains Ingo Molnar's real time patch. I know that there are some entries int the wiki about this (Kernel Compilation with ABS, Custom Kernel Compilation with ABS, Kernel Patches and Patchsets), but they don't answer all of my doubts.
The major question is related to my graphic card's drivers. I'm a happy Radeon user using fglrx proprietary drivers. At the moment they are working fine on a vanilla kernel form [core], the problem is whether I would have to do some voodoo to make them work on a rt-kernel? Now I know what is written in wiki about installing Catalyst drivers on a custom kernel, but when on Mandriva I tried to install 8.1 on my rt-kernel, I had to do some tricks and recompile fglrx to make it work. Does anyone tried installing Catalyst drivers ver. 8.2 on a real-time kernel from AUR?
Another thing: I have a .config file from the previous rt-kernel. Would it be suitable for 2.6.24?
Finally, I recently read about grsecurity patchset. Did anyone tried it on Arch, especially on a real time kernel? Any problems?
Waiting for suggestions

broch wrote:first I hope that you understand that RT kernels on desktops are slower than preempt default or vanilla kernel?
I'm using one on my Mandriva 2008.0 and didn't notice any slowdown.
broch wrote:second: I use grsec (or RSBAC) kernels.
grsec will not work with anything messing up with memory (even Kolivas patches in past had issues with grsec). This can be fixed but then what is the point of enabling hardened kernel with disabled features?
I simply patch vanilla with grsec.
Remember that some pax options are incompatible with X (all explained when option is selected, so no way to make mistake)
finally it works well lowest overhead, best speed and easies to manage among kernel hardening patches (I do not count Apparmor, as this is rather limited tool)
If I understood you, then it's a choice between real time and more security, right?

Compile Real Time dll in MSVS 2008

Similar Messages

Maybe you are looking for