Troubleshooting DirectSOFT PID Mode Changes on DL450

On the DL450 installation described here, five independent PID loops continued to accept direct mode-bit changes, but the DirectSOFT PID control interface would not hold a change from Automatic to Manual. Treat this first as a difference between the interface command path and the PLC’s mode-control path—not as proof that the PID loops or PLC program have failed.

Read the mode through both control paths

Start with a read-only comparison while the process is in a safe state. Record the mode shown by the DirectSOFT PID control interface, then inspect the relevant PID mode bits in the PLC without changing them. The reported addresses were Addr+00.Bit0 and Addr+00.Bit1; verify the correct address and bit assignment for each loop in the project before using them. Do not transfer one loop’s address assumptions to the other four.

Observation	What it tells you	Next check
Interface briefly shows Manual, blanks, then returns to Automatic	The mode request is not being retained or the display is not receiving a valid confirmation. The display behavior alone does not identify which.	Watch the PLC mode bits and loop status during one controlled interface request.
Direct bit change takes effect, but interface request does not	The PLC can respond to at least one manual mode-bit operation; the fault is narrowed to the interface command/readback path or how the request is processed.	Check the command target, communications, and loop-specific mapping.
Neither interface request nor direct bit change affects PLC status	The problem is not isolated to the interface. Investigate PLC execution, address selection, and loop configuration before changing software versions.	Confirm the selected PLC, program state, and actual loop status.
Interface reports Automatic but the PLC status indicates Manual	The display may be stale or its readback mapping may not match the loop being observed.	Confirm the interface is connected to the intended PLC and loop.

The critical measurement is the PLC’s actual mode indication during and after a request, not the momentary text in the interface. If the control-system display provides no trustworthy status indication, pause before relying on it for operation.

Check the CPU keyswitch before changing the project

Read the CPU keyswitch position locally. A question raised during this fault investigation was whether the switch had moved from Term to Run. The reported PLCs were already in Term, so changing the switch was not a demonstrated correction. Record its actual position rather than cycling it as a trial fix.

If the switch is not in the expected position, follow the site’s approved operating procedure and check the controller documentation for the effect of changing modes. Do not assume that a keyswitch change will repair a PID interface command. If the switch is already in Term, move to the interface and communications checks; repeating the same check adds no diagnostic value.

Verify DirectSOFT’s target and live communication

A mode selection that appears, pauses, blanks, and reverts can result when a command is rejected, times out, or is followed by a readback that still says Automatic. These are diagnostic possibilities, not a confirmed explanation for this installation. Establish whether DirectSOFT is communicating with the intended PLC and whether its live data view updates reliably before sending another mode request.

1. Confirm the project and online session identify the intended DL450.
2. Observe a known live status value for the affected loop and confirm it changes or refreshes as expected.
3. Check that the PID interface is associated with the correct loop and address, using the installed project’s configuration rather than assumed offsets.
4. Issue one controlled mode request and monitor the PLC-side mode bits and status immediately before, during, and after the request.
5. Record whether the PLC accepted a write, whether the mode changed, and whether the interface readback followed it.

If other live values stop updating or the target PLC is uncertain, stop mode testing until communications and target selection are corrected. If PLC-side status changes but the PID interface returns to Automatic, focus on its readback or loop mapping rather than rewriting the ladder program.

Use direct bit operation only as a controlled diagnostic

The reported operator could change Addr+00.Bit0 or Addr+00.Bit1 manually, while the DirectSOFT PID control interface failed. That observation is useful because it separates at least one PLC-side control path from the interface path. It does not, by itself, prove which bit means Manual or Automatic, whether the write was retained, or whether the process was safely controlled.

Before any direct write, verify the loop’s actual bit definitions and the machine’s operating state. Use a single-loop, approved test with the process owner’s authorization; observe the corresponding mode/status and process response. Avoid repeated bit forcing or simultaneous changes across the five loops. A manual bit write can bypass the interface’s normal checks or operator confirmation, so do not turn this diagnostic into an undocumented production procedure.

For the installation in question, direct bit manipulation was considered a last-resort operating method, not a preferred repair. If a controlled manual mode is needed to keep the equipment safe, use the plant’s authorized fallback procedure and document precisely which loop and verified control were used. Do not assume that forcing a bit is equivalent to a validated Manual command.

Compare DirectSOFT builds without expecting an automatic fix

The installed software was reported as DirectSOFT 4.0 Build 18. It was updated to Build 25, and the PID control problem persisted. Therefore, repeating that same update is not a supported next action for this particular symptom.

Capture the installed DirectSOFT version/build, the exact interface behavior, PLC-side mode/status observations, and whether direct bit changes still work. If the site uses a different build, verify compatibility and known behavior through official AutomationDirect support or product documentation before upgrading. Schedule any software change under site change control, preserve the current project and communications settings, and test on a safe loop or offline setup when available. Do not treat a software update as a substitute for checking the command target and readback.

Reload only after the live-state checks

Reloading the ladder program without clearing the PLC’s full memory and scratchpad was attempted, and it did not resolve the issue. A complete clear was proposed as a next step but was not reported as completed. The distinction matters: the partial reload does not establish that a full clear would fix the interface problem.

A memory clear can remove PLC data and configuration beyond the logic required for the immediate PID test. Do not clear the controller while connected equipment is operating or before the complete recovery image, program, configuration, and restart plan are verified. The reported operator could only consider this step when four connected engines were offline; use the actual site interlock and outage requirements, not that count, to decide when a clear is permissible.

Before any clear-and-reload operation, confirm an approved outage, a verified backup, the correct program and PID configuration, and a controlled restore plan. If those prerequisites are unavailable, stop; preserve the running controller and escalate rather than performing an irreversible test during production. After a restore, verify PLC execution and each PID loop’s mode/status before returning equipment to service.

Restore operation and verify each loop

Use the least disruptive resolving branch: correct the interface target or readback if PLC-side mode status responds; repair communications if live values are unreliable; investigate PLC-side execution and loop configuration if neither control path works. The evidence does not show that a full PLC clear restored this system, so do not make clearing memory the default remedy.

1. Place the process in the approved test condition and identify the loop being checked.
2. Record the loop’s current mode and status from PLC data and the DirectSOFT interface.
3. Request a mode change through the interface once, then verify that PLC-side status changes and the interface continues to display the same mode.
4. Return the loop to its required operating mode using the approved procedure and verify the display and PLC status agree.
5. Repeat the check for all five loops individually; confirm that none is cascaded only as a project-specific configuration detail, not as a reason to skip validation.

Production release requires agreement between the intended command, PLC-side mode status, and interface readback, plus a normal process response under the approved test. If any of those disagree, use the documented safe state and stop further writes. Escalate to official AutomationDirect support with the build, loop addresses, PLC mode/status readings, and the exact test results; do not clear the PLC or continue forcing bits while the controller state is uncertain.

FAQ