Skip to content

Testral Core and Testral Cell

A named platform, not a blank sheet every time

Sixty to seventy percent of any project is the same core. The remaining thirty to forty percent is your fixtures, your product, and your tooling. That ratio is what makes a fixed price honest, and it is why the second station costs less than the first.

Testral Core

The software every station runs

A test executive, an abstraction layer over the instruments, a results database, an operator interface, and a report generator. Written in Python, deployed with no seat licenses, and readable by the engineers who have to live with it.

  • InstrumentsHardware abstraction layer. Every instrument sits behind one interface. Swap a digital multimeter and the sequence above it does not change. This is the layer that stops an instrument going end of life from turning into a rewrite.
  • Test executiveSequencer. Steps, limits, branching, retries, and operator prompts. Built on pytest so the test sequence is ordinary Python your engineers can read, review, and run in continuous integration.
  • DataResults store. SQLite per station, Postgres plant-wide when you are ready. Serial number, operator, station, firmware revision, and every measured value, on every unit.
  • FloorOperator interface. Scan, run, read the result. Built for a technician on a twelve-hour shift, in Qt on the station or in a browser when the station is shared.
  • OutputReport generator. HTML and PDF per unit and per batch, driven by limits files rather than by code, so a specification change is a data change.
Testral Core architectureA five layer stack. Instruments connect into a hardware abstraction layer, which feeds a pytest based sequencer. The sequencer writes to a results store and drives an operator interface, and the results store feeds a report generator that produces HTML and PDF reports.DMM · SCOPE · SMU · SWITCH · DUTReport generatorOUTPUTOperator interfaceFLOORResults storeDATASequencerTEST EXECUTIVEHardware abstraction layerINSTRUMENTS
Sixty to seventy percent of any project is this stack, unchanged. The custom work sits at the edges: your fixtures, your product, your tooling.

Testral Cell

The hardware it runs on

Standard rack configurations, and robot-tended test and inspection cells for the loops where a person is loading, testing, and inspecting the same part all shift. Same software underneath, so the cell is an extension of the station rather than a second system to learn.

  • Cobot

    Universal Robots first, FANUC CRX where payload demands it. Loading, tending, and part presentation.

  • Vision

    Keyence or Cognex, for inspection, measurement, and code reading. Certified on Keyence.

  • Test rack

    The same Testral Core stack that runs a benchtop tester, in a rack the cell feeds.

  • Fixturing and end effector

    Designed with a local machine shop rather than a shop I would have to build.

  • Safety

    A documented risk assessment against RIA R15.06 and ISO/TS 15066 in every cell scope. It is a paid deliverable, not a disclaimer.

  • Simulation

    Offline layout and cycle time in RoboDK before anything is bought, so the payback number is checkable.

Robot-tended test and inspection cell, plan viewA collaborative robot at the centre of a guarded cell, with an infeed, an outfeed, a vision inspection station, a test fixture, and a reject bin all inside its reach envelope. The instrument rack stands outside the guarding and connects to the fixture by cable. The operator works from the left-hand side, outside the fence, across a light curtain that covers the infeed and outfeed opening.GUARDINGREACH ENVELOPERackVisionTest fixtureInfeedOutfeedReject binLIGHT CURTAINOPERATOR SIDE, OUTSIDE THE GUARDING
Layout, reach, and cycle time get simulated offline before anything is bought, which is what makes the payback number checkable rather than promised.

Instrument coverage

What the platform already drives

Every measurement class below has a first-party Python driver running on a free driver runtime, which is what makes a deployed station cost nothing per seat and nothing per year.

Measurement

The core measurement classes, all with first-party Python drivers on free runtimes.

DAQ, analog and digital IO, counters
nidaqmx
Digital multimeter
nidmm
Oscilloscope and digitizer
niscope, with nitclk for multi-module sync
Source measure unit and programmable power
nidcpower
Stimulus

Generating the signal the unit under test has to respond to.

Function and arbitrary waveform generation
nifgen
Digital pattern
nidigital
RF signal generation
nirfsg. RFmx analysis in Python is newer, verified per instrument
Switching

Getting one instrument onto many pins without one relay per test.

Switch modules and multiplexers
niswitch, nise
Pickering PXI switching
Official Pickering Python
Signal routing and topology
Modelled in the abstraction layer, not hard-coded in the sequence
Any SCPI box

The long tail. If it speaks SCPI over any transport, it is reachable.

GPIB, USB, LAN, serial instruments
pyvisa
Instruments with no vendor Python at all
Driver written behind the Testral Core abstraction layer
Development with no instrument on the desk
PyVISA-sim and the drivers own simulate option
Talking to the unit

The interfaces your product actually exposes.

Serial and USB console
pyserial
CAN and CAN FD
python-can
Modbus RTU and TCP
pymodbus
Custom protocols and bootloaders
Written per product, tested against a simulator
Vision

Inspection, measurement, and code reading, which is the usual payload of a tended cell.

Keyence vision systems
Vendor SDK. Certified
Cognex In-Sight
Vendor SDK
Custom inspection
OpenCV, when a smart camera is the wrong tool
Robotics

Studies and simulation now, builds when the cell is scoped and the safety assessment is signed.

Universal Robots
Primary cobot platform in this radius
FANUC CRX
Where payload or reach rules out a UR
Offline layout and cycle time
RoboDK, delivered as a simulation video in the feasibility study
LabVIEW and TestStand

Taken when your ecosystem requires it, which in aerospace, defense, and medical it often does.

Existing TestStand sequences
Maintained, or migrated a sequence at a time
Hybrid transition
TestStand executive calling Python modules, so migration is gradual
TestStand deployment licenses
Passed through at cost as a line on the bill of materials
Pricing
15 to 25 percent above standard rate
Where Python does not reach

Published because you should hear it before you sign, not after. Every fixed bid checks these first.

LabVIEW FPGA, FlexRIO, R-series
Stays in LabVIEW
LabVIEW Real-Time targets such as cRIO
Stays in LabVIEW
Some of the newest RF instruments
Verified instrument by instrument during the assessment
Deployment operating system
Windows. NI Linux support is partial and I will not pretend otherwise

Getting off LabVIEW and TestStand

A migration nobody has to hold their breath through

Nothing gets switched off before its replacement works. The rack keeps running the whole time, and the cost is spread across changes you were already going to make.

  1. 01

    Pilot one sequence

    One complete sequence ported end to end, running against your instruments, with results matched side by side against the original.

  2. 02

    Run both in parallel

    TestStand keeps the executive and starts calling Python modules. Nothing is switched off, so nothing is at risk.

  3. 03

    Move sequences as they come up

    Each one that needs a change gets ported instead of patched. The effort is spread across the work you were doing anyway.

  4. 04

    Retire the seats

    When the last sequence is across, the deployment licenses stop. NI Python drivers run on free driver runtimes.

Who owns what

You own the deliverables. Nobody owns you.

Yours

Your sequences, your fixtures, your configuration, your limits files, and every row of test data. Delivered as readable source, not a compiled black box.

Licensed to you

The platform underneath: the abstraction layer, the sequencer, the report engine, the reference designs. It stays my pre-existing intellectual property and you get a license to run it, which is exactly why you are not paying to have it built from scratch.

Not a dependency

No seat licenses, no annual renewal, no phone-home. Your own engineers can read it, change a limit, and deploy it without me. If you stop calling, nothing stops working.

Next step

Tell me what your test bench is holding up.

Thirty minutes, at lunch or after five, on your product and your current test process. No deck. If it is not a fit I will say so on the call, and if I know someone better placed I will tell you who.

Replies within 24 hours. Or write directly to [email protected].