LabVIEW Real-Time Idea Exchange

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.

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.

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.

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.

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.

Having used our LabVIEW 2011 StateChart module with great success on a CompactDAQ system, I now have a new project using a CompactRIO 9075 which will
be controlling a hydraulic test unit.  I would like to again use our StateChart Module so the functionality of the machine is understandable to all stakeholders.

The best NI example project I could find is the Chemical Mixing Example w/StateChart.  It is exactly what I need except that it is a "headless" architecture.  I need a 1:1 networked communication to my host PC for recipe entering and data logging much like the Bioreactor Example in the CompactRIO Developers Guide.  See attached architecture jpg. I need to know how, specifically, to add a Host UI and incorporate network streams for the Host Command sender -> RT Command Parser.

In other words, what software architecture would combine the Chemical Mixing Example (w/StateChart) with the Bioreactor Example?

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 

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

The only functionality of RT USB is mass storage. It would be helpful to add at least RAW Data USB support to use USB port for connecting i.e. USB / RS232 adapter. Many analyzers use integrated serial/USB converter chips to transfer data to PC, because no need of specialized driver (you get the driver with the chip). The ability of RAW USB support allows to connect these analyzers to cRIOs and RT PC Targets. 

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

Different versions of NI-RIO only support certain versions of Labview, see link below.  You can not have Labview 8.5.1 Real-Time & 2011 Real-Time co-exist on the same PC because NI-RIO 4.0 only supports up to 8.6.1.  Wouldn't it be nice if you could install multiple version of NI-RIO just like you can have multiple version of Labview?

NI-RIO and LabVIEW Version Compatibility

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.

At the moment Labview RT does not support high speed USB 2.0 (EHCI) functionality on PXI-8xxx controllers even if the controller has supporting hardware.  We implemented a copy operation to transfer data files from a harddrive on the PXI chassis to an external USB connected flash drive using the copy VI, and only obtained speeds at USB 1.1 (OHCI) levels.  We also tried a move version using the Move VI with similar results.  The controller used in our tests was a PXI-8186, which has USB 2.0 ports.

My discussions with NI Support and the R&D team indicate this a limitation imposed by the ETS RTOS from Phar Lap that Labivew RT runs on.  This is inline with the fact that VxWorks supported controllers have access to EHCI speeds as per this faq:

http://digital.ni.com/public.nsf/allkb/BE80D012BB933B54862572D6004FE5F9

Could we get high speed USB support implemented in Labview RT/ETS?

Here are some benchmarks that we obtained:

1. Right Click on Blank Cursor Column will crash DSM

2. Make cursors Max and Min actually work

I was replying to a message thread someone had about question marks showing up for the times in the I/O channels for a compact Fieldpoint system.  While investigating, I notice on my system that I had timestamps for data that occurred later in the day than the current time.  So I know those timestamps were from a day prior than the current day.  Actually, the test stand had been idle for quite a few days, so I pretty much know those I/O channels had not been updated for a while.  But I could not tell from the timestamp when exactly that data was from.

In the attached screenshot, the current time was about 1:44 pm.  Some data shows it had just been timestampled.  Some data was from 7am,  other data from 2:19 pm or 4:19 pm.  I know that that data had to have been from yesterday or older.  The 7am could be from today or older, but there was no way to tell.  Based on my usage of that test stand, I'm pretty sure all of that data is at least 3 days old, and perhaps 6 or 7 days old.  That is okay and not a problem.  But there is no way of knowing how old that data actually is based on this screenshot.

I think MAX should show the date as part of the timestamp when looking at the I/O data.