LabVIEW Real-Time Idea Exchange

Post an idea

I use "Set System Image" to set an image on freshly manufactured units. Every now and then, the imaging process fails for one reason or another (possibly a hardware/networking failure). I know that the image process in my case usually takes about 4 minutes. Unfortunately when the imaging process fails, there's no way for the application to gracefully stop "Set System Image". The only option is to wait a really long time or use the task manager to force-quit the application. The abort button on the VI doesn't work

So, I'd like one of two things. Either, an input so I can adjust the timeout based on my application or some way to let "Set System Image" know that the application would like to stop if possible (maybe nothing had been written yet). For example, it could take in a DVR and the application could feed it a "true".

System Image Escape.png

Edit Unknown Files Through WIF

Add ability to monitor network usage

The Set System Image VI (and by extension, the Replication and Deployment Tool) have a deployment blacklist. Currently, files on that list are never deployed. It would be helpful if instead, those files, if they exist in the image, were deployed only if they do not already exist on the target. That would make it easier to create a single image that could be used for both an upgrade, where you do not want to overwrite existing configuration files, and for initial setup, where you want to install a default configuration file.

Did I misunderstand something about the way the deployment blacklist works? The documentation says "Files on the blacklist will not be copied from the image to the target" which makes me wonder why you would ever want to include those files in the image at all.

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)

Support for Real-time Module on Mac OS

The SVE on a windows based platform acts as a OPC-DA server. Due to the requirements for DCOM, this is not possible on real-time target. However, as OPC-UA is gaining traction, I would find it very useful to have the SVE act as an OPC-UA server for integration with 3rd party systems (SCADA, IIoT).

I know that there is the OPC-UA API palette, however, this takes more time to setup than creating a shared variable (i.e. a tag) and moving on with the application development. If update rates are slow enough (500-1000ms), I have found the shared variable to be more than adequate for my applications (500-800 NSVs), so I'm not looking for granular control over how I send data out of the cRIO system. Ease of use is my primary concern.

View All (4)

Currently viewing, testing or configuring NI-9862 Modules in a cRIO using NI-MAX needs a lot of effort. It requires:

- Installation of the complete Labview Realtime and FPGA development suite on the connected PC

- Setting up a Labview project including the NI-9862 Modules and an empty FPGA VI

- Compiling the emty FPGA VI to a FPGA bitmap file

- Starting the FPGA VI

Without these steps the NI-9862 Modules are invisible in NI-MAX

Proposed improvement:

- NI-MAX should include a default FPGA bitmap file that includes the communication with NI-9862 modules

- When the user connects to the cRIO with NI-MAX, the current cRIO configuation should be automatically saved to a backup and the default bitmap file should be activated

- When the user disconnects, the backup should be restored

Advantage:

- viewing, testing or configuring NI-9862 Modules in a cRIO could be possible just by starting the NI-MAX and connecting to the cRIO, as simple as with any standard I/O modules.

Currently a VI running in a Real Time environment does not support run time menus. I understand the restriction, but what I find odd is VIs that have the menu reference wire cannot compile for RT targets. This may seem like no big deal, because why would you have a menu reference wire, but not use it? But I have come to find two examples that make RT code a bit more difficult due to this issue.

If I have a polymorphic VI, and one of the polymorphic types has a menu reference terminal, then I can't use that polymorphic VI in an RT VI, even if the instance that is being used doesn't use the menu reference. One work around for this is to wrap the entire VI that does use the menu reference (terminals and all) in a conditional disable structure so that it does nothing on RT.

Another issue comes in the form of templates. I have various temples to get code started, and most of it can run on RT or other targets without any need to change the code, just place conditional disable structures where needed. But I found one issue where I can't have an event structure on RT, that has the Shortcut Menu Activation? event, because it generates a menu reference wire. Ideally this event just can't be generated on RT, so the compiler would know to not include it, and it would allow the VI to run on RT. Same for polymorphic VIs that have a menu reference in one of its instances.

A better solution might be to lift all restrictions of using the menu reference wire on RT, and just assume that using the menu reference on RT does nothing, like a No-Op. Optionally an error could be generated if one of the menu reference functions are used, but for the sake of simplicity I'm not sure that is needed. What I'm really looking for, is a way to allow VIs to run on RT, that have menu reference wires types, but aren't used. Note the VI below which can't run on RT and the reason given is that the menu reference can't be used on RT, but it isn't being used, it is just wired to a disabled case.

The RAD tool is not a perfect fit for all cRIO deployments. If you are unable to use the RAD utility to deploy a new version of drivers to the cRIO the process to get the Network Variable Engine onto the cRIO goes something like this: Install LabVIEW and LabVIEW Real-Time, install NI CompactRIO drivers, install NVE and other driver software to the cRIO and then uninstall the LabVIEW components from the host PC. This assumes that an executable will be installed to the host computer as the UI to the cRIO. Seems like a lot of work for something most people would be using on the majority of cRIO deployments and might assume is a part of the CompactRIO drivers.

