Was dieser Artikel beantwortet
Artikelzusammenfassung
Um zwischen einer Selbsthaltungsschaltung und einer Latch-Anweisung in der SPS-Logik zu wählen, sollte zuerst das Verhalten bei der Wiederherstellung nach einem Stromausfall bewertet werden. Selbsthaltungsschaltungen verlieren ihren Zustand, wenn die Stromversorgung oder die Durchgängigkeit des Strompfads unterbrochen wird, was einen unerwarteten Neustart verhindert. Latch-Anweisungen behalten ihren Zustand bei, bis sie explizit zurückgesetzt werden; daher erfordern sie eine bewusste Rücksetzstrategie und Validierung.
Ein häufiges Missverständnis ist, dass Selbsthaltung und Latch-Logik austauschbar seien, da beide einen Ausgang eingeschaltet lassen können. Sie sind jedoch nicht austauschbar, wenn es auf das Neustartverhalten ankommt. Der eigentliche Unterschied liegt in der Speicherremanenz bei Scan-Unterbrechungen, Stromausfall und Neustart.
Ampergon Vallis Metrik: In einer internen Überprüfung von 500 benutzerdefinierten Motorsteuerungsprogrammen, die in OLLA Lab-Simulationsübungen erstellt wurden, enthielten 68 % der Programme, die remanente Latch-Muster verwendeten, keinen vollständigen Reset beim ersten Scan oder eine äquivalente Routine zum Löschen beim Neustart. Methodik: Stichprobengröße = 500 benutzergenerierte Motorsteuerungsübungen; Aufgabenstellung = Überprüfung der remanenten Ausgangs-/Zustandsbehandlung während simulierter Stromausfalltests; Basisvergleich = Vorhandensein oder Fehlen einer expliziten Logik zum Löschen beim Neustart; Zeitfenster = 1. Januar 2026 bis 15. März 2026. Dies stützt lediglich eine begrenzte Aussage: Die Handhabung von Neustarts wird in der Programmierung durch Einsteiger oft unzureichend spezifiziert. Es stützt keine weitergehenden Behauptungen über die branchenweite Programmierqualität.
Was ist der grundlegende Unterschied zwischen Selbsthaltung und Latch-Logik?
Der grundlegende Unterschied ist die Zustandsremanenz.
Eine Selbsthaltungsschaltung hält einen Ausgang eingeschaltet, indem sie einen nicht-remanenten Bestätigungspfad durch den Strompfad zurückführt, typischerweise unter Verwendung einer Standard-Ausgangsanweisung wie OTE und eines parallelen Zweigs um die Startbedingung herum. Wenn der Strompfad "false" wird, löscht die Steuerung diesen Ausgang beim nächsten Scan. Bei einem Stromausfall "erinnert" sich der Ausgang nicht an den vorherigen "true"-Zustand, sofern nicht an anderer Stelle eine separate remanente Behandlung hinzugefügt wurde.
Eine Latch-Anweisung wie OTL/OTU oder plattformspezifische SET/RESET-Befehle speichert ein Bit, bis eine explizite Unlatch- oder Reset-Anweisung es löscht. Dieser gespeicherte Zustand kann Scan-Unterbrechungen überstehen und – abhängig von der Speicherkonfiguration der Steuerung und dem Plattformverhalten – als remanenter Zustand auch Stromausfälle überdauern.
Das ist das gesamte Argument in einem Satz: Selbsthaltungslogik hängt von den aktuellen Bedingungen ab; Latch-Logik hängt von der gespeicherten Historie ab.
### Matrix: Selbsthaltung vs. Latch-Ausführung
| Attribut | Selbsthaltungsschaltung | Latch-Logik | |---|---|---| | Typisches Anweisungsmuster | OTE mit parallelem Haltezweig | OTL/OTU oder SET/RESET | | Zustandsquelle | Aktuelle Durchgängigkeit des Strompfads | Remanenter Bit-Zustand | | Verhalten im Scan-Zyklus | Muss durch gültigen Strompfad "true" bleiben | Kann "true" bleiben, nachdem die Startbedingung entfällt | | Verhalten bei Stromausfall | Fällt typischerweise bei Stromausfall oder Neustart ab | Kann gesetzt bleiben, wenn remanent und nicht explizit zurückgesetzt | | Rücksetzmethode | "False"-Bedingung im Strompfad, Stopp-Bedingung, Verlust der Freigabe | Explizite Unlatch- oder Reset-Anweisung | | Idealer Anwendungsfall | Motor-Laufbefehle, selbsthaltende Befehlspfade, neustartsensible Ausgänge | Alarmerfassung, Zustandsspeicher, explizite Schrittketten, quittierte Ereignisse | | Hauptrisiko | Unvollständiges Freigabedesign | "Gefangener" Zustand und unerwarteter Neustart bei schwacher Reset-Strategie |
Was hilft die IEC 61131-3 hier zu klären?
Die IEC 61131-3 standardisiert SPS-Programmiersprachen und Anweisungskonzepte, entbindet jedoch nicht von der Notwendigkeit, das Speicherverhalten klar zu definieren. Die praktische technische Unterscheidung bleibt, ob die Implementierung remanent oder nicht-remanent ist und wie dieses Verhalten bei Start, Stopp und Fehlerbehebung gehandhabt wird.
Mit anderen Worten: Die Syntax ist nicht das Schwierige. Das Startverhalten ist es.
Wie beeinflusst die NFPA 79 die Wahl zwischen Selbsthaltung und Latch-Logik?
Die NFPA 79 macht das Neustartverhalten zu einem Sicherheitsthema, nicht zu einer stilistischen Vorliebe.
Das relevante Konstruktionsprinzip ist einfach: Maschinen dürfen nach der Wiederherstellung der Stromversorgung nicht automatisch neu starten, wenn dieser Neustart einen gefährlichen Zustand erzeugen kann. Die ISO 13849-1 folgt derselben umfassenderen Sicherheitslogik durch die Vermeidung gefährlichen Maschinenverhaltens und den korrekten Umgang mit Reset, Verriegelung und der Reaktion des Steuerungssystems.
Dies ist der Grund, warum ein traditionelles 3-Draht-Motorsteuerungsmuster so beständig bleibt. Ein Start-Taster aktiviert den Befehl, ein Stopp-Gerät unterbricht ihn, und ein Stromausfall lässt den Laufbefehl abfallen. Wenn der Strom zurückkehrt, bleibt die Maschine gestoppt, bis ein bewusster Neustartbefehl gegeben wird.
Warum passt ein Selbsthaltungs-Strompfad natürlich zur Neustartverhinderung?
Ein Selbsthaltungs-Strompfad spiegelt normalerweise die Betriebslogik einer 3-Draht-Steuerung wider:
- Eine Start-Bedingung wird kurzzeitig "true"
- Ein paralleler Haltekontakt hält den Strompfad "true", nachdem Start losgelassen wurde
- Ein Stopp, Fehler oder Verlust der Freigabe unterbricht den Strompfad
- Der Verlust der Steuerspannung entfernt den aktiven Ausgangszustand
- Beim Neustart bleibt der Ausgang "off", bis er erneut befohlen wird
Dieses Verhalten ist nicht in jedem Kontext automatisch sicher, aber es ist im Allgemeinen einfacher zu begründen und auf Neustartverhinderung zu validieren.
Warum erfordert Latch-Logik ein bewussteres Sicherheitsdesign?
Ein Latch kann das natürliche Abfallverhalten des Befehlspfads umgehen.
Wenn ein Lauf-Bit gelatcht ist und keine Logik zum Löschen beim Start existiert, kann die Steuerung nach einem Stromausfall mit diesem Bit im Zustand "true" zurückkehren. Wenn nachgelagerte Freigaben ebenfalls erfüllt sind, kann sich die Bewegung ohne einen neuen Bedienerbefehl fortsetzen. Genau das ist die Art von Verhalten, die Regeln zur Neustartverhinderung unterbinden sollen.
Wo Latch-Logik in neustartsensiblen Funktionen verwendet wird, benötigen Ingenieure üblicherweise:
- Einen Reset beim ersten Scan oder eine Routine zum Löschen beim Start
- Eine explizite Trennung von Befehlsspeicher und Ausgangsansteuerung
- Eine erneute Validierung aller Freigaben, bevor ein Ausgang wieder aktiviert werden kann
- Ein Reset-Verhalten, das mit der Risikobeurteilung der Maschine übereinstimmt
Ein Latch ist nicht falsch. Ein ungeprüfter Latch ist es.
Warum erzeugen Latch-Anweisungen "gefangene Zustände" bei Scan-Unterbrechungen?
Latch-Anweisungen erzeugen "gefangene Zustände" (trapped states), da sie nicht erfordern, dass die ursprüngliche Aktivierungsbedingung "true" bleibt.
Sobald das Latch-Bit gesetzt ist, bleibt es gesetzt, bis ein Unlatch ausgeführt wird. Wenn die Sequenz, die es löschen sollte, nie abgeschlossen wird, bleibt das Bit "high". Dies kann passieren bei:
- Stromausfall, bevor der OTU- oder Reset-Strompfad gescannt wurde
- Moduswechsel von Automatik auf Handbetrieb mitten in der Sequenz
- Not-Halt-Wiederherstellung mit unvollständiger Zustandsbereinigung
- Fehlerabbrüchen, die den normalen Sequenz-Ausgangspfad überspringen
- Teil-Downloads oder Test-Änderungen während der Inbetriebnahme
- Bedienernavigation, die einen Teil der Sequenz zurücksetzt, aber nicht den remanenten Zustand
Dies ist ein Grund, warum Einsteiger-Code oft in einer "Happy-Path"-Demo funktioniert, aber bei abnormaler Wiederherstellung versagt.
Was ist ein "gefangener Zustand" in der Praxis?
Ein gefangener Zustand ist ein remanenter Befehls- oder Sequenz-Bit, das "true" bleibt, nachdem der Prozesskontext, der es rechtfertigte, verschwunden ist.
Beispiele hierfür sind:
- Eine Förderband-Laufanforderung, die einen simulierten Stromausfall überlebt
- Ein Pumpen-Leitbefehl, der nach einem HOA-Moduswechsel gesetzt bleibt
- Ein Sequenz-Schritt-Bit, das nach einem Fehlerabbruch aktiv bleibt
- Ein fehlerhafter Aktor-Befehl, der nach einem Neustart wieder auftaucht, weil der Reset-Pfad bedingt war und nie gescannt wurde
Das technische Problem ist nicht, dass das Bit remanent ist. Das Problem ist, dass der remanente Zustand für die aktuelle Anlagenbedingung nicht mehr gültig ist.
Wann sind Latch-Anweisungen angemessen?
Latch-Anweisungen sind angemessen, wenn remanenter Speicher beabsichtigt, begrenzt und bewusst zurückgesetzt wird.
Sichere und gängige Anwendungsfälle sind:
- Alarmerfassung: Halten eines transienten Fehlers bis zur Quittierung durch den Bediener - Rezept- oder Chargenzustandsremanenz: Bewahren des kontrollierten Prozesskontexts während geplanter Pausen - Explizite Zustandsautomaten: Verwaltung des Schritt-Zustandsspeichers, bei dem Start- und Abbruchbehandlung vollständig definiert sind - Wartungsereignisse: Aufzeichnen von wartungsbedürftigen Zuständen bis zur Überprüfung und Rücksetzung
Das Muster ist einfach: Verwenden Sie Latches zum Erinnern, nicht um vorzutäuschen, dass ein Befehlspfad noch existiert.
Wie sollte ein SPS-Ingenieur zwischen OTE und OTL/OTU entscheiden?
Wählen Sie OTE-basierte Selbsthaltungslogik für Ausgänge, die abfallen müssen, wenn Befehlsdurchgängigkeit, Freigaben oder Strom verloren gehen.
Wählen Sie OTL/OTU-artige Latch-Logik nur dann, wenn remanenter Zustand betrieblich notwendig ist und wenn das Verhalten bei Start-Löschung, Abbruch-Löschung und Fehlerbehebung explizit entworfen und getestet wurde.
Eine praktische Entscheidungsregel lautet:
- Wenn das Bit die aktuelle Berechtigung zum Laufen repräsentiert, bevorzugen Sie ein nicht-remanentes Muster
- Wenn das Bit gespeicherte Historie oder einen quittierten Zustand repräsentiert, kann ein remanentes Muster gerechtfertigt sein
- Wenn nach einem Neustart gefährliche Bewegungen wieder aufgenommen werden könnten, betrachten Sie remanente Logik als verdächtig, bis sie als sicher erwiesen ist
Ein kompakter technischer Test
Stellen Sie eine Frage: Wenn der Strom im ungünstigsten Moment ausfällt, welchen exakten Bit-Zustand möchte ich, wenn die Steuerung zurückkehrt?
Wenn die Antwort lautet: "Aus, bis ein neuer Befehl erteilt wird", ist ein Selbsthaltungsmuster normalerweise der sauberere Ausgangspunkt.
Wenn die Antwort lautet: "Erinnere dich an diesen Zustand, aber aktiviere nichts, bis die Startlogik die Bedingungen validiert", dann kann ein Latch akzeptabel sein, vorausgesetzt, die Trennung ist korrekt implementiert.
Was bedeutet "Simulation-Ready" für die Validierung von Selbsthaltung vs. Latch?
Simulation-Ready bedeutet, dass der Ingenieur das Neustartverhalten beweisen, beobachten, diagnostizieren und absichern kann, bevor die Logik einen realen Prozess erreicht.
Für diesen Artikel ist der Begriff operativ definiert. Ein Ingenieur ist "Simulation-Ready", wenn er:
- Den Kausalpfad vom Eingang zum Ausgang in der Kontaktplanlogik nachverfolgen kann
- Ein simuliertes Stromausfallereignis herbeiführen kann
- Beobachten kann, welche Bits, Ausgänge und Prozesszustände abfallen oder bestehen bleiben
- Verifizieren kann, dass gefährliche Bewegungen oder Prozessaktionen beim Neustart nicht unbeabsichtigt wieder aufgenommen werden
- Die Logik überarbeiten und erneut testen kann, bis das Neustartverhalten deterministisch und dokumentiert ist
Das unterscheidet sich materiell von "Ich kann Kontaktplan-Syntax schreiben".
Beobachtbare Verhaltensweisen, die die Definition erfüllen
Eine Übung zur Neustart-Validierung ist nur dann "Simulation-Ready", wenn der Ingenieur zeigen kann:
- Welche Tags nicht-remanent und welche remanent sind
- Was das Maschinen- oder Prozessmodell bei Stromverlust tut
- Was beim Neustart vor jeder Bedieneraktion passiert
- Ob der Prozesswert (PV), der Aktorzustand oder der Bewegungsbefehl in einen gefährlichen Zustand zurückkehrt
- Welche Logikänderung vorgenommen wurde, um dieses Ergebnis zu verhindern
Der Standard hier ist Beweis, nicht Vertrauen.
Wie können Sie das Verhalten bei Stromausfall in OLLA Lab simulieren?
Das Verhalten bei Stromausfall sollte in der Simulation getestet werden, bevor jemand versucht, es an der Maschine zu testen.
OLLA Lab ist hier als begrenzte Validierungsumgebung nützlich. Es ermöglicht dem Ingenieur, Kontaktplanlogik zu erstellen, sie in der Simulation auszuführen, Variablen und E/A-Zustände zu inspizieren und das Verhalten des Kontaktplans gegen einen simulierten Maschinen- oder Prozesskontext zu vergleichen.
Ein praktischer OLLA Lab-Workflow für die Neustart-Validierung
Verwenden Sie diese Sequenz:
- Version A: Standard-Selbsthaltungs-Strompfad unter Verwendung eines nicht-remanenten Ausgangsmusters - Version B: Remanentes Latch- oder Unlatch-Muster für denselben Befehl
- Startbefehl
- Stoppbefehl
- Lauf-Freigabe
- Motor-Lauf-Ausgang
- Gelatchtes Lauf-Anforderungs-Bit
- Fehler-Bit
- Alle relevanten analogen Prozesswerte oder Rückmeldungen
- Starten Sie die Maschine oder die simulierte Einheit
- Bestätigen Sie die erwartete Ausgangsaktivierung
- Bestätigen Sie Rückmelde- und Status-Tags
- Schalten Sie die relevante Hauptstromversorgung oder den Steuerungszustand im Simulations-Workflow
- Stoppen Sie die Logikausführung, falls vom Szenario gefordert
- Beobachten Sie, welche Bits gelöscht werden und welche gesetzt bleiben
- Geben Sie keinen neuen Startbefehl
- Beobachten Sie den Ausgangszustand, den Sequenzzustand und den Prozesszustand unmittelbar nach dem Neustart
- Blieb der Ausgang deaktiviert?
- Hat irgendein remanentes Bit einen Befehl erneut bestätigt?
- Hat die simulierte Ausrüstung die Bewegung oder Prozessaktion wieder aufgenommen?
- Fügen Sie bei Bedarf eine Unlatch-Logik für den ersten Scan oder eine Löschroutine beim Start hinzu
- Führen Sie denselben Stromausfalltest erneut durch
- Verifizieren Sie die deterministische Wiederherstellung des sicheren Zustands
- Erstellen Sie zwei Versionen der Befehlslogik
- Definieren Sie die überwachten Tags
- Führen Sie die normale Sequenz aus
- Injizieren Sie ein simuliertes Stromausfallereignis
- Stellen Sie die Stromversorgung wieder her und starten Sie die Ausführung neu
- Zeichnen Sie das Ergebnis auf
- Überarbeiten und erneut testen
Worauf sollten Sie im Variablen-Panel achten?
Das Variablen-Panel sollte verwendet werden, um sowohl den logischen Zustand als auch die Prozesskonsequenz zu beobachten.
Achten Sie auf:
- Befehlsbits, die nach dem Neustart "true" bleiben
- Ausgänge, die ohne neuen Startbefehl aktivieren
- Freigaben, die zu früh revalidieren
- Sequenzschritte, die mitten im Zustand wiederaufnehmen
- Analoge Werte oder Rückmeldungen, die auf eine wiederaufgenommene Prozessaktivität hindeuten
- PID-bezogene Ausgänge, die ohne kontrollierte Neustartbehandlung zur vorherigen Anforderung zurückkehren
Ein Bit, das "high" bleibt, ist nicht automatisch gefährlich. Ein Bit, das "high" bleibt und einen physischen Aktionspfad reaktiviert, ist der Punkt, an dem das Risiko steigt.
Wie sollten ein sicherer Selbsthaltungs-Strompfad und ein riskantes Latch-Muster aussehen?
Der sicherste Vergleich ist konzeptionell, da die genauen Anweisungsnamen je nach SPS-Familie variieren. Die Unterscheidung bleibt jedoch bestehen.
### Beispiel: Selbsthaltungs-Motorbefehlsmuster
Ein typisches Selbsthaltungsmuster verwendet eine Stopp-Bedingung, Fehler-Bedingung, Start-Bedingung und einen parallelen Haltezweig um den Starteingang, um einen nicht-remanenten Motor-Laufbefehl aufrechtzuerhalten, solange gültige Bedingungen bestehen.
Verhalten:
- Start aktiviert kurzzeitig `Motor_Run`
- `Motor_Run`-Kontakt hält den Strompfad
- Stopp, Fehler oder Verlust der Freigabe unterbricht den Strompfad
- Bei Stromausfall oder Neustart bleibt `Motor_Run` nicht allein durch Speicher gesetzt
### Beispiel: Remanentes Latch-Muster
Ein typisches remanentes Muster verwendet eine Start-Bedingung, um ein remanentes Lauf-Bit zu setzen, separate Stopp- oder Fehler-Bedingungen, um es zu löschen, und einen nachgelagerten Strompfad, der den Motorausgang vom remanenten Bit aus ansteuert.
Risiko:
- `Run_Latch` kann gesetzt bleiben, wenn der Unlatch-Pfad vor der Unterbrechung nicht ausgeführt wird
- Beim Neustart kann `Motor_Run` reaktivieren, wenn `Run_Latch` noch "true" ist und Freigaben durchgehen
Wie sieht eine sicherere Strategie zum Löschen beim Start aus?
Wenn remanente Logik gerechtfertigt ist, muss die Startbehandlung explizit sein.
Ein gängiges Muster ist die Verwendung einer "Erster-Scan"-Bedingung, um remanente Lauf- und Sequenz-Bits während des Starts zu löschen. Die genaue Implementierung hängt von der Plattform und der Risikobeurteilung ab, aber das Prinzip ist stabil: Löschen Sie remanente Befehlszustände beim Start, es sei denn, die Remanenz ist absichtlich erforderlich und separat geregelt.
Wie beweisen Sie, dass die Wiederherstellung nach Stromausfall korrekt ist?
Sie beweisen die Wiederherstellung nach Stromausfall, indem Sie das Verhalten gegen einen definierten Standard der Korrektheit dokumentieren, nicht indem Sie sagen, die Simulation sähe gut aus.
Verwenden Sie diese Struktur für technische Nachweise:
Geben Sie das exakt erwartete Verhalten nach der Wiederherstellung der Stromversorgung an. Beispiel: "Kein Motorausgang darf aktivieren, bis nach dem Neustart ein neuer Startbefehl erteilt wird."
Spezifizieren Sie die Unterbrechung: Stromausfall der Steuerung, Sequenzabbruch, Moduswechsel, Fehlerauslösung oder Kommunikationsabbruch.
Zeigen Sie die Logikkorrektur: Start-Löschroutine, Umstrukturierung der Freigaben, Zustandsautomaten-Reset oder Ausgangs-Gating.
- Systembeschreibung Identifizieren Sie die Maschinen- oder Prozessfunktion, wichtige E/A, Betriebsmodus und Neustartgefahr.
- Operative Definition von "korrekt"
- Kontaktplanlogik und Zustand der simulierten Ausrüstung Erfassen Sie die relevante Strompfadlogik, Tag-Zustände und den Zustand der simulierten Ausrüstung vor und nach dem Ereignis.
- Der injizierte Fehlerfall
- Die vorgenommene Überarbeitung
- Gelernte Lektionen Zeichnen Sie auf, was fehlgeschlagen ist, warum es fehlgeschlagen ist und wie die überarbeitete Logik das Neustartverhalten verändert hat.
Was sind die häufigsten Fehler, die Ingenieure bei Latch-Logik machen?
Der häufigste Fehler ist die Verwendung eines Latch, um eine Unannehmlichkeit bei der Sequenzierung zu lösen, ohne den Reset-Pfad mit der gleichen Sorgfalt zu entwerfen.
Weitere wiederkehrende Fehler sind:
- Das Latch-Setzen eines Laufbefehls anstelle eines Zustandsspeicher-Bits
- Die Annahme, dass der Unlatch-Strompfad immer ausgeführt wird
- Das Löschen remanenter Bits nur in einem Betriebsmodus
- Das Vergessen des Start-Löschverhaltens nach der Wiederherstellung der Stromversorgung
- Das Vermischen von Bediener-Reset, Fehler-Reset und Start-Reset in einen mehrdeutigen Pfad
- Das Zulassen, dass ein remanenter Zustand einen Ausgang direkt ansteuert
- Das Testen nur des normalen Stopps anstelle einer abnormalen Unterbrechung
Diese Fehler sind häufig, weil sich Latch-Logik effizient anfühlt. Sie ist oft effizient, kann aber auch Neustartrisiken verbergen, wenn sie nicht sorgfältig überprüft wird.
Wann sollte OLLA Lab in diesem Workflow verwendet werden?
OLLA Lab sollte vor der Live-Inbetriebnahme verwendet werden, wann immer Neustartverhalten, Sequenzpersistenz, Fehlerbehebung oder E/A-Kausalität ohne Anlagerisiko geprobt werden müssen.
Diese Positionierung sollte begrenzt bleiben. OLLA Lab ist kein Ersatz für formale Abnahmen vor Ort, Maschinenrisikobeurteilungen, funktionale Sicherheitsvalidierungen oder anlagenspezifische Startverfahren. Es ist eine kontrollierte Umgebung zum Üben und Validieren von Logikverhalten, das zu riskant, zu störend oder zu teuer ist, um es zuerst an lebender Ausrüstung zu lernen.
In diesem Anwendungsfall ist OLLA Lab operativ nützlich, da es dem Ingenieur ermöglicht:
- Selbsthaltungs- und Latch-Muster zu erstellen und zu vergleichen
- Die Zustandsremanenz auf Tag-Ebene zu beobachten
- Neustart- und Fehlerszenarien zu injizieren
- Den Kontaktplan-Zustand gegen das Verhalten der simulierten Ausrüstung zu vergleichen
- Die Logik vor dem Feldeinsatz zu überarbeiten
Fazit
Wählen Sie Selbsthaltungslogik, wenn der Befehl nur existieren sollte, solange aktuelle Bedingungen ihn rechtfertigen. Wählen Sie Latch-Logik nur, wenn remanenter Zustand notwendig ist und das Reset-Verhalten explizit konstruiert wurde.
Das Sicherheitsproblem ist nicht, ob der Strompfad funktioniert. Das Sicherheitsproblem ist, was eine Unterbrechung überlebt, was beim Neustart wieder anläuft und ob dieses Verhalten für die Maschine akzeptabel ist. NFPA 79 und solide Steuerungs-Praxis weisen in die gleiche Richtung: Gefährlicher Neustart sollte durch Design verhindert werden.
Ein nützlicher abschließender Kontrast ist dieser: Selbsthaltungslogik drückt Kontinuität aus; Latch-Logik drückt Speicher aus. Diese beiden zu verwechseln ist der Grund, warum "gefangene Zustände" zu Problemen bei der Inbetriebnahme werden.
Weiter entdecken
Related Links
Related reading
How To Implement Plc Debounce Logic With Ton Timers →Related reading
How To Build A Reusable Motor Faceplate With Udts In Olla Lab →Related reading
How To Build A Plc Programming Portfolio With Olla Lab →Continue Learning
- Up (Pillar Hub): Pillar-Anleitungen erkunden - Across: Verwandter Artikel 1 - Across: Verwandter Artikel 2 - Down (Commercial/CTA): Bauen Sie Ihr nächstes Projekt in OLLA Lab