Migrating NI Compact FieldPoint to cDAQ or cRIO

March 2018

Are you currently using a Compact FieldPoint (cFP) device and want to know what you should be thinking about to transition to a CompactRIO or CompactDAQ platform?

Are you doing control inside the cFP?

Are you doing any control with your system?  If so, is it being done within the cFP, or is it actually being done on a PC connected to the cFP?

If you have control algorithms running at higher than 100 Hz, you’ll probably want to use a cRIO (or at least a cDAQ with an RT controller).  The FPGA & real-time processor lend themselves well to high-rate deterministic loops, with the FPGA being able to run faster than RT.

Also, if you’re doing anything even remotely safety-related, you’ll want a cRIO, and sometimes you’ll even want to utilize a PLC or the FPGA side of the cRIO.

What can you do with the cFP that you can’t do with cDAQ?

I/O:

In general, beware of the size of the screw terminals available with cDAQ C Series modules; they tend to be smaller than are available with cFP modules. This smaller size can be an issue if your field wiring gauge is too big (i.e., smaller wire gauge number). Note that some C Series modules come in a couple connector styles that have built-in terminal blocks versus DSUB style connectors, the latter allowing cabling to larger terminal blocks with bigger screws.

Since there are many more types of C Series modules than cFP modules, you will almost certainly find a C Series module to replace your cFP module, but channel counts per module can be different (e.g., current output) and you might have to substitute a couple of C Series modules to accommodate all the I/O in a single cFP module (e.g., combined current input and output). The specifics of which C Series modules can replace the cFP modules are listed in the section below titled “Module limitations”.

Finally, note that, from an I/O module standpoint, many, but certainly not all, of the C Series modules are compatible with cDAQ (see here http://www.ni.com/product-documentation/8136/en/ for more).

Performance:

Being an older vintage, cFP is pretty limited from a CPU speed and memory capacity standpoint compared to a cDAQ with controller. Plus, the analog I/O in C Series typically has more bits than a comparable cFP module.

Using Controller or Just the I/O:

Originally, cDAQ chassis were used only for I/O and the “controller” was the PC you connected to the cDAQ chassis. Back around 2015, NI introduced a standalone cDAQ with a controller attached to a chassis for holding the I/O modules. If your cFP hardware is being used just for I/O and you are using a PC as the “controller”, you can continue with that same system design by using a traditional cDAQ module-only chassis. If you were using LabVIEW RT to run an application on the cFP controller, you can use a cDAQ controller system.

Software Application:

Whichever style of cDAQ you choose, you will have to rewrite some part of your application. Unfortunately, you can’t just move the cFP app onto cDAQ and expect it to work. The largest change will likely be in the I/O channel addressing, since cFP uses a completely different scheme for channel definition than DAQmx. But, since cFP applications followed a “single point” access scheme (rather than waveforms), the translation will be fairly straightforward, even if not trivial.

Environmental:

The cFP hardware has the same operational temperature range -40° to 70° C. the cFP has slightly better shock & vibration specs than the cDAQ hardware (50 g versus 30 g for shock, and 5 g vibration for both).

What can you do with cFP that you can’t do with cRIO?

Much of the remarks about moving to cDAQ from cFP also apply to moving to cRIO from cFP. However, some differences are listed below.

I/O:

The transition to C Series from cFP modules is the same for cRIO as cDAQ. Certainly, there are some C Series modules that don’t work with cDAQ and others that don’t work with cRIO, but none of these modules have comparable modules in cFP.

A point of difference is that using an FPGA to manage I/O via direct calls to the I/O channels, rather than going through FPGA Scan Engine (cRIO) or DAQmx (cDAQ) allows your cRIO much faster reaction. If your old cFP application depends on the slower responsiveness of the cFP controller and I/O, you may find that the cRIO system shows different behavior.

Performance:

The big change here, as alluded to earlier, is the availability of the FPGA in the cRIO. The cFP has nothing close to the performance capabilities available with an FPGA.

Software Application:

If your cFP application uses the cFP controller for the realtime capabilities, then a cRIO controller will give you all the capabilities you need to translate your application. As with cDAQ, the largest change will likely be in the I/O channel addressing, since cFP uses a completely different scheme for channel definition than Scan Engine or FPGA I/O. If you use the FPGA, while the I/O is programmed as single point access, you will still need to get those I/O values from your RT application layer into the FPGA, so there is another step involved. You’ll likely need to use a DMA FIFO.

Environmental:

The cRIO equipment can have the same operational temperature range as cFP of -40° to 70° C, but you can also purchase a cRIO controller with a smaller range of -20° to 55° C, so look for the extended temperature controllers if you need that wider range. Also, the cFP seems to have a slightly better shock & vibration specs than the cRIO hardware (50 g versus 30 g for shock, and 5 g vibration for both), but the cRIO controllers are tested to 30 g with a 11 ms half sine and 50 g with a 3 ms half sine over 18 shocks at 6 orientations. If it exists, it’s not easy to find from the NI literature exactly how the cFP equipment is tested for shock and vibration.

C Series Module Limitations

For the most part, whatever you could accomplish with a cFP from an I/O module standpoint, you can accomplish in a similar manner with a cRIO, with some notable limitations.  See this NI white paper for more info: https://www.ni.com/en-us/support/documentation/supplemental/14/transitioning-from-compact-fieldpoint-to-compactrio.html.

Something to keep in mind as well is that there are 3rd party cRIO module manufacturers that may have what you’re looking for.  See here: http://www.ni.com/product-documentation/2726/en/.

How to get help with a transition?

If you’d like help making the transition, Viewpoint can help.  We used to use cFP back in the day, and we’ve used cDAQ & cRIO quite a bit.  We’ve completed over 500 cRIO-based projects (see here for more).  We’re also a Platinum level National Instruments Alliance Partner, which puts us in the top ~2% worldwide.

Of course, there are tons of nuanced gotchas based on the specific cRIO/cDAQ model chosen, as well as your specific I/O needs.  We can help you select modules and port code over to the new platform.  To get started, it’s helpful to share whatever info you have revolving around: a hardware list, application overview, and source code.  Feel free to reach out here to initiate a conversation.

Yes, I want someone to migrate my NI Compact FieldPoint application »

Deep in learning mode?  You might be interested in these resources: