RobFlow 8.2

Highlights

RobFlow 8.2 überarbeitet die Kommunikation mit Modbus/TCP-Geräten und macht die Flow-Steuerung verlässlicher. Der rote Faden: Fehler sollen sichtbar sein. Ein fehlgeschlagener Lesevorgang pausiert jetzt den Flow und meldet sich, und ein Ausgang, den die Steuerung nicht bestätigt, stoppt den Flow, statt als gesetzt angenommen zu werden.

• Ein Socket pro Gerät: Verbindungen mit gleichem Host und Port teilen sich jetzt einen TCP-Socket und werden über die Unit-ID zugeordnet. So erschöpft das gleichzeitige Aktualisieren vieler Variablen nicht mehr das Verbindungslimit eines Geräts.
• Modbus-Schreibvorgänge außerhalb der Event-Loop: Schreibvorgänge laufen in einem Worker-Thread, sodass HTTP-API, Websockets und Safety-Server auch dann ansprechbar bleiben, wenn ein Gerät ausfällt.
• Lesefehler werden gemeldet: Ein fehlgeschlagener Modbus-Lesevorgang erzeugt einen Fehler und pausiert den Flow, statt unbemerkt zu bleiben.
• Bestätigte Ausgänge: „Set Outputs“ wartet auf die Bestätigung jedes Werts durch die Steuerung und stoppt den Flow — unter Nennung der Variable —, wenn sie ausbleibt.
• Verlässliches Stoppen und Pausieren: Der Stop-Node hält auch einen bereits pausierten Flow an, und ein in einem parallelen Zweig erreichter Pause-Node benötigt kein zweites Fortsetzen mehr.

Features & Änderungen

Ein Modbus/TCP-Socket pro Gerät

Modbus/TCP-Verbindungen mit gleichem Host und Port teilen sich jetzt einen TCP-Socket und ordnen jede Anfrage über die Unit-ID zu. Geräte, die nur wenige gleichzeitige Verbindungen zulassen, fielen bisher aus, wenn mehrere Variablen gleichzeitig aktualisiert wurden; diese Fehlerklasse entfällt.

Damit ändert sich das Verhalten an vier Stellen:

• Verbindungen werden erst bei der ersten Nutzung geöffnet, nicht schon beim Konfigurieren.
• Die Erreichbarkeit wird beim Flow-Start einmal pro Gerät geprüft, nicht einmal pro Verbindung.
• Das Umbenennen einer Verbindung trennt sie nicht mehr — der zugrunde liegende Socket bleibt bestehen.
• POST /reconnect-modbus verbindet den gemeinsamen Socket neu, für alle Verbindungen, die ihn nutzen.

Warnung bei doppelten Verbindungen

Robot Config weist jetzt auf Modbus/TCP-Verbindungen hin, die sich Host, Port und Unit-ID teilen. Durch den gemeinsamen Socket sind solche Duplikate unproblematisch — die Warnung ist also ein Hinweis auf vermeidbare Konfiguration, kein Fehler.

„Set Outputs“ wartet auf Bestätigung

Der Befehl Set Outputs hält den Flow jetzt an, bis die Robotersteuerung jeden gesetzten Wert bestätigt hat. Bleibt eine Bestätigung aus, stoppt RobFlow den Flow, zeigt einen Fehler an und nennt die betroffene Variable — so ist klar, welcher Punkt an der I/O-Klemme zu prüfen ist.

Authentifizierung für zwei Modbus-Endpunkte

POST /reconnect-modbus und GET /variables/modbus erfordern jetzt eine Authentifizierung. Wer einen dieser Endpunkte aus einem externen Skript oder einer Integration aufruft, muss vor dem Upgrade Zugangsdaten ergänzen.

Korrekturen

Modbus/TCP

• Modbus-Condition-Nodes melden fehlgeschlagene Lesevorgänge an die Oberfläche und pausieren den Flow.
• Schreibvorgänge auf ein nicht erreichbares Gerät laufen in einem Worker-Thread, während der Flow auf die Bestätigung wartet.
• Ein Fehler innerhalb eines Worker-Threads pausiert den Flow und zeigt eine Fehlermeldung an.
• Gut/Schlecht-Zählerereignisse und Problemstatus von Variablen werden zuverlässig aus Worker-Threads aktualisiert.
• Das Speichern von Robot Config gelingt auch dann, wenn es sich mit einem laufenden Reconcile-Zyklus überschneidet.
• Das Schließen einer Verbindung wartet auf noch laufende Lese- und Schreibvorgänge auf diesem Socket.

Flow-Steuerung

• Der Stop-Node hält die Ausführung an, unabhängig davon, ob der Flow läuft oder bereits pausiert ist.
• Wird ein Pause-Node erreicht, während der Flow bereits pausiert ist, werden alle Zweige mit einem einzigen Fortsetzen freigegeben.
• Der Do-Until-Node führt seinen zur Bedingung passenden Zweig auch dann aus, wenn die Bremsen den Roboter halten.
• Interne Verwaltungsaufgaben für Subflows laufen unabhängig vom Sicherheitszustand.

Start und Laufzeit

• Der Speicherbedarf beim Start bleibt begrenzt, auch wenn große oder viele Flows, Subflows und Dashboards gleichzeitig migriert werden.
• Abgebrochene asynchrone Tasks werden korrekt aufgeräumt; zuvor blockierten sie Stop- und Pause-Befehle.