Watch
A first in the micro-PLC world: the EQSP32 has scriptable test forcing built in. Over one USB cable you inject any sensor value and read back every output, while your program runs on the actual controller. Every state, fault and timer is exercised before the plant is wired.
Run the tests by hand, from a script, or hand the whole job to an AI agent. Either way, the hardware decides what passes.
Tested on the controller that ships, not in a simulation.
Every PLC programmer has forced an input from a laptop to see how the logic reacts. The EQSP32 takes that idea to its conclusion: every input can be forced over USB and every output read back, by command, so a whole test sequence can be written down once and replayed on demand. Think of it as a FAT (Factory Acceptance Test) procedure that runs itself: step, forced value, expected result, actual result, pass or fail.
The control logic is not modified and does not know it is under test. The same program runs on the same processor as in production. Only the sensors and actuators are replaced by a wire. It is a bench facility for a test build, not an override on a running plant.
This is called Hardware-in-the-Loop (HIL). It is routine for aerospace and automotive controllers, and until now virtually unheard of on a micro-PLC.
Nothing is emulated on the PC. A test that passes is a test of the binary that ships.
One call, eqsp32.beginHil(), enables HIL and one build flag turns it off for production. The logic is identical in both builds.
HIL is a standard part of the free EQSP32 library.
Bench testing and commissioning only sample a controller's behaviour: the happy path and the few faults you dare to provoke. Because any input can be forced on demand, you reach the cases that are slow, dangerous or impossible to create on a real plant.
More coverage than commissioning can safely reach, and every case repeatable on demand.
The forcing mechanism is the same in all three. What changes is who types the commands.
Type a command in a serial terminal: force an input, read an output. It is the quickest way to see how HIL works, and useful for a spot check on the bench.
Put the same commands in a test script with the expected result for each step. You get a repeatable pass/fail test that you re-run after every change. No AI is involved.
Writing a full test suite by hand is slow work. An AI agent writes the test plan and the script, runs them on the controller, and corrects the program until every check passes. You approve the specification first and review the test report at the end.
Read the app noteStart wherever you are comfortable. The tests you write by hand and the tests an agent writes run on the same hardware, the same way.
Nothing the agent writes is accepted until the real controller has been driven through every specified condition and behaved correctly. You hold the two gates: approve the specification at the start, accept the test report at the end.
A passing report records what the physical EQSP32 did, not the agent's opinion.
A wrong trip fails a hardware check whether it came from a typo, a misread setpoint or an invented detail.
Specification, test plan, commented program and test report: the set a design review asks for.
Works with any capable agent. Tell it an EQSP32 is connected to the PC and point it to the EQSP32 library on GitHub.
A real reverse-osmosis skid: ten sensors, three actuators, eight states, five fault conditions. Starting from a specification the engineer had approved, the agent delivered a controller validated on the hardware and a full test record, in effect a 31-step FAT run without the panel, in eighteen minutes. Commissioning against the real skid, the SAT, remains the next, separate step.
See the full demoThe complete build, step by step: the specification, the test plan, the HIL test run and the test report.
The same principle applies to every interface the EQSP32 speaks: exercise the real logic, observe the real traffic, and judge it from outside the controller.
A USB-to-RS485 adapter lets the test side play the opposite role. If the EQSP32 is the master, the test acts as the slave, and the reverse. It loads registers with test values, drives requests, and confirms the EQSP32 sends the right traffic and handles the replies correctly, including malformed and out-of-range responses.
The test publishes and subscribes on the same topics the EQSP32 uses, as its real peers would. It checks reconnects, retained messages, payload format, QoS and the reaction to bad messages. Any broker works, local or cloud, with no extra hardware.
Nothing on the test side carries a license fee. If you choose to use an AI agent, that is the only running cost.
The full library, with all Hardware-in-the-Loop functions, is free. HIL is a standard feature, not a paid tier.
The build toolchain is open source. No IDE license, no seat fees, no runtime charges.
A small cost per project with a frontier tool, and close to nothing with open-source models. It pays for the test writing that deadlines usually squeeze out.
The platform is free and the testing is free. The agent is optional, and costs far less than the bench time it saves.
Native Hardware-in-the-Loop is a standard feature of the EQSP32, not an add-on. Use it to test the code you write, or to hold AI-written code to the same standard.
