The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
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:
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:
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.
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.
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.
Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
Browse by label or search in the LabVIEW Real-Time Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW Real-Time Idea Exchange. Be sure to submit a separate post for each idea.
Watch as the community gives your idea kudos and adds their input.
As NI R&D considers the idea, they will change the idea status.
Give kudos to other ideas that you would like to see in a future version of LabVIEW Real-Time!