Prüfpläne als calScript

Ein Prüfplan lässt sich statt im Schritt-Editor auch als Text schreiben: calScript. Der Text wird beim Speichern in dasselbe calserver.procedure-Dokument übersetzt, das auch der Editor erzeugt. Lauf, Erfassung, Bewertung und Kalibrierschein bleiben unverändert; jede bestehende Vorlage lässt sich umgekehrt als Skript lesen und wieder speichern.

Wie Prüfplan, Treiber und Ablesung (von Hand, über den Messplatz, mit der Kamera) zusammenspielen, erklärt das Konzept; die Geräteseite steht unter Treiberprofile und Dialekte.

Beispiel

calscript 0
plan "Fluke 23 — Kalibrierung mit Fluke 5520A"

group "Sichtprüfung"
  info "Prüfling und Normal 30 Minuten akklimatisieren."
  confirm "Gehäuse und Buchsen unbeschädigt"
  confirm "Keine Batteriewarnung"
end

group "Gleichspannung 320 mV"
  image "anschluss-v-ohm.svg"
  result numeric
  prefix m
  unit V
  range 320
  resolution 0.1
  tol 0.3% + 1 D
  uncertainty 0.03
  k 2
  rule "ILAC-G8 w = U"
  measure 100 "100 mV"
  measure 200 "200 mV"
  measure 300 "300 mV" @ 50 Hz aux "Bereichsende"
end

rate "Zustand der Messleitungen" map "1-2:fail|3-5:pass"
message "Kalibrieretikett anbringen"

Beispielpläne

Sieben vollständige Pläne liegen calServer bei. Im Schritt-Editor öffnet sie die Skript-Ansicht unter Mehr › Beispiel öffnen; ein Beispiel ersetzt den Text erst nach Rückfrage und wird gespeichert wie jeder andere Plan. Der Kommentarkopf jedes Beispiels sagt, was es zeigt, welche Treiberprofile der Messplatz braucht und woher die Messunsicherheit kommt.

Beispiel	Arbeitsweise	Zeigt vor allem
1 Tischmultimeter 6½ Stellen	vollautomatisch: Runner stellt den Kalibrator (source cal) und liest den Prüfling (read device uut)	Gerätebindung als Gruppenvorgabe, repeat, Modifier, ask/if yes/else mit anderer Messfunktion je Zweig, if fail, Halt an Meldungen
2 Handmultimeter mit IR-Schnittstelle	halbautomatisch: Drehschalter von Hand, Runner hält an jeder Meldung	Frage wählt die Ablesequelle (IR-Adapter oder Kamera), Gruppen in einem if-Block, Toleranz mit Digits
3 Handmultimeter ohne Schnittstelle	Kamera: Kalibrator von Hand, Webcam liest	read camera, capture auto und confirm, Kamera mit repeat, read manual als Ausnahme, md, if no
4 Feinmessmanometer 10 bar	rein manuell	Serien mit direction up/down und Umkehrspanne, Referenz von Hand mitgelesen (ref manual), feste Messunsicherheit mit k und rule, ref none, result noyes, rate, verschachteltes if, if pass … else
5 Kalibrator als Prüfling	vollautomatisch mit getauschten Rollen: Prüfling gibt (source uut), Referenzmultimeter misst (ref device dmm)	Treiberprofil ohne Rolle, frei benannte Rolle, Ablesung des Normals als Bezug, stable, ppm plus Absolutwert mit Einheit
6 Temperaturfühler im Kalibrierbad	Sammellauf: ein Bad, ein Referenzthermometer, mehrere Prüflinge an den Kanälen eines Mehrkanal-Thermometers	ref device thermo, stable mit absolutem Band, source bath, contrib des Bades, direction mit Umkehrspanne, optional
7 Fluke 289, Ablesung wählbar	dieselben Punkte über den Runner (IR-Adapter), per Kamera oder von Hand; die Ablesung wählt der Prüfer im Vorlauf	read device uut \| camera \| manual mit source cal in jeder Wahl, jeder Punkt nur einmal im Plan, Halt an Meldungen, optional

Die Toleranzen sind Beispielwerte nach Art eines Datenblatts. Vor dem produktiven Einsatz gehören sie gegen das gültige Datenblatt des Prüflings geprüft. Die Dateien liegen im Repository unter laravel/resources/calscript/examples/; ein Test stellt sicher, dass sie ohne Hinweis kompilieren, das Formatieren und den Weg über die Tabelle überstehen und zusammen jedes Sprachmittel zeigen.

Editor

Das Skript ist seit Dokumentversion 4 die Quelle eines Prüfplans; Tabelle und Karten sind zwei Ansichten desselben Plans. Der Schritt-Editor (Prozeduren › Prüfpläne, „Neu erstellen" oder „Schritte bearbeiten" im Zeilenmenü, ebenso im Reiter Prüfpläne einer Prozedur) hat dafür rechts oben einen dritten Schalter Skript. Der Wechsel übersetzt live: aus der Tabelle ins Skript und zurück. Ein Skript mit Fehler lässt sich nicht in die Tabelle wechseln; der Fehler steht an seiner Zeile.

Beim Speichern entscheidet die aktive Ansicht, was gespeichert wird. In der Skript-Ansicht geht der Text an den Server, so wie er dasteht, mit Kommentaren und Leerzeilen; die Schrittzeilen werden daraus kompiliert und liegen im Dokument daneben, damit Laufzeit, Bewertung, Schein und Export nichts merken. In Tabelle und Karten gehen die Zeilen an den Server, und er leitet das Skript daraus ab. Kommentare eines früher geschriebenen Skripts gehen dabei verloren; der Editor sagt das beim Wechsel. Wer eine Vorlage öffnet, deren Schritte er nicht angefasst hat, sieht in der Skript-Ansicht das gespeicherte Skript mit allen Kommentaren.

