Implementierung von PLC-Entprelllogik mit TON-Timern in OLLA Lab

Um mechanisches Kontaktprellen in der Kontaktplanlogik (Ladder Logic) zu beheben, verwenden Ingenieure häufig einen Timer On-Delay (TON)-Baustein als Software-Entprellfilter. Durch die Einstellung einer Zeitvorgabe (Preset), die etwas länger als die physikalische Prelldauer ist – typischerweise 20 bis 50 ms –, kann die PLC transiente Zustandsänderungen ignorieren und nur auf ein stabiles Eingangssignal reagieren.

Mechanische Eingänge schalten nicht sauber, selbst wenn der Kontaktplan sauber aussieht. Ein Endschalter, ein Taster oder ein Relaiskontakt kann physikalisch etwa 10 bis 50 ms lang prellen, bevor er einen stabilen Zustand erreicht. Eine PLC, die alle 1 bis 10 ms abtastet, kann diese einzelne Betätigung als mehrere separate Übergänge interpretieren.

Ampergon Vallis Kennzahl: Während eines 1.000-Zyklen-Stresstests im Simulationsmodus von OLLA Lab erzeugte ein roher, mechanischer Endschaltereingang unter injizierten Prellbedingungen durchschnittlich 3,4 falsche Zustandsänderungen pro Betätigung; die Anwendung eines 50-ms-TON-Filters entfernte diese falschen Übergänge in der simulierten Sequenz ohne beobachtbare Verzögerung auf Maschinenebene. Methodik: n=1.000 Eingangsbetätigungszyklen in einem Entprell-Laborszenario, Basis-Vergleichswert = ungefilterter roher boolescher Eingang, Zeitfenster = eine Testsitzung am 24.03.2026. Dies unterstreicht den Wert der TON-basierten Entprellung in einem kontrollierten Simulations-Workflow. Es wird kein Anspruch auf universelle Feldleistung über alle Hardwaretypen, Zykluszeiten oder Sensortechnologien hinweg erhoben.

Diese Unterscheidung ist wichtig. Syntax ist nicht gleichbedeutend mit Einsatzfähigkeit, und verrauschte Eingänge sind der Punkt, an dem diese Verwechslung meist teuer wird.

Mechanisches Kontaktprellen ist ein physikalischer Effekt, kein Programmierfehler. Wenn Metallkontakte innerhalb eines Schalters oder Relais den Zustand ändern, vibrieren sie oft kurzzeitig, bevor sie einen stabilen offenen oder geschlossenen Zustand erreichen. In einem 24-VDC-Steuerstromkreis erzeugt dies eine schnelle Serie von kurzzeitigen EIN/AUS-Übergängen anstelle einer sauberen Flanke.

Das praktische Problem tritt auf, wenn die PLC schneller ist als die Hardware. Wenn das Eingabegerät 30 ms lang prellt und die Steuerung alle 5 ms abtastet, kann das Programm diesen einzelnen Tastendruck als mehrere Zustandsänderungen lesen. Die PLC arbeitet nicht fehlerhaft; sie tut genau das, wozu sie aufgefordert wurde, nur schneller, als die Mechanik sauber reagieren kann.

Dies ist besonders wichtig bei Logiken, die auf Flanken reagieren oder Ereignisse zählen, darunter:

• Kartonzählung auf Förderbändern
• Fortschritt von Zustandsautomaten (State Machines)
• Trigger für die Umschaltung von Haupt-/Reserve-Aggregaten
• Fehler-Speicherglieder (Latching)
• Start/Stopp-Tasterlogik
• Positionsrückmeldungen von Endschaltern

Ein verrauschter Kontakt kann Folgendes verursachen:

• falsche Zählwerte
• vorzeitiges Fortschreiten von Sequenzen
• doppelte Befehle
• Race Conditions zwischen Netzwerken
• Störmeldungen
• intermittierende Fehler bei der Inbetriebnahme

Warum macht der Zyklus das Prellen sichtbar?

Der Zyklus (Scan Cycle) erzeugt den Konflikt zwischen physikalischer Einschwingzeit und logischer Interpretation. In einem Standard-PLC-Zyklus liest die Steuerung die Eingänge, führt die Logik aus, aktualisiert die Ausgänge und wiederholt den Vorgang. Wenn das Prozessabbild der Eingänge mehrere Prellübergänge über aufeinanderfolgende Zyklen hinweg erfasst, kann das Programm diese als legitime Änderungen behandeln.

