Quadlog CCM+ Controller Node Address Reset After Firmware 4.5.4 Update

The Siemens APACS Quadlog CCM+ (Control and Communications Module) is a process controller deployed in legacy DCS (Distributed Control System) architectures across refineries, chemical plants, and power generation facilities. After upgrading a CCM+ controller to firmware version 4.5.4 through the standard 4Mation export/import operation, engineers frequently encounter a node address assignment that drifts from the original configuration—most commonly, a controller originally provisioned as node 0 reappears on the system module tree as node 12. This article documents the root cause, the hardware hierarchy that governs node assignment on the local Module Bus (mbus), and the verified field procedures for restoring the original node address without losing the running configuration.

Problem Description

A CCM+ controller originally configured as Node 0, Rack 9, Slot 1 is upgraded to firmware 4.5.4 using the 4Mation export/import sequence. The 4Mation tool extracts the controller's configuration database, signs it, and re-imports it after the firmware image is replaced. After re-initialization, the controller comes up on the module tree as Node 12 instead of the expected Node 0. All process control functions continue to operate correctly—the scan, I/O updates, and control strategies resume without alarm—but the node address stored in the controller's startup identity is now 12, blocking any future configuration download that references the original N0R9S1 path.

The problem is not firmware corruption and it is not a 4.5.4 defect. The CCM+ controller always derives its runtime node address from external sources on the local mbus. The firmware update changes the in-rack slot addressing logic, which forces the controller to re-poll the bus for its identity. Any source on the bus with a higher node number can win the arbitration at the moment the controller completes its re-initialization cycle. In the field case described here, the controller was upgraded from a 4Mation workstation whose MBI card was set to node 12. The controller adopted that claim, and the address has been sticky ever since.

Root Cause: Node Claim Arbitration on the Local mbus

The CCM+ controller does not carry a hard-coded node address in its firmware or its NVRAM-resident configuration. At power-on, or after a re-initialization triggered by a firmware import, the controller scans the local mbus for the first valid "node claim" packet. The first claim packet it receives is the address it adopts for the remainder of its run-time. This is by design—the architecture was built to allow hot-swap replacement of any controller without manual addressing on the controller itself.

Three classes of devices can transmit a node claim on the local mbus:

• MBX module (Module Bus eXtender): A dedicated module with a hardware node switch behind the front bezel. When present and active, every controller on the same local mbus segment will adopt the MBX's switch setting as its node address. This is the dominant addressing source in installations that have an MBX in the rack.
• PC MBI card (Module Bus Interface): Any PC equipped with an MBI card on the local mbus can transmit a node claim. The NRS (Node/Rack/Slot) address of the MBI card is set in the APACS Control Panel applet. If the MBI is set to node 12, the controller will boot as node 12—even if an MBX is present with switch set to 0—provided the MBX is not actively transmitting a claim.
• Controller transition board: Every CCM+ controller carries a small transition board (sometimes called the "xtion bd" in field documentation) with a 4-position DIP switch. This switch does not set the node directly; it adds or subtracts from the base node address being claimed, depending on whether the base is even or odd.

In a typical site, the controller is being told to come up as node 12 because the PC that performed the 4Mation export/import has its MBI card NRS address set to node 12. The 4Mation PC is a normal workstation on the mbus; when it is on-line during a controller re-initialization, its MBI card is actively transmitting node claims. The first claim the controller hears is the PC's, not the MBX's. The controller boots as node 12 and stays there until it is power-cycled or reset with cleared NVRAM.

Node Address Source Hierarchy

When multiple node-claim sources are present on the same local mbus segment, the arbitration order is fixed by the bus protocol, not by the physical location of the device. The hierarchy is:

If the MBX is present and its switch is set to 0, the controller should boot as 0. The reason it does not is that the MBX is typically powered off, faulted, or absent on a rack where engineers perform firmware updates from a standalone 4Mation PC. In that case, the PC's MBI is the only valid claim source, and the PC's NRS address wins. The controller caches the first valid claim it sees and refuses to re-arbitrate for the rest of its run-time.

Hardware Components: MBX, MBI, and Transition Board

The following hardware components participate in node assignment and must be inventoried before any reset procedure is started:

Note that the APACS architecture gives the user no direct control over which PC's claim a given controller will adopt. Any MBI-equipped PC on the local mbus can become the authoritative source if it is the first to transmit a claim. The only mitigation is to ensure every PC on the segment is set to the same node, so the controller sees a consistent claim regardless of which workstation is on-line.

Pre-Procedure Verification and Safety

