Description

Hard-Numbers: Technical Specifications

Processor: Three (3) x Intel 80486DX4 @ 96 MHz per processor
Architecture: Triple Modular Redundancy (TMR) – 3-vote 2-out-of-3
User Program Memory: 240 KB per processor (720 KB total)
Register Memory: 240 KB per processor (720 KB total)
Floating Point: Supported (32-bit hardware per processor)
Discrete I/O: 2048 points max combined (%I + %Q)
Analog Input: 128 words (%AI) per processor (up to 8K with option modules)
Analog Output: 64 words (%AQ) per processor (up to 8K with option modules)
Ethernet Port: 1 x RJ-45 10/100 Mbps auto-sensing (TMR-coordinated)
Ethernet Protocols: SRTP, Modbus TCP, EGD
Serial Ports: 2 x SNP/X (master/slave)
Baud Rate: Up to 115.2 Kbaud
Internal Coils (%M): 1024 bits per processor
Timers/Counters: 340 combined per processor
Scan Rate: 0.22 ms per 1K Boolean logic per processor (typical)
Voting Cycle: 50-100 microseconds (processor synchronization and compare)
Power Draw: 3.2 A @ +5 VDC (all three processors active)
Operating Temperature: 0°C to 60°C (32°F to 140°F)
Module Type: Modular (plugs into CPU slot)
SIL Rating: SIL 3 capable (per IEC 61508)
IC693CPU372

The Real-World Problem It Solves

Your safety-critical application outgrew the 80K memory of the CPU364, and you’re hitting memory limits with complex interlocking logic, extensive alarm handling, and integrated process control functions. This TMR CPU delivers 240K of user program memory per processor—three times the capacity of the CPU364—so you can run large, complex safety programs without sacrificing redundancy. You get the same 2-out-of-3 voting and SIL 3 capability, but with enough memory to handle sophisticated safety systems that would choke smaller CPUs.

Where you’ll typically find it:

Complex ESD Systems: Large offshore platforms or refineries with extensive emergency shutdown logic involving multiple process units, hundreds of interlocks, and complex cause-and-effect matrices
Integrated Safety and Process Control: Applications combining SIS functions with process control logic in a single TMR platform—turbine generator control with overspeed protection, boiler control with safety interlocks
Multi-Loop Safety Systems: Chemical plants requiring simultaneous control of multiple reactor loops with independent safety logic for each, all running in a single TMR CPU

Bottom line: It’s the big-memory variant of the Series 90-30 TMR CPU—same redundancy and voting architecture as the 364, but with three times the program capacity for complex safety applications.

Hardware Architecture & Under-the-Hood Logic

The IC693CPU372 extends the CPU364 TMR architecture with expanded program memory. Each of the three processors has 240KB of user program memory and 240KB of register memory—triple the 80K capacity of the CPU364. The voting circuit, synchronization logic, and backplane interface operate identically to the CPU364, but the larger memory footprint enables more complex ladder logic, extensive structured text routines, and larger data tables. The physical form factor matches the CPU364, so it plugs into the same CPU slot and uses the same TMR backplane requirements.

Power-up Sequence: All three 80486DX4 processors boot simultaneously and load identical ladder logic from their 240KB program memories. The voting circuit waits for all three processors to complete program load and report ready status before initiating synchronization.
Memory Architecture: Each processor has independent 240KB program memory and 240KB register memory. The three memory banks are not shared—each processor operates on its own copy of the program and data. The voting circuit compares results, not memory contents.
Parallel Execution with Large Programs: All three processors execute identical complex programs from their 240KB memories simultaneously. The scan rate remains 0.22 ms per 1K Boolean logic—the larger program size doesn’t slow execution, but total scan time increases proportionally to program size.
Voting on Extended Memory Operations: When processors write to registers or internal coils, the voting circuit compares all three outputs. Larger register memory (240KB per processor) means more data points to vote, but the voting mechanism operates identically regardless of memory size.
Output Voting and Backplane Drive: After each scan, the voting circuit compares outputs from all three processors on every discrete point, register write, and analog value. The 2-out-of-3 majority drives the physical outputs to the backplane. The larger program size doesn’t affect output voting speed.
Failure Masking with Complex Programs: If Processor A disagrees with Processors B and C at any point in a complex program, the voting circuit flags A as faulty and ignores its outputs. The system continues with B and C. The larger program doesn’t change failure handling behavior—single faults are still masked.
Ethernet Coordination: The integrated 10/100 Mbps port presents a single IP address to the network. All three processors send identical data, and the compare circuit ensures one coherent data stream reaches the network. Larger memory doesn’t affect Ethernet operation.
Dual-Failure Safe State: If two processors fail in a complex program, the voting circuit can no longer establish a majority. The CPU drives outputs to predefined safe state per configuration. The larger program doesn’t change safe-state behavior—safety is determined by configuration, not program size.

