Labbot Core — Admin / Installation Manual

Deployment, accounts, and site policy for Admin accounts

Labbot Analytics AB

2026-10-28

Introduction

This manual is for whoever sets up and administers Labbot Core on a lab PC — typically Admin, not the people running experiments day to day. It covers installation, accounts and roles, site-wide policy (sign-in scheme, restrict deletion), the instrument's service calibrations, recovery, and diagnostics.

If you are looking for how to run an experiment, edit a procedure, or take a manual measurement, that is the separate Labbot Core Manual (docs/manual/, Help ▸ Labbot Core Manual in the app) — this manual deliberately does not repeat that content.

Who should read this

Anyone who will:

The account model, in one paragraph

Every Labbot Core account has one of three roles — User, Manager, or Admin — each a strict superset of the one below it. The very first account on a PC is always created as Admin, through a first-run wizard. From there, Admin administers every other account from User ▸ Users…. Two independent site-wide choices — how people sign in, and whether deletion is restricted — apply once per PC, not per account, and can be changed at any time from the same screen. See Accounts and roles and Site policy.

Installation

Requires Windows 10 version 1809 (LTSC 2019) or later, or Windows 11, 64-bit. Windows 10 1607 (build 14393, often Enterprise LTSB 2016) and older are not supported: they lack Windows' own ICU libraries, and Labbot Core would not start ("icuuc.dll is missing"). The installer refuses to install there. To check the version: Win+R, winver.

Run Labbot Core_<version>_Installer.exe as a Windows administrator, once per PC. It:

Then the first launch starts the setup wizard - see First run.

The pH meter's driver

The pH meter's USB-serial port needs exactly Prolific driver 3.6.81.357 (package "PL-2303 USB-to-Serial" 1.12.0); newer Prolific drivers don't work with it. The installer installs that package if it isn't there yet, and then removes every newer Prolific serial-port driver from Windows' driver store, so the port falls back to 3.6.81.357. What it removed is in C:\ProgramData\Labbot\logs\installer-prolific.log. This affects any other Prolific USB-serial device on the PC as well; they work with 3.6.81.357 too.

