Every guide in this series so far has assumed a control worth talking to, a CNC, a PLC, something running firmware with an address you can read. A real plant floor also has the other kind of machine, a bench grinder, a shop vac, a hydraulic press from before anyone put a chip in anything, a compressor. Nothing to browse a tag on, nothing with an IP address, sometimes nothing electronic at all beyond a motor and a contactor. Those machines are not a gap in what you can track. They’re a different, well-worn path.
The question these machines answer is smaller, and that’s fine
A CNC’s control can tell you the active program, the spindle load, an alarm code, a part count straight from the machine tool’s own counter. None of that exists to ask for on a bench grinder. What you can get, reliably, is smaller: is it running, is it idle, is it off. That’s a narrower question than a FOCAS feed answers, and it’s still the question that drives the numbers that matter most on a shop floor. Availability, downtime, and a meaningful chunk of OEE are built on exactly that on/off signal, whether it comes from a control’s run-state bit or a sensor reading current draw.
How the read actually works
A clamp-on current sensor goes around one of the machine’s own power leads, no rewiring of the machine’s circuit, nothing added to its own panel. It measures how much current the motor is drawing, and current draw maps cleanly onto machine state for almost anything with a motor in it, near zero when it’s off, a baseline level when it’s idling, a clear step up when it’s actually cutting, pumping, or running under load. The sensor wires to one of the gateway’s own analog input terminals, and Spall does the rest from there.
Three ways in
Current sensing is the common case, but it’s not the only sensed path. A machine with a stack light or a simple dry contact, a limit switch, a door interlock, a cycle-complete relay, can wire straight into the gateway’s isolated digital inputs instead, a cleaner on/off signal than current draw when one’s already there for the taking. And a machine that passes discrete parts, a stamping press, a bagger, a fill line, can drive a cycle counter off either a digital pulse or an analog threshold crossing, counted on a fast local loop at the gateway itself rather than a slow poll cycle that would miss a beam-break pulse a few tens of milliseconds wide. All three feed the same downstream numbers, availability, downtime, and a genuine part count where a counting signal exists.
Calibration is the step that actually matters
A sensed machine’s thresholds start as reasonable defaults, not proven ones, and the setup isn’t done until you’ve run the machine through a real cycle and watched the reading track it, off through idle through running and back, adjusting the boundary if it flags idle as running or never leaves off while the machine’s clearly on. Skip that step and you have a plausible-looking number that hasn’t actually been checked against reality, which is worse than a visible gap, because it looks trustworthy without having earned it.
That’s why a sensed machine’s run-state reading carries a visible note until it’s been calibrated, and even after calibration it keeps a permanent label: state inferred from power draw. That’s not a warning to make go away, it’s a fact about where the number came from, the same way a scheduled job and a floor-logged one both show up labeled by origin rather than blended together as if they were the same thing.
What it doesn’t give you, said plainly
A sensed machine’s data is real, but it’s not the same shape as a native control feed. There’s no alarm code, because there’s nothing generating one. There’s no active program name, because current draw doesn’t know what job is running, that has to come from a person or a mapped tag if the machine has any signal at all worth reading for it. And a part count only exists where there’s a genuine countable event, current draw alone tells you running, not how many. If any of that matters for a specific machine, it’s worth a real conversation about what’s actually achievable rather than assuming the sensed path covers everything a controller connection would.
When it’s the right call, on its own merits
It’s tempting to treat sensed monitoring as what you settle for when a real connection isn’t available, and sometimes that’s exactly the situation. But it’s also legitimately the right first move on a machine with a controller you haven’t gotten around to integrating yet, or one where the controller’s data isn’t worth the setup effort for what you’d actually use. A ten minute clamp install that gives you real availability today beats a FOCAS integration that’s still waiting on network access from IT three weeks from now, and the same clamp doubles as a real cost number once a rate’s attached to it, see energy monitoring as a first win. Nothing stops you from upgrading a sensed machine to a real controller feed later if the case for it grows, the historical data doesn’t get thrown away, it just gets a better source going forward.
Quick recap
- No PLC, no problem, current sensing, digital contacts, and cycle counting cover machines with nothing to browse a tag on
- The question answered is narrower, off/idle/running, but that’s the signal availability and OEE are actually built on
- Calibrate against a real cycle before trusting the thresholds, that step is the whole point, not a formality
- A sensed machine’s run state stays labeled as inferred from power draw permanently, from setup onward
- No alarm codes, no program name, no part count without a real countable event, know the limit before you count on more
- Sensed is a legitimate first move on its own merits, and nothing stops an upgrade to a real controller feed later