Deshalb ist Entprellung keine kosmetische Bereinigung. Es ist eine Maßnahme zur Zeitsteuerung, die die Logik gegen bekanntes elektromechanisches Verhalten härtet, bevor dieses Verhalten den Rest des Programms erreicht.

Ein TON-Baustein filtert Prellen, indem er erfordert, dass der Eingang für eine definierte Zeit kontinuierlich TRUE bleibt, bevor der Ausgang TRUE wird. Wenn der Eingang vor Ablauf der Zeitvorgabe abfällt, wird der Timer zurückgesetzt und der Ausgang schaltet niemals ein.

Das ist der Kernmechanismus. Ein prellender Eingang unterbricht den Timer wiederholt, sodass die abgelaufene Zeit niemals den Schwellenwert erreicht. Nur ein stabiles Signal überlebt lange genug, um den Filter zu passieren.

In IEC 61131-3-Begriffen verhält sich der TON wie ein deterministisches Software-Gatter:

- instabiler Eingang: Timer startet, setzt zurück, startet erneut, qualifiziert sich nie - stabiler Eingang: Timer läuft kontinuierlich bis zum Preset - qualifizierter Zustand: Ausgangsbit wird TRUE und kann von nachgeschalteter Logik verwendet werden

Eine nützliche Korrektur an dieser Stelle: Entprellung ist nicht dasselbe wie das Hinzufügen von Verzögerungen an jeder Stelle. Eine gute Entprellung fügt nur dort eine kleine, begrenzte Qualifizierungsverzögerung hinzu, wo die Physik des Eingangs dies erfordert.

Standard IEC 61131-3 TON-Parameter

Für Entprelllogik sollten die TON-Parameter operativ verstanden werden:

- IN (Eingang): das rohe Sensor- oder Schaltersignal, das in den Timer eintritt Beispiel: `Raw_Sensor_Input`

- PT (Preset Time): die minimale kontinuierliche TRUE-Dauer, die erforderlich ist, um das Signal zu akzeptieren Beispiel: `T#50ms`

- Q (Ausgang): das entprellte, stabile boolesche Signal, das vom Rest des Programms verwendet wird Beispiel: `Sensor_01_Debounced`

- ET (Elapsed Time): die akkumulierte Zeit, während `IN` TRUE bleibt; sie wird sofort zurückgesetzt, wenn `IN` FALSE wird, bevor `PT` erreicht ist

Für Software-Entprellung ist `ET` der entscheidende Indikator. Wenn dieser während eines verrauschten Übergangs immer wieder auf Null zurückfällt, erfüllt der Filter seine Aufgabe.

Welche Zeitvorgabe (Preset) sollten Sie für die Entprellung verwenden?

Die Zeitvorgabe sollte die erwartete Prelldauer überschreiten, aber kurz genug bleiben, um die Maschinenreaktion nicht zu beeinträchtigen. Für viele mechanische Kontakte ist ein praktischer Startbereich 20 bis 50 ms, der dann basierend auf dem Geräteverhalten, der Zykluszeit und der Prozesssensitivität angepasst wird.

Verwenden Sie ein kürzeres Preset, wenn:

• das Gerät relativ sauber schaltet
• die Maschine eine schnelle Reaktion erfordert
• der Eingang nicht sicherheitskritisch ist und leicht zu beobachten ist

Verwenden Sie ein längeres Preset, wenn:

• der Kontakt mechanisch rau oder gealtert ist
• die Umgebung elektrisch verrauscht ist
• falsche Übergänge Sequenzfehler oder Zählfehler verursachen
• der Prozess eine etwas langsamere Qualifizierung tolerieren kann

Der richtige Wert wird nicht geraten. Er wird beobachtet, getestet und begründet.

Die Standardstruktur ist einfach: Platzieren Sie den rohen Eingang in einem Netzwerk, das einen TON ansteuert, und verwenden Sie dann den `Q`-Ausgang des Timers als die einzige akzeptierte Version dieses Signals im restlichen Programm.

Diese Trennung ist wichtig. Der rohe Eingang gehört an die Schnittstelle. Das entprellte Bit gehört in die Sequenz.

