Safety System Products
Production Test Cabinet
Once SSP's Simplifier Gateway was certified, the next problem was serial production. I implemented the production test cabinet and the complete end-to-end test that now screens every Gateway before it can be shipped. The test runs more than 80 checks across the six connected PCBs, records the measurements in the company ERP system, and stops a failed unit from moving forward until it has been repaired and tested again.
Project Brief
- My role
- End-to-end implementation of the production test cabinet
- Type
- End-of-electronics production test
- Platform
- Beckhoff TwinCAT 3 / CX7080
- Integration
- Company ERP system
1.From certification to production
The missing production step
The Gateway had been tested manually a few times during development, but there was no production tester. That was expected while the product was still being developed. Once certification was complete and units were going to customers, manual spot checks were no longer enough. Every manufactured unit needed to go through the same test and leave behind a result tied to its identity.
The Gateway contains six separate PCBs connected as one device. A useful production test therefore had to check the complete electronics assembly rather than treat each board as an isolated part.
Owning the complete test
I implemented the cabinet and the complete end-to-end production test. That work crossed the physical test setup, Beckhoff modules and PLC, automated sequence, .NET backend, Vue 3 operator interface, reporting, and ERP integration. I had a part in all of it, with most of my direct implementation work sitting in the control and software layers.
The important part was making those pieces behave like one production tool. The operator should not need to know which PLC variable, serial command, or ERP call sits behind a test step. They connect the unit, start the sequence, and get a clear result they can act on.
A gate, not a spot check
The cabinet became the release gate for every shipped Gateway. A failed serial number is blocked in the ERP system until the unit has been repaired and passes a new test. Production staff can run that process without an engineer standing next to the station.
2.What the test covers
The 80-plus-step sequence
The test begins by scanning the unit and retrieving its serial number, MAC address, and model from the ERP system. It then powers the Gateway, flashes the target firmware, and starts working through more than 80 checks.
The sequence exercises digital I/O loopback, both CAN interfaces, internal voltages, fieldbus communication, buttons, LEDs, and the display. Each step has an explicit timeout and must produce a defined result before the sequence moves on.
Faults that visual inspection misses
A board can look fine and still fail once signals and power start moving through it. The cabinet tests the assembled Gateway while it is running, which has exposed faults that were not visible during inspection.
- Connectors with incomplete solder joints
- Buttons or LEDs that do not respond
- Internal voltage measurements outside their allowed range
Recover when it makes sense, stop when it does not
Not every failed step means the Gateway is defective. A communication timeout may be temporary, a connector may not be seated all the way, or a required part may not have been fitted. The operator can correct those problems and retry the affected step instead of restarting a five-to-six-minute sequence.
An invalid internal voltage is different. That can indicate a real hardware fault, so the cabinet stops the test and generates a failure report. The report records the failed step and its measured value, which gives production staff something concrete to diagnose.
Traceability in the ERP system
Each test result is written back to the unit in the ERP system. A passing unit receives a PDF report, and the same report can be sent to the customer when requested. A failed unit stays blocked until it is fixed and passes its retest.
- Serial number, MAC address, and model
- Test timestamp and operator ID
- Measured values and flashed firmware version
- Failed step and measured value when a test stops
3.The parts that fought back
Getting the Beckhoff rack to behave
On paper, configuring EtherCAT modules in a TwinCAT PLC rack sounds like ordinary setup work. In practice, the Beckhoff software and ecosystem have a steep learning curve, especially when several different modules have to work together in one application. A small configuration mistake can surface as poor or misleading error feedback, and the documentation often presents many possible fixes without making it clear which one applies to the actual problem.
This was not a quick bring-up task. It took months to configure the modules, understand their individual behavior, and then make their functions work together reliably inside the test sequence. The EL6751 CAN terminal alone also had to be multiplexed through relays so one terminal could test both CAN ports on the Gateway. Most of the difficulty was not writing a PLC function. It was finding out why a correctly-looking rack still refused to behave like one system.
One interface for German operators and an English-speaking developer
The production operators speak German, while I work in English. So internationalization, i.e. keeping every operator-facing text available in both languages, was part of the frontend architecture rather than something added at the end.
Commands, buttons, progress messages, measurement labels, and failure feedback can switch language while the application is running. There is no reload and no separate language download. The current test state stays in place, which matters when an operator changes language in the middle of diagnosing a failed unit.
Using AI where my experience was thinner
Frontend development is not my main specialization. I used AI-assisted development to move faster through the parts where my experience was thinner, especially the visual implementation and interaction details, while I kept control of the application structure, test workflow, state, API contract, and final behavior.
That made it practical for me to build an interface that was not merely functional, but clear and pleasant for production staff to use every day. AI filled gaps and shortened the feedback loop. It did not decide how the tester worked or replace the engineering needed to connect the interface to the real cabinet.
4.System architecture
Beckhoff hardware and PLC
The cabinet runs TwinCAT 3 on a Beckhoff CX7080 embedded PC. Its EtherCAT terminals match the Gateway's I/O well enough that the cabinet can drive outputs, read electrical values, and test both industrial communication and the ordinary physical controls.
The following terminals were used: EL2008 for digital outputs, EL3174 for voltage measurement, EL3692 for resistance measurement, EL6751 for CAN transmit and receive, and EL6631 for PROFINET and PROFIsafe. Relays multiplex the EL6751 across the Gateway's two CAN ports. The PLC also controls a digital power supply over RS-232.
.NET backend and sequence engine
The backend runs on .NET 8 and exposes a REST API to the operator interface. A sequence engine owns the test lifecycle: it executes the steps, manages hardware connections, handles retries and hard stops, generates the reports, and records the final result.
The step layer translates each test action into concrete PLC or serial work. It communicates with TwinCAT over ADS and with the Gateway over a 460800 baud serial link. A stats manager keeps the live measurements in one place so the API, operator interface, and report generator all work from the same values.
Vue 3 operator interface
The frontend follows the order in which the operator actually works: connect the station, select a test method, identify the device, run the sequence, and inspect the result. Configuration that is not part of the normal production flow stays on a separate Settings screen.
Five stores hold connection state, sequence progress, device measurements, settings, and report data. The frontend polls the backend through one API service, opens reports inside the application, and can switch all operator-facing text between German and English at runtime. Quite frankly, production staff should not have to understand the software stack to test a Gateway, and the interface was built around that constraint.
5.Proving the tester
Known values and signals
A production tester is only useful if its own result can be trusted. The cabinet was checked against known electrical values and known signals so that its measurements and interface tests could be compared with expected results.
Known faulty boards
The sequence was also run against faulty boards. This verified the less convenient half of the test: that a real defect reaches the correct failed step, records the useful measurement, and prevents the serial number from being released in ERP.
The production result
Every Gateway shipped to a customer now passes through the cabinet. The full sequence takes five to six minutes, and production staff can run it without engineering support. What started as a planned requirement for serial production is now the point where a manufactured Gateway becomes a shippable one.