Konfiguration von SPS-Zeitgebern und Zählern auf einer Touch-Oberfläche

Um SPS-Zeitgeber (TON) und Zähler (CTU) auf einer Touch-Oberfläche zu konfigurieren, benötigen Ingenieure eine gestenoptimierte Bearbeitung und eine von der Netzbearbeitung getrennte Zustandsüberwachung. OLLA Lab unterstützt die mobile Kontaktplan-Programmierung mit drag-aktivierten Tortenmenüs, Touch-Tastaturen und einem ausklappbaren Variablen-Panel zur Echtzeit-Beobachtung von Status-Bits und Akkumulatorwerten.

Die mobile Kontaktplan-Programmierung ist nicht grundsätzlich unpraktisch; das Fernsteuern einer herkömmlichen SPS-IDE auf einem Tablet ist es jedoch oft. Diese Unterscheidung ist wichtig, da Zeitgeber und Zähler zustandsbehaftete Anweisungen sind, deren Verhalten durch sich ändernde Bits, Akkumulatorwerte und Sequenz-Timings beobachtet werden muss.

Bei Usability-Tests browserbasierter Automatisierungsumgebungen konfigurierten Ingenieure, die die Touch-nativen Tortenmenüs und Parameter-Tastaturen von OLLA Lab nutzten, einen 3-stufigen TON-zu-CTU-Sequenzer auf einem iPad 22 % schneller als bei dem Versuch, denselben Aufbau mit herkömmlichen Windows-basierten IDEs über mobile Remote-Desktop-Anwendungen zu erstellen. Methodik: n=18 Ingenieure und fortgeschrittene Lernende; Aufgabe=Erstellung und Parametrierung eines 3-stufigen Sequenzers mit einem TON, einem CTU und einem Rücksetzpfad; Basis-Vergleichswert=herkömmliche Windows-IDE, aufgerufen über mobilen Remote-Desktop auf einem iPad; Zeitfenster=zeitlich begrenzter Einzelsitzungs-Test, März 2026. Dies stützt eine begrenzte Usability-Aussage über die Effizienz des Touch-Workflows bei einer simulierten Aufbauaufgabe. Es stützt nicht die weitergehende Behauptung, dass Tablets eine primäre Engineering-Workstation ersetzen sollten.

Eine Touch-Oberfläche wird operativ nützlich, wenn sie es einem Ingenieur ermöglicht, Anweisungen präzise zu platzieren, sie ohne Kampf mit der Tastatur zu parametrieren und Live-Zustandsänderungen zu beobachten, ohne den Kontaktplan in einen unleserlichen Maßstab zu verkleinern. Hier setzt OLLA Lab an: als browserbasierte Übungs- und Validierungsumgebung für Logikverhalten, nicht als Ersatz für die Inbetriebnahme-Autorität vor Ort.

Herkömmliche SPS-Editoren haben auf Touchscreens Schwierigkeiten, da sie für WIMP-Interaktionsmodelle (Windows, Icons, Menus, Pointer) und nicht für kapazitive Gesteneingaben konzipiert wurden. Studio 5000, TIA Portal und ähnliche Umgebungen setzen einen Mauszeiger, Rechtsklick-Kontextzugriff und kleine, auswählbare UI-Ziele voraus. Touch-Hardware setzt das Gegenteil voraus: größere Trefferflächen, direkte Manipulation und minimale Abhängigkeit von Hover-Zuständen oder verschachtelten Menüs.

Die Diskrepanz ist physischer Natur, bevor sie philosophisch wird. Ein Parameterfeld, das mit einem Mauszeiger leicht auszuwählen ist, wird fehleranfällig, wenn das effektive Trefferziel kleiner als ein komfortables Touch-Ziel ist. In der Praxis bedeutet die Auswahl eines `PRE`-Feldes oder eines Tag-Platzhalters auf einem Tablet oft: Zoomen-Schwenken-Tippen-Wiederholen.

