Building one machine takes two things: control logic and an operator screen. The logic is the PLC’s job, the screen is the HMI’s. Normally the two are built in separate tools, with the addresses matched up by hand.

Senbrix and Senvas cover those two halves, and both are built by talking to an AI. This post covers that way of working, and how the two halves meet.

The PLC and HMI follow the same five stages

The AI-assisted workflow flows the same way in both products.

Interview → Design → Plan → Implement → Verify

The AI sits inside the editor, gets a confirmation at each stage, and only then moves on. Our part is mostly saying “here is what I want to do.”

The interview stage carries more weight than you would expect. Explaining something out loud makes the spec grow on its own. The arcade cabinet started out as “one round with a toggle switch,” turned into an analog lever during the interview, and ended up as ten rounds plus a leaderboard.

Getting a confirmation at each stage is the important part. Building the whole thing first and then asking “is this right?” makes undoing a wrong turn expensive.

The PLC side - writing ladder

Sequence control and interlocks are written in ladder, and written by name rather than by address — St30 instead of M33, BtnPlay instead of P0. With a name and a description attached, it reads better for a person, and in a conversation with the AI a phrase like “while pouring” carries through as it is.

The things that are awkward in ladder — shuffling cards, tallying a score — are written in C#. Ladder and C# look at the same memory and wake each other with handshake bits.

Field I/O is expanded with add-on boards. A single CAN pair carries analog input (AD-4), analog output (DA-4), and digital I/O (IO-8).

The HMI side - drawing screens

HMI screens are drawn in Designer and run in Runtime. Drag and drop works, and screens and logic can also be built through a conversation, with the AI connected over MCP. Not having to start from a blank screen makes a real difference in practice.

Finished screens are deployed to the device through the management launcher, and the screen can be viewed — and even touched — remotely.

Where the two meet — a shared Modbus TCP address space

The PLC and the HMI look at the same address space. The HMI reads the PLC’s D area over Modbus TCP, and commands are written into a designated range.

One principle matters in this structure. Keep the source of a decision in one place — the values live in the PLC, and the HMI only reads them and draws them. Then the screen and the record cannot disagree. It works the same way on equipment as it does in a game.

Verification happened on an arcade cabinet

Validating the PLC and the HMI becomes the question the moment they are built: what do you validate them on? Putting it into real equipment is the most accurate answer, and also the riskiest one with the fewest chances to try.

So we built an arcade cabinet. In some respects a game is more demanding than a machine — a person works it by hand and watches it with their eyes, so any lag is felt immediately, analog is not optional, several kinds of I/O run in one program at once, and leaving it powered for days brings cumulative faults to the surface.

Four games — beer pouring, blackjack, a shooter, and fishing — run out of a single project. The whole build is written up in a seven-part series on the beer game cabinet.

Along the way we caught real problems: the non-linearity of the analog output, the screen stutter that the communication update interval produced, and the move of the entire address map after the expansion board address space ran short. Without the cabinet, those are problems we would have met on a customer’s site.

Keeping the values in the PLC and letting the HMI only read and draw them is what makes it impossible for the screen and the record to disagree.

Contact