SPS–Vision-Handschlag mit eindeutigen Zuständen

Problem und Voraussetzungen

Kurze Triggerpulse und unquittierte Ergebnisse können Teile verlieren oder alte Entscheidungen wiederverwenden. Vereinbaren Sie Zustände vor der Zuordnung zu realen Signalen oder Protokollen. Der Anhang ist konzeptioneller Pseudocode.

Versuch vorbereiten

Definieren Sie Bereit, Beschäftigt, Ergebnis und Störung mit Teilekennung und passender Quittierung. 200 ms Verarbeitungsfrist und 500 ms Quittierungsfrist sind Beispielannahmen.

Schreiben Sie den Anwendungskontrakt vor I/O- oder Protokollzuordnung. Definieren Sie Anfragekennung, Zustandsverantwortung, Quittierung und Teileverbleib bei Fehler. Ready, Busy, Result und Fault sind Konzepte, keine zugesagten Register oder Befehle. Prüfen Sie reale Trigger- und Ergebnisschnittstellen. Dokumentieren Sie elektrische oder Netzwerkzeit getrennt von Prüfung. Ohne Transaktionskennung braucht die physische Schnittstelle ein geprüftes Zuordnungsverfahren; das nächste Ergebnis gehört nicht automatisch zum nächsten Teil. Beobachten Sie Austausch mit Traces oder geeigneter Messung.

Vorgehen

1. Erlauben Sie neue Anforderungen nur im Zustand Bereit und speichern Sie die Kennung vor Beschäftigt.
2. Veröffentlichen Sie Kennung und Ergebnis gemeinsam und halten Sie beide stabil.
3. Wechseln Sie erst nach passender Quittierung zu Bereit; falsche Kennungen werden abgewiesen.
4. Bei Fristablauf oder Aufnahmefehler melden Sie Störung, ohne altes OK als aktuell zu zeigen.
5. Prüfen Sie Anforderungen während Beschäftigt, Duplikate, verlorene Quittierung und Neustart.

VENDOR-NEUTRAL PSEUDOCODE — state semantics, not protocol commands
# Serialize these application events; names below are conceptual.
state = READY
generation = new_generation()
active_token = none
on_request(id):
    if state != READY: record_rejected_request(id); return
    active_token = (generation, id)
    state = BUSY
    arm_processing_deadline(active_token)
    start_bounded_inspection(active_token)
on_completed(token, value):
    if state != BUSY or token != active_token:
        record_stale_result(token); return
    cancel_processing_deadline(token)
    if not application_payload_valid(value):
        enter_fault(token, INVALID_PAYLOAD); return
    publish_stable_result(token, value)
    state = RESULT
    arm_acknowledgement_deadline(token)
on_acknowledge(token):
    if state != RESULT or token != active_token:
        record_unmatched_acknowledgement(token); return
    cancel_acknowledgement_deadline(token)
    clear_published_result()
    active_token = none
    state = READY
on_timeout(token, expected_state):
    if token != active_token or state != expected_state:
        record_stale_timer(token); return
    enter_fault(token, TIMEOUT)
on_acquisition_failure(token):
    if state == BUSY and token == active_token:
        enter_fault(token, ACQUISITION_FAILURE)
enter_fault(token, reason):
    cancel_all_deadlines(token)
    invalidate_pass_result()
    record_fault_and_pending_part(token, reason)
    state = FAULT
on_authorized_recovery:
    if state != FAULT: return
    resolve_part_disposition()
    stop_pending_work_and_clear_events()
    generation = new_generation()
    active_token = none
    state = READY

Ready übernimmt eine gültige Anfrage und bindet Kennung vor Aufnahme. Busy hält sie stabil und weist Folgeanfragen ausdrücklich ab oder puffert nach Entwurf, ohne Ersatz. Veröffentlichen Sie Ergebnis und Kennung gemeinsam bis passender Quittierung. Andere Quittierung löscht nichts. Timeout, Aufnahmefehler oder ungültige Daten führen definiert zu Fault und entwerten altes Gut. Rückkehr zu Ready braucht autorisierte Wiederherstellung mit Teileklärung. Das ist Prozesskoordination, kein Ersatz für unabhängige Maschinensicherheitssteuerung.

Beispielhaftes Prüfprotokoll

Rechen- und Prüfannahmen, keine gemessenen Deyi-Ergebnisse. Ersetzen Sie diese Werte durch Ihre eigenen freigegebenen Prüfprotokolle.

Halten Sie für T300 Ergebnis und Kennung bis zur passenden Quittierung oder zum definierten Fehlerübergang stabil. Prüfen Sie eine zweite Anfrage bei Busy, eine Quittierung für T299, ein Ergebnis nach Timeout und einen Steuerungsneustart. Protokollieren Sie Zustand und tatsächlichen Teileverbleib. Beenden Sie alte Timer oder prüfen Sie ihre Generation, damit T300 keine spätere Anfrage stört. Der Anhang beschreibt Verhalten; Signale und Telegramme hängen vom gewählten Steuerungsprotokoll ab.

Jeder Timer braucht Eigentümer, Startgrenze und Anfragegeneration. Die Beispielfristen prüfen verschiedene Wartephasen und sind keine Geräteeinstellungen. Beenden Sie Timer beim Zustandswechsel oder prüfen Sie Kennung und Generation. Späte Fertigstellung bleibt Diagnose und darf nach Fehler oder Ersatz nicht veröffentlichen. Quittungsverlust ist nicht gleich Prüffehler: Entscheidung kann gültig, Transaktion offen sein. Legen Sie erneutes stabiles Senden, Teileabsicherung oder Bedienerklärung fest. Nutzen Sie dokumentiertes Wiederverbinden; gesunde Verbindung klärt alte Transaktion nicht automatisch.

Zwei Ansichten des Ablaufs

Fehlersuche

• Zu kurze Pulse benötigen geänderte Signale oder Protokollführung.
• Eine falsche Quittierungskennung weist auf Reihenfolge- oder Listenfehler hin.
• Automatisches Löschen einer Störung kann ungeprüfte Teile verbergen.

Abnahme und Übergabe

Jede Anforderung braucht genau einen nachvollziehbaren Endstatus ohne Überschreiben. Prüfen Sie Fristen und Rücksetzen auf beiden Seiten, auch nach Stromausfall. 200/500 ms belegen keine Gerätekompatibilität.

Legen Sie die Abnahmegrenzen vor dem Versuch fest und bewahren Sie die Originaldaten auf. Die Beispiele belegen keine Eigenschaften eines angebotenen Modells.

Prüfen Sie eine vorher erstellte Soll-Zustandstabelle: Normalfall, zweite Anfrage bei Busy, falsche oder doppelte Quittierung, fehlendes Bild, späte Fertigstellung, Verbindungsverlust und Neustart. Vergleichen Sie Zustand, aktive Kennung, Ergebnis und Teileverbleib. Neustart darf altes Gut nicht neu veröffentlichen. Prüfen Sie Grenzfehler für Timer- und Ergebnisrennen und wiederholen Sie Normalablauf. Übergeben Sie Zustände, Timer, Traces, Wiederherstellung und echte Signalzuordnung. Der neutrale Anhang braucht gerätespezifische Implementierungsprüfung, ist kein SPS-Befehl oder Deyi-Funktionsnachweis.

Weiterführende Informationen

Lesen Sie vor der Geräteauswahl die verknüpften Auswahl- und Anwendungsleitfäden. Für eine technische Prüfung benötigen wir Beispielbilder, das geforderte Ergebnis, Betriebsbedingungen und Ihr Prüfprotokoll.