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 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.
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
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
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
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
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
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
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
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
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
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.
- 01
Pilot one sequence
One complete sequence ported end to end, running against your instruments, with results matched side by side against the original.
- 02
Run both in parallel
TestStand keeps the executive and starts calling Python modules. Nothing is switched off, so nothing is at risk.
- 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.
- 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].