IC693CPU372

Field Service Pitfalls: What Rookies Get Wrong

Assuming memory upgrade fixes scan time issues

You upgrade from CPU364 to CPU372 because your scan time is too long. The larger memory doesn’t help—you still have the same 0.22 ms/K execution speed, and your program is now even bigger. Scan time increases, not decreases.

Field Rule: CPU372 has the same execution speed as CPU364—0.22 ms per 1K logic. More memory means you can write larger programs, not faster programs. If scan time is your problem, optimize your logic or move to a faster platform (Series 90-70 or Rx7i). Don’t upgrade to CPU372 expecting better performance—you’re getting more capacity, not more speed.

Underestimating scan time impact of large programs

You load a 200K program into each processor of your CPU372. Total scan time is now 44 ms per scan, exceeding your I/O update requirements and causing control loop instability. The larger memory let you write a bigger program, but now your control is slow.

Field Rule: Calculate scan time before loading large programs. At 0.22 ms per 1K logic, a 200K program scans in approximately 44 ms. Factor in voting overhead (50-100 microseconds) and I/O update time. Ensure total scan time meets your process control requirements. Use program segmentation, subroutine calls, and efficient coding practices to minimize scan time. Large programs require careful scan time management.

Mixing CPU364 and CPU372 in TMR set

You replace one failed CPU372 with a CPU364 because that’s what you have in spares. The TMR system faults immediately because the processors have different memory sizes and cannot load the same program. The voting circuit fails before synchronization even starts.

Field Rule: Never mix CPU models in a TMR set. All three processors must be identical models—all CPU364 or all CPU372. Different models have different memory sizes and cannot load the same program. Maintain separate spares inventories for CPU364 and CPU372. If you must upgrade, replace all three modules simultaneously during a planned outage.

Neglecting memory initialization during replacement

You replace a failed CPU372 with a spare module that has different program content loaded. The TMR system faults because the processors are executing different programs. The voting circuit detects mismatched outputs immediately.

Field Rule: Ensure replacement CPU372 modules have the exact same program loaded as the remaining two processors. Load the same project file to all three modules before installation. Verify program checksums match across all processors using programming software. Never assume a spare has the correct program—load and verify before applying power.

Overlooking power supply requirements with larger programs

You install a CPU372 in a rack with IC693PWR330 and assume you’re good. Your large program causes heavy register memory usage, increasing current draw beyond the 5A capacity. The rack faults randomly under heavy processing loads.

Field Rule: CPU372 draws 3.2A minimum at +5VDC—the same as CPU364. However, large programs with heavy memory operations can increase current draw. Calculate total current including CPU, all I/O modules, and option modules. Derate for ambient temperature above 40°C. Consider dual power supplies for heavily loaded racks. Don’t assume power capacity just because the CPU model is the same base type—program complexity affects power draw.

Forgetting that TMR doesn’t fix bad code

You write sloppy, inefficient code because “we have 240K memory, we’re fine.” The program is bloated, scan time is excessive, and you still have race conditions and logic errors. TMR voting won’t mask logic bugs—all three processors execute the same bad code.

Field Rule: TMR protects against hardware failures, not software bugs. All three processors execute identical code, so logic errors affect all three equally. Write efficient, well-structured code regardless of memory capacity. Follow good programming practices—use subroutines, avoid unnecessary coils, minimize register usage. Large memory is not an excuse for sloppy programming. Your code quality determines system reliability, not just hardware redundancy.

Commercial Availability & Pricing Note

Please note: The listed price is for reference only and is not binding. Final pricing and terms are subject to negotiation based on current market conditions and availability.