Beta: test plan editor, runs at the workstation and camera reading¶

3 November 2026

Until now, a test plan in calServer V2 was a table in the step editor, and values were entered by hand. Three new building blocks are now available to try: a test plan editor in which the plan is written as a script (calScript), a procedure run that a program at the workstation executes with connected instruments, and camera reading, which reads displays without an interface through a webcam. One idea runs through all three: what is required, how it is measured and who reads the value live in separate places and only come together in the calibration.

Beta

All three features are beta. They ship with calServer V2 and can be used, but they have not yet been proven in production at customer sites. In practice:

The language and the plan document are still growing. New capabilities get a new document version (up to version 8 today, for plans with a camera binding); older documents are still read.
The bundled driver profiles were written from public programming manuals. Check every profile on the real instrument before its first run (calserver-runner probe).
Camera reading needs a vision model and is switched off by default.

Feedback from day-to-day lab work goes straight into the next steps.

Four building blocks, one procedure¶

A classic calibration procedure is a program in which the test task, instrument control and reading are interwoven. If a different calibrator is on the bench, or a handheld meter without an interface is to be read, the procedure has to be touched although the test task has not changed. calServer splits this across four places:

Building block	Answers	Changes when …
Specification of the device type, with options	What is required, which tolerance applies at which point?	a data sheet, a standard or a customer agreement changes
Test plan in calScript	What is measured, in which order, with which role?	the lab changes its method
Driver profile	How do you talk to this instrument model?	a new instrument model is added
Workstation with runner, camera or by hand	Who reads the value, which instrument plays which role?	a different bench, standard or unit under test is used

The script is the link. Normally it carries no tolerance and no instrument, only measurement points, functions and roles (uut for the unit under test, cal for the standard). When the plan is loaded into a calibration, the tolerance comes from the selected option of the specification; when it runs at a workstation, calServer resolves the roles to instruments that the runner addresses through their driver profiles. Load the plan, choose the option, read at the bench: only then does it become the procedure that is measured.

group "DC voltage"
  result numeric
  unit V
  read device uut
  source cal
  function "VDC"
  settle 2
  measure 1 10 100 "{value} V"
  measure 0 "Zero" read manual

The same plan runs on every workstation where suitable instruments are available. A new data sheet calls for a new revision of the specification, not a new plan; a customer with tighter limits gets an option, not a copy of the plan. Evaluation always happens in calServer: no runner, no driver and no camera decides pass or fail.

Specification: what is required¶

Each device type has one specification with several options: manufacturer specification, standard class, customer requirement or a usage with a smaller scope. Rows are bands (tolerance across a range), points (tolerance for exactly one value, and at the same time a required test point) or uncertainty contributions of a standard. The tolerance is stored per option on the row.

Only a draft can be edited. Release records person, time and a content hash and makes the revision immutable; released revisions are withdrawn, never deleted. Every calibration chooses exactly one option before loading. If calServer finds no tolerance, or no unambiguous one, for a point, the point stays without a verdict instead of a row being guessed. The certificate states the specification, revision and option it was evaluated against, and for each point where its tolerance came from.

Create procedure builds a test plan on the device type from the point rows of an option; the plan contains only the method.

Test plan editor: the plan as a script¶

Next to table and cards, the step editor has a third view, Script. The script is the source of the plan; table and cards are views of it, and switching translates live in both directions.

Writing with feedback: the text with line numbers and colours on the left, a preview of the steps the server derives from it on the right. Errors are shown at their line, hints tint the line yellow, F8 jumps to the next one. Comments are kept when saving.
Importing MET/CAL procedures: a .mc file is translated as far as calScript can express it. Whatever is not translated stays in place as a comment line and appears in the rework report. The import never silently produces a different plan. Bus commands for the unit under test go into a driver profile draft, not into the plan.
Test cases: a plan can be checked with test cases that feed readings in and expect verdicts. calServer also produces a limit profile per point and reports findings such as a point that cannot fail or a test accuracy ratio below 4:1. The cases also run against the most recently approved version, so the effect of a change is visible.
Dry run and AI draft are available in the same editor.

Versioning, approval and release of plans stay as introduced with the procedure editor.

Driver profiles: instrument knowledge as data¶

