How Do I Configure DL205 Redundant Vacuum Pump Control?

The pump can start from the panel or the EPICS HMI, but one station can leave stale bits that override the other or hold a ladder rung true. Restore predictable control by turning both stations into momentary request sources, merging equivalent requests into one internal command layer, and publishing status back from the PLC-controlled state.

Reject the quick fixes that keep causing stale commands

Do not maintain separate local and remote state images and copy one over the other when a mode changes. That arrangement creates two authorities for one device. The result depends on scan order, selected mode, and whichever image was copied last.

Do not solve this by adding more bidirectional copies. Get both command paths into one logic point, then fix the display and communications behavior around that point.

Define what redundant control means here

This application uses a DL205-format system controlling three pumps in a deep-vacuum process. The identified hardware includes an H2-DM1 CPU in the legacy base and an ECOM100 communications module. EPICS reaches PLC memory through Modbus/TCP.

The requested redundancy is dual-station operating authority: an operator can start a pump from EPICS and stop it at the panel without first selecting Local or Remote. It is not redundant PLC hardware, redundant communications, or automatic failover between controllers.

Confirm the CPU and programming environment before selecting instruction mnemonics. The installation was initially described as a DL205 PLC, then identified more specifically as a Do-More CPU using the legacy base. Those platforms can expose different instructions even though the rack format and address style look familiar. The Boolean design below does not depend on a platform-specific toggle instruction.

Separate requests, retained state, outputs, and status

Use four distinct signal roles. Mixing them is the root of most two-station control faults.

The HMI command tag and HMI status tag must be different tags. Pressing an HMI button writes a request. The HMI then reads the resulting state from the PLC. Do not make the displayed state depend on whether the button tag remains high.

Likewise, drive the panel LED from the resulting PLC state rather than directly from X0. A remote command will then update the local indication. If the installation has physical running feedback, label and display that feedback separately from the PLC output command; an energized output is not proof that a pump is turning.

Build one request layer for both stations

1. Configure the EPICS HMI ON and OFF controls as momentary commands. Verify that each bit becomes true when pressed and returns false when released.
2. Create an ON request rung with X0 and DLY0 on parallel branches feeding C0.
3. Create an OFF request rung with X1 and DLY1 on parallel branches feeding C1.
4. Repeat the same pattern for each pump and valve. Give every action its own local input, remote input, and unified request bit.
5. Replace the original local ON and OFF contacts in the main logic with the corresponding unified C
6. Keep the existing permissives and protective checks in the main device logic. The new request layer changes command sourcing, not process protection.

Unified_ON  C0 := X0 OR DLY0
Unified_OFF C1 := X1 OR DLY1

Retained_Run := (Retained_Run OR C0) AND NOT C1
Output_Command := Retained_Run AND Existing_Permissives

The final two expressions describe behavior, not required instruction syntax. Implement them with the instructions available for the confirmed CPU. The OFF expression makes a simultaneous OFF request dominant. Apply that policy consistently so an ON from one station cannot defeat an OFF arriving from the other during the same scan.

Do not place separate output coils for C0 on consecutive local and HMI rungs. If the local rung writes true and the following HMI rung writes false, the second rung wins. Parallel branches produce one assignment and preserve either request.

Preserve the original latch and process interlocks

The existing local-only program uses momentary ON and OFF actions with a retained ladder state. Keep that structure, but substitute C0 and C1 for the physical input contacts. The retained state belongs in the device-control layer; neither the panel nor EPICS should own it.

A single-button toggle scheme is the wrong pattern for the described panel because the installation uses separate momentary ON and OFF controls with status LEDs. Rising-edge toggle logic can invert the wrong state when an operator presses a button without knowing the current command. Separate ON and OFF requests express intent directly.

If an HMI request continues completing the rung, watch its raw Modbus value online. A bit that stays at 1 after release is still configured or written as a maintained toggle, or its release write is not reaching the PLC. Correct that command behavior before changing the pump latch.

Test what happens if communications fail while a momentary HMI command is active. If the HMI can leave the request high, use a command handshake or a PLC-cleared request mechanism supported by the confirmed CPU and EPICS implementation. Read the product documentation for the chosen mechanism; do not guess at instruction behavior from the rack family alone.

Schedule the tasks without creating a second authority

Run the input-mapping program at the start of each scan so the main logic sees a single, current request image. Use OR logic to form the unified requests; do not copy an entire local block over the HMI block or reverse the direction by operating mode.

Retain the First Scan task for pressure set-point initialization if that layout remains clearer to maintenance personnel. First Scan initialization serves a different purpose from recurring command mapping and must not be used to process operator requests.

Copy status bits outward for the HMI after the main control logic has calculated the device state. This gives EPICS the result of the current control decision rather than a mirrored copy of its own command. Keep request memory and status memory in separate blocks so a remote write cannot alter an indication that the PLC owns.

Scan order should follow this data flow:

1. Read physical inputs and received Modbus request values.
2. Merge local and remote momentary requests into the unified C
3. Execute the retained device state, permissives, and output logic.
4. Publish command state, LED state, and any available process feedback to the HMI status area.

Prove control from both locations before returning service

Test one pump first with its process output inhibited by the site's approved commissioning method. Monitor the raw local inputs, raw HMI requests, unified C

1. Press local ON. Confirm X0 and C0 operate momentarily, the retained state turns on, and both panel and HMI indications follow the PLC state.
2. Release local ON. Confirm X0 and C0 return off while the retained state remains on.
3. Press HMI OFF. Confirm DLY1 and C1 operate momentarily and the retained state turns off without a Local/Remote selection.
4. Start from the HMI, then stop locally. Repeat in the opposite direction.
5. Press local ON and remote OFF as close together as practical. Confirm the documented OFF-dominant policy.
6. Block one existing permissive. Confirm neither station can bypass it and the displayed status distinguishes a request from an allowed output state.
7. Interrupt the communications path during an active HMI command test. Confirm no request remains stuck and local control still behaves as designed.
8. Repeat the matrix for all three pumps and every mapped valve or auxiliary output.

Only restore the process outputs after every command releases correctly and the status displays agree with the PLC state. Save a mapping list for each local request, remote request, unified bit, retained state, physical output, and HMI status tag.

FAQ