Production deployment · customer anonymized ·
Thirteen Interfaces, One Stand
The sequencer had become the ceiling on what this end-of-line stand could test, and there was no one left to raise it. Rebuilding on EBE Test Stand Executive added the tests the line needed — without replacing a single instrument.
- Interfaces
- 13on one stand
- Transports
- 7CAN to MSSQL
- Pack
- 650 Vtraction, liquid-cooled
- Telemetry
- 280cell voltages, 56 temps
- Enerchron
- 0components remaining
- New hardware
- 0bought for the retrofit
The stand
A Tier-1 automotive supplier runs end-of-line test on liquid-cooled traction packs. Every pack leaving the line is scanned in, brought up through a precharge and contactor sequence, cycled against two paralleled cyclers, interrogated over two separate buses, checked for isolation and balance-circuit faults, and signed off into a traceability database.
It worked. Packs shipped. On paper there was no reason to touch it.
Why they changed anyway
Four reasons, and only the last one was a surprise.
The sequencer was the ceiling
Every new thing engineering wanted from the line — screen the slave modules for unstable readings, actually verify the balance circuit, get the BMS serial into the report automatically, write results where the plant's own systems could read them — sat outside what the old sequencer could reach. The stand couldn't answer new questions, so the questions stopped being asked.
Nobody was left to call
The sequencer is no longer developed and there is effectively no one supporting it. That's tolerable until a production stand is down on second shift, at which point it isn't a preference, it's an unhedged risk sitting in the middle of the line.
Failures were opaque
When a step failed, diagnosis meant opening the test log, finding the step, and inferring what the instrument had actually done. Recovery was often a full power cycle of the cabinets — mid-test, on a hunch, with no way to confirm the cause afterward.
A test that had been passing packs on the wrong measurement
The isolation test contained a contactor close that was failing silently. The sequence carried on and recorded its contacts-open reading against a state the stand was never actually in. Nothing flagged it, no run ever failed because of it, and it had been that way for as long as the sequence had existed. It was reported to the customer's engineering team rather than quietly corrected. This is the reason worth sitting with: a sequencer nobody maintains cannot tell you what it is getting wrong.
What the stand can do now that it couldn't
Same cyclers, same BMS, same plant IO, same computer class. The difference is what the sequencer can reach.
- A balance-circuit test that actually detects a failure. The previous implementation could only report a fault under one narrow condition. The current one catches modules with the balance resistors cut, verified against a deliberately faulted module on the tester.
- Voltage-stability screening. A new test that didn't exist before: watch each cell reading over time and flag the non-conforming modules that drift or jitter rather than sitting still. This was the test engineering had wanted and couldn't have.
- Traceability without transcription. BMS serial number read over the bus into the report automatically, with a retry when the first attempt fails, plus part number and work order pulled from the plant database and results written back per pack.
- It tells you when it fails. A text alert when a run fails overnight, instead of finding out the next morning.
- Diagnosable failures. Per-step instrument logs, contactor-coil current recorded through the sequence, and a lookup tool for pulling up a given pack's history — so a failure is investigated rather than power-cycled.
- Unattended updates. Stations pull new versions from a network share, so a fix reaches every stand without someone walking the floor with a USB stick.
- The old sign-off report still gets filled. The legacy Excel form the plant already used continues to populate exactly as before. Nobody downstream had to change anything.
Interface inventory
| Interface | Function | Detail |
|---|---|---|
| CAN — Vector, PCAN, NI-XNET | ||
| Pack BMS, control | Contactor open/close, IMD test, diagnostic session held open | 500 kbps, 11-bit |
| Pack BMS, diagnostics | Serial number and software revision read | UDS, DID 0xFD10 |
| Slave modules | Parameter change mode, module programming | ID 0x700 |
| Chiller mimic | Transmits the status frame the pack expects from the chiller | J1939, DBC |
| Serial | ||
| Pack BMS, telemetry | 280 cell voltages, 56 temperatures, extended stream, balance self-test | RS-232, 1 Hz |
| SCPI | ||
| Battery cyclers ×2 | Precharge, charge, discharge, parallel sync across both units | NHR 9300, 650 V |
| Bench DC supply | Contactor-coil current readback, logged per pack | 10 Hz |
| Modbus | ||
| Relay / IO module | Switches BMS 24 V and ignition | discrete out |
| Annunciator | Sounds when an operator prompt first appears | coil write |
| Analog | ||
| HV current sensor | Under-load pack voltage against BMS sum-of-cells | per-step log |
| USB | ||
| Barcode scanner | Pack scan-in; detects and warns on wrong scanner mode | USB-COM / HID |
| Network | ||
| SMB share | Report output and unattended software update | plant share |
| MSSQL | Traceability write and part / work-order lookup | per pack |
Instrument vendors are named. The customer is not.
Where the engineering actually was
None of the work that mattered was writing code to open a port. It was the behavior that only appears with a real pack on the fixture.
Parallel sync on the cyclers
The Set Operation frame that keeps two cyclers in parallel isn't documented anywhere. It was recovered from captures — byte 40 carries the enable bits — and bench-verified on the paralleled pair before it went near a pack.
A contactor that wouldn't confirm
On one pack the negative contactor never reported closed inside the 20-second window, though the command was correct. It closes reliably only when the command ordering matches the legacy program exactly. A generated implementation gets this wrong and looks like a hardware fault.
Commands the BMS quietly ignores
Contactor commands are dropped unless the BMS is held in diagnostic mode, which means a TesterPresent keep-alive on every poll, not once at the start. Without it the sequence runs clean and does nothing.
Also running in production
- Cell grading and formation at a cell manufacturer — three
NHR 9200modules cycling simultaneously, CV taper and 2 V cutoff, multi-hour unattended runs. - Mid-production layer tester —
NI cDAQ-9189over DAQmx, roughly 40 channels of cell voltage and temperature sampled at 1 kHz in hardware, plus voltage-stability screening for non-conforming modules. - AC source control at an equipment OEM —
Pacific Power 3150RGS-4UC, split-phase configuration over SCPI.
Why replacing the software was the cheap option
Everything above was bought for the price of software. That is the part worth understanding, because it is usually the reason a stand like this never gets fixed.
When a sequencer is licensed to a vendor's controller and that controller is sold with the vendor's instruments, changing the software means repurchasing the stand — so the decision leaves the maintenance budget and becomes a capital request that has to outrank everything else on the list. Most of the time it doesn't, and the stand stays as it is. Here it stayed a software decision: no cabinet, no specified controller, no instrument swap, and a pilot that could run on the existing stand before anyone committed. That economics is its own argument, but the short version is that the exit price is what keeps labs where they are.
- Runs on a standard Windows workstation. The machine driving the stand above is an ordinary plant PC. No specified model, no proprietary controller, no dongle-and-chassis bundle.
- Your instruments stay yours. Every one of the thirteen interfaces above is hardware the customer already owned. Nothing was replaced to accommodate the software, and nothing is locked to one supplier's catalog.
- Light enough to run on a Pi. Validated on a Raspberry Pi under Linux, for cases where a full workstation per station is more than the job needs. Every customer deployment to date is Windows.
If it has a programmatic interface, EBE Test Stand Executive can drive it. Here's how much of that is already proven.
Tested
A real test has run against this exact hardware and the driver ships in the box — everything listed above, plus the CAN interfaces: Vector, PCAN and NI-XNET.
Class-supported
Reached through generic SCPI, Modbus, VISA or CAN without custom work. Most bench instruments land here: configuration, not development.
On request
Anything else with a documented interface. The driver gets written and quoted as work, and then it joins the tested list.
The AI sequence assistant is optional and can be removed entirely, pointed at a model on your own hardware, or pointed at a provider you already hold an enterprise agreement with. With it off, nothing leaves the test machine.