Morning all. CPU 1515F-2 PN, TIA V17, ET 200SP station with an F-DI 8x24VDC HF. Channel 2 is a guard door.
Last week the buffer showed "Channel 2: Short-circuit" and the channel passivated. Our electrician found a chafed wire in the door loom and repaired it, and the buffer now says "Channel 2: Fault resolved". But the process value for that channel stays 0 and the QBAD bit in the F-DI DB stays TRUE, with the door closed and the module LED green for that channel.
The only thing that brings it back is a STOP and RUN on the CPU. I tried a second F-DI from stores, same behaviour, so I don't think the module is faulty.
Is there something in the CPU that has to be cleared, or could anyone point me in the right direction?
One question. In the F-I/O DB for that module, what is ACK_NEC?
ACK_NEC is TRUE, default I think, nobody's changed it since we set the station up on V17. ACK_REQ is also TRUE right now, since the fault cleared. The rest of the DB I haven't touched.
Both your 24VDC F-DI modules are fine then, still on TIA V17. ACK_REQ TRUE means the channel's repaired and waiting to be let back in. What writes ACK_REI in your safety program, if anything?
Nothing writes it, so I put a pulse on ACK_REI from a test network in the safety program and the channel came straight back, value 1, QBAD FALSE. Can I set ACK_NEC to FALSE instead and let it reintegrate on its own? The machine builder's gone and nobody here wants another button on the panel.
Not without the safety engineer. ACK_NEC TRUE means after a passivation the channel does not come back by itself, it waits for a rising edge on ACK_REI. That is the default on purpose: a door input coming back on its own after a wiring fault is what the standard does not want for a guard. Setting it FALSE is a decision the risk assessment has to cover, and for a door it usually says no.
The fix is a reintegration button outside the zone, on a standard input, written to ACK_REI from the safety program on the rising edge. ACK_REQ to a lamp so the operator knows when a press will do something. The CPU restart was never the answer. There's a writeup on the interlock side of this here: https://plctr.com/implementing-plc-safety-interlock-systems-in-industrial-environments/
ACK_REQ to a lamp, then nobody guesses which door wants a press.
Added a reintegration pushbutton on the panel and a white lamp next to it. ACK_REI is set from the rising edge of the button in the safety program, ACK_REQ drives the lamp. Tested with a wire pulled: passivation, lamp on, press, channel back. No CPU restart.
The channel was doing exactly what it had been configured to do. ACK_NEC TRUE and nothing anywhere writing ACK_REI, so it sat waiting for an acknowledge that was never coming, and the CPU restart only ever cleared it by accident. The button and the lamp give it one properly.
Still don't know why the wire chafed in the first place, the loom looks fine. The "faulty" module from stores goes back on the shelf. Thanks pnina and larsdk.
Marking solved.
plctr.com team