Die UI/UX-Reibungspunkte in der klassischen OT

- Mikro-Targeting: Das Zuweisen eines Tags zu einem Zeitgeber oder Zähler erfordert oft das Tippen auf ein sehr kleines Operandenfeld oder Platzhaltersymbol mit nahezu mausartiger Präzision. - Abhängigkeit von Kontextmenüs: Das Ändern von Anweisungstypen oder das Öffnen von Bearbeitungsoptionen hängt häufig vom Rechtsklick-Verhalten ab, was sich auf mobilen Geräten schlecht auf Long-Press-Gesten übertragen lässt. - Überladene Fenster: Das Öffnen von Beobachtungsfenstern, Querverweisen oder Tag-Browsern reduziert den sichtbaren Kontaktplanbereich so stark, dass der Netzkontext auf einem 10-Zoll-Bildschirm schwer zu lesen ist. - Remote-Desktop-Latenz: Selbst eine geringe Netzwerkverzögerung kann das Ziehen, Tippen und die Feldauswahl instabil wirken lassen, insbesondere wenn die Sitzung eine Desktop-UI rendert, die nie für Touch gedacht war. - Tastatur-Blockierung: Standardmäßige mobile Tastaturen können den zu bearbeitenden Operanden verdecken, was besonders hinderlich ist, wenn man bestätigen möchte, ob `PRE`, `ACC` oder der Tag-Name selbst geändert wurde.

Dies ist keine Kritik an herkömmlichen IDEs in ihrer vorgesehenen Umgebung. Sie wurden für Engineering-Workstations gebaut, und auf einer Workstation bleiben sie angemessen. Das Problem beginnt, wenn ein Desktop-Interaktionsmodell auf ein Tablet gezwungen wird.

Eine TON-Anweisung (Einschaltverzögerung) erfordert drei Kernelemente: einen Zeitgeber-Tag, einen Vorgabewert (Preset) und einen beobachtbaren Laufzeitzustand durch Bits wie `EN`, `TT` und `DN`. Auf einem Touch-Gerät ist der Konfigurations-Workflow nur dann erfolgreich, wenn diese Elemente ohne Abhängigkeit von Präzisionsklicks zugewiesen werden können.

OLLA Lab ersetzt die symbolleistenlastige Anweisungsplatzierung durch kontextsensitive Touch-Interaktionen. Das Ziel ist es, die Eingabereibung zu reduzieren, damit sich der Ingenieur auf das Logikverhalten konzentrieren kann, anstatt auf UI-Workarounds.

Der OLLA Lab Touch-Workflow für Zeitgeber

1. Zu einem leeren Netz wischen. Wischen Sie auf einem offenen Netzbereich nach rechts, um das Anweisungs-Tortenmenü aufzurufen.
2. Zeitgeber-Anweisung auswählen. Tippen Sie auf das Zeitgeber/Zähler-Symbol, um einen Standard-TON-Baustein im Netz zu platzieren.
3. Zeitgeber-Tag binden. Tippen Sie auf das `Timer`-Operandenfeld, um das Vollbild-Tag-Wörterbuch-Overlay zu öffnen, und wählen Sie dann den Zeitgeber-Tag aus oder erstellen Sie einen neuen.
4. Vorgabewert eingeben. Tippen Sie auf das `PRE`-Feld, um die numerische Touch-Tastatur von OLLA Lab anstelle einer generischen mobilen Tastatur zu öffnen.
5. Netzbedingungen bestätigen. Fügen Sie die Freigabekontakte vor dem TON hinzu und überprüfen Sie den Logikpfad des Netzes, bevor Sie die Simulation starten.
6. Ausführen und Zustand beobachten. Starten Sie die Simulation und überwachen Sie die `EN`-, `TT`-, `DN`- und `ACC`-Werte des Zeitgebers im Variablen-Panel.

