From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
using dll in labview realtime
@antoniolc wrote:
Hi to all,
I would like to know the best way how to open a file DLL in labview.
I created this dll with matlab, real time-workshop, nidll.tlcafter that I have to use these dll in a real time VI, for using that into a cRIO,does it exist a tutorial in order to explain the procedure?
thank you
Haven't use the realtime workshop at all so far, but one problem with many cRIO targets is that they do not use Windows style DLLs but VxWorks .out files. That is a completely different binary format (and OS) and unless your realtime workshop knows exactly how to create VxWorks compatible out shared libraries, you will not be able to use your shared library on those targets.
Here is a list of the various RT devices that NI sells or has sold, and the OS they are using. Pharlap ETS means that it can run Windows style DLLs, if they don't make use of unsupported Windows API functions and are not compiled with the greatest and latest Visual Studio version. But I have found that the only safe way to make it compatible to most Pharlap ETS versions is to use Visual Studio 6 which is really ancient for a compiler. Newer Visual Studio versions tend to pull in Windows API calls through their runtime libraries that are incompatible with Pharlap ETS, even for the most simple C code.
No it is not! As it uses Cygwin to port the Gnu Unix tools so they can run under Windows. Cygwin is a great tool but had always a hard time to run on newer Windows versions than what was released at the time a particular Cygwin version was created.
The VxWorks versions that NI used for their realtime controllers is very old. There is no hope that someone would go through the trouble of trying to backport the Cygwin bugfixes since that time to this Gnu toolchain, nor has VxWorks any interest in creating a new Gnu toolchain based on modern Cygwin and Gnu tools for older VxWorks versions.
NI has moved since away from using VxWorks. In fact the only reason they went with VxWorks, was because Pharlap ETS was not compatible with the PPC CPU and at that time the choice in powerful x86 compatible CPUs for embedded applications was VERY small or actually non-existent.
As you can see Open source observes similar rules as commercial software. Don't spend much time in trying to make old stuff work on new versions. In fact commercial software usually makes a lot more effort to be portable across different versions. In Open Source the general tenor is, I want feature X, that requires GCC Y, which will only work with glibc x.z.v. Don't spend time in trying to make any of these work with older versions too, or update older applications to work with newer OSes etc. If you want Windows 7 or 8 you have to have Cygwin 1.7.something and that will usually require GCC 4.something and a myriad of other dependencies. The gnu toolchain for VxWorks 6.3 which is used on the NI controllers since LabVIEW 8.5 uses GCC 3.4.4.
Considering that LabVIEW 8.5 was released in 2008 and the VxWorks tools to create the OS for the controllers obviously even quite some time before that, but Windows 7 RTM was only in July 2009, there is not much you can complain about the fact that those tools do not run on Windows 7 or 8.
