Beta: Prüfplaneditor, Prüflauf am Messplatz und Kamera-Ablesung¶
3. November 2026
Bisher stand in calServer V2 ein Prüfplan als Tabelle im Schritt-Editor, und gemessen wurde von Hand. Jetzt gibt es drei neue Bausteine zum Ausprobieren: einen Prüfplaneditor, in dem der Plan als Skript (calScript) geschrieben wird, einen Prüflauf, den ein Programm am Messplatz mit angeschlossenen Geräten abarbeitet, und eine Kamera-Ablesung, die Anzeigen ohne Schnittstelle per Webcam liest. Dahinter steht eine Idee, die sich durch alle drei zieht: Was verlangt ist, wie gemessen wird und wer abliest, steht an getrennten Orten und kommt erst in der Kalibrierung zusammen.
Beta
Alle drei Funktionen sind Beta. Sie sind in calServer V2 enthalten und benutzbar, aber noch nicht im Produktivbetrieb bei Kunden erprobt. Konkret heißt das:
- Sprache und Plandokument wachsen noch. Neue Möglichkeiten bekommen eine neue Dokumentversion (heute bis Version 8 für Pläne mit Kamera-Bindung); ältere Dokumente werden weiter gelesen.
- Die mitgelieferten Treiberprofile sind nach öffentlichen
Programmierhandbüchern geschrieben. Vor dem ersten Lauf am echten Gerät
gehört jedes Profil geprüft (
calserver-runner probe). - Die Kamera-Ablesung braucht ein Vision-Modell und ist ab Werk ausgeschaltet.
Rückmeldungen aus dem Laboralltag fließen direkt in die nächsten Schritte.
Vier Bausteine, eine Prozedur¶
Eine klassische Kalibrierprozedur ist ein Programm, in dem Prüfaufgabe, Gerätesteuerung und Ablesung ineinanderlaufen. Steht ein anderer Kalibrator am Platz oder soll ein Handmultimeter ohne Schnittstelle abgelesen werden, muss die Prozedur angefasst werden, obwohl sich an der Prüfaufgabe nichts geändert hat. calServer verteilt das auf vier Orte:
| Baustein | Beantwortet | Ändert sich, wenn … |
|---|---|---|
| Spezifikation des Gerätetyps, mit Optionen | Was ist verlangt, welche Toleranz gilt an welchem Punkt? | ein Datenblatt, eine Norm oder eine Kundenvereinbarung sich ändert |
| Prüfplan in calScript | Was wird gemessen, in welcher Reihenfolge, mit welcher Rolle? | das Labor sein Verfahren ändert |
| Treiberprofil | Wie spricht man mit diesem Gerätemodell? | ein neues Gerätemodell dazukommt |
| Messplatz mit Runner, Kamera oder Hand | Wer liest den Wert ab, welches Gerät spielt welche Rolle? | ein anderer Platz, ein anderes Normal oder ein anderer Prüfling dran ist |
Das Skript ist dabei das Bindeglied. Es trägt im Normalfall keine
Toleranz und kein Gerät, sondern Messpunkte, Funktionen und Rollen
(uut für den Prüfling, cal für das Normal). Beim Laden in eine
Kalibrierung kommt die Toleranz aus der gewählten Option der Spezifikation,
und beim Lauf am Messplatz löst calServer die Rollen in Geräte auf, die der
Runner über ihre Treiberprofile anspricht. Plan laden, Option wählen, Eingabe
am Platz: erst daraus wird die Prozedur, die gemessen wird.
group "Gleichspannung"
result numeric
unit V
read device uut
source cal
function "VDC"
settle 2
measure 1 10 100 "{value} V"
measure 0 "Nullpunkt" read manual
Derselbe Plan läuft so auf jedem Platz, an dem passende Geräte stehen. Ein neues Datenblatt verlangt eine neue Revision der Spezifikation, keinen neuen Plan; ein Kunde mit engeren Grenzen bekommt eine Option, keine Kopie des Plans. Bewertet wird immer in calServer: Kein Runner, kein Treiber und keine Kamera entscheidet über bestanden oder nicht bestanden.
Spezifikation: was verlangt ist¶
Je Gerätetyp gibt es eine Spezifikation mit mehreren Optionen: Herstellerangabe, Normklasse, Kundenanforderung oder Verwendung mit kleinerem Umfang. Zeilen sind Bänder (Toleranz für einen Bereich), Punkte (Toleranz für genau einen Wert, zugleich verlangter Prüfpunkt) oder Beiträge zur Messunsicherheit eines Normals. Die Toleranz steht je Option an der Zeile.
Bearbeitet wird nur ein Entwurf. Die Freigabe hält Person, Zeitpunkt und einen Inhalts-Hash fest und macht die Revision unveränderlich; freigegebene Revisionen werden zurückgezogen, nie gelöscht. Jede Kalibrierung wählt vor dem Laden genau eine Option. Findet calServer zu einem Punkt keine oder keine eindeutige Toleranz, bleibt der Punkt ohne Urteil, statt dass eine Zeile geraten wird. Auf dem Schein steht, gegen welche Spezifikation, Revision und Option bewertet wurde, und je Punkt, woher die Toleranz kam.
Aus den Punktzeilen einer Option legt Prozedur erzeugen einen Prüfplan am Gerätetyp an, der nur das Verfahren enthält.
Prüfplaneditor: der Plan als Skript¶
Der Schritt-Editor hat neben Tabelle und Karten eine dritte Ansicht Skript. Das Skript ist die Quelle des Plans, Tabelle und Karten sind Ansichten davon; der Wechsel übersetzt live in beide Richtungen.
- Schreiben mit Rückmeldung: Links der Text mit Zeilennummern und Farben, rechts die Vorschau der Schritte, die der Server daraus macht. Fehler stehen an ihrer Zeile, Hinweise tönen die Zeile gelb, F8 springt zum nächsten. Kommentare bleiben beim Speichern erhalten.
- MET/CAL-Prozeduren importieren: Eine
.mc-Datei wird übersetzt, soweit calScript sie abbilden kann. Was nicht übersetzt wird, bleibt als Kommentarzeile an seiner Stelle stehen und erscheint im Nacharbeitsbericht. Der Import erzeugt nie stillschweigend einen anderen Plan. Busbefehle für den Prüfling gehen in einen Treiberprofil-Entwurf, nicht in den Plan. - Testfälle: Ein Plan lässt sich mit Testfällen prüfen, die Ablesungen hineingeben und Urteile erwarten. Dazu erzeugt calServer ein Grenzprofil je Messpunkt und meldet Befunde wie einen Punkt, der nicht durchfallen kann, oder ein Test-Accuracy-Ratio unter 4:1. Die Fälle laufen auch gegen die zuletzt genehmigte Version, damit sichtbar ist, was eine Änderung bewirkt.
- Probelauf und Entwurf mit KI stehen im selben Editor.
Versionierung, Genehmigung und Freigabe der Pläne bleiben, wie sie im Prozedureditor eingeführt wurden.
Treiberprofile: Gerätewissen als Daten¶
Der Runner am Messplatz kennt nur Transporte (über VISA: GPIB, LAN, seriell,
USB) und einige Dialekte für Gerätefamilien. Was ein bestimmtes Modell
versteht, steht in einem Treiberprofil: Kennung auf *IDN?,
Schnittstelleneinstellungen, Befehle je Funktion (VDC, VAC, ADC,
AAC, OHM, OHM4, CAP, FREQ, TEMP) und die Grenzen des Geräts.
- Fähigkeiten statt Rollen: Ein Profil sagt je Funktion, ob das Gerät
Werte gibt, misst oder beides. Ob es Normal oder Prüfling ist, sagt der
Lauf. Derselbe Kalibrator ist heute
calund wird morgen mit demselben Profil selbst kalibriert. - Fail-closed: Passt die Kennung am Anschluss nicht zum Profil, öffnet der Runner das Gerät nicht. Eine Funktion, die das Profil nicht kennt, und ein Wert über den Grenzen des Profils werden nicht gesendet.
- Mitgeliefert: Profile für Fluke 5500A, 5502A, 5520A, 5522A und 5320A, Keysight 34401A, 34461A, 34465A, 34470A, Keithley DMM6500, Fluke 8846A und die Handmultimeter Fluke 287/289 über IR-Adapter. Sie erscheinen unter Administration, Treiberprofile als Standardprofile und lassen sich als eigene Kopie übernehmen.
- Neues Gerät aus dem Handbuch: „Aus Handbuch mit KI“ liest das Programmierhandbuch (PDF) und entwirft ein Profil, das calServer gegen eine Prüfliste hält. Gespeichert wird immer von einem Menschen und inaktiv; ein Messplatz holt das Profil erst, wenn es nach der Abnahme am Gerät aktiv gesetzt ist.
Messplätze und der calServer Runner¶
Ein Messplatz ist in calServer ein eigener Datensatz (Administration, Messplätze) mit eigenem Messplatzkonto, das nur Läufe lesen und darauf erfassen darf. Am Rechner des Messplatzes läuft der calServer Runner, herunterladbar von derselben Seite für Windows (Installer je Benutzer ohne Administratorrechte, MSI für die zentrale Verteilung oder ZIP) und Linux.
- Koppeln ohne Passwort: calServer erzeugt einen Kopplungscode (8 Zeichen, 15 Minuten gültig), der Runner tauscht ihn gegen ein Token des Messplatzkontos. Widerruf in calServer sperrt es sofort.
- Gesteuert aus calServer: Der Runner meldet sich regelmäßig und holt Kommandos ab. Er öffnet keinen Port; der Messplatz darf hinter NAT und Firewall stehen.
- Geräte einlesen: Auf Knopfdruck listet der Runner die Geräte am Bus mit ihrer Kennung und schlägt passende Treiberprofile vor. Ein Gerät am Platz trägt Anschluss, Treiberprofil und Inventareintrag, aber keine Rolle.
- Offline weitermessen: Jeder Wert geht erst in ein lokales Journal und wird nachgesendet, wenn das Netz zurück ist.
Der Prüflauf¶
Die Prüflauf-Seite (/procedure-run/<Kalibrierung>) ist eine eigene
Vollbildseite, die ein Werkstattplatz direkt per Adresse öffnet, wahlweise
als Tabelle oder als Schritt-für-Schritt-Ansicht für Tablet. Sie aktualisiert
sich von selbst, wenn ein anderer Bildschirm oder ein Messplatz Werte
schreibt.
Nach dem Vorlauf gibt Am Messplatz ausführen den Lauf an einen
gekoppelten Platz. Vorher zeigt calServer, welches Gerät welche Rolle spielt:
uut ist das Gerät am Platz, dessen Inventareintrag kalibriert wird, cal
das Normal, das der Vorlauf zugeordnet hat. Eine Rolle ohne Gerät bleibt mit
Grund offen, und ihre Punkte misst der Runner nicht. Wo ein Mensch handeln
muss (Messleitungen umstecken, Drehschalter stellen, eine Frage
beantworten), hält der Runner an, und die Seite zeigt „Messplatz wartet auf
dich“ mit dem Knopf Weiter. Mit dem Sammellauf misst ein Platz
mehrere Kalibrierungen derselben Planversion gemeinsam, je Kanal eines
Scanners oder Mehrkanalthermometers ein Prüfling.
Der Runner sendet Rohwerte. Toleranz, Messunsicherheit und Urteil rechnet
calServer, und jeder Wert trägt seine Herkunft (device, camera,
manual).
Kamera-Ablesung¶
Für Anzeigen ohne Schnittstelle liest die Webcam im Browser. In der Erfassungstabelle öffnet Kamera-Ablesung ein Panel; der Prüfer zieht einmal einen Rahmen um die Anzeige, und nur dieser Ausschnitt geht an ein Vision-Modell. Das Modell kennt Einheit und Nachkommastellen des Punkts, nie den Sollwert und nie die Toleranz, damit es nicht in Richtung des erwarteten Werts liest. calServer rechnet aus der Antwort eine Ampel:
- rot (kein Wert, Überlauf, mehrere Werte, falsche Größe, Modell unsicher): wird nie übernommen;
- gelb (Blendung, unsicheres Vorzeichen, zweite Lesung weicht ab und ähnliches): Vorschlag im Feld, der Prüfer übernimmt mit Klick oder tippt um;
- grün: Übernahme per Klick (
capture confirm) oder, wenn der Plan es erlaubt, ohne Klick (capture auto, nur wenn zwei Lesungen hintereinander grün sind und übereinstimmen).
Zu jedem übernommenen Wert speichert calServer ein kleines Beweisbild,
genau den Ausschnitt, den das Modell gesehen hat. Mit repeat N füllt die
Kamera N Wiederholmessungen mit laufendem Mittelwert und Streuung. Das Panel
steht auch ohne read camera im Plan an jedem Messpunkt als Eingabehilfe
bereit, sobald die KI-Routine „Kamera-Ablesung“ eingeschaltet ist; die Hand
bleibt immer möglich. Wird ein externer KI-Anbieter genutzt, verlässt der
Bildausschnitt das Haus, und das Panel sagt das vor dem ersten Bild.
Was die Beta noch nicht kann¶
- calScript kennt in Sprachversion 0 keine Variablen, keine Schleifen und keine freien Rechenausdrücke. As-Found/As-Left je Punkt ist für Sprachversion 1 vorgesehen.
- Wie viel Logik ein Treiberprofil zwischen zwei Befehlen ausdrücken darf (umrechnen, abhängig von einer Antwort verzweigen), ist noch offen. Bis dahin bleibt ein MET/CAL-Punkt, der mit dem gelesenen Wert rechnet, beim Import Handablesung.
- Die Lauf-Ansicht aktualisiert sich per Abfrage alle paar Sekunden, nicht per Push.
Details im Handbuch: Konzept: Plan, Treiber, Ablesung, Prüfpläne als calScript, Treiberprofile und Dialekte, Spezifikationen.