A CPU 1515F-2 PN on TIA Portal V17, an ET 200SP station with an F-DI 8x24VDC HF, and channel 2 on it is a guard door. The buffer showed “Channel 2: Short-circuit” last week and the channel passivated; the electrician found a chafed wire in the door loom and repaired it, the buffer now says “Channel 2: Fault resolved”, the channel LED is green, the door is closed – and the process value for channel 2 is still 0 with QBAD in the F-DI’s DB still TRUE. The only thing that brings it back is STOP and RUN on the CPU, and a second F-DI from stores does exactly the same, which is how the question arrived on our forum. The module is fine. Both modules are fine. Nothing in the safety program is writing a rising edge to ACK_REI, and until something does, Siemens F-module passivation holds a repaired channel at 0 by design. Everything below is from the SIMATIC Safety manual’s chapter on F-I/O access and the Siemens programming guideline, and it says which page where it matters.
The one-line answer: the fault being resolved is step one of two. Step two is an operator’s acknowledgement, and a STOP-to-RUN only works because it skips it.
What Siemens F-module passivation is, and why the value is 0 rather than stale
Passivation is the F-system deciding it can no longer trust a channel and substituting a value it can defend, which for every fail-safe input and output is 0.
The manual lists when it happens: at startup of the F-system, on a communication error between the F-CPU and the F-I/O, on an F-I/O fault or a channel fault such as wire break, short-circuit or a discrepancy error, and for as long as your own program holds PASS_ON at 1 in the F-I/O DB. With “Behavior after channel fault” set to passivate the channel, only the faulty channel goes; with it set to passivate the entire module, all eight do. While a channel is passivated its channel value in the process image is the fail-safe 0 and its value status bit is 0, and the guideline gives the four places you can see it: value status false, QBAD true in the F-I/O DB, the channel and module LEDs red, and the diagnostics buffer entry. The value is 0 and not the last good reading on purpose. A guard-door input that froze at “closed” while its wire was shorted would be worse than no input at all, and an F-DQ output that held its last state through a fault would keep a contactor in. So the substitute is the safe state, and the safety program sees the door as open until the channel is reintegrated. The thread had all four signs at once and read three of them as “fine” because the LED had gone green and the buffer said resolved. The two that matter to the program – value status and QBAD – were still saying passivated, and they were right.
The buffer describes the wire. QBAD describes the channel. They are allowed to disagree, and after a repair they do.
Everything a person looks at says the fault is gone. The two bits the safety program looks at say passivated, and ACK_REQ = 1 is the module saying it is ready to be told.
Three ways a channel comes back, and only one of them is automatic
Section 6.5 of the manual splits reintegration by what caused the passivation, and the thread’s symptom sits squarely in the third case.
After a startup of the F-system, reintegration is automatic: the manual says it happens regardless of ACK_NEC or the channel-failure-acknowledge setting, no sooner than the second cycle of the F-runtime group. After a communication error – a PROFIsafe timeout, a pulled PROFINET cable, an F-monitoring time set too short – reintegration always requires an acknowledgement with a positive edge at ACK_REI in the F-I/O DB, or at ACK_REI_GLOB of the ACK_GL instruction, once every communication error is gone and the F-system has set ACK_REQ to 1; there is no automatic option for that case at all. After an F-I/O fault or a channel fault, which is what a short-circuit on channel 2 is, it depends: with ACK_NEC at 0 in the F-I/O DB, or “Channel failure acknowledge” set to automatic on modules that carry that parameter, the channel reintegrates by itself as soon as the F-system sees the fault corrected, immediately for inputs and possibly minutes later for outputs because an F-DQ has to apply its next test signal first. With ACK_NEC at 1 or the parameter on manual, the channel waits for the same rising edge on ACK_REI as a communication error would. The initial value of ACK_NEC when the F-I/O DB is created is 1, the default of the parameter when the module is created is manual, and warning S010 says setting either to automatic is only allowed if automatic reintegration is permitted for the process from a safety standpoint. A guard door that re-enables the machine the moment its wire stops being shorted is the case that warning is written for.
So the module on the thread behaved exactly as configured. The fault cleared, ACK_REQ went to 1, and the channel waited for an edge that never came.
The shape of the manual’s signal sequence for channel-granular passivation with manual acknowledgement. Between the repair and the acknowledgement nothing is wrong except that nobody has pressed anything.
Why STOP to RUN “fixes” it
Because a startup of the F-system is the first case above, and the first case does not ask.
The manual’s warning under the startup sequence says it plainly: when the F-CPU goes from STOP to RUN the safety program starts up as in a cold restart, all F-DBs are initialised from load memory, saved error information is lost, and the F-system reintegrates the F-I/O automatically. That is what the thread was doing twice a week. It works, it is not a fault in the CPU, and it is the wrong tool for three reasons. It reintegrates every passivated channel on every F-module in the CPU, not the one somebody looked at. It throws away the saved error information the manual says it throws away, which is the DIAG byte and any stored fault in the safety blocks, so the record of what happened goes with it. And it takes the whole machine through a restart to clear one door, which is how a restart becomes the standard fix for anything that reads 0. Warning S008 in the same place is the one to keep: if your process does not allow a startup that automatically reintegrates, program a restart protection that blocks the output of process data until it is manually enabled. Most machines with a guard door are that process.
An acknowledgement button costs one input. A restart costs the record and the shift.
Wiring the acknowledgement
The rising edge on ACK_REI has to come from a person, and the manual gives two ways to produce one.
Warning S011 sets the rule: the ACK_REI tag of the F-I/O DB must be interconnected with a signal generated by an operator input, never with an automatically generated signal. The first way is an acknowledge key on a fail-safe input, or on a standard input if the risk analysis allows it, and the manual’s own note about that key is the second gotcha in this story: if the key is wired to an F-I/O and that F-I/O has the communication error or the F-I/O fault, you cannot acknowledge its reintegration from it, and that blocking can only be removed by a STOP-to-RUN of the F-CPU. So it recommends an HMI acknowledgement as well. Channel-granular passivation softens that – a key on channel 5 of the same F-DI still works when channel 2 alone is passivated – but a communication error passivates the whole module and takes the key with it. The second way is ACK_OP from the HMI, and on an S7-1500F it takes two steps by design: the operator writes 6 into a standard memory word or DB word connected to the block’s IN, then writes the identifier configured at ACK_ID, a number between 9 and 30000, and the block’s OUT gives you the edge; warning S013 says the two steps must never be triggered by one operation. Either signal goes into ACK_REI of the F-I/O DB for that module – the fully qualified access “F00010_F_DI_8x24VDC_1”.ACK_REI – and it is worth gating it with ACK_REQ so the edge is only offered while the module is asking. Where one button should clear every module in the F-runtime group, ACK_GL does that with one instruction; where a distributed machine needs local acknowledgement per cabinet, the guideline shows separate ACK_REI tags per module.
Pick the F-I/O DB by name. The DB the thread was watching QBAD in is the same DB whose ACK_REI needs the edge.
Network 1 is the answer to the thread. Networks 2 and 3 are the same edge produced two other ways; which one is the risk assessment’s call.
The thing everyone checks first
The module. Then the second module. Then the firmware.
The thread had already swapped the F-DI, which is the natural move when the LED is green and the value is 0, and it told them something useful without meaning to: two modules with the same behaviour is not a module. The order that finds it in five minutes is the F-I/O DB, not the hardware. Open the DB online and read four tags. QBAD at 1 with the buffer clear means passivated and waiting. ACK_REQ at 1 means the F-system has already accepted that the fault is gone and wants an acknowledgement; at 0 with QBAD at 1, the fault is not gone yet, or the module is passivated by PASS_ON from your own program, or it is an F-DQ still waiting to run its test. ACK_NEC tells you whether it was ever going to come back by itself. And DIAG, the non-fail-safe byte, holds the last cause until the acknowledgement – bit 0 for a timeout, bits 1 and 2 for an F-I/O or channel fault – which is the record the STOP-to-RUN was erasing. Only after those four is the hardware worth a look, and a chafed loom is more likely than a module every time.
QBAD 1, ACK_REQ 1, ACK_REI never rising: that is the whole diagnosis, and it is four clicks.
From section 6.5 of the manual. Only the first row happens by itself on every module; if a STOP/RUN is your only fix, you are in row three with nothing on ACK_REI.
Next step
Open the F-I/O DB for the F-DI online, watch QBAD and ACK_REQ, and press whatever you have wired to ACK_REI; if nothing is wired, that is the fault, and network 1 above is the fix. Then decide, per module and with the risk assessment open, whether channel-failure acknowledge stays on manual – for a guard door it does – and write ACK_NEC next to it in the safety summary. The parameters this acknowledgement sits beside on the F-DI, the discrepancy time and the 1oo2 evaluation, are set up in configuring an ET 200SP F-DI in TIA Portal; the short-circuit that started the thread is the fault the module’s sensor-supply test exists to find, worked through for both vendors in cross-fault detection between two safety channels; and the reset discipline that stops a reintegrated door from restarting the machine by itself is the rising-edge reset article. If you are the person who asked on the forum: the second module was never the problem, and you can put the first one back.
Fault resolved is the module’s opinion. Reintegrated is yours, and it takes an edge.