Eine Methode ausführen

Jede Operation dieser Anwendung - Erkennung, Szenenanalyse und Modulverwaltung - wird auf dieselbe Weise gestartet und meldet ihren Ausgang auf dieselbe Weise. Es sind Execute-Methoden des Data Layer; wie Execute-Methoden allgemein funktionieren, ist in Execute-Methoden beschrieben.

Der Aufbau einer Operation

Eine Operation liegt unter einer eigenen Adresse und hat immer drei Teile:

<operation>/execute                 write here to run it
<operation>/input/...               the values it works on
<operation>/output/status-code      what happened, as a number
<operation>/output/status-text      what happened, in words

Manche Operationen haben unter output/ mehr - ein Erkennungsergebnis, ein Label-Bild oder ein Histogramm -, aber execute, status-code und status-text sind immer vorhanden.

Eine Operation ausführen

  1. Schreiben Sie die Eingabeknoten.

  2. Schreiben Sie auf execute. Der Wert spielt keine Rolle; der Schreibvorgang selbst löst die Operation aus.

  3. Lesen Sie output/status-code, um zu erfahren, ob sie erfolgreich war.

Das Schreiben auf execute ist ein blockierender Aufruf: Er kehrt zurück, wenn die Operation abgeschlossen ist. Sie müssen also weder ein "ready"-Flag pollen noch in Ihrem Programm einen Zustand verfolgen. Eingaben behalten ihre Werte zwischen den Durchläufen, eine wiederholte Operation braucht also nur Schritt 2.

Den Ausgang prüfen

output/status-code ist eine vorzeichenbehaftete Zahl, und allein das Vorzeichen sagt Ihnen, ob die Operation erfolgreich war:

Wert Bedeutung

größer als 0

Die Operation war erfolgreich

0

Die Operation ist seit dem Start der Anwendung nicht ausgeführt worden

kleiner als 0

Die Operation ist fehlgeschlagen und hat nichts erzeugt

Die Prüfung in einer SPS ist also einfach status-code < 0. Einen bestimmten Code brauchen Sie nur, wenn Sie auf verschiedene Fehler unterschiedlich reagieren wollen - etwa auf eine ungültige Eingabe anders als auf eine Kamera, die nicht antwortet.

output/status-text enthält denselben Ausgang als Satz und benennt den fehlerhaften Wert, wenn es einen gibt:

error: crop/startX + crop/width (100 + 900 = 1000) exceeds the image width 640

Lesen Sie ihn, wenn etwas schiefgeht; bauen Sie keine Logik darauf auf, denn der Wortlaut kann sich zwischen Releases ändern. Die vollständige Liste der Codes steht unter Ausführungsstatus.

Der Grund kommt auf output/status-text an, nicht in der Antwort auf den Schreibvorgang auf execute selbst. Ein fehlgeschlagener Schreibvorgang antwortet nur mit einem Statuscode - über REST mit einem bloßen 400. Der Data Layer verwirft jedes Detail, das ein Provider an einen fehlgeschlagenen Aufruf anhängt; output/status-text anschließend zu lesen ist daher der Weg, um herauszufinden, was falsch war. Die Ergebnisse, mit denen ein Schreibvorgang antworten kann, und ihre Namen auf dem ctrlX Data Layer und auf LumiScan Keryx sind in Ergebnisse eines Methodenaufrufs aufgeführt.

Derselbe Text wird in das Protokoll der Anwendung geschrieben, sodass sich ein Fehler auch ganz ohne den Data Layer diagnostizieren lässt: auf ctrlX OS über das ctrlX Logbook oder journalctl, auf einem PC über die Konsolenausgabe der Anwendung. Sind mehrere Eingaben falsch, erhält jede ihre eigene Warnzeile.

Eine Operation zur Zeit

Ein Modul führt jeweils eine Operation aus. Eine zweite zu starten, während die erste noch läuft, stellt sie nicht in eine Warteschlange - sie kehrt sofort mit Statuscode -1 (belegt) zurück und tut nichts. Der Schreibvorgang selbst antwortet mit TooManyOperations (ctrlX: DL_TOO_MANY_OPERATIONS), siehe Eine Operation zur Zeit.

Die Sperre gilt pro Modul, verschiedene Module erkennen also parallel - eine zweite Kamera wird von der ersten nicht aufgehalten. system/analyse-scene hat eine eigene Sperre; eine Szenenanalyse blockiert daher keine Erkennung, und zwei Analysen können nicht miteinander in Konflikt geraten.

Die Ausgaben gehören zum startenden Durchlauf

Jede Methode leert ihre eigenen Ausgabeknoten, sobald sie beginnt - detect-area sein output/result, analyse-scene sein output/histogram. Sie werden geleert, bevor irgendetwas fehlschlagen kann; ein Durchlauf, der aus welchem Grund auch immer fehlschlägt, hinterlässt sie also leer, statt das Ergebnis eines früheren Durchlaufs zu behalten.

Deshalb ist es sicher, eine Ausgabe zu lesen, ohne vorher output/status-code zu prüfen: Was Sie sehen, ist entweder das Ergebnis dieses Durchlaufs oder nichts, nie ein veralteter Wert von einem früheren Bild.

output/status-code und output/status-text sind die Ausnahme - sie beschreiben immer den letzten Versuch, und genau dafür sind sie da.

Lesen Sie eine Ausgabe, bevor Sie den nächsten Durchlauf auslösen. Die Ausgaben beschreiben den jüngsten Durchlauf, und der nächste Aufruf leert sie in dem Moment, in dem er beginnt. Erneut execute aufzurufen und dann das vorherige Ergebnis zu lesen liefert nichts.

Der einzige Fall, der nichts leert, ist ein als -1 (belegt) abgelehnter Aufruf: Er ist nie gelaufen und lässt die Ausgaben der laufenden Operation unberührt. Ein zweites execute, das unmittelbar nach dem ersten abgesetzt wird, hat also zwei mögliche Ausgänge, und sie unterscheiden sich:

  • Der erste Durchlauf läuft noch - der zweite wird mit -1 abgelehnt, und die Ausgaben enthalten weiterhin den Durchlauf davor;

  • der erste Durchlauf ist gerade fertig - der zweite wird angenommen und leert die Ausgaben, die der erste Durchlauf gerade erst geschrieben hat.

Warten Sie, bis execute zurückkehrt, lesen Sie die Ausgaben, und lösen Sie erst dann den nächsten Durchlauf aus.