LabVIEW Real-Time Idea Exchange

Community Browser
Showing results for 
Search instead for 
Did you mean: 
Post an idea



I noticed there seem to be no way to guarantee the state of an output module controlled by a scan engine in case the RT Application (or the Host Application, depending who is controlling the chassis) crashs. With FPGA one can program some kind of watchdog setting back the output values of a module in case the RT Exe fails. With Scan there just seem to be no possibility.


This is why I think adding a FailSafe Value for a Scan I/O node could be a creat idea. in ase the RT application got aborted  or stops  without cleanup, the output value would not be random no more but set back to their FailSafe value. I imagine it could look like that:




What do you think about it?

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:


SCAN Engine.png   

When renaming a set of variables for all the channels on a cRIO module, the names are assigned numbers starting with 1. These names do not line up properly with the names of the physical channels, and referencing the inputs becomes confusing with two different assigned numbers. This could be resolved by zero-indexing the numbers that are appended to the name of the channel.




If you have a deployed RT system running the scan engine you may have IOV channels with scaling that was configured and deployed from the project.

What happens when you need to change a scaling factor after the system has been deployed?  You would need the development tools to do this.

Since the smarts for this is already built into the LV IDE why not put the same code into MAX for remote viewing and modification of IOV properties.

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.

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


Currently, when you add a new (not existing) cRIO controller and chassis to a LabVIEW project, there is no check as to whether this is a valid configuration or not. For example, you can successfully add a cRIO 9072 controller with a 9112 chassis to a project, even though the 9072 is a controller with an integrated chassis. I believe that the LabVIEW Project interface should notify the user (via dialog box) that this is not a valid configuration before they can add modules and start developing code to use an invalid configuration.

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

For the use of a variator that generates his own clock and distributes it on EtherCAT, I need to make the RT loop synchronous with clock posted on EtherCAT by the variator.

So would require the scan engine parameter is in receipt of the EtherCAT clock.

This function is imperative on Labview-RT to be compatible with ability to manage EtherCAT variators ( Beckhoff).