Preferred NI system for Rocket Engine Development

[Jack_Oswald]

I'm pretty new to working with NI products, and have been using a CompactDaq chassis with various AO, voltage, thermocouple, and current measurement modules for benchtop testing of our pneumatic and engine subsystem testing needs.  This system was nice for rapid setup and a crash course on Labview programming-I relied on the DAQ Express functionality and simple logic.  For actually testing our engine, we'll need a more robust system spanning multiple  devices (high end pressure transducers, thermocouples, control regulators, valve actuation, and Coriolis flowmeters), microsecond IO control, and precision time synchronization (as opposed to relying on the Windows clock like with CompactDaq).  I believe a PXI build is most appropriate, but would love to hear what this forum can recommend.

Best,

Jack Oswald

Impulse Space Propulsion

[santo_13]

Obviously PXI setup will be more robust and scalable.

I think your application is specialized such that selecting the HW has to go hand in hand with plans for SW development and detailed analysis of your requirements.

I would recommend reaching out to NI or NI partners to do this requirement analysis.

[crossrulz]

For a more direct replacement for cDAQ would be a cRIO.  The cRIO platform uses a Linux RT OS and an FPGA backplane.  Using the FPGA, you can really get your timing down while the RT is useful for file IO, communications with other systems, and "slow" control loop.

[Jack_Oswald]

We were looking at the CRio vs the PXI as well, if I'm not mistaken that would allow us to reuse the capable CompactDaq voltage, AO, and thermocouple modules we've already purchased- definitely a big plus.  In fact, while I imagine I will be sold a PXI, the CRio looks like it may have everything we require.  I do have a chain started with customer support but certainly appreciate any advice from users who have built up similar systems.

Best,

Jack Oswald

[Jacobson-ni · Accepted solution]

I've seen both cRIO and PXI based systems be successful in this type of testing (I've also seen cDAQs used in certain situations).

You've probably thought about these points already but generally people would choose the cRIO because it is rugged they are excited about being able to put the system closer to the sensors (thereby saving time and money spent on cabling). People also think they will get a lot of use out of the FPGA backplane of the cRIO although I don't think it always turns out that way. Using the FPGA can be pretty simple/straightforward for a one-off system but if you need to add more I/O to your system and you aren't keeping to very strict module configurations, basically every future cRIO deployment will turn into a one-off deployment. If you want to get to the point where you can just have a super general control framework and just put any modules in a new cRIO, give it an appropriate configuration file and add it to your system you will probably end up keeping away from the FPGA in a lot of circumstances.

If you go the PXI route, you'll have to place your system much farther away from the rocket but I would guess you'll save a lot of time on the development end not having to worry about the synchronization between chassis (PXI time-based sync will probably be better and simpler than using the cRIO). I bet you'll also save time by virtue of just having much fewer systems that need to be communicating with each other. Even if you end up needing multiple PXI systems you'll be able to take advantage of some reflective memory card to communicate between systems more reliably than communicating over ethernet between cRIOs.