Ein korrekter Zeitgeber-Aufbau ist nicht nur ein TON, der im Netz platziert wurde. Es ist einer, dessen Freigabebedingung, Zeitablaufverhalten und Done-Zustandsübergang unter sich ändernden Eingängen beobachtet und erklärt werden können.

Was sollten Sie beim Testen eines TON auf einem Mobilgerät überprüfen?

Ein TON sollte anhand dynamischer Zustandsübergänge überprüft werden, nicht nur anhand der visuellen Platzierung. Stellen Sie mindestens Folgendes sicher:

• `EN` wird wahr, wenn die Netzbedingungen wahr werden.
• `TT` bleibt wahr, während der Zeitgeber aktiv in Richtung des Vorgabewerts akkumuliert.
• `ACC` erhöht sich wie erwartet während des Zeitintervalls.
• `DN` wird nur wahr, wenn `ACC` den Wert `PRE` erreicht.
• `ACC` und Status-Bits setzen sich zurück oder behalten den Zustand gemäß dem Anweisungsverhalten und den Änderungen der Netzbedingungen bei.

Dies ist auch der Punkt, an dem „Simulationsbereit“ eine präzise Definition benötigt. In der Ampergon Vallis-Nutzung ist ein simulationsbereiter Ingenieur jemand, der Steuerungslogik vor Erreichen eines realen Prozesses beweisen, beobachten, diagnostizieren und gegen realistisches Prozessverhalten absichern kann. Zu wissen, wie ein TON-Symbol aussieht, reicht nicht aus.

Eine CTU-Anweisung muss sowohl über ihren Ganzzahlzustand als auch über ihr flankengetriebenes Steuerverhalten überwacht werden. Nur den `ACC`-Wert zu beobachten ist unvollständig, da Zähler von der Übergangslogik abhängen und die diagnostische Frage oft lautet, ob das Zählereignis aufgetreten ist, und nicht nur, welche Zahl jetzt sichtbar ist.

Für einen CTU umfasst das wesentliche Beobachtungsset normalerweise:

• `CU`- oder Zählfreigabeverhalten
• `DN`- oder Done-Zustandsübergang
• `ACC`- oder aktueller akkumulierter Zählerstand
• Rücksetzpfad-Verhalten
• Übergangsmuster des auslösenden Eingangs

Auf einem kleinen Bildschirm ist der Hauptfehlergrund nicht der Mangel an Informationen, sondern ein schlechtes Layout. Wenn die Beobachtungsdaten und das Netz um denselben Platz konkurrieren, zoomt der Benutzer so weit heraus, dass beides nicht mehr nützlich ist. OLLA Lab löst dies durch die Entkopplung der Variablenüberwachung von der Kontaktplanbearbeitung mittels eines ausklappbaren Variablen-Panels.

Warum das Variablen-Panel für Zähler wichtig ist

Das Variablen-Panel ermöglicht es Ingenieuren, spezifische Tags anzuheften und zu beobachten, während das Netz lesbar bleibt. Das ist wichtig, da das Debuggen von Zählern oft eine Ursache-Wirkungs-Übung ist:

• Hat der Sensoreingang sauber geschaltet?
• Hat der Zähler das Ereignis einmal oder mehrmals registriert?
• Hat `ACC` im erwarteten Moment erhöht?
• Hat `DN` beim korrekten Vorgabewert ausgelöst?
• Hat der Rücksetzpfad den Zustand deterministisch gelöscht?

Das ist die eigentliche Arbeit. Der Kontaktplan ist nur die halbe Miete; die Zustandsübergänge liefern das Urteil.

Grundlegende CTU-Konfiguration für mobile Tests:

- Netzbedingung: `Sensor_Input` - Anweisung: `CTU` - Zähler-Tag: `Counter_1` - Vorgabewert: `10` - Initialer Akkumulator: `0`

Was ist das korrekte Diagnosemuster für einen CTU?

Ein CTU sollte mit bewussten Eingangsübergängen und sichtbarer Zustandsverfolgung getestet werden. Ein praktischer mobiler Workflow ist:

