A machine monitoring system is only as good as its record.
What the four layers of a monitoring system actually do, how each machine on your floor gets connected, and where these systems genuinely fall short.
A machine monitoring system answers one question continuously: what is every machine on this floor doing right now, and what was it doing at 14:20 last Tuesday. Everything else — OEE, downtime Paretos, predictive alerts, MIS packs — is arithmetic performed on top of that record. If the underlying record is incomplete or arrives late, no amount of dashboard work rescues it.
That is worth stating plainly because most monitoring projects fail at the acquisition layer rather than the presentation layer. A plant buys a system, discovers that half its machines cannot be read, fills the gap with operator data entry, and within two months the operators have stopped entering. The system still exists; the record does not.
Four layers, and only one of them is the dashboard.
Getting the signal
Reading machine state from a controller over the network, from a PLC over Modbus or OPC-UA, or from hardwired I/O where no controller exists. This layer determines what the whole system can ever know.
Moving it reliably
Buffering when the network drops, timestamping at source so a reconnection does not scramble the timeline, and never losing a cycle because a switch rebooted.
Keeping it queryable
A time-series record that stays fast when it holds three years of second-level data across sixty machines, and that can be exported without a vendor's help.
Making it usable
Dashboards, TV screens, shift reports and alerts. The visible part, and the part most vendors demonstrate first.
Three routes, chosen per machine.
Machines with a modern CNC control — FANUC, Siemens SINUMERIK, Mitsubishi, Haas — are read over your existing network using the control's own interface. Nothing is installed on the control, no parameter is modified, and the machine does not need to stop for it. This is the majority of machines on most machining floors and needs no added hardware.
Machines with a PLC but no CNC control — presses with Allen-Bradley logic, furnaces with a temperature controller, packing lines — are read over Modbus RTU, Modbus TCP or OPC-UA by nominating the specific tags or registers that represent machine state and counts.
Machines with neither are wired to a MachineWise Gateway using discrete signals: the contactor that closes when the spindle runs, the stack light, an existing counter output, a proximity sensor on a ram. This is how equipment older than the software industry ends up on the same dashboard as a machine bought last year.
Networked CNC controls
Read over the plant LAN using the control's documented interface. Typically live the same day, without stopping production.
PLC-equipped equipment
Modbus or OPC-UA reads against nominated tags. Requires a network path to the PLC and agreement on which tags to expose.
Everything else
Conventional, hydraulic and pre-electronic machines. An afternoon of wiring per machine, scheduled around a planned stop.
What a monitoring system cannot do for you.
Fix anything by itself
Measurement surfaces losses. Recovering them takes a supervisor who reads the Pareto on Monday and changes something. Plants that treat installation as the deliverable get dashboards and no improvement.
Invent data the machine does not expose
If a control does not publish spindle load, no software can display it. During a pilot we confirm what your specific machines expose rather than promising a feature list.
Replace reason codes with magic
A system can detect that a machine stopped and for how long. Why it stopped still needs a human at the machine — which is why reason capture has to take two taps, not fifteen fields.
Where each part runs.
MachineWise runs on a server inside your plant. Acquisition services poll each machine on its own interval, write to a local time-series store, and serve dashboards over your LAN. Nothing about normal operation depends on an internet connection: if the link to the outside world drops, machines keep being recorded, TV screens keep updating and local alerts keep firing. What stops is remote access and outbound WhatsApp or email notification.
For groups running several plants, each site keeps its own server and its own data, with a rollup view that reads from them. That structure exists because comparing plants only works when every plant computes the same KPI the same way — which is easier to guarantee when one platform defines it than when three plants each maintain a spreadsheet.
How the number gets built.
Take a 30-machine machining unit running two shifts, 26 days a month. Management believes utilisation is around 70%. The first fortnight of measurement usually shows something lower, and — more usefully — shows the shape of the gap: a cluster of machines losing the first 40 minutes of every shift, one bottleneck machine waiting on material twice a day, and a long tail of stops under six minutes that nobody had ever logged.
The financial argument follows from your own machine-hour rate rather than ours. If the measured loss on that floor is two hours per machine per day and the absorbed rate is what your costing sheet already uses for quoting, the annual figure lands in the ₹1–2 crore band for a plant of that size — large enough that the first question becomes which losses are structural and which are simply unrecorded. The downtime cost calculator does this arithmetic with your numbers, in your browser.
The point of the example is not the total. It is that before measurement the plant had one number it half-believed, and after measurement it had a ranked list of causes with hours against each.
What the first month looks like.
A pilot covers two machines for thirty days at no cost. We connect them — software-first where the control allows it — confirm what those specific machines expose, and let the system record. You get live dashboards from day one: there is no shift calendar to build and no production schedule to load before the data becomes useful.
At the end of the thirty days you have a measured downtime and OEE report for those machines and an ROI model built on your rates rather than assumptions. If it does not persuade you, the report is yours to keep. If it does, the rollout usually goes bottleneck machines first, then the rest of the cell, then the plant — because the argument for machine eleven is much easier to make once machines one and two have paid for themselves.
Connect two machines
Software-first where possible. No production stoppage on networked controls; a scheduled slot for Gateway installs.
Record everything
Cycle states, stop durations, reasons captured at the machine, counts and OEE — with shift summaries on WhatsApp so the floor sees it daily.
Decide on evidence
A measured report for your machines and an ROI model at your machine-hour rate. No obligation either way.