Windows Update can bring a newer Prolific driver back later - then the pH meter stops responding. To prevent it, exclude drivers from Windows Update on this PC (Group Policy Do not include drivers with Windows Updates, or your management tool's equivalent). If it has happened, run the Labbot Core installer again - it removes the newer driver again.

The installers aren't code-signed yet. Windows SmartScreen may show "Windows protected your PC" with an unknown publisher: choose More info, then Run anyway. If your site blocks unsigned installers, allow Labbot Core_1.5.0_Installer.exe and Labbot Lens_1.5.0_Installer.exe (for example by file hash) before installing - ask your supplier for the hashes.

Labbot Lens on other PCs (people analysing data on their own computer): run Labbot Lens_1.5.0_Installer.exe. It asks whether to install for all users (needs administrator rights) or only for the current user (no administrator rights). Lens needs no drivers or folders of its own; data comes from Labbot Core's Export (see Labbot Lens and the experiment data).

Deployment model

Labbot Core is a per-machine install, not per-user. Two separate locations are involved, deliberately kept apart:

Location Holds Who can write to it, by default
C:\ProgramData\Labbot\ Accounts (LabbotUsers), the shared procedure/titrant library (LabbotPrefs), the instrument profile, the project list and the activity log Nobody, until an administrator grants it (below) — this is Labbot Core's own internal state, and it should not come into existence with whatever permissions the first person who happens to launch it has.
C:\ProgramData\Labbot\Experiments\ Experiment results — one folder per Labbot Core account Created automatically the first time a run is saved; covered by the same grant as the folder above, no extra step. An Admin can move it to another folder — see Where experiment data is kept.

Both are per-machine, not per-Windows-account, so every operator on this PC shares the same library and sees the same experiment data regardless of which Windows session they're in. The experiment data has to be machine-scoped rather than under an operator's own Documents — otherwise the same Labbot Core account, used from two different Windows sessions on one PC, would end up with its runs split across two unrelated folders. See Site policy for how the optional delete-restriction ACL applies to the experiment-data folder — it covers that folder only, never the stores beside it in C:\ProgramData\Labbot\.

Where experiment data is kept

By default C:\ProgramData\Labbot\Experiments\. ProgramData is hidden in Windows Explorer, so operators work in Labbot Core's Data ▸ Experiment Data window (browse, annotate, export, delete, open in Labbot Lens) rather than in the folder itself. That is the point of the location: it steers everyday use through Labbot Core. It does not protect the data — for that, see Restricting deletion.

An Admin can choose another folder — a data drive, or a network share that is already backed up — in User ▸ Users… ▸ Data Location…. The folder must exist and be writable by the Windows accounts the operators use; Labbot Core checks this when you choose it. The setting is machine-wide and is kept in C:\ProgramData\Labbot\LabbotUsers. Changing it does not move data already saved; use Move Old Data Here… in the same window, or move it yourself while nobody is using Labbot Core.

Backups

Many backup setups skip C:\ProgramData. Check yours. Either add C:\ProgramData\Labbot\ to the backup — it holds the experiment data and the accounts, library and instrument profile — or choose a backed-up folder for the experiment data in Data Location… and back up C:\ProgramData\Labbot\ as well.

No one needs to be a Windows administrator to run Labbot Core day to day; administrator rights are only ever checked at two specific moments, both covered below and in First run / Recovery.

Before the first launch

The installer does this step. If Labbot Core is ever installed without it (an xcopy of the program folder, say), do it by hand. Labbot Core deliberately refuses to silently create C:\ProgramData\Labbot\ — a folder created by whichever ordinary Windows account happens to run Labbot Core first would inherit that account's own permissions, which is exactly the "one operator's save isn't visible to the next" failure this design exists to avoid. The Experiments\ folder inside it needs no step of its own — it's created automatically the first time a run is saved, under the grant below. So, once, before anyone signs in for the first time, an administrator needs to:

  1. Create the folder: 
    mkdir "C:\ProgramData\Labbot"
  2. Grant the local Users group Modify access, inherited by anything created inside it later — this is what lets every operator's account read and write the shared library and logs: 
    icacls "C:\ProgramData\Labbot" /grant *S-1-5-32-545:(OI)(CI)M
    The well-known SID (*S-1-5-32-545) is used instead of the localised group name "Users" so this works on non-English Windows installs too.

If this step is skipped, Labbot Core shows a clear refusal on launch — " C:\ProgramData\Labbot is missing" or "exists but is not writable by this account" — naming exactly what to fix, rather than silently falling back to a per-user location.

Labbot Lens and the experiment data

The experiment-data folder is the record. Labbot Core keeps a small notice file, labbot-data-root.txt, at its top (C:\ProgramData\Labbot\Experiments\, or the chosen folder) - leave it in place: Labbot Lens uses it to recognise original data and opens anything below it read-only. People who analyse data on their own PCs get it with Export in Labbot Core's Experiment Data window, which copies a whole run; Labbot Lens works freely on such copies. If you put the experiment data on a network share, give users on other PCs read access only, or none - Export is the intended route.

Upgrading an existing install

To upgrade, run the new installer over the old install - it keeps C:\ProgramData\Labbot\ (accounts, library, data) as it is. Without the installer: replace the program folder, keep C:\ProgramData\Labbot\, relaunch. Every store under it (LabbotPrefs, LabbotUsers, LabbotInstrument) parses older, missing, or partial fields migration-safely — an older file loads with today's defaults for whatever it predates, and gets the current format back the next time Labbot Core saves it. If this PC was running a version from before this app was renamed from Labbot.exe, or before it had accounts at all, see Upgrading for what that specifically means for the app itself, the procedure/titrant library, and experiment data.

First launch

After the installer (or the manual step above), launch Labbot Core as any ordinary account. See First run for what happens next — a short administrator check, then the setup wizard that creates the first Admin account and walks through the two site-wide choices.

Upgrading from an older version

What actually happens to an existing install's app, library, and data when this version is installed over it — three separate things, handled three different ways.

The application itself

Labbot 1.3.x was Labbot.exe in C:\Program Files\Labbot\. Labbot Core now goes into C:\Program Files\Labbot\Labbot Core\ and Labbot Lens into C:\Program Files\Labbot\Labbot Lens\.

The installer uninstalls the old Labbot software it finds in Windows' Apps list - every old Labbot version (e.g. 0.1.2, 1.3.1, 1.3.4, 1.3.5), Labbot_FWU (the firmware updater; Labbot Core updates the firmware itself now) and Viewer 2 (replaced by Labbot Lens) - each with its own uninstaller, silently, shortcuts included. An Apps entry whose uninstaller is already gone is removed. Started after the upgrade, the old Labbot would look for the library in its old place and begin with an empty one - that's why it doesn't stay. An older Labbot Lens in C:\Program Files\Labbot Lens\ or C:\Program Files (x86)\Labbot Lens\ is replaced the same way. What was removed is in C:\ProgramData\Labbot\logs\installer-legacy.log. The library is copied before any of this, so it is never lost (see below). What the old uninstallers leave behind is removed too (C:\Program Files (x86)\Labbot\, an empty Viewer 2 folder), and the old debug logs C:\ProgramData\LABBOT_DebugLog*.txt are moved into C:\ProgramData\Labbot\logs\legacy\ for support.

Instrument firmware

This release of Labbot Core is made for instrument firmware FMX8 1.5.3, and the installer puts that firmware beside the app (C:\Program Files\Labbot\Labbot Core\Firmware\FMX8_1.5.3.uf2). The first time an Admin or Manager connects to an instrument with older firmware, Labbot Core asks to update it - about a minute; the instrument must stay on and plugged in. Labbot Core 1.5.0 needs firmware 1.5.3: until an Admin or Manager has updated an instrument, other accounts can't connect to it (they get a note saying so). The whole sequence is in the session log (fw.update.*).

The connect self-test also checks for the syringe pump. An instrument without one (or with it unplugged) still connects: pump functions are disabled and procedures that add titrant can't be started until the pump is connected and the self-test re-run with Run self-test again.

The procedure and titrant library

Labbot 1.3.x kept the library in one shared file, C:\ProgramData\LabbotPrefs, loose at the ProgramData root. The installer keeps it, unchanged, as C:\ProgramData\Labbot\Legacy\LabbotPrefs-<date> (the date of the install) and removes the loose file. The library itself, C:\ProgramData\Labbot\LabbotPrefs, starts new.

The first start (the setup wizard, see First run) then asks once what to do with the old procedures:

The titrants are taken over either way (old procedures find their titrant by name). Closing the question counts as keep as legacy - nothing is lost. The choice can't be changed later, and the archive file is kept either way; each PC has its own. The answer is logged as legacy.choice.

An install over 1.5.0 leaves an existing library as it is.

As a fallback (no archive), the very first time Labbot Core runs against a PC that still has no current library file, it checks two older locations in order and adopts whichever one it finds:

  1. %AppData%\Roaming\LabbotPrefs — a per-Windows-account copy that only pre-release builds of 1.5 (August-September 2026) wrote.
  2. C:\ProgramData\LabbotPrefs — the 1.3.x shared file, if the installer didn't move it.

Whichever is found is loaded, then immediately saved back out to the current location — a one-time, silent adoption, logged as prefs.adopted_legacy_location (source: local or source: central) so it's visible in the activity log if you want to confirm it happened. On the second launch, and every one after, the library simply loads from the current location directly — nothing to check twice.

If somehow neither older location has anything and the current one is also empty, the library starts empty, same as a genuinely fresh install — this only happens if there was truly nothing to adopt.

Experiment data

Experiment data has lived in three places over Labbot Core's history. Only the most recent one moves with a button.

Version Where runs were saved
Current (from 2026-09-28) C:\ProgramData\Labbot\Experiments\<labbot-account-name>\, or the folder an Admin chose in Data Location… — see Installation
2026-09-18 to 2026-09-27 C:\Users\Public\Documents\LABBOT data\<labbot-account-name>\
Before the account system each Windows account's own Documents\LABBOT data\ — one flat folder, no per-Labbot-Core-account folders

Labbot Core's Experiment Data window only lists runs under the current location, so older runs don't show there until they're moved. Nothing is lost meanwhile: the files stay where they were, and Labbot Lens can still open a run from any folder.

From Public Documents — Move Old Data Here…

Sign in as an Admin and open User ▸ Users… ▸ Data Location…. If data is still in C:\Users\Public\Documents\LABBOT data\, the window says so; press Move Old Data Here…. Labbot Core:

  1. copies every file into the current location, keeping the folder layout (one folder per account, runs, Manual);
  2. checks each copy byte for byte against its original;
  3. deletes an original only when its copy checked out — and removes folders left empty, including LABBOT data itself at the end.

A file that already exists in the new location with different content is never overwritten: it's left in both places and listed at the end, as is anything Windows wouldn't let Labbot Core copy or delete. Sort those out and press the button again — it carries on where it stopped. Everything is also in the session log (exp.migrate.*).

If the old folder was delete-protected ("Non-free"), Labbot Core lifts that protection first so the originals can be deleted. Windows only allows this for files the signed-in Windows account created; anything else is reported as "copied, but the original could not be deleted" — delete those yourself in Explorer as a Windows administrator once you've checked the new copies.

Choose the location before moving: the move always goes into the saved location, so change Data Location… and press Save first if the data should go somewhere other than C:\ProgramData\Labbot\Experiments\.

From an older version — by hand

Runs from before the account system sit in each Windows account's own Documents\LABBOT data\, and nothing in them says which Labbot Core account they belong to, so Labbot Core can't move them for you. If you want them in the Experiment Data window — recommended if this PC uses the "Restrict Deletion" policy, which only protects the current location (see Site policy):

  1. For each Windows account with a Documents\LABBOT data\ folder, decide which Labbot Core account the runs belong to — whoever ran them, or one shared account if that doesn't matter to you.
  2. Copy each run folder into C:\ProgramData\Labbot\Experiments\<that labbot-account-name>\ (or the folder chosen in Data Location…). ProgramData is hidden in Explorer: type the path into the address bar. Create the account folder if it isn't there yet — Labbot Core creates it the first time that account saves a run.
  3. Check the copies in Labbot Core's Experiment Data window, then delete the originals.

Copy rather than move: a move on the same drive keeps the old folder's permissions, so the new location's delete protection would not apply to the moved runs. Nothing needs to be running, and nobody needs to be signed in, while you do this — it's just files on disk.

Accounts

A PC that had no accounts at all on the old version (true for every install before the authorisation system existed) reaches First run the moment this version launches against an empty account store — the same wizard a genuinely new PC sees. Nothing about that flow is upgrade-specific; that chapter covers it fully.

First run

The first time Labbot Core runs against an empty or missing account store — a genuinely new PC, or one where every account has been removed — it walks through a short setup wizard instead of the ordinary sign-in screen.

The administrator check

Before anything else, Labbot Core checks whether the current Windows account is a Windows administrator on this machine (group membership, not whether Labbot Core happens to be running elevated right now). If it is not, Labbot Core shows "no accounts exist yet — sign in as an administrator" and quits outright, regardless of anything else. This is the one place Labbot Core checks Windows administrator status at all — day-to-day sign-in and role assignment never do.

If this PC has any record of having run before — the previous store's backup file, or an internal marker left by a genuine first-run — a prominent warning appears instead of a silent bypass: "this looks like it has run before." Setup still proceeds (refusing outright would risk locking a site out of its own data permanently), but the event is logged as a security event. See Recovery for the full reasoning. This warning is expected and harmless if you deliberately cleared C:\ProgramData\Labbot\ to test a clean install.

The wizard, stage by stage

  1. Create the first account. Name and password — this account is always created as Admin, the highest role; there is no default or implicit account. Passwords are hashed and salted before anything is written to disk.
  2. The one-time recovery code. Immediately after account creation, Labbot Core generates a recovery code and shows it exactly once, with a confirm-you-have-stored-it checkbox before Continue is enabled. Write it down somewhere safe — a password manager, a printed copy in a secure location. It will not be shown again. See Recovery for what it's for.
  3. Sign-in scheme. Choose between Independent (Labbot Core's own accounts and passwords, the default) and Windows-bound (an account is only reachable from the one Windows session whose username matches it). If you pick Windows-bound and the account you just created doesn't match the current Windows username, Labbot Core warns you before letting you continue — see Site policy for the full trade-offs.
  4. Restrict deletion. Choose between Free (the default — a User or Manager can delete their own personal procedures/titrants, and the experiment-data folder is unrestricted) and Non-free (only Admin can delete a procedure or titrant, and the experiment-data folder gets a delete-protection ACL). See Site policy for what each mode actually does.

Stage 4 also reminds whoever is setting up the PC to connect Labbot Core to the instrument at least once after finishing. Until that first real connection happens, the procedure editor stays unavailable — see The Procedure editor for what that connection unlocks.

Finishing the wizard saves both choices and closes into the ordinary sign-in screen. Both can be changed at any time afterward from User ▸ Users… — see Site policy.

The first start also adds four example procedures (named TMPL - …) and the two titrants they use (HCl, NaCl) to the shared library - a starting point for users to duplicate (the user manual's "Example procedures"). A Manager or Admin can delete them from the library if they aren't wanted; they aren't added again.

If setup is abandoned partway

The account and recovery code are saved as soon as stage 1 completes, before either policy stage is reached — closing the app between stages 3 and 4 loses nothing except the chance to set those choices immediately. Relaunching goes straight to normal sign-in with the account already created, and both policies at their safe defaults (Independent, unrestricted) until set deliberately from User ▸ Users….

Accounts and roles

User ▸ Users…

Visible to an Admin account only — a User or Manager never sees this menu item enabled. Lists every account on this PC with its role, status (Active / Disabled / Must change password), last sign-in time (Never if it hasn't signed in yet), and when its password was last changed.

Moving accounts to another PC

A lab with several instruments usually wants the same accounts on each PC. Set them up once, then:

  1. On that PC: User ▸ Export Users… (Admin) saves a list of every account - name, role, disabled or not - and the sign-in and deletion settings. No passwords are in it, so it can be passed on by e-mail or USB stick.
  2. On each other PC: User ▸ Import Users… (Admin), choose the file. A preview shows every account as new, already here, or already here, different. Only the new ones are added; an account that already exists on this PC is skipped and keeps its own role and password. Nothing is deleted. Untick a new account to leave it out on this PC — the file itself can't be edited (a changed file is refused).
  3. Enter one temporary password for the new accounts. Each user must change it at their first sign-in on that PC. (With Windows-bound sign-in without password there is nothing to enter.)
  4. Tick Also use the sign-in and deletion settings from the file to make this PC match. Switching to Windows-bound sign-in warns first, as in Login Scheme…. The data location is not part of the list.

A list that was edited or damaged after the export is refused. Both steps are in the activity log (auth.users.export, auth.users.import). Personal procedures don't travel with the accounts.

Roles

Role Can do
User Run experiments; own personal procedures/titrants; duplicate a shared procedure or titrant into a personal copy; change their own password.
Manager Everything a User can, plus curate the shared library (edit, promote, demote) and view or manage every user's personal entities.
Admin Everything a Manager can, plus all of User ▸ Users…, and choosing site policy (sign-in scheme, restrict deletion, where experiment data is kept).

Each role is a strict superset of the one below it — there is no capability a User has that a Manager lacks, and none a Manager has that Admin lacks. See the Labbot Core Manual's Administration chapter for how the shared/personal library split actually works day to day; this manual only covers the administrative side of accounts.

The last-Admin guard

Labbot Core refuses to disable, delete, or demote the last enabled Admin account on a PC, whether through User ▸ Users… or the quick Disable/Enable toggle — there is always at least one way in. This is a free safeguard, not a configurable setting, and it is the main reason most "we're locked out" incidents never happen in the first place. If you genuinely need to remove someone's Admin access, create or promote a replacement Admin account first, then demote or disable the old one.

Changing your own password

User ▸ Change Password…, available to any signed-in account regardless of role, asks for the current password before accepting a new one. This is separate from Admin resetting someone else's password via Edit above — a self-service change never requires Admin involvement.

Site policy

Two choices apply once per PC, not per account, and can be changed at any time from User ▸ Users… (an Admin account only) — both are also asked during first run, but neither is permanent.

Sign-in scheme

User ▸ Users… ▸ Login Scheme…

Mode Behaviour
Independent (default) Labbot Core has its own accounts and passwords, entirely separate from the Windows account signed in to. The sign-in screen lists every account and pre-selects whichever one most recently signed in from this Windows session, as a convenience only.
Windows-bound Each Labbot Core account is only reachable from the one Windows session whose username matches it, by name. The account picker is skipped entirely — there is only ever one legal account to reach from a given Windows session. If it's set to not require a password, sign-in happens automatically with no window at all; if it does require one, a password-only prompt appears for that one account.

Windows-bound has one hard consequence: an account with no matching Windows username on this PC becomes completely unreachable — there is no fallback to the account picker, since that would make the binding advisory rather than real. Login Scheme… only checks the current session's own Windows username against existing accounts (Labbot Core has no way to enumerate every Windows account that might exist on a PC) — switching into Windows-bound mode warns you if that one account would be locked out, but cannot warn about every other account. Check that every account you intend to keep using actually has a matching Windows username before switching.

Windows-bound mode also means one Windows account can no longer host more than one Labbot Core account (a 1:1 name match structurally can't do otherwise) — if your site relies on several people sharing one Windows session under different Labbot Core identities, stay on Independent mode.

Restricting deletion

User ▸ Users… ▸ Restrict Deletion…

One combined choice, covering both procedures/titrants and experiment data together — the two are configured together deliberately, not as separate settings, so there is exactly one decision to make rather than two that could drift out of sync.

Mode Procedures / titrants Experiment data
Free (default) A User or Manager can delete their own personal entities; a Manager or Admin can delete a shared entity or another user's personal entity. The experiment-data folder (C:\ProgramData\Labbot\Experiments, or the one chosen in Data Location…) is completely open. In Labbot Core's Experiment Data window anyone can delete their own runs and manual measurements, and a Manager or Admin other accounts' too; Windows Explorer can delete anything.
Non-free Only an Admin account can delete a procedure or titrant at all — own, someone else's, managed or personal. The experiment-data folder gets a Windows ACL denying Delete to the built-in Users group, inherited by every subfolder — nobody can remove a saved run through Explorer, standard account or not. Only an Admin can delete, in the Experiment Data window: Labbot Core lifts the Deny entry on that one run folder or file first (see below).

Off by default, deliberately. Many existing installs — academic labs especially — rely on today's self-service delete for personal work. Turning this on is a considered Admin choice, not something a new install silently imposes.

How an Admin deletes in Non-free mode. The Deny entry applies to every Windows account in Users, whatever the Labbot Core role. So when an Admin deletes a run or manual measurement in the Experiment Data window, Labbot Core first gives that one folder or file its own copy of the inherited permissions without the Deny entry (icacls /inheritance:d, then /remove:d *S-1-5-32-545), then deletes it. Everything else keeps the protection. This needs the Windows account running Labbot Core to own the files, which is the normal case when the runs were made in that Windows session. If Windows still refuses, Labbot Core says so: delete the item while signed in to Windows as an administrator. Each step is logged (exp.delete, exp.delete.acl).

Copying is never affected, in either mode. Non-free only denies Delete and Delete-child — reading, writing, creating, and copying a file out of the protected folder all still work normally; only removing the original, or moving it out (which requires Delete under NTFS), is blocked. This is deliberate: an operator can still back up or share a result, they just cannot remove it from the shared record.

Plots made in Labbot Lens. Labbot Lens may add, edit, duplicate, rename and delete its own plots (<plot>.mxt) in run folders in the experiment-data folder, in either mode; everything else there - the spectra, the text data and Labbot Core's own plots (<name>_TD.mxt, <name>_TD2.mxt) - it opens read-only. Windows still decides:

When the data location changes. Choosing a new folder in Data Location… applies the Deny entry to it straight away when Non-free is on; the default Experiments folder gets it when Labbot Core creates it. The previous folder keeps its entry until its data is moved — Move Old Data Here… lifts it from the old folder first so the originals can be deleted (see Upgrading).

One honest limit: the experiment data is hidden (C:\ProgramData is hidden in Explorer), not locked away. Every standard account can write to the folder — that's how runs get saved — and each file is owned by the Windows account that created it, so a sufficiently determined user could, in principle, reset the permissions on files they own. Non-free is a real barrier against casual or accidental deletion, not an absolute guarantee against someone deliberately working around it.

Service calibrations

Three of the instrument's settings depend on its mechanical parts and are set at the factory. Service in the menu bar lets an Admin set them again on site, for example after a new syringe or after the filter wheel has been out:

Menu item What it sets When to run it
Pump Offset… where "empty" lies for the syringe pump - just before the plunger meets the bottom of the syringe after fitting a new syringe, or if doses look uneven
Filter Wheel Offset… how far the filter wheel is turned so its positions line up with the light beam after the filter wheel has been taken out or changed
Absorbance Offset… which pinhole the absorbance light passes through - the biggest one the flash lamp's lowest level doesn't overfill after Filter Wheel Offset, or if the absorbance light is too strong or too weak

The items are visible to everyone and enabled for Admin accounts only. Each opens a window with what to prepare, a Start button and the result.

Before you start

If the instrument isn't ready, the window says what is missing and Start stays disabled.

What happens

  1. Start measures. Nothing is written to the instrument yet.
  2. The window shows what was measured, the value the instrument has now and the new one. Save writes the new value; Keep old writes nothing and puts the instrument back as it was.
  3. After Save, a check. Pump: one more scan checks the new setting - it drives past the new empty position to the bottom and reports how far beyond empty the bottom lies (about 10 full steps, 0.1 µl). In normal use the pump stops at empty and never touches the bottom. Filter wheel: each pinhole is read at its normal position.
  4. Cancel stops a measurement at any time; nothing is written, and the instrument is put back. The window can't be closed while a measurement runs.

After Filter Wheel Offset has been saved, run Absorbance Offset - the light through each pinhole has changed. Either one also clears the absorbance blank kept in the manual absorbance window, so its next Blank sets the light again.

If the filter wheel's pinholes disagree by more than 48 microsteps, the window says so before you save: check that the filter wheel sits properly (through the filter lid) and measure again.

If a calibration stops with an error - the instrument didn't answer, or refused a command - switch the instrument off and on, connect again and retry; if it happens again, contact support with the session log.

In the log

Every calibration is logged in the session log (category SERVICE): when it started, what was measured (service.measured, with the readings), whether it was saved or kept, and the result with the check (service.done), or why it stopped (service.fail). See Diagnostics for where the log is.

Recovery

Labbot Core has no vendor-side override — Labbot Analytics AB cannot reset a customer's install remotely, and there is no support challenge/response mechanism. Everything below is self-serve, by design: a vendor-held master key would be a liability for a regulated customer, not a reassurance.

The recovery code

Generated once, at first-run setup alongside the very first Admin account (see First run), and shown exactly once. Only its salted hash is ever stored — the same discipline as a password. If every Admin account's password is lost:

  1. On the sign-in screen, use the hidden recovery shortcut (below) to open the recovery window.
  2. Enter the recovery code. It either resets an existing (disabled or password-forgotten) Admin account, or creates a new one if none remain enabled.
  3. A fresh recovery code is generated and shown immediately — the same confirm-you-have-stored-it step as first run — since the one just used stops working the moment it succeeds.

Both generating and using a recovery code are logged as security events.

Reaching the recovery screen

There is no visible "Forgot password?" link — a permanently visible recovery entry point is itself a bigger attack surface than the low- frequency need for it justifies. Instead, from the sign-in screen: hold Ctrl+Shift and press F9. This only works if the current Windows session belongs to a Windows administrator on this machine — the same administrator check used for first run. A non-administrator session pressing the shortcut sees nothing happen.

If the recovery code is lost too

There is no third mechanism. The last resort is deleting LabbotUsers (C:\ProgramData\Labbot\LabbotUsers) and restarting Labbot Core — this triggers first-run setup again, creating a brand-new Admin account and losing every existing account record. Labbot Core does not do this silently.

The empty-store bypass warning

Because there is no third recovery mechanism, deleting LabbotUsers must stay available as a genuine last resort — refusing it outright would risk permanently locking a site out of its own data, which is worse than an honest, logged bypass. What it does not stay is silent or available to just anyone:

If you deliberately want a clean first-run for testing (not a real recovery), clear LabbotUsers, LabbotUsers.bak, LabbotPrefs, and logs\store-initialized.marker together — leaving any one of them still triggers the warning, which is expected, not a bug.

Diagnostics

The activity log

Every session writes a structured, JSON-lines log to C:\ProgramData\Labbot\logs\labbot-session.jsonl — one continuous record shared by every account on this PC, not per-user. It rotates on each launch and keeps the last 10 runs (labbot-session.1.jsonl … .10.jsonl). Each line is one event, and every entry carries the signed-in Labbot Core account name and the Windows account together — so an out-of-band edit under C:\ProgramData\Labbot is attributable even if it never went through Labbot Core at all.

Every experiment additionally writes its own labbot-run.jsonl inside that run's own save folder — a self-contained slice of the same events, covering just that run, that can travel with the data.

Security-relevant events worth knowing the shape of, without needing to memorise them: sign-in success/failure, account creation/disable/role change, sign-in scheme and restrict-deletion policy changes, recovery-code generation and use (including the probable-bypass warning from Recovery), promote/demote and delete of a procedure or titrant (naming who and whether it was their own), and force-takeover of a locked run. The full event catalogue lives in the repository's LOGGING.md if you need the exact field names for a specific investigation.

Two entries are worth knowing for support. If Labbot Core ever has to close because of an internal error, it first writes an app.crash line with the error and where it happened - send the log with the problem report. Every connect writes selftest.spectra with the self-test's dark and flash-lamp readings, a health history of the instrument's light path.

Raising verbosity

Ordinary operation logs unconditionally at INFO and above. A per-frame TRACE level exists for serial/DLL-level debugging, off by default — toggle it by hand-editing C:\ProgramData\Labbot\logs\log-settings.txt to contain trace=1 before launch, no rebuild required. Turn it back off the same way once you're done; it is verbose.

Report a Problem

Help ▸ Report a Problem…, available to anyone signed in, opens a pre-filled report form — the person's own description plus the build number, platform and Windows version (read from the registry) — with e-mail, clipboard, and screenshot options. This is the right channel for a bug in Labbot Core itself, not for an account or policy question, which this manual should already answer.

Per-user interface state

Each Windows account's own window positions and last-used folders are kept separately, under %AppData%\Labbot\prefs.txt for that account — this is purely cosmetic convenience, never security-relevant, and is not shared between accounts the way C:\ProgramData\Labbot is. Deleting it just resets window positions to their defaults on next launch.