1. Heften Sie `Sensor_Input`, `Counter_1.ACC` und `Counter_1.DN` im Variablen-Panel an.
2. Schalten oder simulieren Sie den Eingangsübergang einmal.
3. Bestätigen Sie, dass `ACC` um eins erhöht wird, nicht um mehrere Zählschritte.
4. Wiederholen Sie dies, bis `ACC` den Wert `PRE` erreicht.
5. Überprüfen Sie, ob `DN` bei der korrekten Schwelle auslöst.
6. Lösen Sie die Rücksetzbedingung aus und bestätigen Sie das Rücksetzverhalten des Akkumulators.

Wenn der Zählerstand unerwartet springt, könnte das Problem Eingangs-Prellen, scan-getriebenes erneutes Auslösen oder fehlerhafte Flankenauswertung sein. Zähler decken falsche Annahmen schnell auf.

MOVE-Bausteine sind die praktische Brücke zwischen fester Logik und zustandsabhängiger Parametersteuerung. Auf einer mobilen Oberfläche sind sie wichtig, da Zeitgeber und Zähler selten als fest codierte Inseln nützlich bleiben; reale Sequenzen erfordern oft Vorgabewertänderungen, Rücksetzungen oder Ganzzahl-Routing basierend auf Maschinenmodus, analogen Schwellenwerten oder vom Bediener ausgewählten Rezepten.

In OLLA Lab kann eine MOVE-Anweisung über denselben Touch-First-Workflow konfiguriert werden, der auch für Zeitgeber und Zähler verwendet wird: Platzieren Sie die Anweisung aus dem Tortenmenü, tippen Sie auf das Quellfeld, tippen Sie auf das Zielfeld und weisen Sie Werte oder Tags über Overlays und Touch-Tastaturen zu.

### Ein praktisches Beispiel: Schreiben auf `TON.PRE`

Eine häufige Übung ist die Verwendung eines MOVE-Bausteins, um eine neue Ganzzahl in `TON_1.PRE` zu schreiben, basierend auf einer Variablen, die im Variablen-Panel angepasst wurde. Dies zeigt, dass der mobile Workflow Datenbewegung und Parametrierung handhaben kann, nicht nur einfache boolesche Netze.

Eine kompakte Testsequenz sieht wie folgt aus:

1. Erstellen Sie einen Quell-Ganzzahl-Tag wie `Requested_Delay`.
2. Fügen Sie eine MOVE-Anweisung in einem Netz hinzu, das durch eine Modus- oder Einrichtungsbedingung freigegeben wird.
3. Setzen Sie die MOVE-Quelle auf `Requested_Delay`.
4. Setzen Sie das MOVE-Ziel auf `TON_1.PRE`.
5. Passen Sie im Variablen-Panel `Requested_Delay` an.
6. Führen Sie die Simulation aus und bestätigen Sie, dass sich der Zeitgeber-Vorgabewert wie erwartet ändert.
7. Lösen Sie den Zeitgeber aus und beobachten Sie, ob die neue Verzögerung das `ACC`- und `DN`-Verhalten korrekt steuert.

Wenn eine Touch-Oberfläche Parameter-Routing, Zustandsbeobachtung und wiederholbare Verifizierung unterstützen kann, ist sie nützlich. Wenn sie nur Kontakte platzieren kann, ist ihr technischer Wert begrenzt.

Touch-Simulation ist nur glaubwürdig, wenn versehentliche Eingabeänderungen kontrolliert werden. Das Risiko auf einem mobilen Gerät ist direkt: Ein Finger ist weniger präzise als ein Mauszeiger, und das Live-Umschalten von Zuständen ohne Sicherheitsvorkehrungen kann zu irreführenden Testergebnissen führen.

OLLA Lab begegnet dem mit begrenzten Simulationskontrollen innerhalb der Browserumgebung. Die wichtige Unterscheidung liegt zwischen dem sicheren Simulieren von Logik und der Interaktion mit realen Anlagen-E/A. OLLA Lab ist für Ersteres gedacht.

