Home

NI Linux Real-Time Documents

turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Document Options

NI Linux Real-Time FAQ

by Member Sanjay_C. on ‎01-28-2014 09:27 AM

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:

    • NI Linux Real-Time relies on a UNIX style file paths as opposed to Windows style file paths. As a result, any file path datatypes in a NI Linux-Real Time programming context will be coerced to a proper UNIX style file path. For example a file path constant with “C:\” will be coerced to “/C”.
    • NI Linux Real-Time also has a different file structure. As a result, it is recommended that users put their files in the “home” directory for their specific user (by default, this is /home/lvuser). There is a small layer of redirection so that the impact to existing LabVIEW Real-Time code is minimal.
    • This layer of redirection as well as the UNIX still file path differences are documented in the “README_File_Paths.txt” file located under “/” on the target. For more information on this topic, please refer to Working with File Paths on Real-Time Targets

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 cRIO-9068: Performance and Throughput Benchmarks and 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:

    1. NI will Support: User-mode libraries and applications. These are generally available as pre-built applications/libraries through a package manager which is installed on the CompactRIO, similar in concept to the Apple App Store. This package manager, called opkg, will point by default to a certain store, or repository, of pre-built applications/libraries. Since these applications are community sourced we cannot guarantee the quality of application. Applications/libraries are also available outside of the package manager, however, these one off packages have to be manually transferred and installed on the target with appropriate dependencies introducing further complexity for our users.
      Once the applications/libraries are installed on the CompactRIO, they can be accessed from within LabVIEW in various ways. NI can help ensure that the NI software stack (for example, LabVIEW Real-Time) behaves properly – the solution may involve having to use a different tool from the Linux ecosystem if it so happens that a given tool/application/package is ultimately the culprit in compromising the NI software stack. Note that NI will not support the actual installation, configuration, or use of 3rd party tools from the Linux ecosystem – there are far too many tools to be able to feasibly provide such support.
    2. NI Will Not Support: NI will provide the source code for the NI Linux Real-Time kernel, but does not officially support modifications to the kernel. An example of a kernel modification is the addition of a kernel module. Users are free to make changes to the kernel, but will need to have the requisite skill and will need to self-diagnose and resolve any issues. Note that changes to the kernel configuration or source code risks affecting the jitter and determinism of the system and may also prevent NI drivers, including NI-RIO, from loading properly.

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: 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 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 https://decibel.ni.com/content/message/83844#83844 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, or a virtual machine, or an x64 desktop PC, etc.)?

Answer: We are not planning to support LabVIEW Real-Time on 3rd party hardware 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 Sales Engineer if you decide to move forward porting to such hardware.  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.  See this page for more information.

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://decibel.ni.com/content/message/65378

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.

  1. Enable SSH access to your target within MAX or WIF.
  2. SSH into the target.
  3. Type the following commands one after each other (allowing the previous command to complete):

[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: On the cRIO-9068 for LabVIEW 2014, you should use:

Share
24 Comments (24 New)
Hide Comments
Comments
James@Work
Member James@Work
Member
on ‎02-04-2015 08:52 AM
Options
on ‎02-04-2015 08:52 AM

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.

  • NI-cRIO-9030-019FE011
  • NI Linux Real-Time x64 3.10.31-ltsi-rt29-2.0.0f0

Any suggestion or explanation for the difference?

Thanks for any details that might help.

James

tduffy
Member tduffy
Member
on ‎02-04-2015 10:05 AM
Options
on ‎02-04-2015 10:05 AM

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.

James@Work
Member James@Work
Member
on ‎02-04-2015 10:33 AM
Options
on ‎02-04-2015 10:33 AM

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!

tduffy
Member tduffy
Member
on ‎02-04-2015 10:39 AM
Options
on ‎02-04-2015 10:39 AM

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.

  1. Get the list of all of the files in /dev
  2. Itterate through the list seeing if each string has the index of '/dev/sd',
  3. If it does have the index, then that is an inumerated device.

You'll need a bit more logic if you plan on supporting multiple USB drives attached at once.

Good luck!

gratian.crisan
Member gratian.crisan
Member
on ‎02-04-2015 11:00 AM
Options
on ‎02-04-2015 11:00 AM

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.

Josh_KNH
Member Josh_KNH
Member
on ‎02-04-2015 11:15 AM
Options
on ‎02-04-2015 11:15 AM

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.

James@Work
Member James@Work
Member
on ‎02-04-2015 11:33 AM
Options
on ‎02-04-2015 11:33 AM

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

ScotSalmon
Member ScotSalmon
Member
on ‎02-04-2015 11:50 AM
Options
on ‎02-04-2015 11:50 AM

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.

kwkengineer
Member kwkengineer
Member
on ‎08-12-2015 10:14 AM
Options
on ‎08-12-2015 10:14 AM

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. .

tduffy
Member tduffy
Member
on ‎08-12-2015 10:20 AM
Options
on ‎08-12-2015 10:20 AM

Added for cRIO-9068 for LabVIEW RT 2014.  I do not have a 9036, so someone else will need to take those on.

kwkengineer
Member kwkengineer
Member
on ‎08-12-2015 11:28 AM
Options
on ‎08-12-2015 11:28 AM

@tduffy are those all available packages or just the packages that ship installed on the cRIO?  I'm interested in all available packages.

tduffy
Member tduffy
Member
on ‎08-12-2015 12:14 PM
Options
on ‎08-12-2015 12:14 PM

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.

BradM
Member BradM
Member
on ‎08-12-2015 01:24 PM
Options
on ‎08-12-2015 01:24 PM

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.

tduffy
Member tduffy
Member
on ‎08-12-2015 01:26 PM
Options
on ‎08-12-2015 01:26 PM

Thanks for the clarification @BradM.

kwkengineer
Member kwkengineer
Member
on ‎08-12-2015 04:41 PM
Options
on ‎08-12-2015 04:41 PM

so does NTP not fit in the "useful for a majority of customers" bucket?  That's all I need.

BradM
Member BradM
Member
on ‎08-13-2015 11:29 AM
Options
on ‎08-13-2015 11:29 AM

What controller are you using? What software release? ntp packages are on both the 2014 and 2015 feeds for both arm and x64...

kwkengineer
Member kwkengineer
Member
on ‎08-13-2015 11:35 AM
Options
on ‎08-13-2015 11:35 AM

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.

tduffy
Member tduffy
Member
on ‎08-13-2015 12:05 PM
Options
on ‎08-13-2015 12:05 PM

@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

kwkengineer
Member kwkengineer
Member
on ‎08-13-2015 12:22 PM
Options
on ‎08-13-2015 12:22 PM

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.

tduffy
Member tduffy
Member
on ‎08-13-2015 12:27 PM
Options
on ‎08-13-2015 12:27 PM

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

arm: http://download.ni.com/ni-linux-rt/feeds/2014/arm/armv7a-vfp-neon/ntp_4.2.6p5-r6.0_armv7a-vfp-neon.i...

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.

BradM
Member BradM
Member
on ‎08-13-2015 01:09 PM
Options
on ‎08-13-2015 01:09 PM

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.

kwkengineer
Member kwkengineer
Member
on ‎08-13-2015 01:22 PM
Options
on ‎08-13-2015 01:22 PM

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!

cderrico
Member cderrico
Member
on ‎03-30-2016 06:54 AM
Options
on ‎03-30-2016 06:54 AM

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

BradM
Member BradM
Member
on ‎03-30-2016 09:14 AM
Options
on ‎03-30-2016 09:14 AM

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://decibel.ni.com/content/thread/27008