At the very least it would be great if the documentation found on the website were explicit as to what software needs to be installed for each of the install options available to install on to the cRIO.

When using the "Open FPGA VI Reference" function you can configure it to reference the FPGA build/bitfile in three different ways:

- Build specification

- VI

- Bitfile

In development mode I often use "Build spec", for deployment I switch to "Bitfile". When using this function it behaves different, depending in which mode it is configured! This makes for a bad "User eXperience"…

In "Build spec" mode:

- when double clicking the pink border of the function it opens the referenced FPGA VI

- you need to right-click the "Open FPGA VI reference" and select "Configure…" to open the configuration dialog

- when selecting the "Build Spec" radio button it opens a selection dialog (probably a listbox) but you can't double click the build spec you want to use, you need to select the build spec and then click on "OK" button

In "Bitfile" mode:

- when double clicking the pink border of the function it opens the configuration dialog, (you don't need to right-click the "Open FPGA VI reference" and select "Configure…" to open the configuration dialog)

- when selecting the "Bitfile" radio button it opens a file dialog and but you can double click the bitfile you want to use

(All this relates to LabVIEW2014SP1. Haven't tested this with LabVIEW2015 so far.)

I propose the idea to make this behaviour consistent, independent of the selected mode in the configuration dialog!

I wish this behaviour:

- double click on pink border of the functions opens the configuration dialog

- double click on the FPGA VI icon shown inside the "Open FPGA VI reference" function opens the FPGA VI

- double click on an item in the "Build spec" selection dialog selects the build spec

Porting VI from cFP to cRIO?

View All (7)

Hello LabVIEW Users.

My name is Eisuke Ono, An Application Engineer at NI Japan.

One of our customer is requesting a function.

The function is to retrieve information of module fault from C Series I/O variable Node (Scan Interface).

I know that we can get the information of module fault through FPGA I/O node, but not through Scan Inteface mode.

The customer's application is embedded condition monitoring system. It runs 24/7.

So it is very convenient if he get information of module fault C Series I/O variable Node Error Output.

I agree his opinion.

What do you think?

Bestr regards.

Eisuke Ono

Many of the features that are not supported on LinuxRT are things that one would expect not to work (due to the underlying technologies), but why no menu and cursor functions?

The lack of menu support in particular means that most GUIs have to be customized to run on the target....even though Xfce should be perfectly capable of handling them in their original design... I was really hoping we could port some of our GUIs straight to the embedded GUI and replace our industrial computers immediately with cRIOs...(the differences in appearances are easier to handle, after all we use system controls and take cross-platform variations into consideration already).

Now we'll have to (decide if we want to) spend time on customizing the GUIs.

enhance access security

It would be good to enhance access security to also include program-control of cRIO's. As it is now you can set user access for a cRIO in a project by opening the Real-Time CompactRIO properties and set Allow/Deny access by IP. However, this only limits access to deploying settings and eventual RT applications on the cRIO. You can still control the cRIO (e.g. set outputs and, as in my case, control servo motor drives connected to the cRIO) from a LabVIEW application on any PC on the LAN.

This added access control could eventually be set up in MAX.

Many measurement and process control application run at relatively slow rates (<100Hz). Using SCAN Engine on the CompacRIO for data acquisition is ideal for these applications because you don't need to program the FPGA and all the measurement and control logic can be implemented on the Real-Time controller.

In many cases you want to process your data before you analize it. Currently you only have the ability to get the raw measurement data from the AI modules, so you need to add the data processing code to your existing LabVIEW program. It would be helpful if the SCAN engine could offload some of the data processing (ex. lowpass filter or sample average) to the FPGA and provide the user with already processed data. For example, this functionality can be added to the module configuration page:

View All (3)

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

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

There should be a way to stop Set System Image.vi if possible

Add support for Labview real-time for Labview 64-bit

Edit Unknown Files Through WIF

Add ability to monitor network usage

Set System Image should deploy files from the image that are in the blacklist and don't exist on the target

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

Support for Real-time Module on Mac OS

Allow Shared Variable Engine on RT target to act as OPC-UA server

Easier NI-MAX access to CAN-Modules NI-9862 in cRIO

Don't Break VIs with Menu Reference Wires

Add the Network Variable Engine Installer as a part of the NI CompactRIO Driver software

"Open FPGA VI Reference": change to consistent behaviour

Porting VI from cFP to cRIO?

Add support for the "Exist" function in the Mathscript RT Module for the LabVIEW RTE

SDXC card support for cRIO 9031 Linux Real Time

Detecting C Series Module Fault through I/O Variable Node

Support for menu and cursor functions on embedded GUI (Xfce)

enhance access security

Expanding the data processing functionality of the SCAN Engine

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