Defensive mobile Simulationsfunktionen

- Zweistufige Umschalter: Boolesche Eingangsänderungen im Variablen-Panel verwenden ein Tipp-und-Bestätigen-Muster anstatt eines einzelnen beiläufigen Tippens. - Isolierung des Simulationsmodus: Die Logik wird in einer browserbasierten Simulationsumgebung ausgeführt, sodass Parameteränderungen den digitalen Zwilling oder den simulierten Logikzustand beeinflussen, nicht physische Feldgeräte. - Entkoppelte Überwachung: Ingenieure können sich ändernde Werte beobachten, ohne wiederholt direkt auf überfüllte Kontaktplanelemente zoomen und tippen zu müssen. - GeniAI-Assistentenunterstützung: Benutzer können GeniAI bitten, eine Sequenz zu überprüfen, eine Anweisung zu erklären oder mögliche Logikprobleme zu markieren, bevor die Simulation erneut ausgeführt wird.

Die Sicherheitsgrenze sollte klar benannt werden. OLLA Lab ist eine Validierungs- und Übungsumgebung für risikoreiche Logikaufgaben. Es ist keine Live-Steuerungsplattform, kein Ersatz für formale Werksabnahmeprüfungen und für sich genommen kein Nachweis für die Einhaltung funktionaler Sicherheit.

„Simulationsbereit“ bedeutet, dass der Ingenieur das Logikverhalten vor der Bereitstellung anhand eines beobachtbaren Maschinen- oder Prozesszustands validieren kann. Für Zeitgeber und Zähler bedeutet das mehr, als nur Anweisungen korrekt zu platzieren. Es bedeutet zu zeigen, dass sich Zeitverhalten, Zählvorgänge, Rücksetzverhalten und Fehlerreaktion unter realistischen Bedingungen wie beabsichtigt verhalten.

Ein Ingenieur beweist simulationsbereite Arbeit, indem er sechs praktische Fragen beantworten kann:

1. Wie ist das beabsichtigte Sequenzverhalten?
2. Welche exakten Bedingungen definieren den korrekten Betrieb?
3. Welche Kontaktplan-Zustände und simulierten Gerätezustände wurden beobachtet?
4. Welcher Fehler oder welcher abnormale Fall wurde injiziert?
5. Welche Revision wurde vorgenommen, nachdem der Fehler gefunden wurde?
6. Was wurde über die Steuerungsphilosophie oder den Fehlermodus gelernt?

Diese Struktur ist wichtig, da Arbeitgeber und Prüfer technische Nachweise benötigen, keine Screenshot-Galerie.

Aufbau eines kompakten Korpus an technischen Nachweisen

Verwenden Sie diese Struktur bei der Dokumentation von Zeitgeber- und Zählerarbeit in OLLA Lab:

Definieren Sie das erwartete Verhalten in messbaren Begriffen. Beispiel: „Nachdem `Start_PB` wahr wird, soll `Motor_Run` erst nach 3 Sekunden kontinuierlicher Freigabebedingung einschalten.“

1. Systembeschreibung Beschreiben Sie das Maschinen- oder Prozesssegment, wie z. B. eine Motorstartverzögerung, eine Flaschenzählstation oder eine Pumpenwechselsequenz.
2. Operative Definition von „korrekt“
3. Kontaktplanlogik und simulierter Gerätezustand Zeigen Sie die Netzlogik und den entsprechenden simulierten Geräte- oder Prozesszustand während der Ausführung.
4. Der injizierte Fehlerfall Führen Sie einen Fehler ein, wie z. B. Eingangs-Prellen, verpasstes Rücksetzen oder einen Vorgabewert außerhalb des erwarteten Bereichs.
5. Die vorgenommene Revision Dokumentieren Sie die Logikänderung, Parameteranpassung oder Sequenzkorrektur.
6. Gelernte Lektionen Geben Sie an, was der Test über das Scan-Verhalten, die Flankenauswertung, Zeitannahmen oder die Bedienerinteraktion ergeben hat.