Links steht der Text mit Zeilennummern, rechts die Vorschau mit den Schrittzeilen, die der Server daraus macht. Text und Vorschau füllen die Höhe des Fensters; der Griff zwischen beiden verschiebt die Aufteilung, und der Browser merkt sich die Breite. Das Augen-Symbol oben in der Vorschau blendet sie aus, dann nimmt der Text die ganze Breite („Vorschau" in der Werkzeugleiste holt sie zurück). In einem schmalen Fenster steht die Vorschau unter dem Text. Das Fenster-Symbol in der Werkzeugleiste legt Skript und Vorschau über das ganze Fenster (Vollbild), etwa auf der Vorlagenseite, wo es keinen Dialog zum Maximieren gibt; dasselbe Symbol oder Escape außerhalb des Editors beendet es.

Beginnt der Plan mit einem langen Kommentarkopf (ein MET/CAL-Import bringt oft 30 bis 40 Zeilen Autor, Quellen und Hinweise), springt die Ansicht beim Öffnen und nach dem Import darüber hinweg, die Einfügemarke bleibt am Anfang. Solange der Kopf im Bild ist, steht oben rechts „Zum Planbeginn“. Einklappen lässt sich der Kopf im Text nicht, aus demselben Grund wie die Gruppen (siehe unten).

Die Vorschau aktualisiert sich kurz nach jeder Eingabe („Prüfen" stößt sie sofort an). Ein Syntaxfehler steht mit seiner Zeile unter dem Text; „Zur Zeile" setzt die Einfügemarke dorthin, die Zeile ist im Text rot getönt und die Zeilennummer markiert. Die Vorschau bleibt dabei stehen: sie zeigt gedämpft den Stand vor dem Fehler und sagt, in welcher Zeile er steckt, statt bei jedem Tippfehler leer zu werden. Hinweise des Compilers (etwa %r ohne range) tönen ihre Zeile gelb und verhindern das Speichern nicht. Unter dem Text steht ihre Zahl („12 Hinweise aus der Prüfung"); ein Klick klappt die Liste auf, ein Klick auf einen Eintrag springt zur Zeile. F8 springt zum nächsten Fehler oder Hinweis, Umschalt+F8 zum vorigen. Rechts neben dem Text markiert eine schmale Leiste, wo im ganzen Skript Fehler (rot), Hinweise (gelb) und Suchtreffer (orange) liegen; ein Klick auf eine Marke springt dorthin.

Eine Gruppe, die Fragen stellt (ask), aber keinen bewerteten Schritt hat (measure, confirm, rate), meldet der Compiler als Hinweis: sie bekommt kein Ergebnis, der Prüfer klickt sie nur durch. Die Vorschau markiert ihren Kopf mit „ohne Ergebnis“. Gruppen nur mit Meldungen (Vorbereitung, Aufbau) sind gewollt und bleiben ohne Hinweis.

Der Text ist eingefärbt: Anweisungen, Eigenschaften, feste Wörter (numeric, device), Zeichenketten, Zahlen und Kommentare haben je eine Farbe; ein erstes Wort, das weder Anweisung noch Eigenschaft ist, bekommt eine rote Welle, noch bevor der Server es ablehnt. Die Farben sind Lesehilfe, die Prüfung bleibt beim Server. Die Einfärbung ändert nur Farben, nie Schnitt oder Breite: Anweisungen sind nicht fett, Kommentare nicht kursiv. Ein fetter Schnitt ist je nach Schrift und Zoom um Bruchteile breiter, und die Einfügemarke lag dann ein Zeichen neben dem sichtbaren Text.

Bleibt der Mauszeiger kurz auf einer Anweisung, einer Eigenschaft oder einem ihrer Werte stehen, erklärt ein Kärtchen das Wort mit Beispielschreibweise und listet die möglichen Werte mit Bedeutung: bei ref etwa device, manual, camera und none, bei result, read, capture und if die festen Wörter, bei tol und über einem Toleranzterm die Toleranzschreibweisen. Über einem Wert ist der gewählte hervorgehoben. Mit der Tastatur steht dieselbe Erklärung samt Werten unten in der Statuszeile, sobald die Marke auf dem Wort steht.

Beim Tippen am Zeilenanfang erscheint eine Liste der passenden Anweisungen und Eigenschaften mit kurzer Erklärung; hinter result, ref, read und capture die zulässigen Wörter, hinter prefix die SI-Vorsätze, hinter unit die Einheiten der Vorschlagsliste, direkt hinter tol und hinter einem + die Schreibweisen eines Toleranzterms. Unter der Liste zeigt eine Vorschau, was der markierte Vorschlag bedeutet und welche Werte danach möglich sind, also schon beim Aussuchen von ref die Auswahl device, manual, camera, none. Pfeiltasten wählen, Enter oder Tab übernimmt, Escape schließt; Strg+Leertaste holt die Liste ausdrücklich. Die Maus wählt einen Vorschlag erst, wenn sie sich bewegt; geht die Liste unter einem ruhenden Zeiger auf, bleibt der erste markiert. Anweisungen, die eine Zeichenkette erwarten, kommen mit Anführungszeichen, die Marke steht dazwischen.

„Einfügen" setzt einen Baustein hinter die aktuelle Zeile (oder in eine leere hinein): eine Gruppe mit Messpunkten, einen Messpunkt, eine Bestätigung, eine Bewertung, eine Meldung, einen Kommentar oder eine mehrzeilige Prüfanweisung. Der erste Platzhalter ist markiert und wird überschrieben. „Syntax" öffnet einen Spickzettel mit allen Anweisungen, Eigenschaften und der Toleranzschreibweise.

Formatieren bringt den Text in die Standardform: eine Anweisung je Zeile, Gruppeninhalt eingerückt, Eigenschaften in fester Reihenfolge, eine Leerzeile vor jeder Gruppe. Kommentare bleiben erhalten; eine Kommentarzeile steht danach vor dem Schritt, der ihr folgt, ein Kommentar hinter einer Anweisung als eigene Zeile vor ihrem Schritt. Der Server prüft, dass der formatierte Text denselben Plan ergibt, und lässt den Text sonst unverändert.

Vorschau und Text sind verbunden: ein Klick auf eine Zeile der Vorschau setzt die Einfügemarke auf die Zeile des Schritts im Skript, und der Schritt, in dessen Zeilen die Marke steht, ist in der Vorschau markiert; die Vorschau rollt mit, auch bei tausenden Schritten. Unter dem Text stehen Zeile und Spalte der Marke und, wenn die Marke auf einer Anweisung oder Eigenschaft steht, eine Zeile Erklärung dazu.

Die Vorschau zeigt je Schritt Nummer, Typ, Beschreibung, Sollwert, Toleranz, die daraus gerechneten Grenzen und ein Symbol für die Ablesung (Gerät, Kamera, von Hand). Sie liest sich wie ein Baum: Schritte einer Gruppe sind unter ihrem Kopf eingerückt, Schritte in einem if-Block eine Ebene weiter, mit der Antwort, unter der sie laufen („bei Ja“, „bei Nein“, „bei bestanden“, „bei nicht bestanden“); die volle Bedingung steht im Tooltip und in den Details. Schritte mit einem Hinweis des Compilers tragen ein Warndreieck. Gruppen lassen sich am Pfeil einklappen, die Knöpfe oben klappen alle ein oder aus; der Kopf einer eingeklappten Gruppe zeigt die Zahl ihrer Schritte. Die Auswahl oben filtert: nur Messpunkte, nur Fragen und Bestätigungen, nur Schritte mit Bedingung oder nur Schritte mit Hinweis. Die Gruppenköpfe der passenden Schritte bleiben stehen, damit der Zusammenhang erhalten bleibt. Darunter stehen die Details zum markierten Schritt: auch das, was der Schritt von seiner Gruppe erbt (gekennzeichnet), Bereich, Auflösung, Unsicherheit, Wiederholungen, Ablesequelle, Auswertung, Bedingung und Prüfanweisung.

Der Schalter Ablauf oben in der Vorschau geht den Plan so durch, wie ihn der Prüfer am Messplatz sieht: Schritt für Schritt, Gruppenköpfe nur als Überschrift. Bei einer Frage (ask) wählt man Ja oder Nein, bei Bestätigungen Bestanden oder Nicht bestanden. An einem Messpunkt steht ein Feld für die Probe-Ablesung (bei repeat N sind es N Felder): beim Verlassen des Feldes rechnet calServer den Punkt wie in der Messwertaufnahme und zeigt Grenzen, Abweichung und Urteil (Bestanden, Nicht bestanden oder bedingt); „Auswerten“ rechnet sofort. Steht ein Wert im Feld, entscheidet allein diese Auswertung: „Weiter: Bestanden“ (oder ein zweites Enter) geht mit dem Urteil weiter, if pass|fail folgt ihm, die Knöpfe zum Wählen sind dann weg. Nur ohne Ablesung bleibt die Wahl Bestanden oder Nicht bestanden, um nur den Weg zu sehen. Bewertungsschritte (rate) nehmen eine Probe-Bewertung mit Sternen und zeigen das Urteil ihrer Bänder. Schritte, deren Bedingung danach nicht zutrifft, werden übersprungen und genannt. So prüft man, ob ein if … else … end dorthin führt, wo es soll. Gespeichert wird dabei nichts. „Ab Marke starten" beginnt beim Schritt unter der Marke, „Im Skript zeigen" springt zurück in den Text.

Unter Optionen im Skript stellt man am Messpunkt ein, wie er gelesen wird: von Hand oder mit der Kamera, bei der Kamera die Übernahme (jede Ablesung bestätigen oder grüne Werte automatisch) und die Zahl der Wiederholungen. Die Ansicht schreibt das als Eigenschaft an den Schritt ins Skript (read camera, capture auto, repeat 3, unter einer Kamera- oder Gerätegruppe read manual) und lässt weg, was nur wiederholen würde, was die Gruppe vorgibt. Der Text bleibt die einzige Quelle; was im Ablauf geändert wird, steht danach im Skript wie getippt. Liest der Punkt an einem Gerät (read device), wird die Bindung im Skript geändert, nicht hier.

Grenzen, die erst mit der Ablesung entstehen. Ohne ref (Bezug UUT Indicated) bezieht sich ein Prozentanteil der Toleranz auf den Ablesewert des Prüflings. Mit ref device, ref manual oder ref camera (Bezug REFERENCE) liegen die Grenzen um die Ablesung des mitmessenden Normals, mit jedem Anteil der Toleranz; der Prozentanteil gilt auch hier vom Wert des Prüflings. Beide Grenzen gibt es erst, wenn abgelesen ist: Vorschau, Probelauf und Prüfablauf zeigen vorher „aus dem Ablesewert“ statt eines Bands auf dem Sollwert und rechnen die Grenzen aus der Ablesung (bei Wiederholung aus dem Mittelwert). Der Prüfablauf fragt die Referenz neben dem Wert des Prüflings ab und speichert ohne sie nicht. Mit source uut und einer Referenz (messendes Normal, Bezug NOMINAL) gilt der Prozentanteil vom Sollwert, die Grenzen stehen dann vorab fest; ebenso ohne Referenz bei Anteilen in U, / oder D.

Grenzen in Anzeigestellen. Untere und obere Grenze stehen in den Stellen der Auflösung des Schritts (ohne Auflösung in mindestens drei Stellen und denen von Sollwert und Toleranz) und sind zum Sollwert hin gerundet: eine Grenze, die die Anzeige nicht darstellen kann, wird nie großzügiger als die Toleranz. Das Guard Band steht in den Stellen von Grenze und Unsicherheit; Toleranzausnutzung und Genauigkeitsverhältnis (TAR) rechnen aus der ungerundeten Toleranz, denn die Rundung gehört zur Anzeige des Prüflings, nicht zur Fähigkeit des Verfahrens. Vorschau, Probelauf und Erfassung rechnen so wie der Server beim Speichern; eine gemeinsame Prüfdatei hält beide Rechnungen deckungsgleich. Null ist eine gültige Grenze (5 ± 5), und ohne Zahl im Messwert gibt es kein Urteil.

Das Rechner-Symbol oben in der Vorschau startet den Probelauf über die geprüften Schritte des Skripts. Er läuft auf der Seite, an der Stelle des Editors, und sieht aus und reagiert wie der echte Prüfablauf: dieselbe Erfassungstabelle, Enter übernimmt und springt zum nächsten Punkt, Fragen (ask) lassen sich beantworten und schalten die Zweige (if yes|no|pass|fail) wie im Lauf, Kopf und Fortschritt zeigen erfasst, offen und das Gesamturteil. Der Cursor steht im Schritt unter der Marke. Ein Punkt mit repeat N bekommt N Felder; bewertet wird der Mittelwert, erst wenn alle N Ablesungen stehen. Kommt für einen solchen Punkt nur ein Wert (etwa über die API), gilt er für alle N Ablesungen. Gespeichert wird nichts, und gerechnet wird mit den Toleranzen des Plans: Spezifikation des Prüflings, Normale und Vorlauf gibt es erst in einer Kalibrierung. Die Kamera-Ablesung steht wie im Lauf über die Taste „Kamera-Ablesung“ über der Tabelle bereit; sie füllt das Feld, ein Beweisbild bleibt im Probelauf nicht, und die Plausibilität gegen die Toleranz prüft erst der echte Lauf. Die Probeantworten bleiben stehen, bis der Editor geschlossen wird; „Probeantworten zurücksetzen“ verwirft sie. „Im Editor zeigen“ an einer Zeile und „Zurück zum Editor“ führen zurück an die Stelle im Skript bzw. in der Tabelle. Auch der Knopf „Probelauf“ des Schritt-Editors rechnet in der Skript-Ansicht mit dem Skript, nicht mit dem Stand der Tabelle.

Steht die Marke auf group, if, else oder end, leuchten die übrigen Zeilen desselben Blocks auf; Alt+Bild↑ und Alt+Bild↓ springen an Anfang und Ende des Blocks, um den die Marke steht, ein zweites Mal eine Ebene höher. Einklappen lassen sich Gruppen nur in der Vorschau, nicht im Text selbst.

Für lange Skripte, etwa aus einem MET/CAL-Import mit tausend Zeilen, gibt es zwei Wegweiser. „Inhalt" blendet links neben den Zeilennummern das Inhaltsverzeichnis ein: plan und jede group mit der Zahl ihrer Schritte; ein Klick springt zur Zeile, die Gruppe, in der die Marke steht, ist markiert. Ob das Verzeichnis offen ist, merkt sich der Browser. „Suchen" (oder Strg+F im Editor) öffnet eine Suchzeile über dem Text; eine markierte Stelle wird zum Suchwort. Alle Treffer sind im Text gelb getönt, der aktuelle kräftig; Enter springt zum nächsten, Shift+Enter zum vorigen, Escape schließt die Suche und setzt die Marke zurück in den Editor. Groß- und Kleinschreibung spielt keine Rolle. Eingefärbt und nummeriert wird nur der sichtbare Ausschnitt des Textes, deshalb bleibt der Editor auch bei mehreren tausend Zeilen flüssig.

Tastatur im Editor: Enter behält die Einrückung der Zeile (hinter group eine Stufe tiefer), Tab rückt ein und Shift+Tab aus (mit Auswahl zeilenweise), Strg+# kommentiert die markierten Zeilen aus und wieder ein (Strg+/ geht auch), Alt+↑/↓ verschiebt Zeilen, Strg+G springt zu einer Zeilennummer, F3 zum nächsten Suchtreffer. Wer das Feld mit der Tastatur verlassen will, drückt zuerst Escape und dann Tab. Strg+S speichert. „Tastenkürzel" unter dem Text zeigt die Liste; seltene Befehle (Formatieren, Gehe zu Zeile, MET/CAL-Import) stehen in der Werkzeugleiste unter „Mehr". Der Name des Prüfplans kommt aus plan "…"; das Namensfeld im Dialog überschreibt ihn.

MET/CAL-Prozedur importieren

„MET/CAL-Prozedur importieren" (Skript-Ansicht, unter „Mehr") nimmt die Textdatei einer Prozedur (.mc) und übersetzt sie serverseitig in ein Skript der Sprachversion 0. Übersetzt werden der Kopf (erster INSTRUMENT-Name wird plan, Autor, Revision und Datum werden Kommentare), HEAD als Gruppe (steht Text in geschweiften Klammern, wird nur der zur Überschrift, denn wie in MET/CAL geht nur er ins Ergebnis; HEAD -2 {…} wird eine Untergruppe, die den Namen ihrer Hauptgruppe vorn trägt, etwa „AC VOLTS › 50 V Range“, und eine Gruppe ohne einen einzigen Schritt entfällt), DISP und MESS als Meldung, EVAL als Ja/Nein-Bestätigung und die Bewertungszeilen der Kalibrator-FSCs (Nennwert mit Vorsatz und Einheit, Bereich, Toleranz in %, %r und absolut; ppm wird in Prozent umgerechnet) als measure. Die Schreibweise des Nennwerts wird die Auflösung (190.00mV ergibt resolution 0.01). Bei einer Quelle (5500, 5520, 5700 …) liest der Prüfer den Prüfling ab, der Bezug ergibt sich von selbst; bei einem messenden Normal (8508, 3458 …) schreibt der Import source uut mit ref manual dmm: der Prüfling gibt den Sollwert aus, das Normal wird abgelesen. RSLT =Text wird ein Kommentarschritt (auf dem calServer-Schein steht er nicht), ein Setup-Test mit Nennwert (MOD4 S) wird die Meldung „5011 einstellen: 30 Vpp (1kH)“. Eine eingerückte Anweisung ohne Schrittnummer direkt nach der Spaltenkopfzeile wird gelesen und im Bericht genannt. Einheitensymbole werden übersetzt (Z wird Ω, H wird Hz, T wird s, degC wird °C, pct wird %).

Verzweigungen werden Blöcke (ADR 2026-10-31 „Entscheidungen im Plan“): OPBR wird eine Frage (ask, mehrzeilig wie DISP; -z und [NO] ändern nur Zahlenwert und Schaltfläche in MET/CAL und entfallen). Ein JMPT, JMPF oder JMPZ direkt nach OPBR oder einem Bediener-EVAL wird ein Block über die Zeilen bis zur Zielschrittnummer, mit der Antwort, bei der nicht gesprungen wird (JMPF 1.006 nach OPBR: die Zeilen bis 1.006 laufen bei Ja). Steht als letzte Zeile des Blocks ein JMP weiter nach vorn, wird der Rest bis dorthin der else-Zweig. JMP t.sss PASS oder FAIL nach einer Bewertung wird if fail beziehungsweise if pass. IF/ELSE/ENDIF auf MEM1 (auch über eine MATH-Kopie wie PUT("x", MEM1)) wird if/else/ end. Ein EVAL ohne eigene Frage nimmt den Text des vorangehenden MESS als Frage, wie es das MET/CAL-Handbuch vorsieht. MEMI wird der Hilfstext des folgenden MEMC/MEMCX (dort gibt der Prüfer den Wert ein), eine Anweisung, wenn die Prozedur die Eingabe danach nur in einer Bedingung prüft (Auswahl „1 = …, 2 = …“), sonst ein Messschritt ohne Sollwert.

Ballast aus Hersteller-Paketen (ADR 2026-11-03 „MET/CAL-Import ohne Ballast“): Was beim Import schon feststeht, rechnet der Import aus, statt es als Kommentar stehen zu lassen. MATH mit festen Werten (@Model = "289") setzt die Variable; [V @Model], [MEM2] und Register mit festem Wert werden im Text eingesetzt. Bedingungen auf feste Werte, IF 0, PSUB/PSUBI (Name, unter dem die Unterprozedur aufgerufen wurde), ISVAR, ZCMP und EMPTY entscheidet der Import: es bleibt nur der Zweig, der gilt. Hängt eine Bedingung an einem Wert, den MET/CAL erst zur Laufzeit liest (Antwort des Geräts, ini-Datei), ist der Zweig in einer Unterprozedur ein Fehler- oder Sonderfall (Schnittstellenfehler, Batteriestand, falsches Modell): Meldungen und Fragen darin entfallen, Messpunkte bleiben. Eine Frage, die im Plan nichts steuert („Befehl erneut senden?“, „Bei Fehlern anhalten?“), entfällt ebenso. Standby, Operate und Reset eines Kalibrators sind keine Messpunkte und entfallen. Stellt der Kalibrator denselben Wert ein, den das folgende MEMC/MEMCX bewertet, ist das ein Messpunkt (Hilfstext „Normal: 5502E; Anzeige eingeben …“), nicht zwei. Ein WAIT vor einem Messpunkt wird dessen Einschwingzeit (Geräteablesung) oder ab 10 s der Hinweis „Vor dem Ablesen 20 s warten“; kürzere Pausen vor einer Handablesung entfallen, sonst steht die Zeit in der Anweisung davor. Jede dieser Entscheidungen steht im Bericht.

Bedienprüfungen mit EVAL -e: Fluke-Pakete stellen bei Bedienprüfungen (Hintergrundbeleuchtung, Tasten, Durchgangspiepser) mehrere OPBR -z-Fragen, kopieren jede Antwort in ein Register (MATH L[1] = MEM1) und bewerten erst am Ende mit EVAL -e L[1] && L[2] : Text: bestanden, wenn alle Antworten Ja sind. Der Import macht daraus Bestätigungen (confirm, Ja = bestanden), statt Fragen ohne Urteil stehen zu lassen. Fehlt an einer Frage -z, ist Nein in MET/CAL −1 und zählt im Ausdruck als wahr: dort bestand der Test auch bei Nein. Gemeint war fast immer Ja = bestanden, so übernimmt es der Import auch, meldet die Stelle aber im Bericht („bitte prüfen“). Ein & (in MET/CAL Textverkettung, kein logisches Und) bleibt Kommentar, mit dem Grund im Bericht. Eine Frage, die schon einen Block steuert, bleibt Frage.

Bereichsprüfung nach einer Eingabe: folgt auf ein MEMI ohne MEMC ein EVAL -e (MEM >= a) && (MEM <= b) (auch mit >/< oder a <= MEM), bekommt der Eingabeschritt die Mitte des Bereichs als Nennwert und die halbe Breite als absolute Toleranz, die Auflösung aus den Stellen der Grenzen. Prüfte MET/CAL mit < oder >, galt die Grenze selbst dort als nicht bestanden; der Bericht sagt das dazu.

Kalibratorzeilen über mehrere Zeilen: lange Anweisungen in benannter Form (Mode = ACI; Coil = 50; in der ersten, +Curr = 300 A; … in der nächsten Zeile mit gleicher Schrittnummer) liest der Import als eine Anweisung. Mehrere Zeilen ohne benannte Parameter bleiben Kommentar, weil nicht klar ist, welche gilt.

Nennwert aus dem Register: steht in der Nennwertspalte nur eine Einheit (5502E mV 1%), rechnete MET/CAL den Sollwert vorher aus. Der Messpunkt kommt trotzdem in den Plan, als „Nennwert von Hand setzen (mV)“ ohne Nennwert, damit er nicht verloren geht; der Bericht nennt jede Stelle. Ein MEMCX mit nur einer Einheit nimmt, wenn möglich, den Wert, den das Normal zuletzt ausgegeben hat (5730A 10V und danach MEMCX V 0.01% ergibt Nennwert 10 V); die Normal-Zeile ohne Toleranz wird dann zur Meldung „5730A einstellen: 10 V“, damit der Punkt nicht doppelt im Plan steht. Passt die Einheit nicht, wird nichts geraten.

Warten und Gerätesteuerung: WAIT mit Text (-t 00:05:00 Warmlaufen lassen) wird die Meldung „Warten: 5:00 min (Warmlaufen lassen)“, eine stille Pause (WAIT [D2000]) entfällt, ebenso Messmodus- und Bereichszeilen messender Normale (M8508, M9100, M3458 …), das Rücksetzen eines Normals (*, auch mit MOD4 S), LABEL und TARGET sowie ein JMPL als Verteiler einer Sammeldatei (PSUBI(…)) oder als Sprung bei Schnittstellenfehler. Das übernimmt der Messplatz oder der Import selbst; der Bericht zählt es unter „weggelassen“.

Texte in Meldungen und Fragen: eckige Klammern mit einer Zahl sind in MET/CAL ein Zeichen nach seinem ASCII-Code, keine Formatierung (Quelle: MET/CAL-Hilfe, Abschnitt „Numeric Literals“). Fluke-Pakete schreiben [32] (Leerzeichen) an den Zeilenanfang, damit die Einrückung erhalten bleibt, und [7] für einen Piepton. Der Import setzt druckbare Zeichen ein, lässt Steuerzeichen weg und kürzt die Einrückung; aus [32] ACHTUNG! wird ACHTUNG!. Eine Anzeigeverzögerung ([D1000]) entfällt, geschweifte Klammern fallen weg. Platzhalter für Laufzeitwerte ([MEM], [V Name], [S1]) haben in calScript noch kein Gegenstück: sie bleiben im Text stehen, und der Bericht nennt jede Stelle. Fortsetzungszeilen einer Anzeige werden echte Zeilen; mehrzeilige Meldungen stehen im Skript als """-Block, auch mit Leerzeilen dazwischen.

Versionsprüfung: IF NOT(VERSIONCHECK("8.1")), gefolgt von END und ENDIF, bricht in MET/CAL ab, wenn die Laufzeit zu alt ist. In calServer gibt es diese Laufzeit nicht; die drei Zeilen fallen weg, auch in Unterprozeduren.

Alles, was Sprachversion 0 nicht kennt (MATH, Sprünge rückwärts oder über Blöcke hinaus, Sprünge mit Prozedurname, IF auf andere Register oder mit ELSEIF, andere EVAL -e-Ausdrücke, MEM2, RSLT ohne =, CALL, ASK, Register, Nennwert- und Vergleichstests mit MOD4, Toleranzen aus TOL oder Registern), bleibt als Kommentarzeile # metcal <Schritt> <Zeile> an seiner Stelle im Skript stehen, mit dem Grund im Bericht. Der Nacharbeitsbericht unter der Vorschau zählt auf, welche Zeilen übersetzt, kommentiert oder weggelassen wurden (ein leeres HEAD, das nur die Anzeige löscht, ein RSLT =, das nur eine Leerzeile ins Ergebnis schreibt, END und die oben genannte Gerätesteuerung). Enthält eine Prozedur gar nichts Abbildbares, etwa eine Hülle aus MATH und CALL, sagt der Import das und verweist auf den Projektimport. Nichts wird stillschweigend verändert: eine Zeile ist übersetzt, kommentiert, oder der Import bricht mit Zeilenangabe ab. Die Originalprozedur gehört nicht ins Repository und nicht in die Dokumentation; der Import arbeitet mit der Datei auf deinem Rechner.

Prüfling über die Schnittstelle: Liest die Prozedur den Prüfling über IEEE, IEEE2, SCPI, VISA oder PORT und bewertet den Wert mit MEMC oder MEMCX, wird der Messpunkt automatisch: read device uut, die Funktion aus Einheit und Modifier (VDC, VAC, ADC, AAC, OHM, OHM4, CAP, FREQ) und, wenn ein Setup-Test des Kalibrators (MOD4 S) genau diesen Nennwert ausgibt, source cal; die Meldung „5520 einstellen …“ entfällt dann. Die Befehle selbst stehen nicht im Skript, sondern in einem Entwurf des Treiberprofils für den Prüfling: Schnittstelleneinstellungen (Baudrate, Abschlusszeichen, Zeitlimit), Rücksetzbefehle als init, je Funktion die Messbefehle, bei mehreren Bereichen je Bereich eine eigene Folge (ranges), und ein Umrechnungsfaktor, wenn ein MATH MEM = MEM * 1000 den Wert in die Einheit des Nennwerts brachte (scale, sonst rechnet der Runner selbst in die Grundeinheit). Eine Wartezeit vor dem Lesen ([D500]) wird settle am Punkt. Die Busbefehle bleiben als # metcal-Kommentar im Skript stehen, damit man sieht, woher der Punkt kommt; im Bericht sind sie „übersetzt“.

Automatisch wird nur, was sich sicher übertragen lässt. Handablesung mit Grund im Bericht bleibt ein Punkt, wenn der Wert von einem Normal kommt (Adresse [@8508], [@3458], [@LFCTR] oder ein Normal aus dem Kopf), ein Befehl einen Laufzeitwert enthält ([MEM], [V Kanal]), ein MATH mit dem gelesenen Wert rechnet, nach dem Lesen noch Befehle folgen, das Normal einen anderen Wert ausgibt, als der Punkt bewertet, oder sich Bereiche und Einstellungen widersprechen. Geraten wird nichts.

Den Entwurf speichert der Einzelimport erst auf Knopfdruck („Als inaktiven Entwurf speichern“, Recht workstation_edit), der Projektimport legt ihn beim Anlegen der Pläne an. In beiden Fällen ist er inaktiv, mit dem Gerätetyp der Spezifikation, und ein vorhandenes Profil mit derselben Kennung bleibt unverändert. Vor dem ersten Lauf prüfst du die Befehle am Gerät, ergänzt die Kennung (idn) und schaltest das Profil unter Treiberprofile ein. Hintergrund: ADR 2026-11-01.

Kamera statt Handablesung: Punkte, die der Prüfer vom Display des Prüflings abliest (nicht source uut, keine Ablesequelle), zählt der Import und bietet unter dem Bericht „Display-Punkte per Kamera ablesen“ an. Das übersetzt dieselbe Datei noch einmal mit read camera uut an diesen Punkten; automatische Punkte bleiben am Bus. Im Projektimport ist das ein Häkchen über der Liste, die Spalte „Ablesung“ zählt je Plan automatische, Kamera- und Display-Punkte. Für einen Plan, der schon im Editor steht, macht dasselbe das Ziel „Ablesung zuordnen“ in „Prüfplan mit KI optimieren“.

Bericht und Skript sind verbunden: ein Klick auf eine Berichtszeile (oder der Pfeil am Zeilenende) setzt die Marke an ihre Stelle im Skript, bei einer kommentierten Zeile auf ihr # metcal, sonst auf den Schritt, der aus ihr entstanden ist oder ihr folgt. Solange der Bericht offen ist, markiert ein Strich am linken Rand der Zeilennummern jede nicht übersetzte Stelle. Bei eingefügten Unterprozeduren ist das die einzige Spur im Text, denn ihre Lücken stehen nicht als Kommentar im Skript.

MET/CAL-Projekt importieren

Eine Prozedur kommt selten allein: die Hauptprozedur ruft mit CALL Unterprozeduren auf (Sicherheitshinweis, Aufwärmzeit, ein Messbereich je Datei). „MET/CAL-Projekt“ in der Prüfplanliste (/procedure/templates) nimmt deshalb das ganze Projekt: ein Fluke-Paket (ZIP mit Manifest und Quell-ZIP), ein ZIP mit .mc-Dateien oder mehrere .mc-Dateien auf einmal. Der normale „Importieren“-Knopf führt eine .mc-Datei oder ein ZIP ebenfalls in diese Vorschau; ein ZIP ohne MET/CAL-Prozedur (ein calServer-Paket) geht wie bisher in den Paketimport.

• Hauptprozedur ist jede Prozedur, die keine andere im Projekt aufruft. Jede gewählte Hauptprozedur wird ein eigener Prüfplan.
• Unterprozeduren werden Bausteine, wenn sie in jedem Plan des Imports dasselbe Skript ergeben und mindestens einen Messschritt mitbringen (siehe Untergruppen und Bausteine). Der Plan bindet sie mit use "Name" version 0.1 ein, statt ihre Schritte zu wiederholen. Gibt es den Baustein schon mit gleichem Inhalt, nimmt der Import ihn wieder; mit anderem Inhalt bekommt er eine neue Version, die ältere Pläne nicht berührt. Hängt das Ergebnis vom Aufruf ab (PSUBI, Variablen des Aufrufers) oder liefe der Plan mit Baustein anders, bleibt die Unterprozedur an der Stelle ihres CALL eingefügt, auch verschachtelt; Kommentarzeilen markieren dann Anfang und Ende. Die Vorschau nennt je Unterprozedur, was mit ihr geschieht, und die Option „Unterprozeduren als Bausteine anlegen“ schaltet das ab. Eine Unterprozedur wird nie ein eigener Plan.
• HEAD -2 wird eine echte Untergruppe (subgroup) unter der Gruppe davor; ohne Gruppe davor steht sie als Gruppe.
• Gesucht wird wie in MET/CAL über jeden INSTRUMENT-Namen einer Prozedur, ohne Groß- und Kleinschreibung.
• Ein Aufruf auf eine Prozedur, die nicht im Projekt liegt, bleibt als # metcal … CALL … im Skript und steht in der Vorschau. Ebenso eine Rekursion (A ruft B ruft A) und alles, was tiefer als 8 Aufrufe läge; dort bricht auch MET/CAL ab.
• Sammeldateien: Fluke bündelt Hilfsprozeduren in einer Datei mit mehreren INSTRUMENT-Namen und einem Verteiler vorn (JMPL <Marke> PSUBI("…")). Eingefügt wird nur der Abschnitt, den der aufgerufene Name erreicht, von seiner Marke bis zum nächsten END. Was in einer Unterprozedur hinter einem END steht, erreicht MET/CAL nur per Sprung; es bleibt draußen.
• Hilfsprozeduren in Bedingungen lesen Messwerte oder zeigen Fehler bei Bedarf. Ein CALL in einem IF-Zweig wird nur eingefügt, wenn er einen Messschritt mitbringt; eine reine Fehleranzeige stünde sonst in jedem Lauf. Der Bericht nennt den Aufruf.
• MEMC/MEMCX (Bewertung eines über die Schnittstelle gelesenen Werts) wird ein Messschritt mit Nennwert und Toleranz; den Wert gibt in Sprachversion 0 der Prüfer ein. Die Schnittstellenbefehle (IEEE, IEEE2) stehen im Bericht.
• Der Dateikopf einer Unterprozedur (Autor, Copyright) kommt nicht in den Plan, und wer dieselbe Unterprozedur mehrfach aufruft, findet ihre Hinweise im Bericht nur einmal.
• Eine Prozedur „Sub …“, die niemand im Paket aufruft, ist meist ein übrig gebliebener Helfer; die Vorschau zeigt sie, wählt sie aber nicht vor.
• Trägt ein Name mehrere Dateien, gewinnt die erste, und die Vorschau sagt es. Eine Datei, die sich nicht lesen lässt, wird übersprungen und genannt.

Die Vorschau zeigt je Hauptprozedur die Zahl der Schritte, die eingefügten Unterprozeduren und den Nacharbeitsbericht. Bedingte Zweige (IF, JMPL) übersetzt Sprachversion 0 nicht: eine Hülle, die je nach Auswahl verschiedene Unterprozeduren ruft, enthält nach dem Import alle Zweige hintereinander. Der Bericht nennt die kommentierten Sprünge; welche Schritte der Plan wirklich braucht, entscheidest du beim Nacharbeiten.

Wie beim Einzelimport wird jede Hauptprozedur eine Option metcal-<prozedur> (Art Verwendung) im Entwurf der Spezifikation des Gerätetyps; gibt es für den Typ noch keine, entsteht sie. Die Zeilen der Option ergeben sich über alle Prozeduren, die per CALL laufen: ein Messpunkt einer Unterprozedur steht an der Stelle ihres Aufrufs, eine Unterprozedur bekommt keine eigene Option. Den Typ schlägt die Vorschau aus dem INSTRUMENT-Namen und aus den Prüflingen im Manifest des Pakets vor. Ohne Typ entsteht nur der Prüfplan. Jede Zeile trägt ihre Fundstelle (Schritt, FSC und ob der Sollwert oder die Ablesung bewertet wird), ein Prüfpunkt steht als Punktzeile, auch negativ. Ein erneuter Import derselben Prozedur ersetzt die Option im Entwurf. Ist sie schon freigegeben, ersetzt der Import nichts stillschweigend, sondern fragt: neue Version (die Option wird im Entwurf der nächsten Revision ersetzt; bis zu dessen Freigabe zählt die freigegebene Revision) oder neuer Name (eine weitere Option daneben). Der Projektimport fragt einmal vorab für alle Pläne, ob er eine neue Version anlegt oder die freigegebene Option behält; „behalten“ meldet sie im Ergebnis. Freigegeben wird eine Option wie jede andere Spezifikation von einer Person. Der importierte Plan trägt kein tol, sobald seine Prozedur eine Option geworden ist: Die Toleranz kommt aus der gewählten Option, und bis zu deren Freigabe bewertet der Plan nichts. Im Plan gewönne tol immer über die Spezifikation, die Option käme nie zum Zug (Konzeptprüfung 2026-11-03). Nur ohne Gerätetyp oder wenn die Spezifikation nicht angelegt werden konnte, behält der Plan tol. Für Bausteine gilt dasselbe: Haben alle Pläne einer Unterprozedur eine Option, trägt der Baustein kein tol; rufen Pläne mit und ohne Option sie, bleibt sie eingefügt. Siehe Spezifikationen.

Unter der Haube ist der Editor seit 2026-11-03 CodeMirror 6: Text, Marke, Farben und Zeilennummern sind eine Fläche, Klick und Tippen landen dort, wo man hinsieht, und Strg+Z nimmt auch die Editorhilfen (Enter mit Einrückung, Tab, Kommentieren, Vervollständigung) einzeln zurück. Hervorhebung, Vervollständigung und Tooltip kommen weiter aus den calScript-eigenen Helfern; eine zweite Grammatik gibt es nicht. Begründung: ADR 2026-11-03 „Editorbaustein für calScript“.

Entwurf mit KI

„KI-Entwurf" in der Skript-Ansicht (und in Tabelle und Karten) entwirft aus Gerät, Spezifikationen und Prüfvorgaben ein Skript dieser Sprachversion, mit Gruppen, Serien und auf Wunsch den Rollen des Messplatzes. Der Compiler prüft es, das Modell bessert bei einem Fehler bis zu zweimal nach. Der Entwurf ersetzt das Skript oder wird ohne zweiten Kopf angehängt; gespeichert wird von Hand. Einzelheiten: Prozedurvorlagen, Entwurf mit KI, Hintergrund: ADR 2026-10-29.

Aufbau

Jede Zeile ist eine Anweisung oder eine Eigenschaft des zuletzt begonnenen Schritts. Einrückung ist Kosmetik, # beginnt einen Kommentar. Ein manueller Prüfplan ist eine Liste, das Dokument dahinter auch; die einzige Struktur darüber sind Gruppen mit Untergruppen, Bausteine und Entscheidungen (if-Blöcke an einer Frage oder einer Bewertung, siehe unten). Freie Ausdrücke, Variablen oder Schleifen gibt es nicht.

Anweisung	Schritttyp im Plan	Bedeutung
calscript 0	–	Sprachversion, erste Zeile (optional, empfohlen)
plan "Name"	–	Name der Vorlage
standard Rolle "Gerätetyp"	–	Vorgesehener Gerätetyp einer Rolle, vor dem ersten Schritt, je Rolle einmal
group "Titel"	Header	Abschnitt; trägt Vorgaben für die Schritte darunter, bis zum nächsten group oder end
subgroup "Titel"	Header (group_level: 2)	Zweite Ebene in einer Gruppe; erbt deren Vorgaben, bis zur nächsten subgroup, group oder end
module "Name"	–	statt plan: das Skript ist ein Baustein, siehe unten
use "Name" [version 1.0]	die Schritte des Bausteins	Baustein einbinden; ohne version gilt die jüngste freigegebene Version
measure [Sollwert] ["Beschreibung"]	Manual Test	Messpunkt, erbt Ergebnistyp, Einheit und Toleranz der Gruppe
measure Sollwert Sollwert … ["Beschreibung"]	Manual Test je Sollwert	Serie, siehe unten
confirm "Beschreibung"	Manual Test (TEXT(Y=PASS))	Ja/Nein-Prüfung; result noyes dreht die Logik
ask "Frage?"	Manual Test (CHOICE(Y/N))	Ja/Nein-Frage ohne Urteil; die Antwort steuert if yes / if no, siehe unten
if yes / if no / if pass / if fail	Bedingung (condition) der Schritte darin	Block bis else oder end; yes/no meint die letzte Frage, pass/fail die letzte Bewertung
else	–	Gegenzweig desselben Blocks
rate "Beschreibung"	Rating	Bewertung mit map "1-2:fail\|3-5:pass"
message "Text"	Message	Hinweis an den Prüfer, kein Ergebnis
comment "Text"	Comment	Interne Anmerkung
end	–	schließt die innerste offene Gruppe oder den innersten if-Block (bei Gruppen optional)

Eigenschaften stehen auf eigenen Zeilen unter dem Schritt oder hinter der Anweisung auf derselben Zeile (measure 100 "100 mV" @ 50 Hz). Nur tol, stable und contrib nehmen den Rest der Zeile.

Eigenschaft	Spalte im Plan	Hinweis
step 7.001	Prüfschritt-Nr.	nur nötig, wenn die automatische Nummer (Gruppe 1, 2, …; Schritte 1.001, 1.002, …) nicht passt; die Schritte danach zählen von ihr weiter (7.002, 7.003 …), und jede Nummer darf im Plan nur einmal vorkommen
value 100	Sollwert	bei measure auch als erstes Argument; ein + davor (measure +100) ist erlaubt, wie in MET/CAL die Bewertungsgröße
@ 50 Hz, modifier 50 Hz	Modifier	zweite Größe, unter der der Sollwert gilt (Frequenz, Temperatur …): Zahl mit Einheit, auch @1kHz; siehe unten
aux "2-Draht"	Hilfsfeld	Freitext, wird nicht bewertet
info "…"	Prüfanweisung	HTML erlaubt; lange Texte als """-Block
md "…"	Prüfanweisung (Markdown)	Alternative zu info
image "name.svg"	Bilder	mehrfach, höchstens 10
result numeric / yesno / noyes	Ergebnistyp (config)	NUMERIC, TEXT(Y=PASS), TEXT(N=PASS)
ref device dmm, ref manual thermo	Bezug (config, Bindung)	ein Normal der Rolle misst mit, seine Ablesung ist der Bezug (REFERENCE): vom Messplatz, von Hand oder ref camera thermo per Kamera; mit source uut NOMINAL; siehe unten
ref none	Bezug (config)	kein Bezug: der Wert wird erfasst, nicht bewertet; fehlt ref, ist der Sollwert der Quelle der Bezug (UUT INDICATED)
config "…"	config wörtlich	statt result/ref
prefix m, unit V	SI-Vorsatz, Einheit	getrennt, damit m nie zweideutig ist
range 320	Bereich	Bezug für %r
resolution 0.1	Auflösung	Bezug für D
tol 0.3% + 1 D	Toleranz	siehe unten
uncertainty 0.03	Messunsicherheit (U, k)
k 2	Erweiterungsfaktor	nur an group; gilt für jeden Punkt der Gruppe, gerechnet oder mit fester uncertainty, und steht neben U auf dem Schein (siehe Messunsicherheit)
rule "ILAC-G8 w = U"	Entscheidungsregel	nur an group; steht im Plan und seiner Revision; bewertet wird nach der Entscheidungsregel der Kalibrierung
repeat 5	Wiederholungen	ganze Zahl 1 bis 100, nur an measure und group; siehe unten
discard 2	Vorlauf verwerfen	ganze Zahl 0 bis 100, nur an measure und group; Ablesungen vor der Messreihe, die nicht zählen
read manual, read device uut, read camera	Ablesequelle	manual ist die Erfassung von Hand; device lässt den Messplatz ablesen; camera lässt die Webcam im Browser ablesen, der Prüfer bestätigt; mit source stellt der Messplatz dazu das Normal; mehrere mit | stellen die Ablesung zur Wahl im Vorlauf (read device uut \| camera \| manual, die erste ist die Vorgabe); siehe unten
source cal, function "VOLT:DC", settle 2	Gerätebindung	nur zusammen mit read device, ref device, read camera oder read manual: Rolle, die den Sollwert ausgibt, Messfunktion, Einschwingzeit in Sekunden; source uut (der Prüfling gibt den Sollwert aus) steht ohne read, mit ref device, ref manual oder ref camera
capture confirm, capture auto	Kamera-Übernahme	nur zusammen mit read camera oder ref camera: confirm (Vorgabe) verlangt den Klick des Prüfers, auto übernimmt grüne Lesungen nach einer Doppelaufnahme ohne Klick
stable thermo 0.01 °C 2 min max 30 min	Stabilitätskriterium	nur am Messplatz: der Runner liest die Rolle (ohne Angabe die Referenz, ohne Referenz den Prüfling), bis die Spanne im Fenster im Band bleibt, höchstens bis zur Höchstzeit; das Band ist absolut, % lehnt der Parser ab
direction up, direction down	Messrichtung	auf- und abwärts am selben Sollwert bilden ein Paar; daraus entsteht beim Laden der Schritt „Umkehrspanne“
optional	Punkt nach Option	der Punkt wird nur geladen, wenn die gewählte Option der Spezifikation ihn als Punktzeile verlangt
contrib "Adapter" 0.02 mV rect	Beitrag U3 bis U10	Beitrag des Verfahrens zum Budget (Adapter, Leitung, Ankopplung), Wert mit Einheit: Halbweite einer Rechteck- (rect, Vorgabe) oder Dreieckverteilung (tri), Standardunsicherheit (u) oder erweiterte Unsicherheit mit k = 2 (k2); höchstens acht je Punkt
accred no	Akkreditierungsumfang	nimmt Messpunkte aus dem Akkreditierungsumfang, der Schein kennzeichnet sie mit „*“: vor dem ersten Schritt alle, an einer Gruppe ihre, an measure den einen; ohne =, siehe unten

An einer Gruppe gelten result, ref, config, prefix, unit, modifier, range, resolution, tol, uncertainty, k, rule, repeat, discard, direction, optional, contrib und accred als Vorgabe für alle Schritte bis zur nächsten Gruppe; ein Schritt darf jede davon für sich überschreiben. contrib am Punkt kommt zu denen der Gruppe hinzu, unter demselben Namen ersetzt er den der Gruppe. Die Ablesung (read, source, function, settle, capture, ref, stable) erbt ein Punkt als Ganzes: Wer am Punkt eine eigene read-Zeile schreibt, ersetzt sie vollständig und wiederholt darum ref und stable, sonst meldet der Compiler einen Fehler. Das ist genau die Gruppenvererbung des Editors (group_defaults).

Der Compiler prüft außerdem: tol, range, resolution, uncertainty, prefix und unit gehören an measure oder eine Gruppe, value nur an measure; step, range, resolution und k verlangen eine Zahl größer null, uncertainty keine negative; prefix muss ein SI-Vorsatz sein (u und das griechische μ werden zu µ). Ein measure wird numerisch bewertet: result yesno/noyes gehört zu confirm, und unter einer Gruppe mit result yesno braucht ein measure ein eigenes result numeric; umgekehrt lehnt confirm ein result numeric ab. Rollen (read, source, ref, stable, standard) sind keine Schlüsselwörter der Sprache und unterscheiden sich nicht nur in der Groß- und Kleinschreibung; uut ist der Prüfling und bekommt keine standard-Zeile. Gibt es standard-Zeilen, meldet der Compiler als Hinweis Rollen ohne Zeile und Zeilen ohne Verwendung.

Untergruppen und Bausteine

Ein großer Plan braucht zwei Dinge, die eine flache Liste nicht hat: eine zweite Gliederungsebene und Teile, die mehrere Pläne gemeinsam nutzen. Beides gibt es seit dem 2026-11-03 (ADR „Untergruppen und Bausteine“).

Untergruppen. subgroup "Titel" steht in einer Gruppe, erbt deren Vorgaben und kann eigene setzen. Sie endet an der nächsten subgroup, an der nächsten group oder an end. Mehr als zwei Ebenen gibt es nicht. Hat eine Gruppe Untergruppen, stehen ihre eigenen Schritte vor der ersten Untergruppe; danach kommen nur noch Untergruppen, sonst meldet der Compiler einen Fehler.

group "Gleichspannung"
  result numeric
  unit V
  tol 0.1% + 2 D
  confirm "Messleitungen an V und COM"
  subgroup "Bereich 10 V"
    range 10
    resolution 0.001
    measure 1 5 10 "{value} V"
  subgroup "Bereich 100 V"
    range 100
    resolution 0.01
    measure 50 100 "{value} V"
end

Kompiliert bleibt der Plan flach: die Untergruppe ist eine Überschrift wie jede Gruppe, mit den Vorgaben beider Ebenen und dem Titel „Gleichspannung › Bereich 10 V“. Laufzeit, Schein und DCC sehen keinen Unterschied, Editor und Vorschau zeigen die zweite Ebene eingerückt.

Bausteine. Ein Baustein ist ein eigenes Skript, das mit module "Name" statt plan beginnt. Ein Plan bindet ihn mit use ein:

calscript 0
plan "Fluke 87V"

use "Sichtprüfung Handmultimeter" version 1.0
group "Gleichspannung"
  unit V
  tol 0.05% + 2 D
  use "DCV Punkte 87V" version 2.1

• Gespeichert wird ein Baustein wie ein Plan (Prüfplanliste, Typ „calScript-Bausteine“), ohne Prozedur, mit Versionen, Genehmigung und Freigabe. Ein Name gehört zu genau einem Baustein; eine neue Fassung ist eine neue Version, kein zweiter Baustein mit gleichem Namen.
• Welche Version gilt: version 2.1 nimmt genau diese. Ohne Version gilt die jüngste genehmigte oder freigegebene; gibt es keine, die jüngste mit dem Hinweis „noch nicht freigegeben“. Der Editor schreibt beim Einfügen die Version immer aus, damit eine neue Bausteinversion den Plan nicht still ändert.
• Eingebunden wird beim Prüfen und Speichern des Plans: die Schritte des Bausteins stehen an der Stelle der use-Zeile, im Plan durchnummeriert, mit den Vorgaben der umgebenden Gruppe und den Bedingungen eines umgebenden if. Die gespeicherte Planversion hält fest, welcher Baustein in welcher Version eingeflossen ist; eine spätere Bausteinversion ändert sie nicht.
• Ebenen: Auf oberster Ebene bleiben die Gruppen eines Bausteins Gruppen, in einer Gruppe werden sie Untergruppen. In einer Untergruppe darf ein Baustein nur Schritte mitbringen. Bringt ein Baustein Gruppen mit, beginnt nach der use-Zeile eine neue Gruppe oder Untergruppe; was sonst folgte, gehörte zu seiner letzten Gruppe, und das meldet der Compiler.
• Ein Baustein darf weitere Bausteine einbinden, bis vier Ebenen tief und nie sich selbst. Ein Fehler im Baustein nennt Name, Version und Zeile im Baustein und steht im Plan an der use-Zeile.
• Im Editor: „Einfügen › Baustein“ listet alle Bausteine mit ihren Versionen. Steht die Marke auf einer use-Zeile, öffnet „Mehr › Baustein öffnen“ ihn in einem neuen Tab; Speichern legt dort eine neue Version an. Das Inhaltsverzeichnis zeigt use-Zeilen mit eigenem Symbol, die Vorschau markiert jeden Schritt aus einem Baustein.
• Die Tabellenansicht kennt keine use-Zeile: wer einen Plan mit Bausteinen aus der Tabelle speichert, bekommt die Schritte ausgeschrieben.

Modifier

Ein Sollwert gilt oft nur unter einer zweiten Größe: 10 V bei 50 Hz, 100 mA bei 1 kHz, ein Widerstand bei 23 °C. MET/CAL nennt das den Modifier und schreibt ihn in der benannten Parameterform mit @ (+Volt = 240 V; @Freq = 50 Hz), in der Spaltenform als MOD1. calScript übernimmt das Zeichen:

group "Wechselspannung"
  unit V
  modifier 1 kHz
  measure 1 "1 V"                # erbt 1 kHz
  measure 10 "10 V" @ 50 Hz      # eigener Modifier
  measure +100 "100 V" @1kHz     # `+` wie in MET/CAL, Leerzeichen egal

Der Modifier ist eine Zahl mit optionaler Einheit (50 Hz, 1 kHz, 23 °C); gespeichert wird er mit Leerzeichen zwischen Zahl und Einheit, egal wie er geschrieben war. Vorsatz und Einheit kommen aus dem Einheiten-Lexikon von calServer: 1 uV und 1 μV werden 1 µV, 50 hz wird 50 Hz, 3 daPa bleibt Dekapascal und 0.8 PF der Leistungsfaktor. Freitext (Sinus, 2-Draht) gehört in aux. Im Editor ist der Modifier eine eigene Spalte und, an einer Gruppe, eine Vorgabe für die Punkte darunter; die Erfassung zeigt ihn hinter dem Sollwert (10 V @ 50 Hz). Ein Kalibrator am Messplatz nimmt die Frequenz daraus, wenn die Einheit Hertz ist. Der MET/CAL-Import schreibt beide Formen in dieses Feld. Ein Plan mit Modifier wird als Dokumentversion 7 exportiert; eine ältere Installation lehnt ihn ab, statt den Modifier stillschweigend zu verlieren. Hintergrund: ADR 2026-10-30 Modifier.

Serien

Mehrere Sollwerte hinter measure sind eine Serie: ein Messpunkt je Wert, alle mit denselben Eigenschaften. {value} in der Beschreibung wird durch den jeweiligen Sollwert ersetzt.

  measure 100 190 300 "{value} Ω" aux "2-Draht"
    uncertainty 0.05

ergibt drei Messpunkte (100 Ω, 190 Ω, 300 Ω), jeder mit Hilfsfeld und Unsicherheit. Die Nummern laufen automatisch weiter; step und value passen deshalb nicht zu einer Serie. Ohne {value} tragen alle Punkte dieselbe Beschreibung.

Im Plan kommt keine Serie an, nur die einzelnen Punkte. Die Tabellen-Ansicht zeigt sie einzeln, und wer dort speichert, bekommt die Serie beim nächsten Wechsel ins Skript zurück, sofern die Punkte sich nur im Sollwert unterscheiden (Beschreibung mit dem Wert als ganzer Zahl, sonst gleich; gleiche Eigenschaften; automatische Nummern). Eine Beschreibung mit Dezimalkomma (1,9 kΩ) bleibt ein Einzelschritt, weil der Sollwert im Skript einen Punkt trägt.

Entscheidungen

Ein Plan kann an einer Antwort oder einem Urteil verzweigen. Die Frage ist ein eigener Schritt, die Zweige sind Blöcke:

ask "Ist ein Zusatzmodul eingebaut?"
if yes
  message "Schalter auf EXT stellen."
  measure 1 "1 V"
else
  message "Ohne Modul weiter."
end
confirm "Gehäuse unbeschädigt"
if fail
  message "Schaden notieren, Kunde informieren."
end

ask stellt eine Ja/Nein-Frage und hält die Antwort fest (Spalte varq, Y oder N), ohne zu bewerten: anders als confirm ändert eine Antwort weder das Ergebnis des Schritts noch das Gesamtergebnis. if yes und if no beziehen sich auf die nächste Frage davor, if pass und if fail auf die nächste Bewertung davor (confirm oder measure), jeweils von innen nach außen und über Gruppengrenzen hinweg. Die Bewertung muss ein Urteil liefern: ein Messpunkt mit ref none wird festgehalten, nicht bewertet, und taugt darum nicht als Ziel für if pass oder if fail; der Compiler lehnt das ab, statt dass der Lauf vor dem Block für immer auf ein Urteil wartet. Blöcke dürfen verschachtelt sein (höchstens acht tief); end schließt die innerste offene Struktur. Ein if darf ganze Gruppen umschließen, dann hängt jede davon an der Antwort. Der Plan bleibt dabei flach: eine group in einem if-Block, der in einer Gruppe steht, beendet diese Gruppe, als stünde end vor dem if. Nach dem Block geht es in ihr nur mit else, end oder einer neuen group weiter; ein Schritt oder eine subgroup dort wäre im Plan Teil der Gruppe aus dem Block, und der Compiler lehnt ihn ab. Der Formatierer schreibt die Gruppe vor dem if zu Ende und öffnet den Block auf ihrer Ebene.

Im Dokument trägt jeder Schritt im Block seine Bedingung (Dokumentversion 9, Spalte condition: Prüfschritt-Nr. der Frage und die erwartete Antwort; bei Verschachtelung alle). Im Lauf bleiben die Schritte beider Zweige offen, bis die Antwort da ist; danach gelten die Schritte des anderen Zweigs als übersprungen: der Assistent springt über sie, die Tabelle zeigt „übersprungen“, der Runner misst dort nicht, Fortschritt und Gesamtergebnis zählen sie nicht. Eine Bedingung auf eine Frage, die es nicht gibt, kann nie erfüllt sein; der Schritt bleibt übersprungen statt heimlich Pflicht.

Mehr als Ja/Nein und bestanden/nicht bestanden gibt es bewusst nicht: keine Ausdrücke, keine Register, keine Rückwärtssprünge. Jede Entscheidung hängt an etwas, das im Lauf festgehalten ist, und bleibt so aus den Ergebnissen nachvollziehbar (ADR 2026-10-31 „Entscheidungen im Plan“).

Wiederholmessungen

repeat 5 an einem Messpunkt (oder an der Gruppe) heißt: der Punkt nimmt fünf Ablesungen. Bewertet wird ihr Mittelwert, mit derselben Toleranz und Entscheidungsregel wie ein Einzelwert. Die Einzelwerte bleiben erhalten, zusammen mit der Standardabweichung (n−1), und stehen im Prüfablauf am Punkt.

group "Außenmessung"
  result numeric
  unit mm
  tol 0.02
  repeat 5
  measure 10 50 100 "{value} mm"

In der Erfassungstabelle zeigt ein solcher Punkt N kleine Felder mit laufendem Mittelwert und Standardabweichung; Enter läuft durch die Felder, aus dem letzten heraus wird gespeichert.

Die API nimmt die Werte als readings statt varq (POST /api/v2/test-steps/{id}/capture); der Server rechnet den Mittelwert. Passt die Anzahl nicht zu repeat, antwortet sie mit 422. Wer einen Einzelwert schickt, ersetzt frühere Ablesungen dieses Punkts. Ein Plan mit Wiederholungen wird als Dokumentversion 5 exportiert; eine ältere Installation lehnt ihn beim Import ab, statt die Wiederholungen stillschweigend zu verlieren. Hintergrund: ADR 2026-10-29.

Drei Ebenen: Labor, Gruppe, Messpunkt

Wie viele Ablesungen ein Messpunkt nimmt (repeat) und wie viele Vorlauf-Ablesungen vorher verworfen werden (discard), kann an drei Stellen stehen. Es gilt der innerste Wert:

1. Messpunkt: measure 10 repeat 3 discard 0
2. Gruppe: repeat und discard an group gelten für alle Messpunkte bis zur nächsten Gruppe.
3. Laboreinstellung: Grundeinstellungen › Kalibrierung › Messreihen, „Ablesungen je Messpunkt“ und „Vorlauf-Ablesungen verwerfen“. Leer heißt keine Vorgabe.

group "Gleichspannung"
  result numeric
  unit V
  tol 0.01%
  repeat 4
  discard 1
  measure 1 "1 V"
  measure 10 "10 V" repeat 8
  measure 100 "100 V" discard 0

Die Laboreinstellung gilt nur für Messpunkte, die eine Zahl ablesen; Fragen, Bestätigungen und Meldungen bekommen nichts. Sie wird beim Laden des Plans in die Kalibrierung übernommen, eine spätere Änderung trifft laufende Kalibrierungen nicht. In der Schrittansicht des Editors steht neben „Wiederholungen“ und „Vorlauf-Ablesungen“, woher der Wert kommt (Messpunkt, Gruppe oder Laboreinstellung); die Tabelle zeigt einen Wert aus der Laboreinstellung mit Hinweis.

Vorlauf-Ablesungen liest der Runner am Messplatz (ab Version 0.15.0) und verwirft sie; sie zählen weder zum Mittelwert noch zur Streuung. Ein älterer Runner liest ohne Vorlauf. Referenzablesung, Stabilitätskriterium und Sammellauf liest erst der Runner 0.17.0 (siehe Referenz, Stabilität, Umkehrspanne und Sammellauf).

Aus MET/CAL

Der Import übernimmt VSET (gilt bis VSET * für alle folgenden Tests, auch über eingefügte Unterprozeduren) und TSET (nur der nächste Test), auch mehrere Zuweisungen in einer Zeile:

MET/CAL	calScript	Anmerkung
NMEAS = n	repeat n	NMEAS = 0 schaltet in MET/CAL nur die Unsicherheitsrechnung ab; der Import setzt eine Ablesung und vermerkt es
NTHROW = n	discard n	-1 (Verhalten älterer Treiber) bleibt Kommentar
UUT_RES = x	resolution	absolut in Grundeinheit, auf den Vorsatz des Punkts umgerechnet
GB, GB_OVERFLOW	rule "MET/CAL GB = …" an der Gruppe	nur dokumentiert; calServer bewertet nach ILAC-G8 mit der Messunsicherheit
[V @NMeas] u. Ä.	nichts im Plan	der Wert kam aus der ini-Datei; es gilt die Laboreinstellung

Haben alle Messpunkte einer Gruppe denselben Wert aus VSET, steht er einmal an der Gruppe; Punkte mit TSET behalten ihren eigenen. Hintergrund: ADR 2026-11-02.

Messunsicherheit

Ein Plan nennt die Messunsicherheit auf eine von zwei Arten:

• Fest: uncertainty 0.012 (am Punkt oder als Gruppenvorgabe) ist die erweiterte Unsicherheit U aus dem eigenen Budget des Labors. Sie gewinnt immer, wie die MET/CAL-Übersteuerung „Expanded Uncertainty“, die Methode heißt Vorgabe. k an der Gruppe nennt den Erweiterungsfaktor, mit dem dieses U gebildet wurde, und steht daneben in der Messzeile. rule ist die Begründung der Bewertung: es steht im Plan und in seiner Revision, gerechnet wird damit nicht; die Zeile „Entscheidungsregel“ auf dem Schein ist ein eigener Auftrag (Beispiel 4).
• Gerechnet: ohne uncertainty rechnet calServer beim Erfassen das Budget nach GUM: U1 aus der freigegebenen Spezifikation des Normals, in der Option, mit der es misst (seine Standardoption am Gerät, sonst die der Spezifikation), S1 aus der Streuung bei repeat, S2 aus resolution, dazu die Beiträge U3 bis U10, U = k · √(U1² + S1² + S2² + U3² + … + U10²), mindestens die CMC aus den Qualitätsvorgaben. k ist das k der Gruppe, sonst ab Werk aus den effektiven Freiheitsgraden (GUM Anhang G, etwa 95 %; ohne repeat 2), oder fest 2 als Laboreinstellung. Welches Normal U1 liefert, sagt die Rolle des Punkts: die Referenz (ref device dmm, auch von Hand oder per Kamera), sonst die Quelle (source cal), nie uut; ohne Rolle das eine Normal der Kalibrierung, das den Punkt abdeckt (Beispiele 1, 2, 3, 5, 6). Deckt kein Normal den Punkt, bleibt U leer, die Methode heißt keine, der Punkt nennt den Grund, und die Abschlussprüfung hält die Freigabe an, solange er ein Urteil hat. Einzelheiten: Ergebnisse, Messunsicherheit nach GUM.

Die Beiträge U3 bis U10 haben je eine Herkunft, die der Schein nennt:

1. Spezifikation eines Normals: Zeilen der Art „Beitrag“ in der Spezifikation des Normals hinter U1, etwa die Linearität eines Referenzthermometers. Liefert ein anderes Normal den Bezug als die Quelle (ein Bad stellt die Temperatur, ein Referenzthermometer misst sie), kommen auch die Beitragszeilen der Quelle hinzu: Homogenität und Stabilität gehören in die Spezifikation des Bades, nicht in den Plan.
2. Plan: contrib nennt Beiträge des Verfahrens selbst, etwa Adapter, Leitungen oder die Wärmeableitung bei der vorgeschriebenen Eintauchtiefe (Beispiele 1 und 6).
3. Umkehrspanne: ist ein Paar aus direction up und direction down erfasst, geht der Betrag der Differenz h in beide Partner ein, als volle Breite einer Rechteckverteilung (u = h / (2 · √3), wie DKD-R 6-1).
4. Unsicherheitsmodell des Labors: Beiträge, die an der Umgebung hängen und in keinem Plan stehen sollen (Thermospannungen, Temperatureinfluss, Ankopplung), stehen unter Administration › Stammdaten & Struktur › Unsicherheitsmodelle, für das ganze Labor oder einen Prüflingstyp. Ein Modell kann auch einen ausgewiesenen Ersatz für das Normal tragen, wenn keine Spezifikation den Punkt deckt (Unsicherheitsmodelle).

Mehr als acht Beiträge je Punkt teilen sich U10, dort steht die Wurzel ihrer Quadratsumme; jeder bleibt einzeln im Budget.

Akkreditierungsumfang

Ob ein Messpunkt im Akkreditierungsumfang liegt, leitet calServer beim Erfassen aus der Anlage in den Qualitätsvorgaben ab. Der Plan muss dazu nichts sagen (Akkreditierungsumfang). Er kann Punkte nur herausnehmen, mit accred no:

calscript 0
plan "Multimeter mit Klimaschrank"

group "Gleichspannung"
  result numeric
  unit V
  tol 0.1%
  measure 1 10 100 "{value} V"
  measure 1000 "1000 V"
    accred no            # Aufbau für 1000 V nicht akkreditiert

group "Klimaschrank"
  accred no              # alle Messpunkte dieser Gruppe
  result numeric
  unit °C
  tol 0.5
  measure 23 "23 °C"

• Vor dem ersten Schritt nimmt accred no alle Messpunkte des Plans heraus, etwa für eine Werkskalibrierung.
• An einer Gruppe gilt es für ihre Messpunkte, auch in ihren Untergruppen, an measure für den einen.
• In einem Baustein vor dem ersten Schritt nimmt es die Messpunkte des Bausteins heraus, wo immer er eingesetzt wird.
• Der Schein kennzeichnet diese Punkte mit „*“, gleich was die Anlage sagt. Eine Wahl von Hand an der Kalibrierung gewinnt trotzdem.

accred yes gibt es nicht. Ob ein Punkt im Umfang liegt, sagt die Anlage; ein Plan, der das behauptete, müsste bei jeder neuen Urkunde nachgezogen werden. Geschrieben wird accred no, ohne =, wie jede Eigenschaft. accred = no, accred=no und noaccred lehnt der Compiler ab und nennt die richtige Schreibweise; dasselbe gilt für ein = hinter jeder anderen Eigenschaft. An confirm, rate, message, comment und ask ist accred ein Fehler, denn eine Bestätigung hat keinen Messpunkt.

Am Messplatz messen

read device uut sagt, dass der Messplatz den Wert abliest, statt dass ihn jemand eintippt. uut und cal sind Rollen, keine Geräte: welches Multimeter oder welcher Kalibrator mit welcher Adresse dahintersteht, entscheidet der Lauf. uut ist das Gerät des Messplatzes, dessen Inventareintrag kalibriert wird; jede andere Rolle ist das Gerät mit dem Inventareintrag des Normals, das der Vorlauf dieser Rolle zugeordnet hat. Ein Gerät am Messplatz (Administration, Messplätze, Geräte) trägt darum keine Rolle, nur Adresse, Treiberprofil und Inventareintrag: derselbe Kalibrator ist heute cal und morgen uut. So läuft derselbe freigegebene Plan auf jedem Platz, an dem die Geräte stehen. „Am Messplatz ausführen“ zeigt vor dem Start, welches Gerät welche Rolle spielt; eine Rolle ohne Gerät (kein Inventareintrag, nicht am Platz, im Vorlauf nicht zugeordnet) bleibt mit Grund offen, und ihre Punkte misst der Runner nicht. Hintergrund: ADR 2026-10-31 Geräte ohne Rolle.

group "Gleichspannung"
  result numeric
  read device uut
  source cal
  function "VOLT:DC"
  settle 2
  measure 1 10 100 "{value} V"
  measure 0 "Nullpunkt" read manual

An der Gruppe gilt die Bindung für alle Punkte darunter; ein Punkt mit eigener read device-Zeile ersetzt sie ganz, read manual hebt sie für diesen Punkt auf. Der Schritt-Editor zeigt die Ablesequelle an, bearbeitet wird sie im Skript. Ein Plan mit Gerätebindung wird als Dokumentversion 6 exportiert. Hintergrund: ADR 2026-10-29 Gerätebindung.

Welcher Gerätetyp hinter einer Rolle vorgesehen ist, sagt eine Kopfzeile:

plan "Fluke 87V"
standard cal "Fluke 5522A"

Der Typ steht beim Namen, wie er unter Gerätetypen heißt, damit der Plan auch auf einer anderen Installation passt. Daraus rechnet der Editor TAR und einen geschätzten TUR (siehe Prüfpläne); die Prüfung selbst rechnet mit dem Normal, das der Vorlauf der Rolle zuordnet. Ein Plan ohne standard läuft genauso, nur ohne diese Vorschau.

Wenn der Messplatz auf dich wartet

Läuft der Plan aus calServer („Am Messplatz ausführen“), sitzt am Runner niemand, der eine Meldung wegklickt. Der Runner hält deshalb (ab Version 0.14.0):

• an einer Meldung, wenn danach ein Gerätepunkt kommt, etwa „Messleitungen an den Stromeingang stecken“ vor der ersten Strommessung;
• an einer Bestätigung (confirm) oder Frage (ask), wenn danach noch ein Gerätepunkt kommt;
• an einem Kamerapunkt mit Quelle am Messplatz (read camera mit source cal, ab Version 0.18.0), nachdem er den Sollwert gestellt hat, bis die Kamera den Punkt übernommen hat;
• an einem Handpunkt mit Quelle am Messplatz (read manual mit source cal, ab Version 0.19.0), nachdem er den Sollwert gestellt hat, bis der Prüfer den Wert in calServer eingetragen hat.

Vor jedem Halt an Meldung, Bestätigung oder Frage schaltet der Runner seine Quellen auf Standby (ab Version 0.18.0): wer umsteckt oder den Drehschalter dreht, hat keinen Sollwert mehr an den Buchsen. Der nächste Gerätepunkt schaltet den Ausgang wieder ein. Am Kamerapunkt bleibt der Ausgang an, dort soll die Kamera ja den gestellten Wert sehen.

Die Prüflauf-Seite zeigt oben „Messplatz … wartet auf dich“ mit dem Text des Schritts. Nach einer Meldung tust du, was dort steht, und drückst Weiter; der Runner misst dann den nächsten Punkt. Eine Bestätigung oder Frage beantwortest du wie gewohnt in der Liste, der Runner sieht die Antwort und macht von selbst weiter; bei einer Frage richtet er sich nach dem Zweig, den deine Antwort wählt. „Weiter“ geht dort auch ohne Antwort weiter. Den Knopf siehst du mit dem Recht, Messplätze zu bedienen (workstation_run). „Lauf anhalten“ in Administration, Messplätze beendet den Lauf auch während eines Halts.

Treiberprofile

Wie ein Gerätemodell angesprochen wird, steht in einem Treiberprofil, nicht im Plan und nicht im Runner. Gepflegt werden die Profile unter Administration, Treiberprofile, auf Wunsch am Gerätetyp. Die Bindung am Messplatz nennt dann nur Profil und Anschluss ("cal": { "profile": "fluke-5522a", "resource": "GPIB0::4::INSTR" }).

• Ein Profil nennt die Fähigkeiten des Geräts je Funktion (gibt Werte, misst, oder beides), die Kennung, die das Gerät auf *IDN? meldet, und die Befehle je Funktion (VDC, VAC, ADC, AAC, OHM, OHM4, CAP, FREQ, TEMP). Eine SCPI-Schreibweise im Plan wie function "VOLT:DC" landet auf derselben Funktion. Ob ein Gerät Normal oder Prüfling ist, sagt das Profil nicht: das entscheiden die Rollen des Plans je Lauf. Derselbe Kalibrator ist heute cal und wird morgen mit demselben Profil selbst kalibriert; ein kombiniertes Gerät wie der Fluke 5320A gibt in einem Schritt und misst im nächsten.
• Jedes Profil trägt eine Revision. Sie steht zusammen mit Kennung, Treiber, Phase, Funktion, Sollwert, den letzten Befehlen, der Antwort und der Fehlerschlange des Geräts in jeder Fehlermeldung des Runners. So lässt sich ein Fehler dem Profilstand zuordnen, der ihn erzeugt hat, und das Profil gezielt bessern. Wer ein Profil ändert, zählt die Revision hoch.
• Kennt das Profil eine Funktion nicht, oder verlangt der Plan von einer Rolle etwas, das ihr Gerät nicht kann (geben mit einem Multimeter), sendet der Runner nichts, und der Punkt scheitert vor dem ersten Befehl mit einer Meldung. Meldet sich am Anschluss ein anderes Modell, öffnet er das Gerät nicht.
• Gekoppelte Messplätze holen die aktiven Profile vor jedem Lauf. Ohne Verbindung gilt der letzte Stand. Ein Profil, das ein Labor am Messplatz selbst ablegt, geht vor, danach kommen die Profile aus calServer, dann die mitgelieferten.
• Mitgeliefert sind Profile für Fluke 5500A/5502A/5520A/5522A (geben), Fluke 5320A (gibt und misst), Fluke 287/289 (messen, Handmultimeter über IR-Adapter), Keysight 34401A/34461A/34465A/34470A, Keithley DMM6500, Fluke 8846A und ein allgemeines SCPI-Multimeter. Vor dem ersten Lauf am echten Gerät prüfen.
• Gerätefamilien ohne SCPI spricht der Runner über einen Befehlsdialekt an, den das Profil nennt ("driver": "fluke.55xx" für die Fluke 5500A/5502A/5520A/5522A). Der Dialekt kennt Identifikation und Reset, die Ausgabe für DC/AC-Spannung, DC/AC-Strom, Widerstand (2- und 4-Draht), Kapazität und Frequenz, Betrieb/Standby mit Nachweis, die Fehlerschlange, die Abfrage des Ausgangs und eine Sicherheitsabschaltung (Standby, notfalls Reset) am Ende jedes Laufs und bei jedem Abbruch. Das Profil trägt die Grenzen des Modells (options.max_voltage_v, options.max_current_a); darüber wird nichts gesendet.
• SCPI-Präzisionsmultimeter (6½ bis 8½ Stellen) misst der Runner über den Dialekt scpi.dmm im festen Bereich: zuerst der Bereich des Schritts (range), sonst der kleinste Bereich des Profils, der den Sollwert aufnimmt, sonst Autorange, wenn das Profil es erlaubt. Dazu feste Integrationszeit (NPLC) und Autozero aus dem Profil, Fehlerschlange vor und nach jeder Ablesung, ein Überlauf ist ein Fehler des Punkts. Die Befehlsworte je Funktion (configure, configure_auto, measure) und die Bereichsliste stehen im Profil; so unterscheiden sich Keysight und Keithley nur in den Daten. Referenzmultimeter ohne SCPI (3458A, 8508A) brauchen einen eigenen Dialekt und sind noch offen.
• Den Fluke 5320A spricht der Dialekt fluke.5320a an: Widerstand (2- und 4-Draht, nieder- und hochohmig) und mit Option VLC Spannung geben, mit dem eingebauten Multimeter Spannung und Strom messen; Fehlerschlange nach jedem Befehlsblock, Ausgang bei jedem Fehler aus. Die Handmultimeter Fluke 287/289 spricht fluke.28x über den IR-Adapter an. Funktion und Bereich stehen dort am Drehschalter: der Runner misst, was anliegt, und meldet einen Fehler, wenn die Einheit nicht zur Funktion des Schritts passt; ein Überlauf oder ein offenes Thermoelement ist ein Fehler, kein Messwert.
• Wechselgrößen brauchen eine Frequenz: der Modifier des Punkts (measure 10 "10 V" @ 50 Hz, auch als Gruppenvorgabe) geht vor; ohne ihn gilt die Angabe hinter der Funktion (function "VAC 1 kHz") oder die Bindung (frequency_hz). Ohne jede Frequenz scheitert der Punkt mit einer Meldung; geraten wird nicht.
• calserver-runner probe --bindings … spricht die Geräte der Bindung an, ohne zu messen: Kennung, Fehlerschlange, Ausgang, Betriebszustand. Für die Abnahme eines Messplatzes.

Rechte: die der Messplätze (workstation_view, workstation_edit, workstation_delete). Hintergrund: ADR 2026-10-29 Treiberprofile.

Treiberprofil anlegen

Unter Administration, Treiberprofile stehen unter den eigenen Profilen die Standardprofile: die Profile, die jeder calServer Runner mitbringt, mit Fähigkeiten, Dialekt und Funktionen. Sie gelten am Messplatz auch ohne Eintrag in calServer. Übernehmen legt eine Kopie unter derselben Kennung in calServer an; die gepflegte Fassung ersetzt dann an jedem Messplatz die mitgelieferte. Ein übernommenes Standardprofil zeigt „In calServer gepflegt“ und öffnet beim Klick die eigene Fassung.

Neues Treiberprofil fragt zuerst den Gerätetyp. Hersteller und Modell kommen aus dem Gerätetyp, die Kennung entsteht daraus (Fluke, 5522A → fluke-5522a) und wird nur angezeigt. Als Ausgangspunkt wählt calServer das passende Standardprofil:

• dasselbe Modell (Fluke 5522A → fluke-5522a): das Profil mit seiner Kennung, gespeichert ersetzt es am Messplatz das mitgelieferte;
• ein verwandtes Modell desselben Herstellers (Fluke 5522A/6 → fluke-5522a, Agilent 34410A → keysight-34401a): Befehle und Grenzen des verwandten Profils, Kennung und *IDN?-Erwartung auf das eigene Modell umgeschrieben, mit einer Notiz, was vor dem ersten Lauf zu prüfen ist;
• sonst die leere Vorlage (gibt und misst VDC).

Den Ausgangspunkt kannst du im Dialog wechseln. Passt keins, führt Aus Handbuch mit KI direkt in den KI-Entwurf; Gerätetyp, Hersteller, Modell und das gewählte Standardprofil nimmt er mit.

Treiberprofil aus dem Handbuch mit KI

Für ein Gerät ohne Profil gibt es unter Administration, Treiberprofile den Knopf Aus Handbuch mit KI. Du lädst das Programmier- oder Steuerungshandbuch hoch (bis zu vier PDF, auf Wunsch mit Seitenangabe je Datei wie 120-260), nennst Hersteller, Modell, Schnittstelle und Gerätetyp, wenn bekannt, und optional ein bestehendes Profil als Basis.

• calServer liest den Text des Handbuchs, wählt bei großen Handbüchern die Seiten mit Befehlen, Bereichen und Grenzen aus, sammelt daraus Fakten und verfasst das Profil. Der Lauf dauert einige Minuten und läuft im Hintergrund; du kannst ihn abbrechen. Die PDF-Dateien werden danach gelöscht.
• Der Entwurf wird gegen den Standard geprüft, also gegen das, was jedes mitgelieferte Profil hat: Kennung, Abschlusszeichen und Timeout, Fähigkeiten je Funktion, Befehle je Funktion, Grenzen für alles, was das Gerät gibt, Standby, Frequenz bei Wechselgrößen, Bereiche, eine Notiz mit Quelle. Fehlt etwas, bessert die KI bis zu zweimal nach. Was im Handbuch nicht steht, wird nicht erfunden, sondern als offener Punkt genannt.
• Du siehst die Prüfliste, offene Punkte, die Seiten je Thema und das JSON. Ändern kannst du direkt im JSON (Erneut prüfen) oder mit einer Anweisung an die KI (Mit KI überarbeiten, ohne erneuten Upload).
• Gespeichert wird inaktiv. Ein Messplatz holt das Profil erst, wenn du es nach der Abnahme am Gerät (calserver-runner probe) aktiv setzt.
• Allgemeine SCPI-Quellen bekommen Grenzen je Funktion ("options": {"limits": {"VDC": {"min": -100, "max": 100}}}); der Runner sendet ab 0.11.0 nichts außerhalb dieser Grenzen.

Die Routine heißt Treiberprofil-Entwurf und ist ausgeschaltet, bis sie unter Administration, KI eingeschaltet wird. Es geht nur der Text des Handbuchs an das Modell, keine Geräte- oder Kundendaten. Gescannte Handbücher ohne Textebene vorher durch eine Texterkennung schicken. Hintergrund: ADR 2026-10-31 Treiberprofile per KI.

Fehlerprotokolle und KI-Analyse

Ein Treiberprofil ist erst am Gerät bewiesen. Scheitert am Messplatz das Öffnen eines Geräts, die Zuordnung oder ein Messschritt, schickt der Runner ein Fehlerprotokoll nach calServer: welche Befehle hinausgingen, was das Gerät antwortete, wie lange es dauerte, was in seiner Fehlerschlange stand, welche Profilfassung am Platz galt, dazu eine Einordnung in Worten (falsches Gerät an der Adresse, Funktion dem Profil unbekannt, Befehl fehlt, Frequenz fehlt, Gerät meldet Fehler, keine Antwort, …) mit dem Hinweis, wo im Profil zu suchen ist.

• Administration, Messplätze zeigt je Platz die Zahl der ungesichteten Protokolle; der Dialog dahinter listet sie mit Zeile, Funktion, Gerät und Einordnung und zeigt zu jedem die Hinweise, die Geräte mit erwarteter und gemeldeter Kennung, die Mitschrift (Einträge des gescheiterten Schritts hervorgehoben) und den Traceback.
• Ein Protokoll lässt sich sichten oder erledigen und mit einer Notiz versehen; dieselbe Kennung ersetzt beim Nachsenden den alten Stand. calServer behält die jüngsten 500 je Messplatz.
• Für KI-Analyse herunterladen gibt eine Datei calserver.error-analysis: das Protokoll, die betroffenen Treiberprofile wie sie jetzt in calServer stehen, der Messplatz und die Aufgabe an den Auswerter (Ursache, betroffenes Profil und Feld, Vorschlag als JSON, Restrisiko). Die Datei gibst du einem Sprachmodell; den Vorschlag übernimmst du im Editor der Treiberprofile, nach eigener Prüfung. Ein falscher Befehlssatz an einem Kalibrator ist ein Sicherheitsrisiko, deshalb ändert niemand ein Profil automatisch.
• Ohne Verbindung bleibt das Protokoll am Messplatz (calserver-runner errors), die Lauf-Ansicht nennt seine Kennung.

Rechte: die der Messplätze. Hintergrund: ADR 2026-10-30 Fehlerprotokoll.

Toleranz

Terme werden addiert und mit + getrennt. Die Einheit hinter der Zahl sagt, worauf sich der Term bezieht:

Schreibweise	Bezug	im Plan
0.3%	Prozent vom Messwert	0.3%
0.5 %r	Prozent vom Bereich (range)	0.5/
1 D	Vielfaches der Auflösung (resolution)	1D
0.02	Absolutwert in der Einheit des Schritts	0.02U
3 mV	Absolutwert mit Einheit, umgerechnet auf den Vorsatz des Schritts	0.003U an einem Schritt in V
50 ppm	Millionstel vom Messwert	0.005%
10 ppm r	Millionstel vom Bereich	0.001/
3 dgt	wie 3 D	3D

Die MET/CAL-Formen 0.003U, 0.5/, 50P% und 50P/ werden ebenso gelesen, damit eine Zeile aus einer Prozedur oder einem Datenblatt ohne Umrechnen hineinpasst. Zurückgeschrieben wird die kurze Form.

Ein Vorzeichen macht den Term einseitig: +0.3% nur obere, -0.3% nur untere Grenze. Dezimaltrenner ist der Punkt. Die gewohnte calServer-Schreibweise (0.3% 1D) wird ebenfalls gelesen. Was keine Termliste ist, steht in Anführungszeichen und wird unverändert übernommen: tol "…".

Der Zahlteil eines Terms ist eine Dezimalzahl mit Punkt: keine E-Notation (1e-3U), kein Punkt ohne Nachkommastelle (1.U), kein Komma. Der Editor liest dieselbe Grammatik; ein Komma schreibt er beim Eintippen zum Punkt um, alles andere bleibt sichtbarer Rohtext, statt im Skript zu scheitern.

Fehlt der Bezug eines Terms (%r ohne range, D ohne resolution), rechnet der Plan dort mit 0; calScript meldet das als Hinweis, bricht aber nicht ab.

Woher der Bezug kommt: ref

read liest immer den Prüfling. ref sagt nur, woher der Wert kommt, gegen den er bewertet wird:

Schreibweise	Bezug	Grenzen liegen um
ohne ref	UUT INDICATED	den Sollwert der Quelle; der Normalfall: ein Normal gibt aus, der Prüfling wird abgelesen
ref device thermo	REFERENCE	die Ablesung des Normals der Rolle thermo, das am Messplatz mitmisst
ref manual thermo, ref camera thermo	REFERENCE	dieselbe Ablesung, von Hand eingetippt oder per Kamera gelesen
source uut mit ref device dmm (oder manual, camera)	NOMINAL	den Sollwert, den der Prüfling ausgibt; abgelesen wird das Normal (Kalibrator als Prüfling, Beispiel 5)
ref none	ohne	nichts: der Wert wird erfasst, aber nicht bewertet

result numeric ohne ref übernimmt den Bezug der Gruppe, sonst den Sollwert der Quelle. Der Prozentanteil einer Toleranz bezieht sich immer auf den Wert des Prüflings. Die früheren Wörter ref nominal und ref uut lehnt der Parser mit einem Hinweis ab, was an ihre Stelle tritt.

Referenz, Stabilität, Umkehrspanne und Sammellauf

Ein Kalibrierbad gibt die Temperatur nur ungefähr vor; der Bezug ist die Ablesung eines Referenzthermometers, gemessen wird erst, wenn die Temperatur steht, und oft stecken mehrere Prüflinge zugleich im Bad. Beispiel 6 zeigt das als Plan:

group "Messreihe aufwärts"
  result numeric
  unit °C
  resolution 0.001
  contrib "Wärmeableitung bei 15 cm Eintauchtiefe" 0.005 °C
  repeat 3
  direction up
  read device uut
  source bath
  ref device thermo
  function "TEMP"
  stable 0.01 °C 2 min max 30 min
  measure 0 50 100 "{value} °C"
  measure 150 "150 °C (erweiterter Bereich)"
    optional
end

• Referenz: ref device thermo liest das Normal der Rolle thermo am Messplatz mit. Bei ref manual und ref camera fragen Messwerterfassung und Assistent seinen Wert neben dem des Prüflings ab; in der Tabelle liest die Kamera ihn, wenn der Cursor im Referenzfeld steht (ein Beweisbild hält sie nur für den Prüfling fest, für die Referenz die Herkunft). calServer legt die Grenzen um den Mittelwert der Referenz; ohne Referenz gibt es kein Urteil.
• Stabilität: stable 0.01 °C 2 min max 30 min lässt den Runner nach Stellen und Einschwingen lesen, bis die Spanne der Werte zwei Minuten lang innerhalb von 0,01 °C bleibt, höchstens 30 Minuten. Das Band ist absolut; ein Anteil der Toleranz würde die Bewertung in den Runner holen und ist deshalb ein Fehler. Den Verlauf speichert calServer je Punkt als Nachweis. Wird es nicht stabil, gibt es keinen Messwert: der Punkt bleibt offen, und du entscheidest über Wiederholung oder Abbruch.
• Umkehrspanne: direction up und direction down am selben Sollwert bilden ein Paar. Beim Laden entsteht je vollständigem Paar ein Schritt „Umkehrspanne“ am Ende des Plans; seine Grenze kommt aus einer Zeile der gewählten Option mit der abgeleiteten Größe Umkehrspanne. Ohne solche Zeile bleibt sie ohne Urteil, geht aber ins Budget beider Partner ein.
• Optionale Punkte: optional lädt den Punkt nur, wenn die gewählte Option ihn als Punktzeile verlangt (hier 150 °C nur mit erweitertem Bereich). Siehe Spezifikationen.
• Sammellauf: Alle Kalibrierungen mit derselben Planversion lassen sich im Prüfablauf über Sammellauf zusammen an einem Messplatz starten. Der Vorlauf (Umgebung, Normale, Rollen) gilt für alle, der Eingangsentscheid bleibt je Prüfling; jeder Prüfling bekommt einen Kanal am Lesegerät oder wird an seinem eigenen Gerät abgelesen (Kanal leer lassen: calServer nimmt das Gerät am Messplatz, dessen Inventar der Prüfling ist). Hängt kein Prüfling an einem Kanal, braucht es kein Lesegerät; gemischt geht auch. Stellen, Einschwingen, Warten auf Stabilität und die Referenz geschehen einmal, abgelesen wird je Prüfling. Zugelassen ist ein Plan, wenn jeder Messpunkt dem Messplatz etwas zu tun gibt (ein Gerät liest den Prüfling, oder er stellt die Quelle bzw. liest die Referenz), der Prüfling nie die Quelle ist und keine Bedingung einen gemeinsamen Schritt überspringt; der Dialog nennt sonst den Grund.
• Handablesung und Kamera im Sammellauf: Fühler ohne Schnittstelle liest der Prüfer ab. Dafür steht am Punkt read manual (oder read camera) zusammen mit ref device thermo: Der Runner stellt das Bad, wartet auf Stabilität, liest das Referenzthermometer und legt die Referenz in calServer ab, bevor er hält. Im Prüfablauf erscheint dann einmal für alle Prüflinge Ablesetabelle öffnen: je Prüfling eine Zeile mit der abgelegten Referenz und einem Feld für die Ablesung, bei repeat N N Felder. Mit der Kamera springt der Cursor nach jeder Lesung zum nächsten offenen Prüfling. Sind alle Zeilen erfasst, stellt der Runner den nächsten Punkt; mit Referenz klammern liest er die Referenz danach noch einmal, und calServer rechnet die Punkte neu. Ohne abgelegte Referenz nimmt calServer keine Ablesung an, statt gegen den Sollwert zu rechnen. Im Einzellauf gilt dasselbe: die Referenz kommt vom Messplatz, die Ablesung aus dem Browser.
• Referenz klammern: Bei vielen Prüflingen dauert das Ablesen; driftet das Bad in dieser Zeit, stimmt die eine Referenzablesung vom Anfang nicht mehr für den letzten Prüfling. Mit Referenz klammern im Sammellauf-Dialog liest der Runner die Referenz in jedem Durchgang vor und nach den Prüflingen; calServer mittelt alle Referenzablesungen des Punktes.

Hintergrund: ADR 2026-11-02 Sammellauf, Stabilität und Referenzablesung, ADR 2026-11-07 Sammellauf mit eigenem Gerät je Prüfling, Referenz klammern, ADR 2026-11-07 Sammellauf mit Handablesung.

Toleranzen aus der Spezifikation

Ein Plan beschreibt, wie gemessen wird; was verlangt ist, steht in der Spezifikation des Geräts oder seines Typs. Ein Messpunkt ohne tol bekommt seine Toleranz beim Laden aus der Option, die die Kalibrierung gewählt hat (Hersteller, Norm, Kunde oder Verwendung), mit Bereich und Auflösung derselben Zeile. Ein tol im Plan (am Punkt oder an der Gruppe) gewinnt; es ist dann ein anderer Maßstab und steht auf dem Schein mit der Herkunft „Plan“. Findet sich keine Zeile oder mehrere, bleibt der Punkt ohne Toleranz und damit ohne Urteil, mit Grund, statt mit einer geratenen Zeile.

Die Herkunft je Punkt („Spezifikation · Option“, „Plan“, „Plan (Gruppe)“, „Keine Toleranz“) zeigt die Messwerterfassung, die Abschlussprüfung prüft sie, der Schein nennt sie. Vorschau, Probelauf und Testfälle im Editor kennen keine Kalibrierung und rechnen deshalb nur mit Toleranzen aus dem Plan. Siehe Spezifikationen und ADR 2026-11-02 Eine Spezifikation mit Optionen.

Zeichenketten

In doppelten Anführungszeichen, mit \", \\, \n, \t. Längere Texte, etwa HTML-Anleitungen, als Block:

  info """
  <p>Prüfling auf V DC, Bereich 320 mV.</p>
  <p>Normal im Modus <b>NORMAL</b>.</p>
  """

Die gemeinsame Einrückung der Blockzeilen wird entfernt. Hinter dem schließenden """ darf auf derselben Zeile nur ein Kommentar stehen. Zeilenumbrüche in Texten speichert das Skript als LF; Windows-Umbrüche (CRLF) werden beim Schreiben umgesetzt.

Eine Prüfanweisung mit HTML (<p>, <b>, <br>, Listen, Links) zeigen Editor-Vorschau, Ablauf, Probelauf, Erfassung und Assistent formatiert an; Skripte, Ereignis-Attribute und javascript:-Links werden dabei entfernt. Reiner Text, etwa aus dem MET/CAL-Import, behält seine Zeilenumbrüche. Ein < als Vergleich („Anzeige < 5 V“) bleibt Text. In Tabellenzeilen, Banner und der Konsole des Runners erscheint die Anweisung ohne Auszeichnung, Absätze werden dort zu Zeilen.

Änderungen vor dem Genehmigen

Wer im Vorlagen-Tab der Prozedur Genehmigen wählt, sieht vor der Bestätigung, was sich am Skript seit der letzten genehmigten Version geändert hat: Zeilenvergleich mit drei Zeilen Umfeld, hinzugefügte Zeilen grün und mit +, entfernte rot und mit -, Zeilennummern beider Fassungen. Eine geänderte Toleranz ist dort genau eine Zeile, statt dass der ganze Plan neu gelesen werden muss.

Verglichen wird immer die jüngste Version, denn die trifft die Genehmigung. Wurde der Plan noch nie genehmigt, zeigt der Dialog das ganze Skript als neu. Eine hochgeladene Datei ohne Schritte (z. B. ein PDF) hat kein Skript, dann bleibt es bei der Rückfrage. Lässt sich der Vergleich nicht laden, ist Genehmigen trotzdem möglich: der Vergleich hilft, er ist keine Bedingung.

Mit der Kamera ablesen

read camera macht die Webcam zur Ablesequelle: der Prüfer hält den Prüfling vor die Kamera, zieht im Panel der Erfassungstabelle einmal einen Rahmen um die Anzeige, und ein Vision-Modell liest den Wert in diesem Ausschnitt. Das Modell kennt Einheit und Auflösung des Punkts, nie den Sollwert; der Server rechnet danach eine Ampel:

Ampel	Bedeutung	Was passiert
rot	kein Wert, Überlauf, mehrere Werte im Rahmen, andere Größe als der Schritt, Modell unsicher	wird nicht übernommen; von Hand ablesen
gelb	Modell nicht ganz sicher, Blendung, Vorzeichen unsicher, andere Nachkommastellen, zweite Lesung weicht ab, mehr als zehnfache Toleranz	steht als Vorschlag im Feld, der Prüfer übernimmt mit Klick oder tippt um
grün	sauber gelesen	capture confirm: Klick des Prüfers; capture auto: Übernahme ohne Klick

group "Anzeige des Prüflings"
  result numeric
  unit V
  tol 0.5%
  read camera
  capture auto
  repeat 3
  measure 1 10 100 "{value} V"
  measure 0 "Nullpunkt" read manual

So startet die Ablesung: In der Erfassungstabelle (Lauf einer Kalibrierung oder Probelauf im Prüfplaneditor) steht über der Tabelle rechts die Taste „Kamera-Ablesung“. Sie öffnet das Kamera-Panel neben der Tabelle; dort die Kamera wählen, den Browser die Kamera freigeben lassen, einmal mit der Maus (oder über „Rahmen per Tastatur“) einen Rahmen um die Anzeige ziehen und „Anzeige lesen“ drücken. Der Wert landet im Feld, in dem der Cursor steht. Ist die Taste ausgegraut, steht der Grund daneben, meist ist die KI-Routine aus. Fehlt sie ganz, fehlt dem Benutzer das Recht ai_assistant_edit oder calibration_edit.

Bildlage: Zeigt die Kamera das Gerät gespiegelt oder quer, dreht „Drehen“ das Bild in 90°-Schritten im Uhrzeigersinn, „Spiegeln“ tauscht links und rechts. Die Lage gilt je Kamera und bleibt im Browser gespeichert; der Rahmen bleibt dabei auf derselben Stelle des Geräts. An die KI und ins Beweisbild geht der Ausschnitt in der eingestellten Lage, also mit aufrechten Ziffern.

capture auto wartet, bis das Bild im Rahmen ruhig steht, liest zweimal und übernimmt nur, wenn beide Lesungen übereinstimmen und grün sind; Gelb bleibt ein Vorschlag, den der Prüfer anklickt. Der Server prüft das nach: eine automatisch übernommene Ablesung ohne grünes Beweisbild weist er ab, der Prüfer liest neu oder übernimmt von Hand. Ohne capture auto gibt es dafür zwei Schalter im Panel: „Automatisch lesen“ liest, sobald die Anzeige am Punkt ruhig steht (nur mit Rahmen), „Automatisch übernehmen“ übernimmt eine passende Lesung ohne Klick, auch nach „Anzeige lesen“. Nur „Automatisch lesen“ heißt: lesen, Vorschlag zeigen, nach dem Klick auf „Übernehmen“ die nächste Position lesen. „Übernehmen bei“ legt fest, ob nur Grün oder auch Gelb ohne Klick übernommen wird; Rot nie, und zwei widersprüchliche Lesungen auch nicht. Der Schalter gilt nur für diese selbst eingeschaltete Automatik; verlangt der Plan capture auto, zählt allein Grün, und das Panel zeigt das an. Die Felder zeigen alle Stellen der Anzeige (2,5000, nicht 2,5). Zeigt der neue Punkt genau den Wert des vorigen, bleibt die Lesung ein Vorschlag (die Anzeige steht vermutlich noch auf dem alten Punkt). Was nicht übernommen wird, steht als Vorschlag im Panel; gelesen wird erst wieder, wenn sich die Anzeige ändert. Bei repeat füllt die Kamera die nächste freie Position und liest weiter, bis alle Positionen voll sind; dann geht es zum nächsten Punkt. Unabhängig vom Plan steht das Panel an jedem Messpunkt als Eingabehilfe bereit, sobald die KI-Routine „Kamera-Ablesung“ in den KI-Einstellungen eingeschaltet ist und ein Vision-Modell eingetragen ist; die Hand bleibt immer möglich.

Kalibrator vom Messplatz, Ablesung per Kamera: Hat der Prüfling keine Schnittstelle, das Normal aber schon, stellt der calServer Runner das Normal und die Kamera liest den Prüfling. Dafür stehen source, function und settle neben read camera:

group "Gleichspannung 5 V"
  result numeric
  unit V
  tol 0.025% + 2 D
  repeat 3
  read camera
  capture auto
  source cal
  function "VDC"
  settle 2
  message "Drehschalter auf V⎓, Bereich 5 V"
  measure 0.5 2.5 4.5 "{value} V"

Je Punkt stellt der Runner cal auf den Sollwert, schaltet den Ausgang ein und wartet die Einschwingzeit ab. Dann meldet er den Punkt bereit: auf der Laufseite steht „Messplatz wartet auf dich“, der Cursor springt auf den Punkt, und erst jetzt liest die Automatik des Kamera-Panels (vorher steht dort „Der Messplatz stellt cal auf den Sollwert“, damit die Kamera nicht den alten Wert liest). Sobald der Punkt übernommen ist, stellt der Runner den nächsten. „Weiter“ auf der Laufseite geht ohne Ablesung zum nächsten Punkt. Ohne laufenden Messplatz stellt der Prüfer das Normal wie bisher selbst. function oder settle ohne source neben read camera lehnt der Compiler ab; sie gehören zur Quelle. Den Runner braucht das ab Version 0.18.0.

Zu jedem übernommenen Kamerawert speichert calServer Herkunft (camera, camera_auto) und ein kleines Beweisbild: genau den Ausschnitt, den das Modell gesehen hat, mit Ampel und Konfidenz. Es steht in der Erfassungstabelle neben dem Wert; ein neuer Wert ersetzt es. Nur der Rahmen verlässt den Browser (höchstens 640 px lange Kante), bei einem externen Anbieter verlässt er auch das Haus, das sagt das Panel. Ein Plan mit Kamera-Bindung wird als Dokumentversion 8 exportiert. Hintergrund: ADR 2026-10-31 Kamera-Ablesung; Eignung eines Modells misst tools/display-reading-eval/.

Ablesung im Lauf wählen

Wer abliest, entscheidet oft erst der Messplatz am Tag der Messung: steckt der IR-Adapter, liest der Runner; ist die Kamera eingerichtet, liest die Kamera; sonst liest der Prüfer. Toleranzen, Punkte und Unsicherheit bleiben dabei gleich. Statt jede Gruppe dreimal zu schreiben, stellt read mehrere Ablesequellen zur Wahl, getrennt durch |; die erste ist die Vorgabe:

group "Gleichspannung 5 V"
  result numeric
  unit V
  tol 0.025% + 2 D
  repeat 3
  read device uut | camera | manual
  capture auto
  source cal
  function "VDC"
  settle 2
  measure 0.5 2.5 4.5 "{value} V"
end

Jede Wahl liest den Prüfling (device uut, camera oder camera uut, manual), jede Art höchstens einmal; Leerzeichen um | sind egal. Was neben der Auswahl steht, gilt so:

Angabe	Gilt
source, function, settle	in jeder Wahl: der Runner stellt das Normal, ob Gerät, Kamera oder Prüfer abliest
capture auto/confirm	nur, wenn die Kamera liest; muss camera unter den Wahlen haben
stable	nur mit device uut an erster Stelle; Kamera und Hand lassen es fallen
ref …, source uut	nicht mit einer Auswahl: die Referenz holt der Runner nur zusammen mit einer Geräteablesung

Im Vorlauf steht dann die Zeile „Ablesung“ mit den angebotenen Arten, die Vorgabe vorgewählt. Die Wahl gilt für den ganzen Lauf; ein Punkt, der sie nicht anbietet, liest mit seiner Vorgabe. Im Lauf öffnet der Knopf „Ablesung: …“ im Kopf der Laufseite den Vorlauf noch einmal, etwa wenn der IR-Adapter ausfällt; die Punkte, die noch offen sind, lesen dann mit der neuen Wahl. Am Messplatz braucht der Lauf nur, was die Wahl verlangt: liest die Kamera oder der Prüfer, genügt das Normal der Quelle, der Prüfling muss nicht am Runner hängen.

read manual mit Quelle geht auch ohne Auswahl: der Runner stellt cal auf den Sollwert, wartet die Einschwingzeit ab und hält, bis der Prüfer den Wert eingetragen hat; die Laufseite sagt „Lies den Prüfling ab und trag den Wert ein“ und springt zum Punkt. Ohne source bleibt read manual die Ausnahme in einer Gerätegruppe wie bisher. Beides braucht den Runner ab Version 0.19.0; ältere Runner stellen an einem Handpunkt nichts, dann stellt der Prüfer selbst. Der Probelauf im Editor rechnet mit der Vorgabe. Beispiel 7 (Fluke 289) zeigt den ganzen Plan. Hintergrund: ADR 2026-11-04 Ablesequelle im Lauf wählbar.

API

Aufruf	Zweck	Recht
POST /api/v2/procedure-templates/calscript/compile	Skript prüfen, Schrittzeilen und Hinweise zurückgeben, nichts speichern	procedure_template_view
POST /api/v2/procedure-templates/calscript/format	Skript in die Standardform bringen (script, changed), nichts speichern	procedure_template_view
POST /api/v2/procedure-templates/calscript	Vorlage 0.1 anlegen (script, optional name, procedure_id)	procedure_template_edit
GET /api/v2/procedure-templates/calscript/examples	Mitgelieferte Beispielpläne: key, name, summary (erster Absatz des Kommentarkopfs), steps, script; nichts speichern	procedure_template_view
POST /api/v2/procedure-templates/calscript/from-metcal	MET/CAL-Prozedur (file oder text, optional camera) übersetzen: Skript, Bericht, Typvorschläge, driver_profile (Entwurf, exists), reading (automated, camera, camera_candidates); nichts speichern	procedure_template_view
POST /api/v2/procedure-templates/calscript/metcal-project/preview	MET/CAL-Projekt (files[], optional camera) lesen und übersetzen: Prozeduren mit Rolle und Aufrufen, je Hauptprozedur Skript, Bericht, Ablesung und Profilentwurf, offene Aufrufe; nichts speichern	procedure_template_view
POST /api/v2/procedure-templates/calscript/metcal-project	Hauptprozeduren als Prüfpläne anlegen (files[], procedures[n][name], optional procedures[n][type_id] für die Spezifikation, die nur mit specification_edit entsteht, optional camera); Profilentwürfe des Prüflings entstehen inaktiv nur mit workstation_edit (driver_profile.action: created, exists, invalid, not_permitted)	procedure_template_edit
PUT /api/v2/procedure-templates/{id}/calscript	Skript als nächste Version speichern	procedure_template_edit
GET /api/v2/procedure-templates/{id}/calscript	Vorlage als Skript lesen	procedure_template_view
GET /api/v2/procedure-templates/{id}/approval-diff	Skript der jüngsten Version gegen die letzte genehmigte (added, removed, hunks)	procedure_template_view
GET /api/v2/driver-profiles	Treiberprofile (Filter filter.type_id)	workstation_view
GET /api/v2/driver-profiles/standard	Standardprofile, die der Runner mitbringt, mit adopted_id, wenn calServer eins unter derselben Kennung pflegt	workstation_view
GET /api/v2/driver-profiles/template?type_id=…&basis=…	Ausgangspunkt für ein neues Profil: Hersteller und Modell aus dem Gerätetyp, passendes Standardprofil (basis leer: leere Vorlage), Kennung	workstation_view
POST /api/v2/driver-profiles, PUT …/{id}	Treiberprofil anlegen oder ändern; das Dokument wird nach den Regeln des Runners geprüft	workstation_edit
DELETE /api/v2/driver-profiles/{id}	Treiberprofil löschen	workstation_delete
GET /api/v2/driver-profile-drafts	Stand der KI-Routine für Treiberprofile: eingeschaltet, Anbieter, Modell, Dateigrenzen	workstation_edit
POST /api/v2/driver-profile-drafts	Entwurf aus dem Handbuch starten (files[] PDF, pages[], manufacturer, model, interface, type_id, base_profile_id, instructions); Antwort 202 mit task_id, Ergebnis über GET /api/v2/tasks/{id}	workstation_edit
POST /api/v2/driver-profile-drafts/refine	Entwurf mit Anweisung überarbeiten (task_id, document, instruction), ohne erneuten Upload	workstation_edit
POST /api/v2/driver-profile-drafts/check	Dokument gegen Runner-Regeln und Standard prüfen, ohne KI	workstation_edit
GET /api/v2/workstations/me/driver-profiles	Aktive Profile für den gekoppelten Messplatz	Messplatz-Token
POST /api/v2/workstations/me/heartbeat mit waiting_step_id, waiting_kind	Runner meldet einen Halt (message, confirm, ask); null hebt ihn auf	Messplatz-Token
POST /api/v2/workstations/{id}/commands mit type: continue, step_id	Wartenden Runner am genannten Schritt weiterschicken	workstation_run
GET /api/v2/calibrations/{ctag}/run → meta.workstations	Messplätze an diesem Lauf mit ihrem Halt (waiting: step_id, kind, since)	calibration_view
GET /api/v2/ai/display-reading/availability	Ist die Kamera-Ablesung möglich: Routine, Modell, Anbieter, Budget, Schwellen, Bildgrenzen, Datenschutzstufe	ai_assistant_edit
POST /api/v2/ai/display-reading	Ausschnitt (image Base64, mime, optional step_id, unit, decimals, display, compare_to) lesen: Text, Wert, Flags, Konfidenz, Ampel mit Gründen, evidence_token	ai_assistant_edit + calibration_edit
POST /api/v2/test-steps/{id}/capture mit source, evidence_tokens[]	Werte mit Herkunft (manual, camera, camera_auto, device) und Beweisbild je Position übernehmen	calibration_edit
GET /api/v2/calibrations/{ctag}/reading-images/{row}/{seq}	Beweisbild einer Ablesung (optional ?phase=)	calibration_view

Ein Syntaxfehler kommt als 422 mit error.line. Hinweise stehen in warnings (Zeile und Text) und verhindern das Speichern nicht. lines nennt je Schrittzeile die Skriptzeile, an der der Schritt beginnt (gleiche Reihenfolge wie steps); der Editor springt darüber von der Vorschau in den Text. Fehler und Hinweise tragen neben dem deutschen Text (detail bzw. message) den englischen Quelltext als message_key mit message_params; die Oberfläche zeigt sie darüber in der eingestellten Sprache (Kategorie app). Die Anmerkungen im Nacharbeitsbericht des MET/CAL-Imports sind noch deutsch.

GET /api/v2/procedure-templates/{id}/steps liefert je Zeile step_kind (measure, confirm, rating, ask, info, header, derived), berechnet aus Typ und geerbter config; Prüfschritte einer Kalibrierung tragen dasselbe Feld. Die Oberfläche leitet die Schrittart daraus ab und nicht mehr selbst.

Was calScript (noch) nicht kann

Sprachversion 0 bildet genau das ab, was der Schritt-Editor kann, dazu Serien als Schreibhilfe, Wiederholmessungen, den Modifier je Punkt, die Ablesequellen Messplatz und Kamera und Entscheidungen an einer Frage oder Bewertung (ask, if). Keine freien Ausdrücke, keine Variablen, keine Schleifen, keine Texteingabe des Prüfers (MET/CAL MEM2). As-Found/As-Left je Punkt ist für Sprachversion 1 vorgesehen. Hintergrund: ADR 2026-10-28, Sprachspezifikation und offene Fragen unter Entwicklung › calScript.