Monitor
Machine monitoring systems that tell you why, not just how much
Counting output is the easy half. The value is in knowing what the machine was doing during the hours it was not producing — and having that answer while the shift is still running, rather than in a report three days later that nobody can act on.
The problem
Everyone knows the plant loses time. Nobody can say where.
Ask for last month's downtime by cause and you get an estimate. Ask which machine is the real constraint and you get an opinion. The data to answer both exists on the shop floor and is thrown away every shift, because capturing it is currently somebody's manual job on top of their real one.
- 01
Downtime is logged on paper, if at all, and only for long stops
- 02
Micro-stops are invisible even though they add up to more than the big ones
- 03
OEE is calculated monthly in a spreadsheet from numbers nobody fully trusts
- 04
Different departments quote different production figures for the same day
- 05
By the time a problem shows up in a report, the shift that caused it is long gone
What we build
Concrete deliverables
Nouns, not adjectives. This is what actually gets handed over.
- 01
Automatic production counting
Counts taken from the PLC or from retrofitted sensors, attributed to machine, shift, operator and product — with no manual entry step.
- 02
Automatic downtime detection
Stops detected from machine state in real time, classified as planned, unplanned or micro-stop, with duration measured rather than estimated.
- 03
Operator reason-code capture
A short prompt on an HMI or tablet at the moment of the stop. Two taps, under five seconds — because anything longer will not be used consistently.
- 04
OEE with visible components
Availability, performance and quality shown separately as well as combined, with the calculation documented so the number can be defended.
- 05
Real-time floor displays and alerts
A shop-floor screen showing current state against target, plus escalation alerts when a stop exceeds a threshold.
- 06
Shift, daily and management reporting
Automatic reports at shift end, Pareto analysis of stop causes, and trend views by machine, line, product and shift.
How it works
The technical path, step by step
Where the engineering decisions actually get made.
- 01
Detect state
Machine state — running, idle, stopped, faulted, changeover — is derived continuously from PLC signals, motor current or a retrofitted sensor.
- 02
Count and classify
Good and rejected counts are attributed to the current product and shift; every state change is timestamped at the edge.
- 03
Capture the reason
When a stop passes a threshold, the operator is prompted for a reason from a short, plant-specific list. Unclassified stops are flagged, not silently ignored.
- 04
Calculate honestly
OEE is computed from measured values with the assumptions written down — ideal cycle time, planned production time, what counts as planned downtime.
- 05
Show it while it matters
Live on the floor, live on a phone, and summarised in shift and daily reports that arrive without anyone assembling them.
Protocols & technologies
Specifics, because vague answers cost you money later
Chosen per site according to what is installed, not according to what we would prefer to work with.
| Technology | Where it is used | Engineering note |
|---|---|---|
| PLC tag read | Cycle counts, machine state, fault codes | The cleanest source when a controller exists. |
| Motor current / CT | Run/stop and load on machines with no controller | Surprisingly accurate for state detection and requires no machine modification. |
| Proximity / photoelectric sensor | Physical piece counting | The retrofit standard where no electronic count is available. |
| Energy meter (Modbus) | Consumption per machine and per unit produced | Also a reliable secondary indicator of machine state. |
| HMI / tablet input | Reason codes, changeover, quality events | The only part that needs a human; designed to take under five seconds. |
| MQTT / time-series database | Transport and storage | Report-by-exception keeps volume low and history long. |
| REST API | Feeding ERP, MES and BI tools | So the monitoring system does not become another island. |
Brownfield
Monitoring is the easiest thing to retrofit
Machine monitoring is usually the first project we do with a plant, because it is non-intrusive, quick to prove and immediately useful. Reading state from an existing PLC changes nothing. Where there is no PLC, a current transformer clamped around the motor feed and a sensor on the output are enough to get real state and real counts — installable in a short window, on almost any machine, at almost any age.
Works with
- Machines with a PLC of any brand or vintage
- Machines with no controller at all
- Mixed lines where each machine is a different make
- Plants with no shop-floor network — we can add one
- Existing SCADA systems, used as a data source rather than replaced
Use cases
What people actually ask us for
Each one is a situation followed by the outcome it produces — not a feature list.
Finding the real constraint
NowThe assumed bottleneck is based on opinion.
AfterMeasured state across every machine shows where time is actually lost, which is frequently not where people expected.
Micro-stop visibility
NowShort stops are never recorded, but there are hundreds a shift.
AfterEvery stop measured, with the cumulative effect of short stops made visible for the first time.
Shift comparison
NowOne shift consistently produces less and nobody can say why.
AfterLike-for-like comparison by shift, product and machine, with stop causes attached.
Changeover reduction
NowChangeover duration is unknown and highly variable.
AfterChangeovers timed automatically, with variation and its causes made visible.
Customer and audit evidence
NowA customer asks for production and quality evidence.
AfterAn automatically maintained record rather than a reconstruction from memory.
Energy per unit produced
NowEnergy is a fixed cost that nobody attributes.
AfterConsumption per machine, per shift and per unit — which usually surfaces at least one machine running when it should not be.
Implementation
How a project runs
Eight stages, each producing something you own. Full detail on the process page.
- 01
Discover
1–2 conversations
- 02
Audit
1–3 days on site
- 03
Design
1–2 weeks
- 04
Engineer
2–8 weeks per phase
- 05
Integrate
1–2 weeks
- 06
Deploy
Your shutdown window
- 07
Monitor
First 4–6 weeks
- 08
Optimise
Ongoing, if you want it
Mixed-vendor machine monitoring rig
Three PLC brands and one machine with no controller at all, read through one gateway and normalised into a single tag model — the situation almost every Indian plant is actually in.
Read the write-upQuestions
Machine Monitoring — common questions
Do we need to add sensors to every machine?
Only where the machine cannot tell you anything itself. If there is a PLC, we usually read what it already knows. Where there is no controller, one current transformer and one counting sensor per machine is typically enough for real state and real counts.
Will operators actually enter downtime reasons?
They will if it takes under five seconds and the list is short and written in their words. They will not if it is a thirty-item dropdown on a laptop in the supervisor's office. We design the reason list with the people who will use it, keep it under about a dozen top-level options, and review it after a month because the first list is never quite right.
How accurate is OEE from this system?
The measured components — availability and performance — are accurate to the resolution of the machine signals, typically well under a second. Quality depends on where reject data comes from; if that is still manual, we say so and show it separately rather than burying it in a single number. We also document every assumption, because an OEE figure whose basis is unclear will be argued with rather than acted on.
Can it work without internet at the plant?
Yes. The whole system can run on-premises with floor displays and dashboards served locally. Internet is only needed if you want access from outside the plant, and even then only the gateway requires outbound connectivity.
How long before we see something useful?
A pilot on a few machines typically produces usable data within the first full week of running. The first month is usually spent discovering that some assumptions about the process were wrong, which is itself the most valuable early output.
Can this integrate with our ERP?
Yes. Production counts, downtime and OEE are exposed through an API and can be pushed into ERP or MES on a schedule or on events. We treat that integration as part of the design rather than as a later add-on, because retrofitting it afterwards is what creates the silos in the first place.
Start with one line
Pick your most problematic line. We will scope a monitoring pilot for it and tell you honestly what it will and will not reveal.