PLE500-8AD Recovery Depends on Node Presence Status

When the PLE500-8AD remains at NETSTAT=6, the deciding condition is whether the PLC still sees the node as present; changing output-error parameters does not itself restore communication. The reported normal state is NETSTAT=5 with MissCNT=0. A software reattach can be tested when the node is absent, but verify recovery from status values rather than assuming the call succeeded.

Output parameter changes and PLC restarts

The reported workaround—restarting the PLC—restored communication, but it interrupts PLC operation and does not identify why the node dropped out. It is not a practical first response when a targeted node-recovery routine can be tested.

Parameters 123 (“Error mode output”) and 124 (“Error value output”) were set to 3 and 0, respectively, to request zero output on error. Those settings do not correct a lost communication path. They also cannot be declared correct from the parameter names alone: consult the PLE500-8AD parameter definition for the meaning of mode value 3, which faults it covers, and whether the configured error value is applied during a communication loss.

The observed board state—output remaining at 100% and digital output active—makes it especially important to distinguish a configured error response from an output that remains at its last state after communication is interrupted. Do not treat the parameter values as proof that the board entered the intended error mode. Confirm the board’s documented behavior for communication loss and test it under controlled conditions before relying on a zero-output response.

Communication loss behind the status-6 symptom

A fast, continuous blink of the green LED was reported while the PLE node was not communicating. The diagnostic interpretation provided for this condition is that the PLC had lost communication with a node that had previously communicated. It is a communication-state indication, not a root-cause diagnosis: the LED alone does not distinguish a node restart from wiring, power, or other communication trouble.

NETSTAT=5 is the reported operational state. A value of 6 or another value means communication is not operational. After a node restart or disturbance, the PLC may reattach and resume communication quickly, even while the PLE LED continues blinking. In the reported case, however, NETSTAT remained at 6 for the duration of remote observation and the node had not been reintegrated after 30 minutes. Treat persistent status 6 as a continuing communications fault, not as a transient indication that can be ignored.

Status values and limits to monitor

Use PLC-visible state as the alarm basis. The suggested alarm rule is NETSTAT <> 5 continuously for several seconds; the exact delay was not specified and should be selected for the machine’s response requirements. A short persistence filter prevents a brief state transition from immediately generating the same alarm as a prolonged loss.

The status transition is the one quantity that decides whether the PLC currently considers the node operational. Keep the output response as a separate safety and process-control check: communication status cannot tell you whether a physical output has gone to zero.

Error-mode settings and output behavior

Review the configured values in context instead of changing them speculatively. The installation set 123=3 and 124=0. Read the module’s parameter documentation to verify that mode 3 selects the intended response, that zero is the right error value for the output range, and that the mode applies to the specific fault being tested. The evidence does not define those code semantics.

1. Record the current values of parameters 123 and 124 before editing them.
2. Check the PLE500-8AD parameter reference for the exact meaning and scope of error mode 3, and confirm that error value 0 is valid for the configured output.
3. Determine whether a lost PLC-to-node communication link invokes that mode or leaves the output at its last commanded state. Use the device documentation and a controlled test.
4. Monitor both the PLC communication state and the physical output during the test. Confirm the output reaches the intended state before putting the response into service.

A parameter setting cannot force a disconnected node to accept new commands. If the node does not respond, troubleshoot communication recovery independently from the configured output-on-error response.

Background-task reattach procedure

A proposed software method checks node presence and calls sysCOPM2_AttachUnconfiguredNode when presence is false. The example uses node number 1; substitute the actual PLE node number in both indexed status access and the call arguments. The final argument is identified as the node number; retain the function’s required argument order from the PLC programming reference.

Stato1CAN1 : BOOL;
Ris : UINT;

Stato1CAN1 := sysCOPMNodeStatus_1[1].pres;
IF Stato1CAN1 = FALSE THEN
    Ris := sysCOPM2_AttachUnconfiguredNode(1, 1);
END_IF;

Run the check in a program associated with the background task, as in the proposed method. Treat Ris as the function result to inspect according to the programming reference; no return-code meanings are provided here. Avoid calling the recovery routine unconditionally: the shown logic calls it only when the presence field is false.

1. Monitor sysCOPMNodeStatus_1[1].pres for the actual node index.
2. When it is FALSE, call sysCOPM2_AttachUnconfiguredNode with the correct node number and the required arguments.
3. Capture the function result in Ris and inspect it using the PLC’s function documentation.
4. Recheck node presence and NETSTAT; do not declare recovery solely because the call executed.

The routine is a recovery attempt, not a diagnosis or guarantee. If presence remains false or NETSTAT remains outside 5, continue fault isolation rather than cycling the PLC repeatedly.

Recovery verification and fault isolation

Consider the node recovered only when PLC status returns to NETSTAT=5 and the reported normal miss count is MissCNT=0. Confirm that the state persists beyond the configured alarm delay. Also inspect the LED and output state: a blinking LED can persist after communication has resumed, so it must not overrule the PLC status by itself.

If the reattach call does not restore operation, record the sequence rather than making repeated blind changes: node presence before and after the call, function result, NETSTAT, MissCNT, LED behavior, and whether the output remains at 100% or the digital output remains active. Compare those observations with the PLE500-8AD communication and parameter documentation. This separates a failed software reattach from an output-mode configuration issue and gives support actionable diagnostic data.

FAQ

Stop repeated reattach attempts if the node remains absent or NETSTAT stays outside 5, and keep the output in a state appropriate to the machine’s risk controls. Escalate to official product support with the node-presence state, function result, NETSTAT and MissCNT history, LED behavior, and the verified settings of parameters 123 and 124.