A plant with one engineer who knows ladder logic and a controller with an open Ethernet port can build a working PLC-to-spreadsheet setup in a weekend. Pull a handful of tags off the PLC on a timer, drop them into a database or a shared spreadsheet, put a chart on top. It works. The question that actually decides build versus buy isn’t whether it works on one machine. It’s what happens as that one machine becomes three, then ten, and whether the person who built it is still around to fix it when a firmware update breaks the tag map at two in the morning, unnoticed until a report looks wrong.
What building it actually takes
A real build starts with a tag list: run state, cycle count, alarm codes, whatever the control exposes and the project needs. Someone writes a poller, a script or a small service that connects to the controller on a schedule and reads those tags, usually over the same protocol the control already speaks, Modbus, an OPC server, a vendor-specific driver. That data lands somewhere, a spreadsheet if the ambition is small, a proper database if it’s not. Then someone builds the part that turns raw readings into something useful: a run state becomes an uptime percentage, a stopped state that lasts long enough becomes a downtime event, a cycle count becomes a rate.
None of that is exotic engineering. A competent controls engineer or an industrial software developer can build a working version for one or two machines without much trouble. What’s easy to underestimate is everything downstream of the first working version: what happens when the connection drops for an hour and the poller needs to know it missed data instead of recording an unflagged flat line, what happens when two machines report cycle counts on different scales, what happens when someone needs the reason a machine was down, beyond the fact that it was.
What breaks around machine ten
One or two machines with the same controller from the same vendor is a manageable build. The trouble starts when the tenth machine isn’t the same as the first. A different control generation exposes tags under different names. An older machine has no Ethernet port at all and needs a serial connection nobody accounted for. A newer one changes its tag layout after a firmware update with no warning, and the poller keeps running without erroring out. It just starts recording numbers that no longer mean what they used to. Nobody notices until a report looks wrong weeks later, and by then the bad data has already fed into a decision or two.
Scale changes the shape of the problem in another way too. A spreadsheet that worked fine for one machine’s worth of readings becomes unusable once ten machines are writing to it around the clock, and the natural next step, a real database with a real schema, is itself a project, not a checkbox. Add a second shift, a third, an informal schedule that doesn’t match any of them cleanly, and the logic that turns raw readings into a shift comparison has to account for all of it correctly, every time, or the number it produces stops meaning what a supervisor assumes it means.
The part that’s easy to skip: reason codes and context
A tag reading tells you a machine stopped. It doesn’t tell you why, and why is most of what a plant manager actually needs to act on a stop. Building a reason-code layer, a way for an operator to say “tooling change” or “waiting on material” against a specific stop, and having that note land connected to the right event, is a second system on top of the first one, with its own interface, its own training, its own discipline problem when operators stop bothering to log it. A tag poller answers “was it running.” A useful monitoring system answers “was it running, and if not, why not, in a form someone can act on.” The gap between those two is most of the real engineering effort, and it’s the part a weekend build almost never gets to.
That gap tends to widen with every machine added, not stay fixed. A reason-code screen built for one press has to get rebuilt, or at least reconfigured, for a stamping line with a different failure vocabulary, a different set of tooling names, a different shift pattern. None of that is hard engineering in isolation. It’s a steady accumulation of small, specific work that a weekend project’s author rarely budgeted time for, because the first working chart made the project feel finished long before the reason-code layer, the shift logic, and the reconnect handling actually were.
What you keep either way
None of this is an argument that building is always wrong. A plant with one controls engineer, a handful of identical machines, and no near-term plan to scale past that can run a homegrown setup for years without much trouble. The tag knowledge that engineer builds along the way, which signals matter, what a stop actually looks like on a specific control, has value no matter which path a plant eventually takes. That knowledge is exactly what a good vendor evaluation draws on too: an engineer who already knows the tag map for a plant’s machines is the person best positioned to check whether a vendor’s connector reads the same things correctly.
What tends to force the decision isn’t the first machine. It’s the tenth, or the second control brand, or the day the person who built it leaves and nobody else can safely touch the poller. At that point the real comparison isn’t build versus buy in the abstract. It’s the cost of finishing the parts a weekend build never got to, reason codes, shift handling, reconnect logic, a tag map for every distinct control on the floor, against the cost of a system that already did that work across a wide range of controls and gets improved for every customer at once instead of one plant’s spare time.
There’s also a plain question worth asking before either path: who actually owns this in three years. A build owned by one engineer is a single point of failure no matter how good the code is, and that risk doesn’t show up on day one. It shows up the day that person takes a new job. A bought system carries a different version of the same risk, a vendor that slows down, changes direction, or gets harder to reach, which is exactly why data portability, a real export, a live feed, an API, matters as much as the initial connection does. Either path needs an answer to what happens if the person or company behind this disappears, beyond whether it works today.
Quick recap
- A homegrown PLC-to-spreadsheet setup is a real weekend project for one or two machines on one control type
- What breaks first is a mixed fleet, a different control generation with a different tag map, or a firmware update nobody caught
- A spreadsheet doesn’t scale past a handful of machines, and the database that replaces it is its own project
- Reason codes and context, the why behind a stop beyond the fact of it, are usually the real engineering effort, not the tag poll
- A build that works for years is a reasonable choice when the fleet stays small and someone owns it long term
- The tag knowledge from a build has value regardless of the path, exactly what a good vendor evaluation draws on