NI Hardware Compatibility – Real-world Tips and Lessons Learned

This article summarizes some compatibility issues. If you want specific advice about your hardware selection, we’re here to help. We can help you wade through the sea of possibilities. We use our (sometimes hard-earned) experience to help identify combinations that work and those that don’t.

What are some common compatibility issues?

The issues we often run into fall into these categories:

• PXIe controller capabilities aren’t enough to handle the required data throughput
• PXIe chassis slot type quantities: hybrid vs PXIe
• cRIO controller capabilities are insufficient to handle data acquisition and/or analysis
• Hardware driver versions are not compatible with the OS version
• Hardware driver versions are not compatible with the LabVIEW version
• Signal voltage levels between digital I/O modules are not compatible
• PXIe and cDAQ modules don’t sample synchronously because TSN wasn’t considered

What do people tend to not worry about, but should?

Some more subtle issues that we consider when selecting hardware include:

1. heat generation,
2. accuracy,
3. life cycle,
4. and cabling.

Some examples from actual test systems we deployed are:

• The PXI chassis didn’t supply enough cooling capacity to remove the heat generated by all the modules in the PXI chassis, causing the modules to overheat.
• The accuracy of an analog input module was insufficient for the measurement requirements. Accuracy performance of a module is a combination of the inherent internal circuit gain and offset, plus the drift due to operating temperature. These can change over long time periods.
• Purchasing a perfectly good module that was about to go end-of-life, jeopardized the long-term utility of the overall test system if the module stops functioning.

Another pitfall to consider is cabling required for the hardware module. Some modules have cables which externally look completely similar, yet internally they are different. Common examples are modules which have the same connectors, e.g., a 68-pin high-density connector, but the version used with a multifunction module uses shielding around the AI and AO channels, whereas one used with a digital I/O module being all digital doesn’t have to distinguish between different types of channels, so the internal shielding is different.

Do I need to consider hardware-software compatibility?

Yes. The specific combination of the software and hardware components can cause issues. This situation is usually especially acute when versions of one or more of the following are upgraded:

• LabVIEW,
• a hardware driver,
• the OS.

For example, all the version transitions in Windows, from XP to 7 to 8 and so on to the latest version, have caused incompatibilities with software needed to control the data acquisition hardware.

Similar issues happen when LabVIEW is upgraded because NI drops support for older, but still purchasable, hardware.

NI hardware compatibility with non-NI hardware

Since PXI is a standard, other companies besides NI sell PXI hardware.

These non-NI devices come with their own hardware drivers, which may or may not work within NI’s Measurement and Automation Explorer (MAX) application.

Regardless of the tightness of integration with the NI ecosystem, these modules generally work….. except when they don’t.

We have less experience with PXI modules from other vendors than those from NI. However, in our experience, if the non-NI hardware doesn’t need to have time-critical functionality (e.g., a switch matrix from Pickering), the hardware almost always works.

Other non-NI hardware that doesn’t plug into a chassis bus is almost always compatible. These devices run off comms like Ethernet, USB, and even GPIB. The same statement about staying away from time-critical needs applies here too. For example, some of these devices work just fine for high-speed data collection and triggering, yet they don’t necessarily integrate their data streams quite so simply into, for example, a PXI backplane data stream.

What are some of the best ways to reduce compatibility risk?

It’s hard to make blanket 100% assurances because the requirements for any specific test system may bump into an edge case not covered in these recommendations.

Being aware of those situations takes years of experience building test systems.

That said, here are some recommendations to avoid compatibility issues:

• Stay within a hardware family (e.g., PXI, cRIO, cDAQ).
• Assure that the hardware drivers are compatible with the selected OS version.
• Confirm that the hardware drivers are compatible with the selected LabVIEW version.
• Check that the selected LabVIEW version supports the hardware.
• Avoid tight timing and synchronization requirements since compatibility issues generally relax. Check for hardware end-of-life dates so your test system doesn’t go obsolete tomorrow. This verification applies to all hardware, not just NI hardware.

I’m designing a new system from scratch. What should I keep in mind?

For a new system, both compatibility and capability are important considerations.

The previous section lists some recommendations to reduce compatibility problems, many of which can easily be managed by proper selection of all new components.

For the capability considerations, most of the decisions will be based around which hardware family will best satisfy your needs in a cost-effective manner.

For example, a test system needing 1000s of channels or extremely fast data rates is best managed with PXI.

Or, a test system needing a small physical size might be best handled with a cDAQ or even a cRIO platform.

Check out Which NI platform is right for my automated test needs? cRIO, PXI, cDAQ?  for more detail.

Finally, don’t forget to consider future-proofing. If you think your test system will need some capability upgrades soon, it may be best to roll those into the test system now to avoid possible compatibility issues later.

I’m trying to add one new hardware component to an old test system. Can I avoid having to upgrade the entire thing?

If the new hardware is compatible, then you can proceed without issue. So, the situation worth discussing is when the new hardware is not compatible with the old test system.

There are two main approaches to attacking this problem:

1. See if another hardware product can be purchased that offers the functionality you need and is compatible with the existing test system. For example, perhaps another vendor offers a compatible product.
2. Consider whether the new functionality needs to physically reside in a chassis in the old test system. Usually, this need arises when tight timing and synchronization between various data acquisition devices is needed. Not every subsystem within the test system needs this type of tight connectivity. Or perhaps only timing is needed and the new external device can be triggered from the old system to start data acquisition at some precise time. And, if tight clocking is needed, look for hardware that can take an external clock signal created by the old system. For example, the old test system might be PXI-based and you’ll need to connect this equipment to some new PXIe hardware to add the needed functionality.

These two approaches solve a lot of problems with upgrading an old test system when compatibility issues arise and they usually occur when a test system has components that are starting to go obsolete, as we’ve seen many times.

I’m trying to update an old system. What should I keep in mind?

If you want to replace your old test system with entirely new components, you’ll have an easier time than a partial upgrade because you’ll have fewer incompatibilities to consider.

We’ve partially addressed this situation above, so let’s assume that by “update” you mean you want to keep as much of the old system as possible while aiming at some increased functionality or longer life cycle.

Both these motivations should include the same types of considerations:

• Bus / comms – The obvious choice for the replacement hardware has a different bus than the old hardware. This might happen because your old computer is based on say PXI, or PCI, or even ISA. If that’s the case, you’ll either need a new computer with subsequent review of all the existing modules for replacement or find a device that will work with external comms (like Ethernet).
• Drivers – The new drivers won’t work with your OS and LV versions.
• Pinouts / cabling – The pinouts on the new device are all different, so new cabling/harnessing is needed.
• Better hardware, different results – The new HW is so much better than the original HW that you are going to see unexpected results (see the Old vs New – How To Prepare For Differences section in 5 Keys to Upgrading Obsolete Manufacturing Test Systems)