Netzwerk 1: Der Entprell-Timer `|---[ Raw_Sensor_Input ]---------------------[ TON: Debounce_Timer, PT: 50ms ]---|`

Netzwerk 2: Die Aktionslogik unter Verwendung des sauberen Signals `|---[ Debounce_Timer.Q ]---------------------( Motor_Start_Sequence )------------|`

Dies ist das minimale lebensfähige Entprellmuster.

Warum sollte nachgeschaltete Logik das entprellte Bit statt des rohen Eingangs verwenden?

Nachgeschaltete Logik sollte nur das entprellte Bit verwenden, da eine gemischte Verwendung den Filter aushebelt. Wenn ein Netzwerk `Raw_Sensor_Input` verwendet und ein anderes `Debounce_Timer.Q`, enthält das Programm nun zwei konkurrierende Interpretationen desselben Geräts.

Das erzeugt vermeidbare Inkonsistenz:

• ein Teil der Sequenz reagiert sofort
• ein anderer wartet auf die Qualifizierung
• die Ereignisreihenfolge wird zyklusabhängig
• die Fehlersuche wird unübersichtlicher

Ein saubereres Muster ist:

• roher Eingang geht in ein Filter-Netzwerk
• gefiltertes Ergebnis wird klar benannt
• die gesamte Sequenzlogik referenziert das gefilterte Tag

Ein kompaktes technisches Nachweismuster für die Entprell-Validierung

Wenn Sie technisches Urteilsvermögen demonstrieren möchten, dokumentieren Sie Entprellungsarbeiten als technischen Nachweis anstelle von Screenshots. Verwenden Sie diese Struktur:

Beispiel: Lichtschranke am Förderband oder mechanischer Endschalter, der einen Zählvorgang oder Sequenzübergang auslöst.

Beispiel: eine physikalische Betätigung erzeugt ein logisches Ereignis und keinen doppelten Übergang.

Das ist es, was simulationsbereit in der Praxis bedeuten sollte: Sie können Steuerungslogik beweisen, beobachten, diagnostizieren und gegen realistisches Verhalten härten, bevor sie einen Live-Prozess erreicht.

1. Systembeschreibung
2. Operative Definition des korrekten Verhaltens
3. Kontaktplanlogik und simulierter Gerätezustand Zeigen Sie den rohen Eingang, das TON-Netzwerk, den entprellten Ausgang und den durch diesen Ausgang beeinflussten Maschinenzustand.
4. Der injizierte Fehlerfall Führen Sie Prellen oder schnelles Umschalten am rohen Eingang ein.
5. Die vorgenommene Revision Fügen Sie das TON-Preset hinzu oder passen Sie es an, und leiten Sie die Sequenzlogik auf das gefilterte Bit um.
6. Gelernte Lektionen Geben Sie an, was sich geändert hat, warum es funktioniert hat und welches Prozessrisiko dadurch beseitigt wurde.

Sie testen Entprelllogik sicher, indem Sie instabiles Eingangsverhalten injizieren, die Timer-Reaktion beobachten und bestätigen, dass nur das gefilterte Bit die Sequenz steuern darf. OLLA Lab ist hier nützlich, da es einen browserbasierten Kontaktplan-Editor, einen Simulationsmodus und Variablen-Sichtbarkeit bietet, ohne dass echte Hardware erforderlich ist.

Operativ fungiert die Plattform als begrenzte Validierungsumgebung. Sie ermöglicht es Ihnen, zu vergleichen, was der Eingang tut, was der Timer tut und was die Maschinenlogik glauben darf.

Schritt-für-Schritt-Workflow für Entprelltests in OLLA Lab

