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 Real-Time Idea Exchange

Post an idea

I'd like to see NI develop a bullet proof way of communicating with a cRIO over TCP/IP to command that it reboot with no startup program, etc. I'm sure it can be done. The question is whether the cost to do this is warranted. I've had the cRIO lock up because of a corrupted deployment and it would not respond over the network until someone physically attended to it by setting the "no app" switch. This cRIO was mounted on a bridge over the Delaware river and was a real hassle to get to, and throw, that switch.

Suggestion: Dedicate a portion of the processor code to servicing the Ethernet ports that can't be consumed by the startup program. The user needs to always be able to reboot the cRIO and download new code.

Create an RT FIFO Primative similar to the Get Queue Status VI that returns the number of elements in the RT FIFO. Currently RT FIFO Read and RT FIFO Write return the number of elements in the RT FIFO, but calling these VIs will affect the contents of RT FIFO.

A workaround for this would be to maintain a count on a shift register and increment/decrement it each time the RT FIFO Write/RT FIFO Read VIs are called. This solution does not work when trying to monitor the size of an RT FIFO in a running VI in another VI that is used to detect memory leaks.

In some critical installations, it is absolutely unacceptable for the cRIO to be able to "go to sleep" (as it can do now) and be unreachable via its Ethernet connection, especially when it runs out of real-time in the software. Currently when a cRIO becomes unresponsive, it requires manual intervention to kill power, push buttons, and/or set DIP switches, etc. to bring it back to life. Our company is dealing with cRIOs that are located in places that are very difficult, expensive and time consuming to reach.

I strongly recommend that NI add, Ethernet accessible, hardware based reset/restart functions to the cRIO. These functions should be completely separate from current cRIO software and hardware and should allow remote control of the cRIO power supply, and setting of the dip switches and reset buttons mounted on the cRIO front panel. NI-MAX should be enhanced to allow a user to remotely control cRIO reboots via these functions.

View All (3)

Currently, non default map constants (like the one shown below) are detected as fatal insanities when deploying to Real-Time targets and crash the LabVIEW development environment.

There is a workaround, which is to build the map from other data structure constants. The map constant above was built from the code below. However, it takes longer to execute, and it takes more code. That is okay in some cases, but it would be better if there was an option to simply use the map constant above.

build map.png

View All (4)

Any controller that contains either a USB or SDIO card would have a bootstrap loader, available when the controller is in safe mode, that would allow the controller to be loaded up to operational status (OS, Drivers, RTEXE, etc...) from a deployment image contained on the removeable media. This would allow a replacement controller to be unboxed and installed in a stand alone system without the need to install software from a development computer.

This is one of those things that sort of bridges between a hardware and software request.

As far as I know, a thumb-drive or hdd that you connect to a cRIO USB port has to be formated using FAT. It would be very handy if NI would support attaching drives formated with the Reliance NITRO file-format. This could in some cases also lessen the pain of being stuck with Reliance (old version) on the cRIO main drive. It would also ensure deterministic file IO on the USB drives in case of power failure, un-expected device disconnection etc.

Thanks for reading and hope for your vote!

QFang

View All (1)

The best thing about Pharlap is that it will run dll's like Windows.

Making shared libraries for VxWorks (*.out files) is quite an arduous process if you don't have Wind River software. The GNU toolchain, that used to be the free alternative, does not work on Windows Vista or 7, leaving those of use who have chosen to upgrade out of luck.

It would be great is LabVIEW could provide a way to compile *.out files from the Application Builder and thereby provide more complete support for development on the CompactRIO platform.

View All (4)

Currently many controllers from NI only have one way to deal with a failure to contact a DHCP server - they will try to use a link local address (APIPA). If this too fails (due to Proxy ARP e.g.) the controller will not even start the RT Application (which might have other tasks to do regardless of the lack of netorking and/or might run code that will remedy the IP problem), but go into Safe Mode. This in itself is bad enough and should be changed to allow the application to be run, however the main request / idea I have will fix this indirectly:

