How to Connect Old Factory Machines to the Cloud

A common misconception about Industry 4.0 is that it requires new machines. It does not. Most of the value in factory digitalisation comes from making existing equipment visible, and most existing equipment can be read without being replaced or modified.

This is the practical route from a machine that produces no data to a dashboard on your phone, including the parts that are more awkward than they are usually presented.

Step 1: Find out what the machine already knows

Before specifying any sensors, establish what the machine already measures internally. A machine with a PLC or a dedicated controller is usually monitoring far more than it displays — temperatures, pressures, cycle counts, fault codes, run states — and holding them in registers.

What you are looking for is a communication port. In industrial equipment, the most common is RS-485 running Modbus RTU. Check the machine's manual, the controller model number, and the terminal block for A/B or D+/D− terminals. Where that port exists, the data is already there and the work is reading it rather than measuring it again.

This distinction matters commercially. Reading existing registers is quick. Retrofitting sensors for values the machine already measures internally is duplicated effort and duplicated cost.

Step 2: Understand what RS-485 and Modbus actually are

These two terms are frequently used interchangeably and are not the same thing.

The practical consequence is that several machines can share a single RS-485 bus, each at its own Modbus address, and one gateway can poll all of them. For a production line this is considerably cheaper than one gateway per machine.

Step 3: Map the registers

This is the step that consumes the most time and is almost never mentioned in vendor material. Knowing a controller exposes Modbus is not the same as knowing which register holds which value, in what unit, at what scaling factor.

Sometimes the manufacturer publishes a register map. Sometimes the map is incomplete, or describes a different firmware revision, or the machine has been modified since commissioning. In those cases, mapping is done empirically: read the registers, change a known condition on the machine, and observe which value moves.

Budget real time for this on any machine without reliable documentation. It is the difference between a clean deployment and a dashboard displaying confidently wrong numbers — which is worse than no dashboard at all.

Step 4: Choose the edge gateway

The gateway sits on the factory floor between machines and the internet. It polls the machines, buffers readings, and forwards them to the cloud. Its requirements are unglamorous:

• Local storage. Enough to hold readings through an extended internet outage and re-transmit afterwards, so the historical record stays continuous.
• Industrial tolerance. Factory floors are hot, dusty, and electrically noisy. Consumer hardware in a plastic box does not survive them.
• Reliable power handling. It must come back up cleanly and unattended after a power interruption.
• Remote management. You will need to change polling configuration without sending someone to site.

The buffering requirement is the one people underestimate. Factory internet is not office internet, and a monitoring system that loses data during an outage will have gaps precisely around the events worth investigating.

Step 5: Decide what actually goes to the cloud

You do not need to transmit everything a machine exposes. Transmitting everything produces storage cost, dashboard clutter, and no additional insight.

A workable rule: transmit what you would act on. Run state, key process variables, energy, fault codes, and anything feeding an alert. Values nobody will ever look at can stay in the machine, and can be added later if a question arises that needs them.

For most industrial applications, one-minute logging is the right resolution — fine enough to catch cycling and transient faults, coarse enough to store for years.

Step 6: Build the layer people actually use

Everything above produces a database. A database is not a solution. What makes the deployment worthwhile is the layer on top: a dashboard answering the specific questions the operations team has, and alerts that reach the responsible person on their phone.

1. ⚙️MachineRS-485 / sensors
2. →
3. 📡Edge GatewayBuffer & forward
4. →
5. ☁️CloudStore & process
6. →
7. 📊DashboardCharts & reports
8. →
9. 📱MobileAlerts

The most common failure of factory IoT projects is not technical. It is a successful data pipeline feeding a generic dashboard that nobody opens after the first fortnight, because it displays everything and answers nothing.

What this realistically involves

A focused deployment across a handful of machines is typically about two weeks from survey to live dashboard. Threshold tuning deliberately comes afterwards: thresholds set before you know what normal looks like generate false alarms, and an alerting system nobody trusts is worse than none.

Where this usually goes wrong

• Starting too broad. Connecting forty machines at once, before anyone knows which data matters. Start with the machines whose failure hurts most.
• Skipping the gateway. Sending sensor data straight to the cloud works until the connection drops, which it will.
• Trusting undocumented register maps. A wrong scaling factor produces plausible numbers that are entirely wrong, and nobody notices for months.
• Building a dashboard before asking what decision it supports. A dashboard that answers no question gets no visitors.