ABB IMRIO02 | INFI 90 Remote I/O Slave Module

Description

• Brand: ABB / Bailey
• Full Model Number: IMRIO02
• System/Series Family: Bailey INFI 90 / Net 90 DCS
• Core Function: Remote I/O communication between the Multi-Function Processor and remotely located I/O slave modules
• Top 3 Hardcore Specs: 1 Mbps communication; up to 10,000 ft / 3,000 m link distance; coaxial, twinaxial, or fiber-optic communication
• Module Type: Remote I/O Slave Module
• Local Role: Master processor when installed with the Multi-Function Processor
• Remote Role: Slave processor at remote I/O location
• Redundancy: Supports redundant Remote I/O hardware configurations
• Stock Status: New Surplus / Fully Tested Refurbished — verify firmware revision and exact condition before shipment

ABB documentation identifies the IMRIO02 as the Remote I/O Module used with Bailey Multi-Function Processors, providing communication with remotely located slave modules at 1 Mbps and supporting link distances up to 10,000 ft (3,000 m) depending on cable type. The module can use coaxial, twinaxial, or fiber-optic communication and supports redundant hardware configurations.

Module 3: Commercial-Technical Deep Dive

Remote I/O faults on an INFI 90 system can affect field signals several thousand feet from the controller, making a communication problem look like scattered I/O failures. The ABB IMRIO02 is the Remote I/O Module used in the Bailey INFI 90 architecture to connect a Multi-Function Processor with remote slave modules. The technical manual specifies a 1 Mbps remote link and a maximum distance of 10,000 ft (3,000 m), subject to cable type and installation conditions. Depending on location, an IMRIO02 can function as the master-side processor or as the remote slave-side processor.

The practical ROI comes from restoring the existing remote-I/O architecture without changing the entire DCS cabinet arrangement. A failed RIO module can interrupt communication with multiple remote slave modules, while a verified spare restores the established topology without rewriting the underlying plant control strategy. Redundant RIO hardware is also supported, which matters for installations designed around communications availability. One important limitation: ABB itself has documented firmware compatibility issues between IMRIO02 and some I/O modules, and its later IMRIO22 upgrade was introduced partly to address obsolescence, communications performance, and compatibility concerns. —Do not treat every IMRIO02 as interchangeable across firmware revisions without checking the installed system configuration.

ABB IMRIO02

Module 4: Compatibility & Installation Traps

Migration/Compatibility

For an existing Bailey INFI 90 installation specifying , the preferred approach is a like-for-like Remote I/O module replacement, provided the firmware version, module address, termination hardware, and communication medium match the existing configuration. The occupies one MMU slot, with front-panel DIP switches used for user options and module addressing.

This is not a programmable PLC CPU, so a conventional logic rewrite is not normally required. However, firmware compatibility is a real concern. ABB’s own remote-I/O upgrade documentation specifically identifies compatibility problems between firmware and some remote I/O modules. ABB subsequently introduced the IMRIO22 as a replacement path for the older RIO02 architecture.

⚠️ Field Traps (Watch Out)

• DIP-switch address mismatch: The uses front-panel switches to configure module options and addresses. Record every switch position before removing the failed unit; an incorrect node address can leave the replacement healthy but invisible to the controller.
• Communication-medium mismatch: The RIO architecture can use coaxial, twinaxial, or fiber-optic links, with distance dependent on the installed medium. Do not substitute or reterminate the cable system without checking the existing termination-unit configuration.
• Master/slave role confusion: The ‘s role depends on its location. The unit adjacent to the Multi-Function Controller functions as the master processor, while remote units operate as slaves. Installing a correctly numbered module in the wrong system position can therefore create a configuration fault rather than a hardware fault.

Module 5: Quality Assurance SOP

For surplus ABB Bailey INFI 90 remote-I/O inventory, the pre-shipment process should verify both the hardware and its communication configuration:

1. OEM anti-counterfeit visual inspection — verify ABB/Bailey identification, complete marking, PCB layout, front-panel labeling, connector arrangement, and evidence of unauthorized repair.
2. Part-number reconciliation — photograph the full identification and every visible secondary label or revision code.
3. PCB condition inspection — inspect the MMU connector, termination interface, DIP-switch assembly, LEDs, captive screws, solder joints, and PCB surface for corrosion, contamination, cracks, or mechanical damage.
4. Power-on self-test (POST) — install the module in an approved INFI 90 test environment and verify startup behavior and expected diagnostic/status indications.
5. DIP-switch verification — document the module address and option settings and compare them with the customer’s supplied configuration.
6. Remote-link verification — establish the appropriate test communication path and verify the expected 1 Mbps RIO link behavior.
7. Communication handshake verification — confirm successful exchange between the master-side RIO and representative remote I/O hardware.
8. Master/slave role verification — test the module in the intended local or remote configuration and verify that the system recognizes its assigned role.
9. Redundancy check — where the customer’s architecture uses redundant RIO hardware, verify primary/backup behavior and communication recovery according to the approved test procedure.
10. Firmware identification — record the installed firmware revision and compare it with the customer system requirement because ABB documentation notes firmware compatibility issues involving .
11. Final QC release — retain identification photographs, switch settings, firmware information, communication results, and packaging inspection records with the shipment file.

For this module, the strongest QA evidence is not a power-up photograph. It is a documented RIO communication test with the correct node configuration and firmware revision.

Module 6: CRO-Driven Buyer FAQ

1. What is ABB ?

The is a Bailey INFI 90 Remote I/O Module. It communicates between an IMMFP01/02/03 Multi-Function Processor and remotely located I/O slave modules. The documented communication rate is 1 Mbps, with a maximum link distance of 10,000 ft (3,000 m) depending on cable type.

2. Is obsolete?

It is a legacy INFI 90 component, and ABB has documented an IMRIO22 upgrade path intended to address RIO02 obsolescence, communications limitations, diagnostics, and firmware compatibility. The IMRIO22 was designed to replace the RIO02 in the remote cabinet while retaining the same general rack form factor.

3. Can I replace without changing the control logic?

A like-for-like hardware replacement generally does not imply a PLC-style logic rewrite. However, module addressing, firmware revision, termination hardware, and the master/slave role must match the existing INFI 90 configuration. A replacement should therefore be commissioned against the system configuration rather than installed solely by part number.

4. Can the be hot-swapped?

Do not assume hot-swap capability. The module occupies an MMU slot and forms part of the DCS remote-I/O communication path. Follow the site’s approved shutdown, isolation, and module-replacement procedure unless the applicable INFI 90 documentation explicitly authorizes energized replacement.

5. What warranty and technical support should I expect?

The quotation should clearly identify whether the unit is new surplus, unused, or tested refurbished, together with the warranty period. Technical support should cover exact-part identification, firmware-version verification, DIP-switch configuration, communication-medium compatibility, and available test records. DCS configuration changes, remote-link redesign, and plant commissioning should remain separate engineering activities.