1. Erstellen oder öffnen Sie ein Kontaktplan-Projekt Bauen Sie eine einfache Sequenz mit einem rohen booleschen Eingang und einer Ausgangsaktion.
2. Fügen Sie das TON-Entprell-Netzwerk hinzu Verwenden Sie den rohen Eingang als `IN`, weisen Sie ein Preset wie `T#50ms` zu und erstellen Sie ein klares gefiltertes Tag aus `Q`.
3. Leiten Sie die Aktionslogik durch den gefilterten Ausgang Lassen Sie nicht zu, dass der rohe Eingang die Maschinenaktion direkt steuert.
4. Starten Sie den Simulationsmodus Starten Sie die Logik und öffnen Sie das Variablen-Panel.
5. Schalten Sie den rohen Eingang schnell um Simulieren Sie Prellen, indem Sie den Eingang in schneller Folge ein- und ausschalten.
6. Beobachten Sie `ET` in Echtzeit Bestätigen Sie, dass die abgelaufene Zeit zu akkumulieren beginnt und dann zurückgesetzt wird, wenn der Eingang abfällt, bevor `PT` erreicht wird.
7. Bestätigen Sie, dass `Q` während des Rauschens FALSE bleibt Der entprellte Ausgang sollte erst dann TRUE werden, wenn der Eingang für die volle Preset-Dauer stabil bleibt.
8. Halten Sie den Eingang lange genug TRUE, um sich zu qualifizieren Überprüfen Sie, ob `Q` erst TRUE wird, nachdem der Timer das Preset erreicht hat.
9. Beobachten Sie den nachgeschalteten Maschinenzustand Bestätigen Sie, dass der Ausgang oder der Sequenzübergang einmalig erfolgt, nicht mehrfach.

Hier wird OLLA Lab operativ nützlich. Sie zeichnen nicht nur ein Netzwerk; Sie validieren das Netzwerk gegen ein Verhaltensmodell und prüfen, ob die Logik ein realistisches Fehlermuster übersteht.

Was sollten Sie im Variablen-Panel beobachten?

Das Variablen-Panel sollte verwendet werden, um das Verhalten des rohen Eingangs, den Timer-Zustand und die Sequenzantwort zu korrelieren. Überwachen Sie für einen Entprelltest mindestens:

• den rohen booleschen Eingang
• den TON `ET`-Wert
• den TON `Q`-Ausgang
• den nachgeschalteten Ausgang oder Zustandsbit
• jedes Zähler- oder Schrittübergangsbit, das anfällig für Doppelauslösungen wäre

Die wichtigste Beobachtung ist einfach: Wenn der rohe Eingang flattert, aber `Q` stabil bleibt, bis sich das Signal qualifiziert, arbeitet die Entprelllogik wie beabsichtigt.

Was beweist dies und was beweist es nicht?

Ein simulationsbasierter Entprelltest beweist, dass sich die Kontaktplanstruktur und die Zeitlogik unter den injizierten Bedingungen korrekt verhalten. Es hilft, Ursache-Wirkungs-Zusammenhänge, das Timer-Reset-Verhalten und die Robustheit der Sequenz zu validieren, bevor Hardware involviert ist.

Es beweist nicht:

• die Qualität der Feldverdrahtung
• den tatsächlichen Zustand des Sensors
• die EMV-Leistung
• die Sicherheitsintegrität
• die Bereitschaft zur endgültigen Inbetriebnahme vor Ort

Diese Grenze ist wichtig. Simulation ist der Ort, an dem Sie logische Fehler kostengünstig entfernen. Die Arbeit vor Ort ist der Ort, an dem die verbleibenden realen Probleme auftreten.

Software-Entprellung ist angemessen, wenn das Problem ein diskreter Eingang ist, der seinen Zustand zu verrauscht für den Zyklus ändert und die Anwendung eine kleine Qualifizierungsverzögerung tolerieren kann. Sie ist besonders praktisch für Standard-mechanische Kontakte in nicht-sicherheitskritischer Sequenzlogik.

Verwenden Sie Software-Entprellung, wenn:

• das Eingabegerät mechanisch ist
• falsche Übergänge intermittierend, aber reproduzierbar sind
• Sie ein transparentes Zeitverhalten im PLC-Programm benötigen
• Sie möchten, dass der Filter sichtbar, einstellbar und testbar ist

Erwägen Sie Hardware-Filterung oder alternative Sensorik, wenn:

• die Rauschquelle elektrisch statt mechanisch ist
• der Signalweg schlecht verdrahtet oder schlecht abgeschirmt ist
• die Anwendung eine sehr schnelle Flankenerkennung erfordert
• die Steuerung oder das E/A-Modul bereits konfigurierbare Eingangsfilter bereitstellt
• die Funktion sicherheitsrelevant ist und ein Design innerhalb des entsprechenden Sicherheitsrahmens erfordert

