What to do with a machine that reports nothing
Three options, and one of them is admitting there will be no telemetry. When each applies, and why an external node is usually the right answer.
A practical question that comes up on every site: you are looking at a machine with no network port, no documentation on data exchange, and no sign that it was ever meant to report on itself.
There are three options.
Option one: the data is there, nobody asked
Check this first, because it works more often than people expect.
The machine may have a serial service port, a fieldbus to its internal controller, or an operator panel connector that carries perfectly readable traffic. The controller inside often speaks a common protocol. It is simply not brought out and not described in the user manual.
Device discovery over serial interfaces exists for exactly this: poll and see what answers.
The limitation: connecting to a service port on running equipment needs approval. And polling must be rate-limited. Dense polling on a shared bus interferes with the machine’s normal traffic.
Option two: observable signals
There is no data exchange, but there are physical signs of operation: contactor state, motor current, limit switch position, pressure present, an output sensor firing.
An external node reads these signals directly and turns them into telemetry. The machine itself is not touched.
This is usually the right answer, and for reasons that have nothing to do with engineering. It needs no consent from the manufacturer, it does not void the warranty, and it does not change how the machine runs. If the node fails, the machine keeps working exactly as it did before the node was installed.
That property decides whether you will be allowed to install anything on a running production floor at all.
Option three: say it will not work
Nothing useful is observable, and interfering with the machine is unacceptable or not worth it.
Then the honest answer is that there will be no telemetry for this equipment, and a separate decision is needed: live without it, plan a retrofit, or replace the machine for other reasons.
A list of equipment that cannot be connected is part of the first stage’s output, not a sign of failure. A client with that list can plan. A client who was promised “we will connect everything” learns the truth later, and at a higher price.
What not to do
Get inside the machine for the sake of complete data. The temptation to get more by tapping into the control circuit is strong, and it is the main reason projects like this get stopped.
The difference between an external observer and interference with control is the difference between a project that gets approved and a project that gets banned.
What even a minimal signal gives you
Facts. Whether the machine ran during the shift or stood idle, how many times it started, how long it was under load.
It looks too simple to be useful. In practice it is the most valuable part of the first stage, because until then this data existed as logs filled in at the end of a shift, and those logs did not match reality.
Precision is not the point here. Continuity is, along with having no human in the collection chain.
Order of work
Discovery across every available interface. Sorting equipment into the three categories above. Describing device classes in the catalogue and verifying them on live devices. External nodes where needed. Only then a conversation about what to do with the data.
The reverse order, starting with the choice of a visualisation system, is more common. It explains why so many sites have beautiful dashboards with two working indicators.