The runner at the workstation only knows transports (via VISA: GPIB, LAN, serial, USB) and a few dialects for instrument families. What a specific model understands is stored in a driver profile: the *IDN? identification, interface settings, commands per function (VDC, VAC, ADC, AAC, OHM, OHM4, CAP, FREQ, TEMP) and the instrument's limits.

Capabilities instead of roles: a profile states per function whether the instrument sources, measures or both. Whether it is the standard or the unit under test is decided by the run. The same calibrator is cal today and is calibrated itself tomorrow with the same profile.
Fail-closed: if the identification at the port does not match the profile, the runner does not open the instrument. A function the profile does not know and a value beyond the profile's limits are not sent.
Bundled: profiles for Fluke 5500A, 5502A, 5520A, 5522A and 5320A, Keysight 34401A, 34461A, 34465A, 34470A, Keithley DMM6500, Fluke 8846A and the Fluke 287/289 handheld meters via IR adapter. They appear under Administration, Driver profiles as standard profiles and can be adopted as your own copy.
A new instrument from its manual: "From manual with AI" reads the programming manual (PDF) and drafts a profile that calServer checks against a checklist. Saving is always done by a person and the profile is stored inactive; a workstation only fetches it once it has been activated after acceptance on the instrument.

Workstations and the calServer Runner¶

A workstation is a record of its own in calServer (Administration, Workstations) with its own workstation account, which may only read runs and capture values on them. The calServer Runner runs on the workstation computer and can be downloaded from the same page for Windows (per-user installer without administrator rights, MSI for central deployment, or ZIP) and Linux.

Pairing without a password: calServer generates a pairing code (8 characters, valid for 15 minutes), and the runner exchanges it for a token of the workstation account. Revoking it in calServer blocks it immediately.
Controlled from calServer: the runner checks in regularly and fetches commands. It opens no port; the workstation can sit behind NAT and a firewall.
Discovering instruments: at the push of a button the runner lists the instruments on the bus with their identification and suggests matching driver profiles. An instrument at the workstation carries its address, driver profile and inventory entry, but no role.
Measuring offline: every value goes into a local journal first and is sent once the network is back.

The procedure run¶

The procedure run page (/procedure-run/<calibration>) is a full-screen page of its own that a bench can open directly by address, either as a table or as a step-by-step view for tablets. It refreshes by itself when another screen or a workstation writes values.

After the pre-run, Run at workstation hands the run to a paired workstation. Before that, calServer shows which instrument plays which role: uut is the instrument at the workstation whose inventory entry is being calibrated, cal the standard assigned in the pre-run. A role without an instrument stays open with a reason, and the runner does not measure its points. Where a person has to act (move test leads, set a rotary switch, answer a question), the runner pauses and the page shows "Workstation is waiting for you" with a Continue button. A batch run lets one workstation measure several calibrations of the same plan version together, one unit under test per channel of a scanner or multi-channel thermometer.

The runner sends raw values. Tolerance, measurement uncertainty and verdict are calculated by calServer, and every value carries its origin (device, camera, manual).

Camera reading¶

For displays without an interface, the webcam in the browser does the reading. In the capture table, Camera reading opens a panel; the inspector draws a frame around the display once, and only that crop is sent to a vision model. The model knows the unit and decimal places of the point, never the nominal value and never the tolerance, so it cannot lean towards the expected value. From the answer calServer derives a traffic light:

red (no value, overload, several values, wrong quantity, model unsure): never taken over;
yellow (glare, uncertain sign, second reading differs and similar): suggestion in the field, the inspector accepts with a click or retypes;
green: taken over with a click (capture confirm) or, if the plan allows it, without a click (capture auto, only when two consecutive readings are green and agree).

For every accepted value calServer stores a small evidence image, exactly the crop the model saw. With repeat N the camera fills N repeat readings with running mean and spread. Even without read camera in the plan, the panel is available at every measurement point as an input aid once the AI routine "Camera reading" is switched on; manual entry always remains possible. If an external AI provider is used, the crop leaves the premises, and the panel says so before the first image.

What the beta cannot do yet¶

calScript language version 0 has no variables, no loops and no free arithmetic expressions. As-found/as-left per point is planned for language version 1.
How much logic a driver profile may express between two commands (converting, branching on a response) is still open. Until then, a MET/CAL point that calculates with the value read stays a manual reading on import.
The run view refreshes by polling every few seconds, not by push.

Details in the manual: Concept: plan, driver, reading, Test plans as calScript, Driver profiles and dialects, Specifications.