Before changing any hardware switch or APACS setting, confirm the following with the process operations team and the plant network administrator:

1. Identify every PC on the local mbus. Each one with an MBI card is a potential node-claim source. Document the PC name, IP address, and physical location of every MBI-equipped workstation.
2. Verify the current NRS address on every MBI-equipped PC using the procedure in Section 6. A PC that is not in the "live" PC list can still claim a node if it is left powered on the engineering network.
3. Locate the MBX module in the controller rack, if present. Open the front bezel and read the node switch position. Note it for the verification step. Confirm the MBX is powered and the ACTIVE LED is solid green.
4. Pull the most recent online configuration backup of the affected controller. The configuration is stored in 4Mation's project directory and should be archived to a network share before any node reset work begins.
5. Schedule a controller outage of 10-15 minutes per controller. The controller must be powered down, the battery-backed NVRAM cleared, and the module re-seated for the new address to take effect.
6. Coordinate with operations for a controlled shutdown of the affected control loop, or transfer control to a backup controller if the architecture supports it, before pulling the battery.

Procedure A: MBI Card NRS Address Reset (PC Side)

The most common cause of the "stuck at node 12" symptom is the engineering PC's MBI card. Changing the NRS address from the APACS Control Panel applet is straightforward in theory, but the APACS software holds a persistent handle to the MBI driver, and any attempt to change the NRS while the driver is active will hang the workstation. The verified workaround uses the Windows Device Manager to disable the MBI adapter before reconfiguration.

Step-by-Step: MBI Card NRS Address Reset

1. Close 4Mation and any APACS client applications. Open the Windows Control Panel → APACS applet only to confirm the current NRS value before proceeding. Do not attempt to change the value from this applet—the driver is still active and the workstation will hang.
2. Open the Device Manager:
   • Right-click My Computer → Manage → Device Manager.
3. Expand the Network Adapters node.
4. Locate the MBI Card Adapter entry. Right-click and select Disable. Confirm the disable action if prompted. A brief network-down notification may appear; this is expected.
5. Double-click the MBI adapter to open its properties.
6. Navigate to the APACS / NRS address tab (typically labeled Advanced or MBI Settings).
7. Change the NRS Address to the desired value (in our case, 0). Click Apply. The new value will be written to the MBI card's on-board NVRAM.
8. Right-click the MBI adapter and select Enable. The adapter will re-initialize with the new NRS value.
9. Verify the change by double-clicking the MBI adapter, opening Advanced, and reading the NRS values. The new node value should be displayed in the diagnostic pane and should match the value you applied in step 7.
10. Reboot the PC. The APACS driver only commits the NRS change on a clean boot; a warm reboot is not sufficient.

Engineers who have attempted the NRS change directly from the Control Panel applet without disabling the adapter first have reported hard hangs that required a power-cycle. The Device Manager sequence is the only verified method for an in-service change. If the workstation does hang during an attempted change, do not force a power-cycle while APACS is still running—this can corrupt the MBI card's on-board NVRAM. Shut down cleanly via the power button, allow 60 seconds for the card to discharge, and re-apply the change via Device Manager on the next boot.

Procedure B: MBX Module Node Switch Configuration

If the rack contains an MBX module, it is the highest-priority node source. Confirm the rotary switch behind the front bezel is set to the desired node (in our case, position 0). The MBX is a passive claim source—it transmits the switch value continuously as long as it is powered and on the local mbus. A faulty or unpowered MBX is invisible to the controllers and is treated as absent.

1. Power down the controller rack using the ModuleRac power sequencer. Confirm the rack is in a safe state for power-down before proceeding.
2. Open the MBX front bezel by releasing the two captive screws at the top and bottom of the bezel.
3. Locate the rotary switch labeled NODE or ADDR. It is a 16-position rotary switch, positions 0-F (hex), with 0-F mapping to nodes 0-15.
4. Set the switch to position 0 using a small flat-blade screwdriver. Do not force the switch past the stops at 0 and F. The detent should click into each position.
5. Close the bezel and re-apply rack power.
6. After the rack re-initializes, observe the module tree in 4Mation. The controllers should appear under the new node address.

MBX switch settings used in typical installations follow the pattern below:

Procedure C: Transition Board DIP Switch Settings

Every CCM+ controller has a small transition board (sometimes called the "xtion bd" in field documentation) that carries a 4-position DIP switch. The DIP switch is not a direct node selector. It applies an offset to the base node address being claimed on the bus. The offset polarity depends on whether the base address is even or odd:

