LabVIEW
Questions about LabVIEW, LabWindows/CVI and RTOS
A few more additions.:
- LabWindows/CVI must be used to write and deploy C code to NI ETS
No, any C compiler that can create Windows x86 compatible DLLs is potentially usable. I know it works with Visual C 6.0 which is a very old version. Newer Visual Studio versions are more complicated as they use version specific C runtime libraries but NI has ported the Visual C runtime library from Visual Studio 2005 and 2008 to their ETS target and usually installs that too, for many of their real-time drivers. So if you can dig up on of these then you should be able to create DLLs with them that can be deployed to NI ETS systems. It is however a somewhat brittle solution unless you use VC 6.0, as you are dependent on the ported C runtime library from NI to be available for your Visual Studio version. And NI only ports the C runtime library if they have a need for it for one of their drivers.
2. Is it possible to install LinuxRT or VxWorks with LabVIEW Real-Time on a PC?
No, the VxWorks version used by NI is compiled for PPC CPU architecture. Your PC runs an on a x86 CPU. Similar about Linux RT which is compiled for the armabi (ARM CPU) architecture.
3) I have existing VxWorks libraries and drivers will it work out of the box on a NI controller(RIO) which has VxWorks on it?
Maybe! Libraries might work if compiled for the PPC architecture. Drivers most likely won't as they typically call into kernel routines that can vary between different versions of the OS and can be customized by the hardware vendor, which NI did for their platform. If you have the source you can re(cross)compile them, which has a high chance to work for libraries but will likely require some modifications to the source for drivers.
4) I have existing Fedora libraries and drivers will it work out of the box on a NI controller(RIO) which has LinuxRT on it?
Libraries maybe, if compiled for armabi. Drivers most likely not because of the same reasons as above. If you have the source you can re(cross)compile them, which has a high chance to work for libraries but will likely require some serious modifications to the source for drivers.
5) I have some multi-platform libraries which have the same prototypes. Will my VIs which interface with my libraries work on both RTOS?
Outlaw gave you a good explanation of that.
6) I have a VxWorks license can I install it to a PC and install LabVIEW Real-Time on it?
Most likely not without a lot of extra effort. First you have to create a VxWorks system that will run on your x86 hardware. Not sure if VxWorks supports x86 targets out of the box. Second you will have to find, compile and install drivers for your most essential hardware devices such as USB controllers, HD controllers, Network card, Video controller. Then you have to modify the VxWorks system to add all the undocumented extensions that NI added to their version for support of various LabVIEW RT specific features. Last but not least you have to recreate any binary component inside the LabVIEW RT system such as shared libraries to run on x86 hardware instead of the PPC hardware that they were compiled for. I would say that building your own LabVIEW like system from scratch is only marginallly more complicated. 
😎 What IDE is used to write and deploy C code to NI Controller(RIO) running VxWorks?
For VxWorks 6.x I only know of the VxWorks Workbench IDE which replaced the earlier Tornado IDE and is based on Eclipse but as far as I know is a rather expensive option. I used for myself in the past the GCC based command line toolchain that is available for free download. It is fine for compiling C source code to .out files but debugging options are limited. I usually do the debugging in the Windows based option of my external libraries and afterwards recompile them in GCC to be deployed to the VxWorks based target.
@schddc wrote:
Hey everyone thanks for the help and responses, I appreciate your time. I may have been a little confusing and used PC as a catch all term. VxWorks does support x86 and PPC. I know NI only supports VxWorks for PPC. I have a PPC freescale system and a PPC single board computer. So what I would like to do is put LabVIEW Real-Time on my freescale system and try to run my VIs from there, is this possible?
That first paragraph is very interesting thanks for sharing that information. From my understanding and what I have been told NI ETS doesnt have a command line. So now I have another question. I have a library with a few samples written in C and a few in G (LabVIEW). If I were to build my libraries and samples using VC 6.0 (lukcily I still have it) how would I run my C samples on NI ETS without using LabWindows/CVI?
Not sure about executables build with Visual C. But for DLLs, if you create your DLL in VS 6.0 and don't use any newer Windows specific features in there (that means at least no ActiveX and any post Win2K APIs) LabVIEW simply will deploy that DLL to the ETS system (at least in the case of a RT RIO controller) when you run the VI in the target context. And when building a standalone executable the DLL will be added as dependency to your executable build. There are tools for various LabVIEW versions, that can check a DLL if it uses any unsupported Windows APIs for the intended target version. Check here for them!
I would assume that a similar thing would apply for executables created in C, but there might be some extra catches in there that I'm not aware of. I only have experience with deploying DLLs/shared libraries to an ETS/VxWorks RT controller system that are used from within LabVIEW code.
As to running an NI RT system on your own hardware. It is most likely not possible without access to internal information within NI. The NI RT system is a very complex system with many components that need to play together without failure in order to get you a workable solution. Some of those components are very tightly coupled with the underlaying hardware including custom extension made to the underlayin OS kernel by NI. You will most likely not be able to identify them all, and implement them correctly in your own version of the RT system. Aside of the fact that a legal version of VxWorks with according source code license to be able to make such modifications, is likely far beyond most peoples reach.
@schddc wrote:
So it sounds like as far as VxWorks goes. If I want to use LabVIEW RT I must use hardware provided by NI.
Is the same true for LinuxRT? Based off of this discussion I could get the source code for LinuxRT from NI. If I was able to compile for my processor I would be able to communicate to it with MAX and use it as a RTOS for my VIs?
That's not so simple. Linux RT is only the kernel part of the controller. The LabVIEW RT system consists of many more parts, such as the LabVIEW runtime system and various support components. They are binary components too (created from C/C++ code) but are not part of the Linux kernel and as such do not fall under the GNU license of the kernel. Therefore they are not available as source code and there is really no way to recreate them on your own!
