# Testral Systems LLC, full site content Generated from the site's own content source. Last built 2026-08-27. Canonical site: https://www.testralsystems.com ## What this business does Testral automates product testing, from benchtop testers to full ATE racks to robot-tended test and inspection cells. Operating as Testral Systems LLC, founded by Noah Nunes, founder and test systems engineer. Test systems are written in Python or in LabVIEW and TestStand, whichever the customer’s quality system, customer specification, or existing rack requires, at the same rate either way. Software, instrument drivers, migrations, and results systems are delivered remotely nationwide. Integration, commissioning, and factory acceptance happen on the customer’s floor. The practice is based in western Massachusetts. A site visit inside about fifty miles is roughly an hour and happens the same day, out to about a hundred and twenty miles is a planned drive, and anywhere else in the country is booked travel. None of that limits who can hire it. Response time: within 48 hours. Engagements start at From $3,000 for an assessment to $25,000 for a robotic cell, then quoted against scope. Contact: hello@testralsystems.com ## Positioning and proof - Both stacks, Python, NI. LabVIEW and TestStand written at the same rate as Python, whichever the job actually calls for. - Keyence, Vision. Certified. Vision is the payload in most tended cells, so it is the training that earns its keep. - 6 years, In test. Defense, aerospace, medical device, and manufacturing programs. Customer quotes are published only once they come from a real acceptance walkthrough, so none are shown rather than invented. Credibility rests on published starting prices, a published process with written acceptance gates, and certifications stated as held or scheduled rather than blurred together. ## Credentials - Engineer in Training (EIT), Massachusetts: held. The Fundamentals of Engineering exam passed and the state registration held, which is the first step of the PE path. - Keyence Machine Vision Certification: held. Vision is the payload in most tended cells, so this is the training that earns its keep. - Universal Robots Training: held. Cobot programming and integration for tended test and inspection cells. - Test Automation Foundations: held. Udemy. The standard patterns and vocabulary, which matter most when the framework being inherited is somebody else’s. - AI for Business Leaders: held. Udemy. Where AI belongs in a delivery process and where it does not, which is the reasoning behind how it gets used here. - BSME, Minor in Electrical Engineering and Mathematics: held. The mechanical half is why the fixtures work, and the electrical half is why the instruments do. - Certified LabVIEW Developer: scheduled. Booked. The exam confirms what the work already covers, and it matters to procurement. - Certified TestStand Developer: scheduled. Booked alongside the CLD, since most racks that run TestStand also run LabVIEW. ## How We Work ### Remote first, on site when it needs a person Development, drivers, migrations, and reporting are remote, which is most of the hours on most projects and is faster and cheaper for you. Integration, commissioning, and factory acceptance happen on your floor. ### Written before verbal One status email a week, so nobody has to sit in a standing meeting. Acceptance criteria written and signed before the build starts. Change orders quoted rather than absorbed quietly. ### Staged, and you can stop after any of them A paid assessment before a pilot, a pilot before a build. Each stage ends with something you own and can take elsewhere, which is the only version of this that is fair to you. ### AI-assisted where it earns it Drivers, boilerplate, test scaffolding, documentation, and the mechanical half of a migration go faster with AI assistance, and that shows up in your schedule rather than in the invoice. Everything it writes is reviewed line by line and tested against real hardware before it ships, on the same standard as anything typed by hand. Nothing of yours reaches a third-party service without your written permission, and on programs where that answer is no, it stays no. ### You own the code Source, documentation, and the walkthrough come with the system. Nothing is escrowed, obfuscated, or held back to make the next call necessary. ## Offers and prices ### Test automation assessment Price: From $3,000 Timeline: 4 weeks Stage: assess Capability: test-systems An audit of how you test now, and an architecture, a bill of materials, and a written bid for building something better. Deliverables: - Written audit of the current test sequence and where the time goes - Proposed architecture with the instrument list and a bill of materials - Driver coverage confirmed instrument by instrument, before anyone commits - Phased roadmap with effort per phase - A written bid for the build, which you can approve or decline Good fit when: You know test is the bottleneck but cannot yet put a number or a scope on the fix. ### LabVIEW and TestStand code audit Price: From $3,000 Timeline: 1 to 2 weeks Stage: assess Capability: labview A read of the code you inherited, and a written account of what it does, where it will break, and what it costs to keep. Deliverables: - Architecture of the existing sequence, written down for the first time in most cases - The parts that will fail on the next instrument change, named specifically - License exposure and what happens at the next renewal - What can be fixed in place, and what genuinely needs replacing - Effort estimate for either path, so the decision is a comparison Good fit when: The rack works, the person who wrote it has gone, and nobody will touch it before a shipment. ### Robotic cell feasibility study Price: From $8,000 Timeline: 3 to 6 weeks Stage: assess Capability: cells Cycle time, payback period, and a modelled cell layout, so the robot decision gets made on numbers instead of a demo. Deliverables: - Cycle-time analysis and a payback calculation on your real volumes - Cell layout with reach, fixturing, and part presentation worked out - Offline model of the cell running your sequence, so reach and cycle time are checkable - Custom end effector concept, with fabrication subcontracted and managed - Safety concept referenced to RIA R15.06 and ISO/TS 15066 - A written build bid, so the study leads somewhere Good fit when: You are short of people on a repetitive load, test, or inspect loop and want to know whether a cobot actually pays. ### Migration pilot Price: From $6,000 Timeline: 3 to 4 weeks Stage: pilot Capability: python One LabVIEW or TestStand sequence ported to Python end to end, so you can see the pattern before betting the rack on it. Deliverables: - One complete sequence running in Python against your instruments - Instrument drivers written behind one hardware abstraction layer - Side-by-side results proving the port matches the original - The hybrid path documented, so TestStand can keep calling Python during the transition - Effort estimate for the remaining sequences, based on measured work rather than a guess Good fit when: The rack still works, but the seat licenses keep climbing and the people who can maintain it keep leaving. ### Instrument driver pack Price: From $3,000 per instrument Timeline: 1 to 2 weeks per driver Stage: pilot Capability: python Clean drivers for the instruments you own, behind one abstraction layer, so swapping a box does not mean rewriting a sequence. Deliverables: - One driver per instrument, behind one hardware abstraction layer - Unit tests run against the instrument itself - Documentation your engineers can read without calling anyone - Simulated-device harness available as a priced add-on, when hardware cannot be freed up early Good fit when: You have an instrument with no usable driver support and a sequence waiting on it. ### Test set for one product line Price: From $15,000 Timeline: 8 weeks to 1 year Stage: build Capability: test-systems A complete functional tester for a single product, delivered with the operator interface, reports, and traceability already working. Deliverables: - Full test sequence, from power-up to pass or fail stamp - Operator interface built for a technician, not for an engineer - Custom fixture design, with fabrication subcontracted and managed - Results database, limits files, and per-unit reports - Factory acceptance test against a written checklist you sign - Ninety-day warranty on defects Good fit when: One product line is eating your test bench and you want it off the bench and onto a station. ### LabVIEW or TestStand system build Price: From $10,000, quoted against scope Timeline: Scoped in the assessment Stage: build Capability: labview The same test system, delivered in the stack your quality system, your customer, or your existing rack already requires. Deliverables: - Sequences in TestStand or applications in LabVIEW, written to be handed over - Instrument drivers and hardware abstraction inside the NI stack - Deployment licenses on the bill of materials, procured with the rest of the materials - Source, documentation, and a walkthrough for the engineers who will keep it - Factory acceptance against the same written checklist any other build gets Good fit when: Python is not the constraint here. A customer specification, a validated process, or an existing rack is. ### Robotic test or inspection cell Price: From $25,000, quoted against scope after the feasibility study Timeline: Scoped in the study Stage: build Capability: cells The cell the feasibility study modelled, built, integrated, and commissioned against the cycle time it predicted. Deliverables: - Robot, end effector, fixturing, and part presentation, procured and integrated - Vision for inspection, measurement, or code reading where the study called for it - The test sequence the cell is tending, on the same terms as any other build - Documented safety risk assessment against RIA R15.06 and ISO/TS 15066 - Acceptance against the modelled cycle time, on your floor, with your parts Good fit when: The study came back with a payback number you were happy with. ### Results and reporting bolt-on Price: From $3,000 Timeline: 2 to 4 weeks Stage: build Capability: data Traceability and reporting added to a rack that already works, without touching the test sequence. Deliverables: - SQL results database, per station to start, plant-wide when you are ready - Full traceability on every record: serial number, operator, station, firmware revision - Limits files, so specification changes stop being code changes - HTML and PDF reports generated per unit and per batch - Yield and first-pass-rate views over the data you have been discarding Good fit when: Your tester passes and fails correctly, but nobody can answer what changed when yield dropped last quarter. ### Support plan Price: $5,000 per year Timeline: One year, renewable Stage: sustain Capability: applies across all of them A warranty-style subscription: eight hours of direct support every month for one flat annual fee, so keeping the tester running does not need a purchase order each time. Deliverables: - Eight hours of direct support each month, used as and when you need them - One fixed fee for the year, invoiced once rather than chased monthly - Fixes, questions, and small tweaks all draw down the same hours - Response within two business days - Hours reset every month on the day of purchase and do not roll over - Bookable several years at a time if you would rather settle it once - Need more than the eight in a given month, extend them for a fee - Anything that is new capability rather than support becomes sustaining engineering Good fit when: The tester is in production and you want somebody on the hook when it stops. ### Sustaining engineering Price: From $3,000, quoted against scope Timeline: Per change Stage: sustain Capability: applies across all of them The step above the support plan. Where support keeps what exists running, this is for the work that changes what it does: a new product variant, a feature the line wants after release, a replaced instrument, a specification that moved. Deliverables: - New product variants added to an existing sequence - Features introduced after release, scoped and quoted before anyone starts - Instruments swapped when one goes end of life, without rewriting the sequence - Limits and specification changes, applied and verified - Re-validation of the parts a change actually touched, rather than all of it Good fit when: The system is working, your product line has not stopped moving, and what you want next is bigger than a support ticket. ### How the numbers work Every figure above is a floor. Where a ceiling is knowable it is stated; past that the work is quoted against a written scope. Most of any test system is the same every time: the layer over the instruments, the sequencer, the results store, the operator interface, the report generator. Those are written once and carried between projects. Your project pays for the part that is genuinely yours, which is the fixtures, the product knowledge, and the tooling. So beyond the starting figures the work is quoted rather than listed. Two testers for the same product can differ by a factor of three on fixture count alone. The honest answer is a written bid against a real scope, and producing that scope is what the assessment is for. The floors above are real and the ceilings on the smaller engagements are real. Past that, a full ATE rack or a multi-station line runs well into six figures, and a fleet of them into seven. Nobody can quote that from a web page, and a page that pretended otherwise would be wasting your afternoon. ### Payment milestones - Custom cells and system builds: 25 percent deposit, which procures the materials, then 25 percent at design review, then 40 percent at factory acceptance, then 10 percent at commissioning. The deposit is what starts the work: materials and instruments are ordered against it, and software and integration follow once they land. Every payment after the deposit is net 30. - Everything else: 50 percent to start, then 50 percent on acceptance. Assessments, audits, feasibility studies, migration pilots, reporting bolt-ons, and driver work. The first half starts the work, the second is net 30 from acceptance. Materials and instruments are procured against the deposit and carry a handling margin, which is what keeps a half-finished bill of materials from becoming your purchasing department’s problem. If a payment does not arrive, work pauses rather than continuing on credit, and picks up again as soon as it clears. ## Capability ### Test Systems and ATE The test set itself, from a single bench-top station to a fully populated 19-inch network rack. - Benchtop functional testers - ATE racks, instrument selection, and the bill of materials - Fixture design, with fabrication subcontracted and managed - Hardware-in-the-loop benches, where the plant is simulated and the controller under test cannot tell - Operator interfaces built for a technician rather than an engineer - Factory acceptance against a written checklist, then commissioning on your floor ### LabVIEW and TestStand New development, and rescuing outdated dysfunctional code somebody left behind. - New LabVIEW development and TestStand sequence development - Taking over inherited code nobody left documentation for - Refactoring a rack that works but cannot be changed safely - Instrument drivers and hardware abstraction inside the NI stack - Deployment, licensing on the bill of materials, and handover your engineers can read ### Python Test Automation Test sequences in Python on free driver runtimes, and a route off LabVIEW that never needs a cutover. - Test sequences in Python, on free instrument driver runtimes - Migration from LabVIEW or TestStand, one sequence at a time - Hybrid operation, where TestStand stays the executive and calls Python - Instrument drivers behind one hardware abstraction layer - Simulated-device harnesses, so development does not wait on hardware ### Robotic Test and Inspection Cells A collaborative robot tending the load, test, and inspect loop, decided on a payback number rather than a vendor demo. - Cycle-time analysis and payback on your real volumes - Cell layout, reach, fixturing, and part presentation - Offline simulation of the cell running your sequence - Machine vision for inspection, measurement, and code reading - Safety concept referenced to RIA R15.06 and ISO/TS 15066 ### Data, Traceability, and Reporting The half that gets skipped and the half an auditor asks about. Added to an existing rack or new development. - Results database, per station to start, plant-wide when you are ready - Traceability on every record: serial, operator, station, firmware revision - Limits files, so a specification change stops being a code change - Per-unit and per-batch reports, in HTML and PDF - Yield and first-pass-rate views over data you have been discarding ### Instrument coverage #### 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 one hardware abstraction layer - Early work before the hardware is free: PyVISA-sim and the vendor simulate options cover some early development. Validation and verification need the real unit under test, and a simulated-device harness is a priced add-on built only where it is genuinely necessary #### 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, verified against the real unit #### Hardware in the loop Where the unit under test is itself a controller, the plant it expects to be wired to gets simulated rather than built. The real-time targets run NI’s own stack, so this is one of the places a LabVIEW seat is the right answer rather than a habit. - Real-time target running the plant model: PXI or CompactRIO under LabVIEW Real-Time, or VeriStand where the model arrives from Simulink - Vehicle, industrial, and avionics buses: NI-XNET for CAN, LIN, and FlexRay, and dedicated interface modules for ARINC-429 and MIL-STD-1553 - Sensor and load emulation: Programmable sources and electronic loads standing in for the sensors and actuators the controller is looking for - Fault injection: Switching that opens, shorts, or degrades a line on command, so the fault handling is exercised rather than assumed #### 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 A feasibility study first, then a build once 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 modelled cell video in the feasibility study - End effector and part presentation: Custom designed by us, fabrication subcontracted and managed by us #### 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: Quoted 25 percent above the Python equivalent #### Where Python does not reach Published because you should hear it before you sign, not after. Every written 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 the assessment says so before a bid does ### Hardware supported - NI (PXI and DAQ): nidaqmx, nidmm, niscope, nidcpower, nifgen, niswitch, nidigital - Keysight (Instruments): SCPI over PyVISA, plus vendor Python where it exists - Pickering (Switching): Official Python support for PXI switching and simulation - Keyence (Vision): Certified. Inspection, measurement, and code reading - Cognex (Vision): In-Sight, for the other half of the installed base - Universal Robots (Cobots): Machine tending, part loading, tended test cells - FANUC (Robots): CRX collaborative series for higher payload cells - RoboDK (Simulation): Offline layout and cycle-time simulation for feasibility studies These are the instruments and robots the work drives. They are not customers, partners, or endorsements. ## Process ### 01 Assess Buy a document, not a project. You end up holding an architecture, a bill of materials, and a written bid you can decline. ### 02 Pilot Prove the pattern on one sequence, one driver, one station, before it is applied to the whole rack. ### 03 Build The system itself, against a written acceptance checklist you sign before anyone invoices for it. ### 04 Sustain Someone on the hook when it stops at two in the morning, on a fixed fee rather than a purchase order chase. ### How a project closes A quote from a happy customer is an opinion. What follows is the contract: the six gates every project is signed off against, written down before work starts and walked through line by line before the final invoice. - Scope is defined as a checklist. The statement of work carries a written acceptance checklist. Agreed before anything starts, listing what has to be true for the work to be done. - Status arrives weekly by email. One email a week: what moved, what is next, what is blocked. No standing meeting, and no status call you have to attend to find out where the project is. - Acceptance is walked through on a call. We go down the checklist together, line by line, against the running system. Anything not met gets fixed before the invoice. - Scope changes are quoted. A change order names the work and the price. Nothing gets added silently and then charged, and nothing gets added silently and then quietly dropped. - The code stays yours to run. You own the deliverables, the source, and the documentation. Where the stack carries deployment licenses they are on the bill of materials from the start rather than discovered later. - Ninety-day warranty on defects. If something built here is wrong, it gets fixed. Support after that is the yearly plan if you want it, and nothing if you do not. ## What gets turned down - General line controls, plant IT, and PLC work that is not part of a test system. - Anything where the deadline is days rather than weeks. Test systems that are rushed are test systems that pass bad units. - Work that cannot be described well enough to write an acceptance checklist for. ## Where the work happens - Short travel (Within 50 miles, about an hour): Springfield, Hartford, Worcester, Amherst and the length of the Pioneer Valley. Close enough to come and look at a commissioning problem the day it appears rather than the week after. - Mid travel (Within 120 miles, planned in advance): Greater Boston, Providence, Albany and southern New Hampshire and Vermont. Still a drive rather than a flight, booked ahead and quoted as travel rather than folded into an hourly rate. - Everywhere else (Planned travel, nationwide): Flights and hotels, agreed before they are booked and billed at cost. Integration and factory acceptance are the visits that earn one. The development in front of them does not need anybody in the room. Integration, commissioning, and factory acceptance happen on your floor. Development, driver work, migrations, and reporting happen remotely, which is faster and cheaper for you and is most of the hours on most projects. Remote work is nationwide. ## Questions and answers ### Do you build hardware-in-the-loop rigs? Yes, for controllers that need the plant around them simulated rather than built. The usual shape is a PXI or CompactRIO target running the plant model, NI-XNET or dedicated modules for CAN, LIN, ARINC-429, and MIL-STD-1553, programmable sources and electronic loads standing in for the sensors and actuators the controller expects, and switching that injects faults on command so the failure paths get tested and not just the happy path. Where the model already exists in Simulink, VeriStand runs it directly instead of having it rewritten. A HIL bench is scoped through the same assessment as any other test set, because the model and the bus list are what drive the cost. ### Do you use AI to write the code? Yes, on the parts of the job where it is genuinely faster, and it shows up in your schedule rather than in the invoice. Drivers, boilerplate, test scaffolding, documentation, and the mechanical half of a migration are where it earns its place. Everything it writes is reviewed line by line and tested against real hardware before it ships, on the same standard as anything typed by hand. Nothing of yours reaches a third-party service without your written permission, and on programs where that answer is no, it stays no and the work gets done the long way. ### How much does test automation cost? A test automation assessment starts at $3,000, and a LabVIEW or TestStand code audit is the same shape and the same floor. A robotic cell feasibility study starts at $8,000, a migration pilot at $6,000, a results and reporting bolt-on at $3,000, a LabVIEW or TestStand system build at $10,000, a complete test set for one product line at $15,000, and a robotic cell build at $25,000. Driver packs are quoted per instrument, and the support plan is $5,000 a year for eight hours of direct support a month. Past those floors, a full ATE rack or a multi-station line runs well into six figures and a fleet of them into seven, which is why the larger builds are quoted against a written scope rather than listed. ### Is the price on the services page what we will pay? It is the floor, not the final figure: every number on this site is a minimum, and the number you sign comes from a written bid against your actual scope. Test work is not a catalogue, and two testers for the same product can differ by a factor of three on fixture count alone. What moves the figure is the number of fixtures, the number of instruments, how much of the product is already characterised, and how much on-site commissioning the install needs. The assessment exists to turn all of that into one number you can approve or decline. ### Do you write LabVIEW and TestStand, or only Python? Either, at the same rate, and a system is built in one of them rather than in a bit of each. Which one your project should use is usually decided by something other than preference: a customer specification that names the stack, a validated process you cannot re-qualify cheaply, a house standard, a LabVIEW FPGA or Real-Time target, or a rack that already exists and works. Where one of those applies, LabVIEW and TestStand are the right answer and you get them without an argument. Where nothing applies and the only reason is habit, Python removes the seat licenses and widens the pool of people who can maintain it, and a migration pilot is the cheap way to find out whether that is worth doing. ### Why pay for an assessment instead of getting a free quote? Because a free quote on an unscoped test system is a guess, and you pay for the guess later in change orders. Two weeks of paid work produces a real architecture, a real bill of materials, driver coverage confirmed instrument by instrument, and a written bid for the build that you can approve or decline. Declining is a normal outcome, and the document is yours either way: take it to another integrator if the bid does not suit you. The point is that you own a scoped project instead of an opinion. ### What are the payment terms? Custom cells and system builds run 25 percent deposit, 25 percent at design review, 40 percent at factory acceptance, and 10 percent at commissioning, while everything else is 50 percent to start and 50 percent on acceptance. The deposit is what starts the work, because materials and instruments are procured against it. We do that procurement and carry a handling margin on it, so a half-finished bill of materials does not land on your purchasing department. Every payment after the deposit is net 30. If a payment does not arrive, work pauses rather than continuing on credit, and it picks up again as soon as it clears. ### Are there software licenses to renew? That depends on the stack, and the answer is on the bill of materials before you commit either way. A Python station runs on free instrument driver runtimes, so a deployed station costs nothing per seat and nothing per year. A TestStand or LabVIEW station carries deployment licenses, and those appear as a line item procured with the rest of the materials rather than as a surprise at renewal. ### Can you convert LabVIEW or TestStand to Python? Yes, and the sensible way to start is a migration pilot starting at $6,000, where we port one sequence end to end and prove the pattern on your hardware. From there TestStand can stay as the executive and call Python modules, so the transition is gradual and nothing gets switched off before its replacement works. Sequences move as they come up for change rather than in one risky cutover. The pilot also produces a measured effort figure for the remaining sequences, which is a better basis for the next decision than an estimate. ### What kind of work do you take? Test software and test systems: benchtop functional testers, ATE racks, results and traceability systems, instrument drivers, and robot-tended test and inspection cells. Development, driver work, migrations, and reporting are done remotely, which is faster and cheaper for you and accounts for most of the hours on most projects. Integration, commissioning, and factory acceptance happen on your floor, scheduled against the design review and acceptance dates written into the statement of work. Work outside test, such as general line controls or plant IT, is not what we do, and we will say so rather than take it. ### How does a project run from the first call to a running station? You pay a modest assessment fee, we evaluate the line and hand back a bid with a bill of materials, you approve or decline, and on approval the deposit kicks off the build. Small consulting engagements and standalone test sets can be bought on their own, but that arc is the shape of a larger engagement, and it exists so that the expensive decision is made on a scoped document rather than on a sales call. After the deposit you are largely hands off: we procure the materials and instruments, build against the checklist you signed, and come back at periodic check-ins with status, anything blocked, and the few decisions that genuinely need you, such as fixture interfaces and acceptance criteria. Design review, factory acceptance, and commissioning are the points where you are back in the room. ### Do you work on site? Yes. Anywhere within about fifty miles of our base in western Massachusetts is roughly an hour and can be visited the same day; out to about a hundred and twenty miles is still a drive rather than a flight and gets planned in advance. Past that it is a booked trip, anywhere in the country. Integration, commissioning, and factory acceptance happen on your floor. Development, driver work, migrations, and reporting happen remotely, because that is faster and cheaper for you, and it is most of the hours on most projects. Remote work is nationwide. ### How fast do you respond? Within 48 hours, stated upfront rather than promised vaguely. Status arrives as one written email a week, which beats a standing meeting for a project you are not running day to day. A station down in production is the exception: that gets picked up the same business day against an active support block. ### Who actually does the work? Testral is a small practice led by its founder, and the engineer who writes your sequence is the one who answers when it misbehaves. You are never re-explaining your product to a new name. Specialists are brought in where the work calls for them and managed by us: fixture design, fabrication for end effectors and fixtures, safety assessment on a robotic cell. What does not happen is your sequence being written by somebody you never speak to. ### Do you have insurance, and can you sign our paperwork? Yes: general liability, professional liability, a certificate of insurance on request, and a W-9 ready. The master services agreement carves out anything written before your project started as pre-existing intellectual property, you own the deliverables and get a license to what sits underneath, liability is capped at fees paid, and acceptance is objective and written. If you have your own paper, we will read it and come back with the specific changes we need rather than a redline of the whole thing. ### Which instruments do you support? Every major measurement class has a first-party Python driver on a free runtime: nidaqmx for DAQ, nidmm for multimeters, niscope for digitizers, nidcpower for source measure, nifgen for generation, niswitch for switching, nidigital for pattern, plus Pickering official Python. Anything that speaks SCPI is reachable through PyVISA, and units under test are reached with pyserial, python-can, or pymodbus. The full table, including where Python does not reach, is on the services page. An instrument with no usable Python support is a driver pack, quoted per instrument. ### Where does Python not work for test? LabVIEW FPGA targets, LabVIEW Real-Time targets such as cRIO, and some of the newest RF instruments still need LabVIEW, and deployment stays on Windows because NI Linux support is partial. This gets verified instrument by instrument during the assessment, before a bid is signed, rather than discovered afterwards. Publishing the gaps is cheaper for both of us than finding them in week six. ### Do you need our hardware? Yes: validation and verification need the actual unit under test, because a sequence that passes against a simulation has proved nothing about your product. Simulated instruments are genuinely useful for early development, and we do use nidaqmx simulated devices, the simulate option on NI driver sessions, and PyVISA-sim where they help. A full simulated-device harness is a different thing: it is a priced add-on, built only when a project really needs it, and it is not typical and not included by default. The measurement instruments themselves are usually not the constraint, because the deposit funds procurement and the instruments we need for verification arrive as part of the build. What we ask you for is units under test, including known-bad ones, since a tester that has never seen a failure has never been tested. ### Who owns the code? You own the deliverables: your sequences, your fixtures, your configuration, your data. The underlying platform stays with Testral as pre-existing intellectual property and you get a license to use it, which is what keeps the number down, because you are not paying to rebuild a hardware abstraction layer that already exists. You get readable source either way, and no part of the arrangement stops your own engineers from maintaining the system. ## Contact Write to hello@testralsystems.com or use the form at https://www.testralsystems.com/contact. Replies within 48 hours. The first step is a thirty minute call on your product and your current test process, and a two-page proposal follows. Certificate of insurance and W-9 available on request.