PXI vs PXIe

It’s worth setting the context from what we see at Viewpoint.  PXIe is becoming the norm for new automated test system development. But there’s obviously more to it than that.

This article is intended to share some of the more common tripping points for someone that currently has a PXI-based automated test system and is considering either buying a new PXI-based test system or transitioning to a PXIe-based tester.

System bandwidth

Bandwidth is the biggest difference between PXI and PXIe. Currently, NI’s fastest PXI chassis has a maximum system bandwidth of 132 MB/s whereas the fastest NI PXIe chassis you can get offers up to 24 GB/s. This is a significant increase that can be very beneficial for applications that acquire and/or process large amounts of data at high rates. The communication architecture for PXIe is based on PCIe, which is a high-speed serial computer expansion bus. Beware that a PXIe module may not support the top rates, even if the chassis backplane does, and vice versa.

Hybrid slots vs non-hybrid slots

Within a PXI chassis, you’ll only find slots that are only compatible with PXI modules. Within PXIe chassis, there can be PXI slots, PXIe slots, and hybrid slots. Hybrid slots support both PXI & PXIe modules. Make sure you have enough hybrid slots for your module application needs in case you may need additional modules, since the NI module you need may be designed only for PXI. Check out this image from NI illustrating how various module connectors interface with a PXI Hybrid Slot: https://ni.scene7.com/is/image/ni/image503115946004604475?scl=1.

Modules

There isn’t a ton of new capability to talk about in the realm of modules for PXIe vs PXI, other than within the high-speed realm, so think RF, high-speed serial, and FlexRIO sorts of modules. It’s more about the natural evolution of electronics, with a focus on higher bandwidth.

Obsolescence

As of the time of this writing, you can buy both NI PXI and NI PXIe-based hardware. However, PXIe is the natural evolution of PXI, so over time it’ll likely dominate new hardware offerings. All other things being equal (e.g., price, performance), we’d generally lean toward using a PXIe.

Software porting

From a software perspective, going from PXI to PXIe is generally not going to be a huge deal. If you are porting an existing application over to a PXIe chassis with or without PXIe modules, the biggest concern you’ll have is your MAX configuration and/or addressing the HW from within your application. If you want to make use of the higher bandwidth of the PXIe chassis and modules you’ll most likely need to alter your application to do so. Keep in mind that migrating to the PXIe-based FPGA RIO modules will most likely require a re-compile.

Finding the cheapest configuration

If you’ve got a pretty basic application, and you’re super cost-constrained, you may find that a PXI-based configuration has a lower purchase price than a similar PXIe-based configuration. However, be sure to think about your lifecycle needs and check with NI on module lifecycle support timeframes.

Other useful context-setting tidbits

So, how likely is it that you’ll need to migrate from PXI to PXIe if you’ve currently got PXI-based hardware? If your application functions and you are not concerned about upcoming end-of-life for your PXI chassis and PXI modules, then there’s no need to migrate. But if you need to add new functionality or are concerned about obsolescence, than, from our experience, it’s on the order of a 50/50 shot. It really comes down to the modules you need, if they’re available in PXI vs PXIe configurations, and the lifecycle of PXI modules you have or might want to purchase. Many of the higher-end FPGA cards and RF products are only PXIe.

If you’re deep into learning mode, check out these resources:

• How to deal with LabVIEW Spaghetti Code
• Which NI Platform is Right for My Automated Test Needs? cRIO, PXI, cDAQ, sbRIO?
• 9 Considerations Before you Outsource your Custom Test Equipment Development
• 5 Keys to Upgrading Obsolete Manufacturing Test Systems
• An Argument against the Universal Test System
• How to Diagnose Failing Custom Test Equipment