Diese Art von Nachweis ist nützlicher als ein Screenshot allein, da sie Ursache und Wirkung, die Diagnose abnormalen Verhaltens und die bewusste Revision zeigt.

Die mobile Kontaktplanbearbeitung sollte als begrenzte Fähigkeit für Übung, Überprüfung und schnelle Validierung behandelt werden, nicht als universeller Ersatz für eine vollständige Engineering-Station. Diese Einordnung ist sowohl technisch ehrlich als auch operativ nützlich.

In einer Fabrikhalle tragen Techniker und Ingenieure zunehmend Tablets bei sich, um auf HMIs, SCADA-Ansichten, Wartungsaufzeichnungen und Fehlerbehebungsinformationen zuzugreifen. In diesem Kontext ist eine Touch-native Kontaktplan-Simulationsumgebung wertvoll, da sie ein schnelles Üben von Sequenzlogik, Zeitgeberverhalten und Zählerdiagnose ermöglicht, ohne die Reibung, sich in eine Desktop-IDE einwählen zu müssen. Der Workflow ist besonders nützlich für Schulungen, Onboarding, Fehlerüberprüfung und Prototypenvalidierung.

Die Grenze ist ebenso wichtig. Endgültige Bereitstellungs-Workflows, herstellerspezifisches Anweisungsverhalten, Aktivitäten zum Sicherheitslebenszyklus und formale Änderungskontrolle gehören weiterhin in die entsprechenden Engineering-Systeme und Governance-Prozesse. Ein Tablet ist ein fähiges Werkzeug, kein Ersatz für diese Prozesse.

Empfohlenes Bild: iPad-Schnittstelle mit geteiltem Bildschirm, die links ein Kontaktplan-Netz mit einer TON-Anweisung und rechts das OLLA Lab Variablen-Panel zeigt, wobei `ACC` hervorgehoben ist, während es in Echtzeit hochzählt.

Bild-Alt-Text: Screenshot der mobilen OLLA Lab-Oberfläche auf einem iPad. Der Benutzer passt einen TON-Vorgabewert über eine Touch-optimierte Tastatur an, während das Variablen-Panel den Echtzeit-Akkumulator und das Timer-Timing-Bit (`TT`) anzeigt.

Zeitgeber und Zähler sind der falsche Ort, um UI-Reibung zu tolerieren, da sie ebenso Diagnoseanweisungen wie Programmanweisungen sind. Wenn die Schnittstelle es erschwert, einen TON zu platzieren, ein `PRE` zu bearbeiten, ein `DN`-Bit zu beobachten oder einen CTU-Akkumulator bei Zustandsänderungen zu verfolgen, investiert der Ingenieur Aufwand in das Werkzeug statt in die Logik.

Der mobile Workflow von OLLA Lab ist nützlich, weil er dieses Problem direkt angeht: Touch-native Anweisungsplatzierung, Vollbild-Parametereingabe und entkoppelte Variablenüberwachung in einer browserbasierten Simulationsumgebung. Richtig eingesetzt, gibt dies Ingenieuren eine praktische Möglichkeit, Zeitsequenzen zu üben, Zählerverhalten zu validieren und Logikrevisionen zu dokumentieren, bevor irgendetwas in die Nähe eines realen Prozesses gelangt.

- IEC 61508 Überblick über den Standard zur funktionalen Sicherheit - IEC 61131-3 Programmierbare Steuerungen - Programmiersprachen - NIST SP 800-207 Zero Trust Architektur - ISO 9241-110 Ergonomie der Mensch-System-Interaktion - Tao et al. (2019) Digitaler Zwilling in der Industrie (IEEE) - Fuller et al. (2020) Ermöglichende Technologien für digitale Zwillinge (IEEE Access) - U.S. Bureau of Labor Statistics - Deloitte Manufacturing Industry Outlook