• Troubleshooting

  • https://nilrt-docs.ni.com/troubleshooting/troubleshooting_index.html

• Manage disk use with extra logging enabled

  • https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/How-to-manage-disk-use-with-extra-logging-enabled/td-p/3472215

• RT Crashing: Because of Priorities

  • https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/Crio-9039-RT-Crashing-Periodically-problem/m-p/3760697#M2561

• Disable Automatic Safe Boot

  • https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kFQ6SAM&l=de-DE

• FIFO Read takes 30 or 40 ms to time out

  • Some cRIO targets use interrupts instead of polling to wait until the requested amount of data has transferred in the FIFO. Enabling interrupts incurs extra setup time compared to polling, which is part of the behaviour. The timeout for the interrupt uses the system “Jiffies” which have a 10ms resolution as set in the kernel configuration on that device, so the timeouts are rounding up to the next 10ms tick. Setting a timeout of 1-10 generates a 30ms delay, 11-20 generates a 40ms delay, and so on. Setting the timeout to 0 does not incur the overhead of setting up the interrupt since it just polls the device once.
  • Source: MattyJ, Discord

• “LabVIEW (0x6) Generic File I/O Error: The File 'lvuser' Could Not Be Loaded”:

  • https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9vbSAC&l=de-DE

• https://forums.ni.com/t5/LabVIEW/cRIO-LabVIEW-StartupApp-manually-start/td-p/4213816

for NI Linux RT on Intel x64 (i.e. Atom) based products

• https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/Leaving-Safe-Mode-via-SSH-Command-Line/td-p/3546207

Boot into safe mode:

  /etc/init.d/nisetbootmode force-safemode && reboot

*note that it seems rebooting while in safe mode will boot back into run mode (unless you have some critical error preventing it, in which case it will fail back into safe mode)

Boot into run mode (Redundant, see comment above):

  /etc/init.d/nisetbootmode force-normal  && reboot

To check a filesystem the filesystem has to be unmounted with umount /path/to_fs. If the filesystem is in use the unmount can be forced with -l. WARMING: To force the unmount can have unpredictable side effects.

To check the filesystem use fsck /path/to_device. If the actual filesystem is not autodetected you can select it manually, e.g. fsck.ext4 /dev/sda4.

Courtesy of NI forums user thoric

To have a more detailed crash dump:

• add the following tokens to /etc/natinst/share/lvrt.conf

  DPrintfLogging=True
  Debugging=True

• add the following tokens to [LVRT] section of /etc/natinst/share/ni-rt.ini

  EnableCoreDumps="True"

• Save the files and reboot the cRIO

• Log files will be found in /var/local/natinst/log/

Use tcpdump to monitor or log network traffic directly on a Linux RT device.

To show TCP and UDP packages on specific ports (leave “-q” for more details):

  tcpdump -i eth0 -q 'port 12345 or port 12346'

To write the dump into a file:

  tcpdump -i eth0 -w output.dump 'port 12345 or port 12346'

Optional: Install “SSH dump” to view logged data directly in Wireshark running on a different machine (eg the host PC).

Further details about tcpdump at https://wiki.ubuntuusers.de/tcpdump/

When wiring a value to the net address input of the “UDP Open” VI (not the UDP Multicast Open?), the UDP connection will not be able to receive broadcasts.

It appears to be a problem with how the Linux kernel handles binding ports and in-fact the “UDP Open” documentation specifically says if you assign an IP to the net address input, the UDP connection will be unable to receive broadcasts.

Why that works on Windows but not Linux again, seems to be with how the kernel routes packets to the interfaces and when you do a UDP open with a specific IP, it must bind the port you choose to only receive traffic send explicitly to that IP, even if it is in the correct subnet to theoretically receive a broadcast.

https://forums.ni.com/t5/LabVIEW/UDP-Broadcast-not-Received-by-UDP-Read-on-NI-Linux-RT-Target/td-p/4292684