CompactRIO and Fieldpoint Qs

[RJHLJH]

 I wanted to use cRIO hardware for a system of approx. 100-120 analog input channels sampled at >1K and additionally 60-70 digital IO channels used to turn on/off UUT by users from a host PC and also alarming produced by input channels mentioned.  Is it possible to expand the cRIO system beyond the 8 slot backplane?  I would like to take advantage of the isolted input modules that the cRIO has and also the ruggedness.  Many of the channels to be recorded are up to 20V with transients that have been measured to -40V.  I am not sure if I will be required to include addtional cRIO controllers and backplanes to fulfill the channel count requirement.  Can anyone provide some insight to this?  I was also considering the use of some Fieldpoint controllers for the digital requirements I just wasn't sure how easy it would be to integrate the systems.  Additionally, how many Fieldpoint network interface backplanes could be added to a cRIO system and how easy and fast could information be transferred back and forth.  I am new to RT applications so any input is appreciated.

thank you

[Justin D]

It is not possible to expand a single cRIO system to multiple backplanes.  A good idea for expanding the channel count of your cRIO system would be to use Fieldpoint for any i/o that doesn't have to be quite as fast.  I would reccommend using the cRIO for your high priority or high speed I/O and use the Fieldpoint expansion for your slower or lower priority I/O. 

The amount of IO that you can add to your cRIO system with Fieldpoint is essentially limitless.  You could connect your cRIO to multiple Fieldpoint network modules through a switch or a hub and easily have multiple units running.  I can't give you any exact benchmarks on speed for the expansion Fieldpoint IO but I would expect more than a few samples per second using this method.

-Justin D

[preston_johnson]

Sounds like a very interesting application. 

I agree that putting your slower speed data on cFP and linking all of these via ethernet is a great way to go.  You can have RT controllers or the enet backplanes 1804 and 1404. 

For the cRIO, you will need to synchronize multiple chassis:

http://zone.ni.com/devzone/cda/tut/p/id/4217 

For the voltage range, you can use the +/- 60V 12 bit module, add voltage dividers for the +/-10V 16 bit module, or in the near future expect a  +/-60V 24bit module.  Can you tell us more about the sensors you are working with?

Keep us posted of your progress.

[RJHLJH]

The higher voltage recordings are sense leads monitoring the voltage characteristics of the pumps we will be cycling. 

I have been leaning towards using multiple cRIO units and configuring the system as many smaller sub-systems.  This should allow me to create a single real time program that can be downloaded to multiple cRIO systems with limited variations between programs.  You had suggested that syncronizing the chassis will be necesary?  If the smaller systems are running independantly of one another with the only link between them being a PC with windows (allowing users to input parameters and cycle criteria), will the chassis need to be sycronized?  With the channel counts required and the way our supporting hardware/setup is configured, I am preparing to purchase 2 cRIO controllers and supporting modules and backplanes; as this testing grows, I want to be able to add additional cRIO sub-sytems to the network, what is necessary to provide a connection to each cRIO sub-system from a windows based PC?  What is recommended?  PCI serial card?  ethernet hub?  Please specify part number if possible.

thanks for the feedback. 

[preston_johnson]

Since each system will operate independently, you can send a log data at the Host Windows machine with the LabVIEW DSC module and shared variables.  https://www.ni.com/en-us/shop/product/labview-datalogging-and-supervisory-control-module.html

You can sycnronize data from each of the cRIOs, by using the host windows time clock as the base source clock. 

I would use ethernet to connect all the cRIOs and the Windows machine together.  You should also consider a switch or router as a way to minimize office traffic on the industrial side of the network. 

What levels of voltage and current are you measuring?  Are you planning to implement motor current signature analysis?

Thanks for your continued comments:

[RJHLJH]

The voltage signals will be 0-20V and yes I will be measuring the current.  50A/50mV shunts will be used.  Why would I use the PC software timed clock if I have real-time controllers. For the cycle timing, it is necessary the appropriate cycle timing is maintained.  As far as data logging is concerned, I wanted to store directly a storage unit via the USB connection while sending data updates to the windows based PC only to allow users to have a sense of the testing conditions.  The goal of the rea-time controllers is to maintain timing of cycle loopsof UUT, control temperatures testing media, and aquire, store, and analysis data for alarm conditions continuosly at 1000 hz.  I wanted to use mass storage units for each cRIO system that can be linked through USB, I believe the 9012 allows this.  Whhich NI products will allow me to communicat to multple cRIO systems?  This system will not be accessible to our office network.  I only want communication to these units.

[preston_johnson]

If you want to have the cRIO systems talk with each other there are two choices I tend to recommend.:

1) shared variable https://www.ni.com/en/support/documentation/supplemental/06/using-the-labview-shared-variable.html - slower speed data (<100hz)

2) TCP:  https://www.ni.com/en/support/documentation/supplemental/21/command-based-communication-design-patte... - higher speed data (> 100hz)

The 9012 does indeed support a USB drive, so you have lots of drive space and options.  You might even leverage the FTP server to trade data files with the Windows world. 

The Windows Box with LabVIEW DSC gives you a trend historian, alarm manager, and graphical display you can use for your cRIO systems. 

Thanks for the info on the electrical power measurements. 

[RJHLJH]

The 1000 hz data logging and alarming will only be done at the cRIO system level while updating the windows PC maybe only at 5-10 hz and with no communication between cRIO systems.  Is it possible to achieve the required minimum 1000 hz data logging, realtime analysis and cycle timing with this type of controller?  In this application I plan to have approx. 7-9 while loop per cRIO controller running simultaneously.  Only that of the data logging will be running at 1ms.  The others will be running at approx. 50ms.  I hope this system will be able to run in excess of 100 hz as suggested.  If not, I will be in search of an alternative.  Also could you give me some feedback on what is gained by using a 3m gate chassis vs a 1m gate chassis.  How does one decide which to use?

[Justin D]

A cRIO system should be more than capable enough for your application.  Something you may want to think about though is your loop speeds.  If you need to get 1000 samples per second, you don't need to have a loop in your realtime code running at 1000Hz.  Usually you will set up your FPGA code to acquire at a certain rate and then dump the data into a DMA FIFO.  The loop in your realtime code just reads data out of the FIFO and logs it (or whatever else).  For example, your realtime loop could run at 10Hz and read 100 samples per iteration from the FIFO to get the full 1000 samples per second back.  This will give you more leeway to do other things in your loop since it doesn't have to run quite as fast.

As far as whether to get a 1M gate or a 3M gate FPGA, it really depends on your application.  If you are doing complex triggering and logic along with lots of analog signals, you should probably get a 3M gate FPGA.  If you are doing mostly digital IO with just a few analog channels, a 1M gate FPGA should be fine.  Also, some of the higher channel count modules occupy a little more FPGA space (such as the cRIO-9205).  So if you have more than a couple 9205's I would reccommend getting a 3M gate FPGA.

Regards,
Justin D