The muting deadlock that locked a cart inside its own safety field

A light curtain has exactly one job: stop the machine when a person is somewhere they shouldn’t be. On a muting setup I worked on, it did that job perfectly. And in doing it, it trapped the cart it was specifically built to let through.

This is the long version of something I posted about, because the short version doesn’t leave room for the part that actually matters — why it happened, and why the obvious fix turned out to be worse than the problem. If you run muting anywhere, this is a trap worth understanding before you meet it on a live machine instead of after.

What we were protecting

A transport cart ran back and forth through a guarded zone. The guard was a SICK deTec4 light curtain with a DMM4 muting controller feeding the safety signal into a Siemens PLC.

The problem with putting a light curtain in front of a moving cart is obvious: the cart breaks the beams every time it passes. If the curtain treated the cart like a person, the machine would trip on every cycle and nothing would ever move. So you need the curtain to let the cart through without dropping its guard against people.

That’s what muting is for.

Why muting exists at all

Muting is the deliberate, automatic, temporary suspension of a safety function so that an expected object can pass through a protective device without stopping the machine — while a person still can’t. It’s not a workaround or a cheat. It’s a defined function with its own standards behind it: the light curtain itself falls under IEC 61496 (electro-sensitive protective equipment), and the application of muting specifically is covered by IEC 62046 (application of protective equipment to detect the presence of persons). The performance level the whole safety function has to hit lives in ISO 13849.

The trick with muting is telling a cart apart from a person. You do that with muting sensors — separate sensors, arranged so that only the expected object, arriving the expected way, can satisfy them. Get the right pattern in the right order and the controller says that’s the cart, and it mutes. A person walking up can’t reproduce that pattern, so the curtain stays live for them.

In this setup it was partial muting: the lower beams were muted so the cart could roll through underneath, while the upper beams stayed live the whole time to protect anyone standing in the zone. The muting itself was fired by two photosensors on a flag — an L-muting arrangement — that tripped as the cart came in.

It ran fine for ages. Then it didn’t.

The deadlock

Someone broke the upper live beams while the cart was still sitting in the field.

That’s not a fault — that’s the curtain working. The upper beams are there for exactly this. The OSSD outputs (the safety outputs that tell the drives “you’re allowed to move”) tripped off. Completely correct behavior.

Here’s where it knots itself:

• The DMM4 drops muting the instant it trips. Fine on its own.
• But the cart is still there, still blocking the lower beams.
• So with muting gone, the curtain now sees the cart as an obstruction too. The whole field reads as blocked. Full red.
• It won’t take a reset, because a reset wants to see the entire field clear first — the curtain has to be showing flashing yellow before it’ll accept an acknowledge.

Now follow the loop. The cart can’t move, because the drives need a safety OK to run. The safety can’t be acknowledged, because the curtain isn’t clear. And the curtain can’t clear, because the cart is parked in the middle of it and can’t move.

Proper deadlock. The cart physically stuck between the emitter and the receiver, and no button on the panel that gets it out.

Edge, not level

This took me a while to actually understand, rather than just brute-force.

The L-muting on the DMM4 is edge triggered, not level triggered. That distinction is the whole story, so it’s worth being precise about it:

• Level-triggered logic acts on a state. As long as the input is high, the condition holds. It cares where the signal is.
• Edge-triggered logic acts on a transition. It fires on the change — a rising edge (0 → 1) or a falling edge (1 → 0). It cares about the moment the signal moves.

The DMM4 arms muting on a rising edge of the muting sensors — the moment they go from “no cart” to “cart arriving.” That’s normally exactly what you want: it proves a fresh, sequenced approach rather than something just sitting in the beam.

But walk through our situation with that in mind. The OSSD trips. The cart never leaves. So the muting sensors are already sitting high — they went high when the cart arrived and they’ve stayed high the whole time. For muting to re-arm, the DMM4 needs to see a rising edge. And there’s no rising edge available, because the signal is already at the top. It can’t rise from a level it’s already at. No edge, no muting, no way out.

I proved it the crude way: pulled the cart out of the field by hand, then drove it back in. Fresh approach, fresh rising edge on the muting sensors — and muting came straight back. That confirmed it. The system wasn’t broken. It was doing precisely what edge-triggered logic does. It just had no path back to a muted state without a transition that the deadlock itself made impossible.

The one-button fix — and the hole it opened

The obvious fix looked clean. In SICK Safety Designer, flip the existing reset input over to a reset/override input — one button, and the DMM4 decides which one it is based on the current state. Override the stuck condition, get the cart moving, done. Clean on paper.

Then I looked at what override actually does, and stopped liking it fast.

An override holds the OSSD green for as long as the muting sensor stays blocked. It only drops the override when the sensor goes 1 → 0 — a falling edge, the cart finally leaving. Which is fine if the only thing that ever blocks that sensor is a real cart on its way out.

But there’s nothing forcing that. Hold anything in front of the muting sensor and the override keeps the OSSD green basically forever. The whole curtain — upper beams included, the ones protecting people — bypassed, indefinitely, with one blocked sensor and one button press.

And notice the symmetry, because this is the actual lesson buried in it. The original deadlock came from edge-triggered logic — it needed a transition that wasn’t available. The override fix is level-triggered — it stays active as long as the state is held. I’d swapped one failure mode for another. The first one traps you and you can see it. The second one bypasses your guard and you can’t. That’s a strictly worse trade.

Why the override is the wrong fix

I even called SICK to talk it through, and I never found an answer I loved — none that closed the hole without reintroducing some version of the original problem.

That’s why the one-button override is the wrong trade. A visible stop that needs someone to physically clear the field is annoying. A silent, holdable bypass of a people-protecting guard is a different category of thing entirely — not something worth designing in to save a few seconds of recovery time.

What it taught me about muting design

I’ll be honest: I never found a fix I actually loved, and I still think there’s a cleaner answer out there that I didn’t reach. Faced with the choice, I’d take a visible, recoverable stop over a bypass you can hold open every time.

But I came out of it understanding muting in a way no datasheet had taught me. Muting is a deliberate hole in your safety function. That’s not a criticism — it’s the entire point of it, and it’s a legitimate, standardized thing to do. The discipline is keeping that hole tightly bounded: bounded by sensor logic, by sequence, by geometry, by time, so it can’t be faked open and can’t be held open. Every “convenience” you bolt on to recover from an awkward edge case is a candidate to widen that hole, and the override was a perfect example — it solved a real annoyance by quietly removing the bound.

And the thing I’d tell anyone setting up muting for the first time: edge versus level is not a footnote. It’s the actual behavior of your safety function under the conditions you didn’t plan for. Edge-triggered logic can strand you when the transition you’re waiting on can’t happen. Level-triggered logic can hold a dangerous state open as long as something keeps it high. Both are correct. Both will bite you. Knowing which one you’ve built, and exactly what happens to it when the machine ends up somewhere you didn’t picture, is most of the job.

The cart got out. I never landed the elegant fix I was after — but I trust muting a lot more now precisely because I know exactly where its edges are.