Troubleshooting ABB Automatic Module Loading Restarts

The replacement takes effect reliably when the controller performs Reset RAPID or when application logic explicitly unloads and reloads the module. A standard warm restart is not a dependable deployment trigger for this configuration: the observed controller retained the existing program module even though a revised file was present in HOME and the restart produced no errors.

Module state and restart timing

The number that matters is the point at which the controller rebuilds the RAPID task, not the number of controller boots. The file in HOME and the module already loaded into the task are separate states. Replacing the file changes storage; it does not, by itself, replace the executable module held by the task.

A warm restart can preserve the loaded task image. If the startup sequence does not reprocess the automatic-module entry, the task resumes with the old module even though the file has a newer timestamp or different contents. This is state retention, not a file-transfer failure. Reset RAPID, also identified as P-Start, rebuilds the RAPID state and processes the configured module, which explains why the revised file appears after that operation. Restoring a backup also reconstructs controller state and produced the same loading result in the reported setup.

Changing the automatic-loading parameter itself can trigger processing of that configuration. Ordinary boots need not repeat the load. That distinction prevents an automatic module from unexpectedly replacing task contents every time controller power cycles.

Deployment-method comparison

Use the automatic entry when a Reset RAPID is an acceptable part of deployment. For batch updates that must activate after a restart without a full RAPID reset, use explicit dynamic loading and call it from the required startup event. That method makes the replacement operation visible and testable.

Decisive diagnostic checks

1. Confirm that the module is listed under the Automatic Loading of Modules configuration type and under CAB_TASK_MODULES in SYS.cfg.
2. Confirm that the configured path and filename match the revised file in HOME. Treat path, filename, and module identity as separate checks.
3. Put a harmless, observable revision marker in the test module. A file timestamp alone proves only that storage changed.
4. Perform one standard warm restart, then read the error log before making another change. Record both loading errors and the loaded revision marker.
5. If the old marker remains, perform Reset RAPID. A new marker after the reset isolates the problem to the restart/loading trigger rather than file transfer or module syntax.
6. If the new marker still does not appear, inspect the configured path, module compatibility, and load errors before testing dynamic loading.

Automatic-loading procedure

For a deployment where RAPID reinitialization is acceptable, place the revised program module at the exact configured location in HOME. Confirm that the target task is the intended semistatic task and that its automatic-module entry identifies the same file.

1. Stop production activity through the site’s established operating procedure.
2. Transfer the revised module to the configured HOME path.
3. Read back the stored file or compare its controlled revision marker to verify the transfer.
4. Execute Reset RAPID (P-Start).
5. Read the error log and verify the marker in the loaded task.
6. Run the affected routines through their normal functional checks before returning the task to production.

This method deliberately ties activation to RAPID reconstruction. A warm restart should not be substituted merely because it is less disruptive; the installation test showed that it left the prior module loaded without producing an error.

Dynamic-loading procedure

Where retaining the rest of the application state matters, keep a standard module unchanged and let it replace the updateable module explicitly. The demonstrated sequence uses a persistent request, unloads the old file, starts a dynamic load, waits for completion, records success, and clears the request.

PERS bool bReqNewModLoad;
CONST string sFolderPath:="HOME:/T_PLC/";

IF bReqNewModLoad THEN
    ! IDelete Trap initialized in DynamicLoad.mod
    ! This proc must exists in DynamicLoad.mod
    %"DynResetTrap"%;
    UnLoad sFolderPath+"DynamicLoad.mod";
    StartLoad\Dynamic,sFolderPath+"DynamicLoad.mod",lsDynLoad;
    WaitLoad lsDynLoad;
    ErrWrite\I,"Dynamic Loading OK",
        "DynamicLoad.mod was loaded successfully.";
    bReqNewModLoad:=FALSE;
ENDIF

The callable procedure DynResetTrap must exist in DynamicLoad.mod for this specific sequence. The example also handles ERR_UNKINO and ERR_UNLOAD with SkipWarn and TRYNEXT. Retain that handling only after confirming that those conditions are acceptable for the application; suppressing an unexpected unload condition can hide an incomplete deployment.

Run the loader from a Power On event routine when restart-driven activation is required. Gate it with bReqNewModLoad so every boot does not replace the module unintentionally.

Verification and recurring pitfalls

A successful restart is not proof of a successful module update. Verify the loaded revision independently, because the controller can report no restart error while continuing to execute the old task image.

1. Confirm that WaitLoad finished before any routine calls code from the replacement module.
2. Confirm the Dynamic Loading OK entry only after the load completes.
3. Read the revision marker from the active task, then exercise one changed behavior under controlled conditions.
4. Restart once more with bReqNewModLoad cleared and verify that the loader does not repeat unexpectedly.

Common failures include updating the correct filename in the wrong directory, confusing stored file contents with loaded task contents, treating an empty error log as proof of replacement, and placing the loading routine inside the module being unloaded. Keep the loader in an unchanged module so its execution path survives the replacement.

FAQ