LabVIEW Real-Time Idea Exchange

Post an idea

Currently, if you have hardware in a LabVIEW project (e.g. a cRIO controller, cRIO chassis, or R-Series PXI card), the only way that you can change this to another product is by adding a new one to the project and deleting the old one. It would be nice to be able to use a configuration window to change the model number of a piece of hardware to a different, but similar one. For example, if you have a 9072 in the project but wanted to change it to a 9073. Another example would be the ability to change, via menus, a PXI 7813R to a 7854R. Of course the user would have to update any code written to account for changes due to the new hardware. This is especially convenient when you are simulating and configuring test systems but aren't quite sure exactly what hardware you need. Currently, for each new piece of hardware (similar or not) you have to create a new device and copy all of the IO, VIs, libraries, etc. under the new device in the project.

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)

Dual network interfaces is often part of the requirements for redundancy, however in such cases it is also very common to specify that the behaviour of borth of these should be identical. You see it in subsea control systems where they have an "A" and "B" channel, you see it topside where the device might need to be on two networks etc.

Unfortunately this is not the case for any of the dual port RT targets from NI. The secondary port is really a second class NIC. It has limited configuration options. It does not support DHCP, you cannot specify a gateway for it - and the code to do programmatic changes to its configuration is not easily available.

Please make the two ports fully interchangable. Port 1 or 2? It should not really matter which one you use.

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)

View All (4)

Streaming data is an important part for many applications. If the amount of data is very large, a RAID can improve system performance significantly.

Sadly, RAID is currently not supported for RT so Real Time Applications cannot use this valuable tool for enhancing streaming performance.

On Hypervisor systems, RAIDs can be used, but data has to be passed from the RT to Windows first. So streaming does not work like/with DMA but it uses CPU load which is in fact a waste of resources.

Norbert

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.

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)

We could solve a lot of our designs with sbRIO and LabVIEW RT if the sbRIOs' CAN interface was designed to be a slave, and there was a DS301 compliant CANOpen slave API available for LabVIEW RT.

I'm a bit surprised that only the master side is covered today, as I'm sure a lot of people will utilize sbRIOs in devices that are more natural to define as slaves, not masters.

Throw in a dual set of equivalent network interfaces and the sbRIO platform and RT is an ideal platform for subsea instrumentation, with SIIS Level 2 (CANOpen) and SIIS Level 3 (Ethernet) communication capabilities, at least as long as the power requirements are kept low.

View All (5)

View All (2)

In lack of a hardware idea exchange I'll post this here. I know composite ideas are not ideal either, but my main point is to voice the wish for a different kind of RT controller:

The "sb-cFP":

We basically use cFP-2220s as small, low power, rugged embedded computers in our systems. We've looked at sbRIOs, especially the newer ones like the 9606, but they do not have dual networking, nor the 4 in-built serial ports (yes you can use the mezzanine, but the power consumption, size etc. goes up). No FPGA is needed, nor any IO other than communication ports like Ethernet/Serial (USB and CANbus is nice though).

In an ideal world we would have a sbcFP version of the 2220, designed for embedded use, and at the price of a sbRIO withoyt an FPGA. The only thing we would miss then is lower power consumption. The cFP-2220 is specified to use around 6W. In real stand-alone use it typically draws around 3.2W (other applications might push that though), but that's still a lot for many types of embedded use.

Underclocking

Perhaps underclocking could be a solution to lower the power consumption of NIs controllers, when customers need a less power consuming device? Imagine beeing able to adjust this dynamically from the System Configuration API / NI MAX...An sb-cFP with 1-2W consumption would remove any reason to abandon LabVIEW RT and NI-hardware in favour of controllers running micro-linux e.g.

View All (7)

I have just gone through a somewhat painful support process to figure out how to adjust something as simple as the analog channel scaling on a NI-9203 module installed in a cRIO rack. Why there is no external way to adjust those properties, besides having a development system hooked up and accessing them through the Project Explorer, is a little baffling. After going a little round and round on the support call, it came down to this: modify your embedded program to include property references, where you can adjust the scaling programmatically. That means I need to modify my code, rebuild the executable, email it to the customer, get them to shut their entire line down, put the cRIO in the "don't run your startup VI" mode, upload the new program, restart, then finally get their entire line back up and running. All because they need to change the scaling on one 4-20mA analog channel from 0-400 to 0-500 units to match their PLC control system changes.

Seems like there should be a way to get into that configuration, maybe in MAX? We can see the cRIO processor, but can't get individual module or channel configurations. Distributed System Manager might be another place that properties could be adjusted. Anything to make the cRIO simpler to support in the field!

View All (5)

View All (2)

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,

It should be nice to create a low level CAN toolkit which could create or parse the 64 data bits of a CAN frame, without having to use the existing heavy tools.

What i would like to see is a list of low level VI's like readBoolean, readInteger, readFloat, readSingle ... writeBoolean, writeInteger ... with direct handling of the data coding (Intel / motorola)

These VI's could read/write channels directly to the 64 data bits of the frame.

These VI's are not very difficult to build ... and everyone who has already use the frame API, without DBC or NCD has done this work before.

My need is to create an official, validated list of low level channel read/write ... without having to use the channel API or CAN engine which ar not very powerfull.

For example :

ReadInteger ( in data, in startBit, in integerLength, in coding(Intel/motorola) , out integerValue )

ReadUInteger ( in data , in startBit, in integerLength, in coding(Intel/motorola) , out UIntegerValue )

readBoolean

ReadFloatCodedInteger( ........ offset, gain )

readFloat

ReadSingle

...

write....

When you speak with NI CAN users they all say ... NI CAN is too slow ... I think that this toolkit could help many CAN users to come back to NI CAN.

The top would be to create, using this low level API and a little bit scripting, a wizzard which could generate automaticaly the read and write VIs for selected frames of a DBC/NCD file. ( A frame = 1 read VI, One write VI and 1 cluster per frame containing the channels )

The generated result could be something like a polymorphic VI.

Manu.net

View All (1)

It would be nice if attaching a thumbdrive to a cRIO / RT usb port triggered a "mounted" event or interrupt in the RT OS. Currently the only way to discover if a thumbdrive has been connected is to periodically run a file/folder info VI and see if one is present. It would be nicer if we could register a dynamic event and wait for it using an event structure, or similarily register for an interrupt event would work as well.

In my case, the use-scenario is a field maintenance person going out and manually plugging in a thumb-drive about once every 4 weeks to get the stored log files off of the controller. (No, we cannot use remote access in this case due to customer network restrictions.) So, in my case, I can easily use the polling solution, but if there is one thing I don't like to do, its to write polling code of any sort. It seems so wasteful. Other possible use cases could be to detect the presence of a thumb-drive and check for patch/updates, copy over new configuration files, etc.

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

Modify Hardware Model in LabVIEW Project Without Having to Create a New One

Expanding the data processing functionality of the SCAN Engine

Dual ethernet ports should have identical features

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

Support newer hardware devices for ETS Real-time targets using Desktop PC

Add RAID support to LabVIEW Real Time

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

Field installed RT target

RT target with C-module in Scan Engine mode to include hi & low pass filters as property by default

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

CAN slave interface - with CANOpen Slave API

USB Support for RT

Access ethernet connected cDAQ units from LV Real-Time

sb-cFP

SDXC card support for cRIO 9031 Linux Real Time

Provide external method for adjusting cRIO module/channel properties

Getting the BIOS Version programmatically

enhance access security

CAN low level Toolkit ...

"USB mount" programatic event on RT