Ein TON ist kein universelles Heilmittel. Es ist eine Standardlösung für eine spezifische Klasse von Problemen.

Der häufigste Fehler ist das zu späte Filtern. Wenn das rohe Signal einen Zähler inkrementieren, einen Sequenzer vorantreiben oder einen Fehler speichern darf, bevor der Entprellbaustein greift, ist der Schaden bereits angerichtet.

Weitere häufige Fehler sind:

• Verwendung des rohen Eingangs in einigen Netzwerken und des gefilterten Bits in anderen
• Wahl einer Zeitvorgabe ohne Beobachtung des tatsächlichen Verhaltens
• Einstellung des Presets so hoch, dass die Maschinenreaktion träge wird
• unterschiedlose Anwendung von Entprellung auf jeden Eingang
• Verwechslung von Kontaktprellen mit analogem Rauschen, Verdrahtungsfehlern oder Fehlern in der Zyklusreihenfolge

Eine praktische Regel ist einfach: Filtern Sie an der Schnittstelle, benennen Sie das gefilterte Bit klar und verwenden Sie es konsistent.

Eine Entprellkorrektur sollte als begrenzte Logikrevision dokumentiert werden, die mit einem beobachteten Fehlermodus verknüpft ist. Eine gute Dokumentation macht die Argumentation für einen anderen Ingenieur, Techniker oder Integrator nachvollziehbar.

Fügen Sie hinzu:

• das betroffene Geräte-Tag und die physikalische Funktion
• das beobachtete Symptom
• den Kontext der Zykluszeit, falls relevant
• die gewählte Timer-Vorgabe und warum
• die überarbeitete Kontaktplanstruktur
• die verwendete Testmethode
• das Akzeptanzkriterium
• das Ergebnis nach der Revision

Zum Beispiel:

- Gerät: `LS_101_InfeedStop` - Beobachtetes Symptom: doppelter Schrittübergang bei einzelner mechanischer Betätigung - Revision: TON-Entprellung hinzugefügt, `PT = T#40ms` - Akzeptanzkriterium: eine Betätigung erzeugt einen Sequenzübergang - Validierung: schnelles Umschalten in OLLA Lab simuliert, `ET`-Resets beobachtet und einzelnes qualifiziertes `Q`

Das ist das Maß an Nachweis, das eine Übergabe überlebt.

Mechanisches Prellen ist eine Hardware-Tatsache, aber Fehlauslösungen sind eine Entscheidung des Logikdesigns. Ein TON-basiertes Entprell-Netzwerk ist die Standard-Softwaremethode, um zu fordern, dass ein Signal stabil bleibt, bevor die PLC es akzeptiert, und in vielen Anwendungen ist ein Preset von 20 bis 50 ms ein solider Startbereich.

Der wichtigere Punkt ist nicht nur, wie man den Timer platziert. Es geht darum, wie man das Verhalten validiert. Ein Ingenieur, der auf die Inbetriebnahme vorbereitet ist, kann das rohe Signal, das Filterverhalten, den nachgeschalteten Effekt, den injizierten Fehler und die Revision, die ihn beseitigt hat, aufzeigen. Das ist der Unterschied zwischen dem Wissen um Kontaktplan-Syntax und der Bereitschaft, Logik in der Nähe eines Live-Prozesses zu vertrauen.

Link up: Software-Entprellung ist eine grundlegende Fähigkeit in unserem Lehrplan zur Kontaktplan-Meisterschaft.

Links across: - Verständnis von Zykluszeiten: Wie OLLA Lab echte Hardware nachahmt - Fehler finden #1: Die Race Condition, die das Förderband zum Absturz brachte

Link down: Testen Sie diese Zeitsequenz selbst im Entprelllogik-Schnellstart-Preset in OLLA Lab.

- Up (Pillar Hub): Pillar-Leitfaden erkunden - Across: Verwandter Artikel 1 - Across: Verwandter Artikel 2 - Down (Commercial/CTA): Bauen Sie Ihr nächstes Projekt in OLLA Lab

- IEC 61131-3 (Programmierbare Steuerungen, Teil 3) - NFPA 79 Elektrischer Standard für Industriemaschinen - Omron Technischer Leitfaden: Grundlagen zu Relais- und Schalterkontaktprellen - Cherry MX Schaltertechnologie-Ressourcen