If your controller is set to a base of 0 and the switch is left at the factory default (all OFF), the effective address is 0. If a previous engineer set the switch to ON/OFF/OFF/OFF, the effective address becomes 0 - 1 = -1, which is invalid; the controller will refuse to boot on the bus. The recommended setting for a node-0 controller is all switches OFF. Refer to the transition board hardware manual (the part number is silkscreened on the board itself) for the exact switch map, as it varies by CCM+ hardware revision.

Procedure D: Controller Battery Reset (Full NVRAM Clear)

If the MBI NRS has been corrected to 0, the MBX switch is set to 0, and the transition board is at all-OFF, but the controller still boots as node 12, the controller's NVRAM-resident address table has been corrupted by a partial write during the re-initialization. The only way to clear the residual is to remove the controller from the rack, pull the battery, and force a full memory loss.

1. Confirm the configuration is backed up in 4Mation. Verify the backup file is not zero-length and opens cleanly in the 4Mation project editor.
2. Put the controller in Stop mode from 4Mation. Wait for the STOP LED to illuminate solid. Do not proceed until STOP is solid; a flashing STOP indicates the controller is mid-shutdown and will not respond to a seat-removal command.
3. Power down the controller slot using the ModuleRac or by removing the controller from the rack on its hot-swap rails. Wait 30 seconds for bulk capacitors to discharge.
4. Locate the lithium battery on the controller carrier. It is typically a 3.6V primary lithium cell in a clip holder. The battery is hot-swappable but here we are removing it to clear NVRAM.
5. Pull the battery clip. Wait a minimum of 60 seconds for the NVRAM supervisor to time out and lose hold-up. Some legacy modules require up to 5 minutes for a full RAM discharge, especially in cold environments where the lithium cell holds higher residual voltage.
6. Re-insert the battery. Confirm polarity against the silkscreen + and - markers. Reversed polarity will permanently damage the NVRAM supervisor IC within seconds.
7. Re-seat the controller into the slot. Power up the rack.
8. Observe the module tree in 4Mation. The controller should now appear at node 0, in the unconfigured state (no application loaded, waiting for download).
9. Download the offline configuration from 4Mation to the controller at the new (correct) node address. Confirm the download completes without error and the controller transitions from STOP to CONFIGURE to RUN.
10. Verify the controller enters Run mode and resumes scan. Check the first few I/O points manually to confirm the configuration is healthy.

LED Diagnostics and Module Tree Verification

The CCM+ controller faceplate has a set of status LEDs that provide a real-time view of the node-claim arbitration process. Use these to confirm the controller has received a valid claim before pulling the battery:

A controller that has its NODE LED solid green but reports the wrong node address in 4Mation is the classic "stuck at node 12" symptom. The NODE LED confirms a valid claim was received, but the bus arbitration logic has already committed the wrong address to NVRAM. This is the indicator that a battery pull is required to force a fresh arbitration cycle.

After completing Procedures A through D, verify the fix end-to-end:

1. Open 4Mation and connect to the controller's new NRS path. The path should be the original (e.g., N0R9S1).
2. Confirm the controller responds to a status poll. The diagnostic pane should show firmware 4.5.4 and the correct slot/rack.
3. Cross-check the module tree: the controller should appear once, at the original node/rack/slot, and not appear at node 12.
4. Force a controller restart (Stop → Configure → Run) and re-verify the node address after the restart. This proves the new address is sticky across re-initialization.
5. Run an I/O loopback test on two analog and two digital points to confirm the configuration downloaded correctly after the battery reset.
6. Monitor the controller for 24 hours with the diagnostic log enabled. Watch for any node-claim collision errors or re-initialization events.
7. Confirm all operator stations can see the controller at the correct NRS path. A misconfigured path on an operator station can mask a successful fix on the engineering side.

Multiple PC Best Practice and Field Troubleshooting Matrix

Installations with more than one 4Mation PC on the same local mbus are particularly susceptible to node-drift issues. The recommended configuration is to assign all PCs the same node address and space their rack addresses by two. This prevents two PCs from being in adjacent rack slots, which can cause the bus to interpret the dual presence as a node collision.

This pattern keeps every PC at node 0 (the standard engineering node) and uses the rack field of the NRS path to distinguish them. A controller on the bus sees a consistent node-0 claim from every PC and is never confused by a higher-numbered node appearing mid-cycle. The rack-spacing rule (PCs separated by two rack numbers) is specific to APACS mbus behavior and is documented in the Siemens technical support write-up that covers transition board switch settings.

The following matrix maps observed symptoms to their root causes and the corrective action that has been verified in the field. Use this as a quick lookup during a recovery:

Frequently Asked Questions