Micro820 Modbus Address: Use RMCC, Not a Code Edit

After the change works, the operator can select the Micro820 Modbus-RTU unit address from an HMI or physical input jumpers without opening the application project. Use Run Mode Configuration Change (RMCC) through a correctly configured MSG_CIPGENERIC instruction; an online code edit is not the required mechanism. Keep the selectable values constrained, control when the message executes, and verify both communications and retention after the write.

Read the panel symptoms first

The HMI usually shows a new requested address while the Modbus master continues polling the old address or reports the slave as unavailable. Start here: decide whether the displayed value is only an operator request or the controller's active communications setting.

Check the generic-message completion and error indications before editing serial wiring, baud settings, parity, or the master configuration. If communications worked at the old address, replacing hardware and retuning unrelated serial settings waste time.

Understand what RMCC changes

A Modbus-RTU slave address is part of the communications configuration, not merely a normal application variable. Writing a new number into an HMI-linked tag therefore does nothing by itself. The program must validate the request and pass it to the controller's run-mode configuration interface.

RMCC means Run Mode Configuration Change. For this application, MSG_CIPGENERIC provides the programmatic path used to apply the selected Modbus unit address while the controller remains in run mode. The same approach was also used to set the Ethernet IP address, but treat that as a separate configuration transaction with its own documented destination and validation.

The exact generic-message service and destination fields are controller-specific. Copy them from the RMCC instructions on pages 23-26 of the Micro820 Programmable Controllers User Manual. Do not substitute guessed class, instance, attribute, or service values; an incorrect destination can fail or affect a different configuration item.

The address change also moves the endpoint from the master's perspective. Once the write takes effect, requests sent to the old unit address should stop receiving the Micro820 response. The master must then poll the new address using the same compatible serial framing settings.

Build a controlled operator request

Separate the operator's request from the active configuration. This prevents a touchscreen edit or bouncing jumper input from launching configuration messages continuously.

• Provide one requested-address value from the HMI, or map approved jumper combinations to approved addresses.
• Validate the request against the address rules used by the installed Modbus network and reject any value already assigned to another slave.
• Require an Apply command or a stable input transition. Do not trigger the write on every scan.
• Block a second request while MSG_CIPGENERIC is busy.
• Expose pending, busy, complete, and failed states to the HMI. A changed entry field is not a completion indication.
• Record the last accepted request and the message error result for troubleshooting.

If both an HMI and input jumpers can select the address, define priority explicitly. A practical pattern is to let the jumpers establish the requested value and require a separate Apply action. Another is to select one source by operating mode. Never allow two sources to overwrite the request asynchronously.

Configure and execute the RMCC write

1. Open the RMCC section on pages 23-26 of the Micro820 user manual and identify the documented configuration item for the Modbus-RTU unit address.
2. Configure MSG_CIPGENERIC with the documented service and destination data. Preserve the data type and length shown for that configuration item.
3. Create a requested-address tag that the HMI or jumper-decoding logic can write. Keep it separate from message control and status data.
4. Compare the request with the permitted local range and the site's slave-address allocation. If it fails either check, inhibit the message and display a validation fault.
5. On a one-shot Apply event, copy the validated request into the message source and trigger MSG_CIPGENERIC.
6. Hold off further Apply events until the instruction reports completion or error. Do not retrigger a configuration write merely because the HMI button remains pressed.
7. On completion, update the displayed active-address status through a readback path or a communications test. On error, retain the requested value separately and display the message diagnostic rather than claiming that the address changed.
8. Coordinate the master-side address update. Expect a temporary loss of polling while the slave moves from the old address to the new one.

Test this logic first with only one operator interface enabled. Add the second source after message triggering, interlocks, and readback work correctly.

Verify the active address and recovery

1. Confirm that the message reaches its completed state without an error indication.
2. Stop polling the old address and poll the requested address from the Modbus master.
3. Read known Micro820 data at the new address. A reply alone is insufficient if another slave could already own that address.
4. Poll the old address and confirm that the Micro820 no longer answers there. Investigate any response before returning the network to service.
5. Repeat the change through each authorized input path: HMI selection and jumper selection.
6. Restart the controller under an approved test condition, then poll the selected address again. This establishes whether the changed value persists for the installed configuration.
7. Test rejection of an out-of-policy value, repeated Apply commands, and a second request while the message is busy.

Capture the generic-message error state before clearing or retrying it. That result separates a rejected configuration transaction from a Modbus polling problem that occurs after a successful address move.

Avoid the recurring failure modes

• Do not bind the HMI entry directly to message control data. Stage and validate the request.
• Do not interpret loss of the old slave as failure. Poll the new address first.
• Do not change unrelated serial settings when the network worked before the address command.
• Do not permit continuous execution of MSG_CIPGENERIC. Use a one-shot request and a busy interlock.
• Do not claim success from the HMI's entered value. Use instruction status plus an end-to-end Modbus read.
• Do not reuse a unit address already present on the bus. Duplicate slaves can produce collisions or responses that appear to come from the wrong device.
• Do not assume restart retention. Prove it with a controlled restart test.
• Do not reuse the Modbus message configuration for the Ethernet IP setting. Each runtime configuration item requires its documented message definition.

FAQ