Question: Should I be concerned by the fact that Linux has a different file structure and file path notation when porting my LabVIEW Real-Time application over to a NI Linux Real-Time based target?
Answer: The vast majority of LabVIEW Real-Time code will function as-is between different operating systems despite any differences in file path notation or file system structure. The few differences worth noting are that:
Question: I used to rely on FTP to transfer files to and from my real-time target. I can’t seem to do that with NI Linux Real-Time based targets. How can I transfer files to and from my system?
Answer: By default the Recommended Software Set (RSS) installed from MAX will not install an FTP server on NI Linux Real-Time targets. If you want to continue using an open, unsecured FTP server, you will have to install it manually from the custom install list. Refer to How Do I Use FTP with My NI Linux Real-Time Target? for details. This is meant to be a security benefit as it removes the security hole of an open FTP server formerly present on existing cRIO systems. Also note that both WebDAV and SSH are good file transfer alternatives (which can be secured). It’s also possible to do SFTP over SSH. For more details, please refer to Using WebDAV to transfer files to your RT target.
Question: What distribution of Linux is shipping on NI hardware running NI Linux Real-Time?
Answer: A Linux distribution is comprised of a unique set number of libraries and utilities shipped with the Linux kernel. As such, NI Linux Real-Time is the distribution is tailored for our user’s needs; it is built using the OpenEmbedded framework, has Real-Time patches applied, and has customizations for better hardware integration with NI real-time hardware targets.
Question: What is the determinism of the Linux-RT operating system on a CompactRIO controller?
Answer: The custom distribution of Linux that NI has created includes real-time patches to make the system deterministic. In NI’s testing, the upper bound of jitter with NI Linux Real-Time on CompactRIO targets is on the same order of magnitude as other CompactRIO systems which run a VxWorks RTOS.
Beyond jitter, note that you will be able to see a substantial performance improvements in loop rates with the NI Linux Real-Time based cRIO-9068 over the cRIO-9024 and cRIO-9074 controllers and with the cRIO-903x controllers over the previous generation cRIO-9025. Additional benchmarking can be found at NI CompactRIO Performance Controller: Performance and Throughput Benchmarks.
Question: I’d like to make use of the Linux ecosystem and install additional software to my NI Linux Real-Time target. What support can I expect from NI?
Answer: There are thousands of community sourced applications available through a variety of means for Linux-based operating systems. If a user is interested in leveraging this ecosystem there is an assumed minimum Linux proficiency required. Below are the guidelines we have in place for what NI will support for those looking to leverage the Linux ecosystem:
Question: If, for whatever reason, the NI Linux Real-Time operating system becomes corrupt or otherwise fails, can it be reinstalled?
Answer: If NI Linux Real-Time fails to boot or becomes corrupt in any other way in the normal operating mode (run mode), the system can be reformatted and reinstalled in about 5 minutes from MAX. In order to do this we have a completely separate Linux image called 'safe mode' that we automatically boot to if run mode is corrupted. We also use safe mode when MAX installs software to the target.
Question: How do I factory reset my target?
Answer: To reset all settings to factory default, for example in the case of a lost administrator password, please contact our Applications Engineering department for assistance. You will need physical access to the controller. To change passwords and manage user accounts, read How Do I Manage User Accounts on NI Linux Real-Time Devices?
Question: What is the file system used as part of Linux-RT? Is it reliable?
Answer: NI's R&D staff investigated the different options for providing a robust file system and selected the Unsorted Block Image File System (UBIFS). To prove out this file system NI R&D has conducted stress testing, including testing on power loss corruption. UBIFS has undergone and passed the same rigorous testing that the robust filesystems on our VxWorks based targets did. On the CompactRIO-9068, the file system is on a NAND Flash device. Additionally, the Intel x86_x64 architecture-based targets use the ext4 journaling file system.
Question: Are there different thread priorities available from LabVIEW on NI Linux Real-Time targets compared to VxWorks or Phar Lap targets?
Answer: The differences in the priority scheme and scheduling on NI Linux Real-Time should have little impact on your existing real-time application. While there are changes to the scheduler between LinuxRT and VxWorks, moving from VxWorks based targets shouldn't cause any noticeable difference in the scheduling/thread prioritization.
Timed structure priorities and LV priorities work the same as before, except that any "normal" priority tasks (ex: normal priority VIs) are not handled with the real-time scheduler but are instead scheduled with Linux's default Completely Fair Scheduler (which should do a better job of scheduling normal priority work between LV and other non-LV threads).
Question: Will NI offer a tool for NI Linux Real-Time that is equivalent to the DLL checker for Pharlap?
Answer: First, it’s important to note that Linux systems do not and cannot use DLLs, and instead rely on “shared objects”, which have a “.so” extension. As Linux is an operating system built with open source principles, there already exist a number of tools such as ‘ldd’ which can help determine whether a given “.so” file will properly work on a Linux based system. NI currently has no plans to provide such a tool for NI Linux Real-Time given the tools that already exist.
Question: For the Xilinx Zynq SOC based targets, will there be any differences in the experience now that the RT Processor and FPGA share the same fabric?
Answer: Yes. For Zynq based products, when the real-time processor reboots, it will also reset the FPGA. Unlike previous generations of CompactRIO and Single-Board RIO, customers should be aware the the FPGA I/O will not be controlled on reboots. Additionally, when loading a new FPGA bitfile, a few of the peripherals will be interrupted as they are either instantiated or routed through the FPGA. This applies specifically to the second gigabit Ethernet port and to the serial ports.
Question: Is it possible to run the NI Linux Real-Time distribution (Operating System) on 3rd party hardware such as Raspberry Pi, BeagleBone Black, etc.? Does NI support this?
Answer: We created the NI Linux RT distribution to support National Instruments hardware, so while you can run it on other boards, it's probably a lot easier to use a Linux distribution meant for your board/consider applying the -rt patch https://rt.wiki.kernel.org/index.php/Main_Page to Linux yourself in order to run a real-time Linux distribution on 3rd party hardware. If you want to run NI Linux RT anyway, it's not supported through NI technical support but it is indeed possible to port our Linux distirbution to third party hardware, in fact, you can get our source from https://github.com/ni. You'll need to make whatever changes are appropriate for your board's processor architecture, peripheral set, and so on. Note that the LINX toolkit discussed below, does NOT run the NI Linux Real-Time distribution, instead it runs on the recomended, debian-based distributions for the BeagleBone Black and Raspberry Pi platforms.
Question: Can I run NI software like LabVIEW Real-Time (proprietary, licensed product) on an "original" Raspberry Pi?
Answer: No, because the Raspberry Pi uses an ARM with a different instruction set architecture than the one used on NI's current ARM boards (armv6 vs. armv7-a). See this document and next Question/Answer.
Question: Can I run NI software like LabVIEW Real-Time (proprietary, licensed product) on other third-party hardware with a compatible architecture (an armv7-a device like BeagleBone Black, Raspberry Pi 2, x64 desktop PC, VM, etc.)?
Answer: Through the LINX Toolkit you can deploy LabVIEW VIs to a BeagleBone Black or Raspberry Pi 2/3 for non-commercial use. The LINX toolkit is intended to be used by makers, hobbyists and students. We are not planning to commercially support LabVIEW Real-Time on third-party hardware running NI Linux Real-Time at this time. You must purchase a LabVIEW Real-Time deployment license for every non-NI hardware target. Please contact deborah.burke@ni.com or your local NI field engineer if you decide to move forward porting to such hardware.
Question: What’s the preferred cross-compile toolchain for building C/C++ applications for NI Linux Real-Time targets?
Answer: We provide gcc toolchains that are tailored to NI Linux Real-Time targets. See this document for more information: Building C/C++ Applications for NI Linux Real-Time
Question: How can I add other software from the Linux community to my NI Linux Real-Time target?
Answer: You can use the opkg package manager to find and install other software to your NI Linux Real-Time target. You will need access to the internet for this to work.
For targets using the 2013 distribution only: Using opkg first requires enabling one or more Linux repositories. This can be done by editing all of the “.conf” files found at /etc/opkg and eliminating the leading “#” and space preceding the URL found in each of the “.conf” files. This process is documented in the first steps of the Tutorial: PostgreSQL with LabVIEW on the NI Linux Real-Time community.
You may find that when installing some software that you may get an error about the version of a dependency. Most commonly, you are likely to run into this error with the version of the libc package. There are two ways to address this problem. One is to force the new software package to use the version of libc6 that is available on NI Linux Real-Time. The other is to remove the flag on the libc6 package and allow it to be upgraded with the installation of the new software package. In either case you could end up with software validated against one version of libc6 using a different version. This is normally fine, but NI does not extensively test this configuration.
Question: How do I get Python installed on the a NI Linux Real-Time target?
Answer: This is an example of using the opkg package manager referenced above. In this case you would do:
opkg update
opkg install python
Question: How do I get GCC and other components of the GNU toolchain on my target?
Answer: The following is a compilation of the information within this thread: https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/Building-software-for-NI-Linux-RT/m-p/337228...
Note: you will need internet access for this process to work correctly, as opkg (the package manager within the Linux install on these targets) downloads the packages from an external site.
[2013 only] opkg flag ok libc6
[2013 only] opkg upgrade libc6
opkg install gcc gcc-symlinks
opkg install cpp cpp-symlinks
opkg install libc6-dev
opkg install binutils-symlinks
opkg install make
These packages and other common tools like Perl are also part of larger "packagegroups" that you can use as a convenient shortcut instead on recent versions of NI Linux RT, for example:
opkg install packagegroup-core-buildessential
Question: Where is the USB drive mounted when I plug it into my NI Linux Real-Time target?
Answer: The OS automaticly mounts any USB drive that is formatted for FAT32 (usually the default file system type, although not nessisarily) to /media/sda1. If the USB drive has more than one partition they will be mounted in /media/sda1, then /media/sda2, and so on. For compatibility with older NI targets it is also accessible at /u (then /v, etc.).
Executing umount /media/sda1 will cause all cached data to be written to it and unmount it. If you only want to flush the cache and not unmount the drive, you can execute the sync command.
Question: What feed URL should I use for `opkg`?
Answer: The general location is: http://download.ni.com/ni-linux-rt/feeds/, and then you select the version and architecture for your application. For example, on the cRIO-9068 for LabVIEW 2014, you should use:
I had developed code for using a USB drive and just tested it this morning.
It did NOT mount as /media/sda1, but /media/sdc1 instead.
Any suggestion or explanation for the difference?
Thanks for any details that might help.
James
Ahh, so this is a good point to bring up.
A lto of the above FAQ was written prior to the x64 verison of NI real-time was released. All of the baove is based on the cRIO-9068 which is ARM.
There will be small differences between the two architectures, and how they load drivers. The USB drivers for the cRIO-9068 appear to be loading the /dev device as 'sda1'. On your target, it is being loaded as 'sdc1'.
The cRIO-9068 only has one USB controller (built into the Zynq IC). The cRIO-9030 (using the Intel Atom) looks to have more than one. The one that you plugged the USB stick into, decided to enumerate it as 'sdc1' rather than 'sda1'.
Some backgroun, the 'sd' is for SCSI Disk (legacy naming). The 'a' or 'c' is the disk number (unique idenfifier), and the '1' is the partition on the disk. If you had more than one partition (say FAT32 for the first 512MB, and then ext4 for the next ~15.5GB, then it would enumerate as two different devices: /dev/sda1 and /dev/sda2.
Hope that clears things up for you!
Edit: wording.
Thanks, that does help a little.
However, the differences across targets makes developing shared code to detect USB drives across different targets a little more complex. ;o)
Thanks again!
Agreed, it does. You can rest assured that it will always be /dev/sd<letter><number> format. So you should be able to do a regex and/or string split to figure that out quickly.
You'll need a bit more logic if you plan on supporting multiple USB drives attached at once.
Good luck!
The order in which drives are detected and named in Linux is not fixed/guaranteed (especially if a USB hub is used and/or multiple drives are plugged/removed over time). One common solution is to detect if the drive is the one you want based on its UUID or partition label.
You can get that information using the 'blkid' utility. It is not installed by default so you will have to do:
opkg update
opkg install util-linux-blkid
For example to find out which /dev/sdX device matches a specific UUID you can call 'blkid -U <uuid number>'.
Alternatively if you want to do this from C there is a library available: libblkid.
Minor clarification on tduffy's post above, the cRIO-9030 enumerates your USB key as 'sdc' because the 'sda' and 'sdb' devices are used by the internal drive (SATA based) and the SD Card slot (USB based), even if you do not have a SD Card plugged in.
Thanks Josh, that helps me understand the why? behind the differences.
I'm trying to update a library of WebDAV VIs used to retrieve data files to support Linux targets. With VxWorks, checking for USB drive presence was simple, but I can see Linux is going to be a little more fun. Evidently, the paths are not even similar across Linux targets (/dev/sda vs. /media/sdc), so I may need to identify the target prior to building relative uri paths.
I was looking at the cRIO-9030 documentation, it states USB mapping is done the same as with VxWorks targets (/u, /v, etc). Ha Ha
Thanks again for the details,
James
I was looking at the cRIO-9030 documentation, it states USB mapping is done the same as with VxWorks targets (/u, /v, etc). Ha Ha
Not a joke, actually. The /dev/sd* path is not the file system path on any target. That's your device node; it needs to be mounted somewhere to access it as a file system. /media/* is a convention used on many distros, including NI's, but for compatibility with VxWorks, /u is also available. They're equivalent:
admin@NI-cRIO-9031-00005BA0:~# ls /u
9031-nirecovery.txt crb-mint.txt crb-nilinuxrecovery.txt time_memcpy32 time_memcpy64 time_memcpy.c
admin@NI-cRIO-9031-00005BA0:~# ls /media/sdc/
9031-nirecovery.txt crb-mint.txt crb-nilinuxrecovery.txt time_memcpy32 time_memcpy64 time_memcpy.c
If you only have a single USB drive, using /u to access it from WebDAV should work on all targets. If it doesn't, that's a bug. Having said that, you may prefer to use the /media location to follow Linux convention, depending on what environments your application will run in.
Can someone add links to the feed servers for both the 9068 and the 9038 to this FAQ? I am unable to connect my cRIOs to the internet and have to download package updates manually. I struggle with finding the correct location every 6 months when I need it, and a link provide in a previous thread is no longer valid. .
Added for cRIO-9068 for LabVIEW RT 2014. I do not have a 9036, so someone else will need to take those on.
@tduffy are those all available packages or just the packages that ship installed on the cRIO? I'm interested in all available packages.
I believe NI is only 'officially' supporting packages that are available via their opkg repo. The links I posted are the ones that ship with the cRIO-9068. I would suggest posting in the discussion section with more details if there are specific packages that you are interested in. @BradM is pretty good about responding quickly.
kwkengineer wrote:
@tduffy are those all available packages or just the packages that ship installed on the cRIO? I'm interested in all available packages.
Those are the packages that are used to constitute the image that is on the Zynq-based controllers as they ship along with packages that have either been requested by customers or NI assumed would be useful for a majority of customers.
Also, @tduffy, NI doesn't officially support (official support == you can call in and get assistance) anything other than what came installed on the controllers (as that's what's been tested and vetted), some of us take a bit of time to help people out with the other packages to take full advantage of the Linux ecosystem on these controllers.
Thanks for the clarification @BradM.
so does NTP not fit in the "useful for a majority of customers" bucket? That's all I need.
What controller are you using? What software release? ntp packages are on both the 2014 and 2015 feeds for both arm and x64...
I thought it was supposed to be on there.
I have two 9068s I got earlier this year, and just got two new 9038s. I've installed 2014 RIO 14.5 on both and ntp was not there. Unless I've missed something. The 9068s earlier this year I had to manual copy the packages over in order to install ntp.
@kwkengineer if you type this in:
opkg update
opkg list | grep ntp
What do you see? This is what I get on 2014:
<redacted>@<redacted>:~# opkg list | grep ntp
ntp - 4.2.6p5-r6.0 - Network Time Protocol daemon and utilities The Network Time Protocol
ntp-dbg - 4.2.6p5-r6.0 - Network Time Protocol daemon and utilities - Debugging files The Network
ntp-dev - 4.2.6p5-r6.0 - Network Time Protocol daemon and utilities - Development files The
ntp-doc - 4.2.6p5-r6.0 - Network Time Protocol daemon and utilities - Documentation files The
ntp-tickadj - 4.2.6p5-r6.0 - Network Time Protocol daemon and utilities The Network Time Protocol
ntp-utils - 4.2.6p5-r6.0 - Network Time Protocol daemon and utilities The Network Time Protocol
ntpdate - 4.2.6p5-r6.0 - Network Time Protocol daemon and utilities The Network Time Protocol
perl-module-net-nntp - 5.14.3-r1 - perl version 5.14.3-r1 perl module net-nntp
sntp - 4.2.6p5-r6.0 - Network Time Protocol daemon and utilities The Network Time Protocol
I can't run opkg update because I can't connect my cRIOs to the internet with lots of IT red tape.
I've grep'ed all my cRIOs and the only ones that have ntp are the ones that I've manually copied the packages.
I did expect that the packages would be on the cRIO (without update) if it is a supported package or at least be on the NI feeds at the link you provided.
After much diging, I did find NTP packages for x86_64 here http://feeds.angstrom-distribution.org/feeds/core/ipk/eglibc/x86_64/base/ I'll take a shot and see if they work for me.
Don't install the x86_64 packages on the 9068 - they won't work. Also, I would recommend using the NI repo, which can be found here:
x86_64: http://download.ni.com/ni-linux-rt/feeds/2014/x64/x86_64/ntp-dbg_4.2.6p5-r6.0_x86_64.ipk
The pakages don't ship with the units - that would be a very unwise use of space. You'll need to download the packages ( and all of their dependences ) and install manually without any internet access.
kwkengineer wrote:
I can't run opkg update because I can't connect my cRIOs to the internet with lots of IT red tape.
...
I did expect that the packages would be on the cRIO (without update) if it is a supported package or at least be on the NI feeds at the link you provided.
After much diging, I did find NTP packages for x86_64 here http://feeds.angstrom-distribution.org/feeds/core/ipk/eglibc/x86_64/base/ I'll take a shot and see if they work for me.
Two things:
First, as tduffy noted, you won't be able to install the x64 ipk to your 9068. It will prevent you and the binaries included within won't run on your controller.
Second, the idea is to install the software to the targets by default to enable the NI software stack and include some basic tools for customers, and make available (via the NI-maintained feed) other packages that may be useful for customers for extending the functionality of the controllers. Note that NI presumed that the majority of customers who would want to extend the functionality of their controllers would have access to the NI feeds (read: the Internet) from their controllers.
In any case, what needs to happen is to download the required ipks for your target (in this case, ntp, ntp-tickadj, and maybe ntp-utils), put them onto a USB storage device, and install them directly from the .ipk.
I understand the different packages for the different architectures, and I'm on target now (pun intended) with where to find the approprirate feeds. Which was my original request, that tduffy satisfied.
My failure was to stop looking for the NTP package on the NI feed when it wasn't under the path that said "all", my bad, figured if it wasn't there it wasn't supported.
Maybe NI would consider adding the packages to Driver Disks so it can ship as part of the SW release? I can't be the only customer in a locked down environment interested in extending the functionality of the controller.
Thanks for all the Help!
Hello,
I deployed my application on CRio RT on Linux.
Which is the "launch command" of my deployed software?
In which folder can I found the script? (rc.0 etc)
I want to create in Desktop folder a virtual link in order to launch application if somene close the software
How can I do it?
Thank you in advance.
Carmine
Carmine, welcome!
Firstly, this really should be a separate discussion to not add your question to the document.
Secondly, since you ask, the way that I would approach your issue would be to kill off the LVRT process on your controller, it will restart and reload your deployed/startup application. The way that LVRT works on these targets is that it will always start up, and it will check to see if you have set a startup application. For more details, see this discussion which is talking about the same issue: https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/quick-software-restart/td-p/3407711
How can I reset the root pw (or even do full factory reset) ?
Where can I find the full linux driver source code for backplane and IO cards ?
(no, we definitively won't use LV).
The original message implies that ldd command is available on NI Linux RT.
Is it?
How to invoke it?
Because every time I try I get "command not found"
We have two ears and one mouth so that we can listen twice as much as we speak.
Epictetus