- It should be an option to not fall back to APIPA, but to use the last known configuration (as long as the lease time is still valid). If the DHCP server is down the controller will have the IP-configuration it received the last time the server was up, and will use that configuration.

I know there has been some discussion in other areas about an "Android build" of LabVIEW, but I am thinking specifically about the Touch Panel Module. An option to target and deploy an HMI onto a low-cost, readily available Android tablet would be tremendous for RT projects, in my opinion. I've got 2 different projects right now that require expensive Win7 tablet PCs, but all they are doing is running a custom LV application to be used as a basic HMI, which is complete overkill. I know the webserver is an option, but it has some limits, and I'd like to have multiple varieties of HMIs available to show varying degrees of system data and performance, which gets dicey with a webserver situation (at least, in my experiences so far).

It just seems like expanding the TPM so that it's keeping up with the times (Android and iOS dominance) seems like a win/win for NI and developers.

View All (3)

Hello LabVIEW Enthusiast,

NI has introduced malleable VI function since LabVIEW 2017. It is a great function to have in advanced LabVIEW application development.

But "Stall Data Flow.vim" function is missing in Real-Time Target OS from timing function palette since 2017.

It is not like you can not use malleable VI in RT side, I have copied same VI from desktop VI to RT VI. It works fine without any error or broken arrow.

NI should include this types of VIs in RT package by default.

RT has Type Specification Structure too, which creates question for me on this missing VI.

If you have any reason(s) to share on this why it is not included on RT side, Please share your thoughts.

RT Side.JPG

Host Side.JPG

Thanks,
Vinal Gandhi

Download All

View All (1)

Currently, on the cRIO-903x series controllers, the Chassis Temperature and the USER1 push button are only available on the FPGA http://digital.ni.com/public.nsf/allkb/75E039282A8B691886257E450049C7B6 and require the chassis to operate in a Hybrid Mode in order to use both the Scan interface and those chassis I/O options.

The cRIO-902x series allowed for both of these I/O options to be accessed in the real-time OS directly. This small feature would add convenience on the cRIO-903x series controllers.

View All (5)

If you have an RT target set up with a startup application (ready to be deployed in the field), running a VI on it from the IDE should not change anything permanently.

Today (LabVIEW RT 2013), doing this will not just temporrarily stop the VIs running on the target (from the executable) - as you get warned about, but also cause the RTTarget.LaunchAppAtBoot=True line to be removed from the ni-rt.ini. So the startup application will not be launched the next time the device is started up, rendering your device useless in the field. Why?

- We had an incident where we narrowly escaped such a scenario. The RT target was embedded into a cannister that was about to be sealed, but an unforseen issue made it necessary to run a special test on it, with a VI from the IDE. The startup application in this case provides the only way into the system once the cannister is sealed (no Ethernet access, just RS485), so having it no longer start would be a catastrophy. No one expected running the VI would actually change anything permanently. We tested it of course, and saw that it stopped the startup application (and so we loaded an image of the correct setup afterwards to be sure all changes were removed), but it would be much better and more intuitive if no such permanent and fundamental changes occured (if actually possible to implement in a such a way).

View All (4)

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

LabVIEW Real-Time Idea Exchange

Update and extend NI System Monitor

Failsafe Remote Control Of cRIO

Get RT FIFO Status

cRIO Remote control of reboot or restart

Add Reliance NITRO to the list of supported file systems

Start including the Ethercat industrial communication drivers in the device driver DVD.

update the SQLite version available via opkg

Allow non default map constants on Real-Time targets

Field installed RT target

Build on deploy, if necessary

Allow USB hard-drive or stick to be formated with Reliance NITRO instead of FAT

Add ability to change text color on the RT Debug String VI

Support for Building VxWorks Shared Libraries (*.out files)

Fallback to last known IP if DHCP fails

Android target option for TPM

Add LabVIEW UNZIP to the RT target

Missing "Stall Data Flow.vim" VI in RT side

Allow Chassis Temp and USER1 Button to be accessed in Real-Time OS without FPGA Programming

Running a VI from the IDE should not touch the application launch flag

Allow RT FIFOs to be of type LV Class