Legacy Machine Connectivity and Data Acquisition

Motionwell Automation does machine data acquisition in Singapore as part of the control system modernisation that is our largest line of work this year, and these projects start with one question: how to get numbers out of a machine that was never designed to give any. What that looks like on delivered equipment: our cleanroom automated test equipment series exports CSV for offline analysis and offers OPC UA connectivity for real-time SPC charting on Siemens WinCC or an equivalent SCADA platform, with control limits and alarm thresholds configurable per test parameter through the HMI. A delivered palletizing cell is sequenced on a Mitsubishi iQ-R architecture over EtherNet/IP, with the ABB IRC5 controller running robot motion independently of the cell PLC. An automated storage and retrieval crane is sequenced by a Siemens S7-1500 over Profinet to a fleet management server. On the QA laboratory automation programme, re-ordered in four consecutive years, every sample state transition is timestamped at millisecond resolution inside an Allen-Bradley PLC. Machines are designed, assembled and tested at our Woodlands Link facility, and the company has delivered more than 150 special purpose machines since 2014 under ISO 9001:2015 and bizSAFE Level 3.

The short answer, before the detail. Read as legacy machine IIoT, this is not a software purchase. It is a ladder of options ordered by how much of the machine you are allowed to touch, and every rung is a real answer for some machine. At the top you read the state and counts a modern controller already holds. Below that a gateway terminates whatever the old controller does speak and presents it upward. Below that, bolt-on sensors infer running from motor current, vibration or the stack light without altering the control system. At the bottom sits a hardwired dry contact off an existing circuit, giving running, stopped and fault and nothing else. Where you land is decided by the machine rather than by ambition, and a signal you can trust completely is worth more than a rich one you cannot, because everything derived from an untrustworthy signal gets thrown away the day somebody proves it wrong.

Where we stand, said plainly. We do not sell an IIoT platform, a historian or an analytics product, so we have no licence revenue riding on how many tags you collect. What we do is the machine end: deciding which signals exist, wiring the ones that do not, structuring them so they mean the same thing on Tuesday as on Friday, and exporting them in a form your systems read. Where the requirement is a regulated record rather than a management metric, that is a different build, described on our electronic device history record page. We are not a notified body, we do not issue CE certificates, and we are not certified under any IEC 62443 scheme.

This page takes the decisions in the order they arrive: what the machine already knows, the ladder itself, why its bottom rung is respectable, what bolt-on sensing can and cannot infer, what is worth collecting, clock discipline, edge against central, what connecting an isolated machine does to its risk profile, what the data has to feed, and when this is the wrong project. The arithmetic those signals eventually feed is in our explainer on what OEE actually measures. If you have a machine list and a controller vintage, skip ahead and talk to an engineer.

What Does the Machine Already Know Before Anyone Buys a Sensor?

More than the enquiry usually assumes, because a machine cannot sequence itself without knowing where it is.

Every interlocked motion depends on a confirmation. On our delivered electronic test equipment a magnetic reed switch on the cylinder wall tells the PLC the piston has arrived, and the controller issues the next command only once that confirmation is present. On an inspection station, a pass or fail bit plus the measured values already travel to the PLC over EtherNet/IP, PROFINET or digital I/O, because the reject gate needs them. On the delivered palletizing cell the PLC already owns a set of handshakes with the rest of the line: part ready, cell ready, buffer full, fault, reject asserted. None of that was installed for reporting. All of it is state.

So the first question is not which sensor to buy. It is which of the things the controller already computes it has no way to say out loud, and that is answered from the program and the I/O list rather than by walking the floor with a catalogue. It is the same survey we run on lab instruments, where some expose digital I/O, serial or Ethernet control a PLC can drive directly and others offer only an operator interface, described on our laboratory automation page.

The honest exception is the machine at the bottom of the range. A relay-logic machine has no cycle-active tag and no counter anything can read, so there is nothing to expose and the conversation moves straight down the ladder, or onto our machine retrofit and modernisation page.

What Is the Honest Ladder From a PLC Tag Down to a Dry Contact?

Five rungs, ordered by how much of the existing control system the work has to disturb. Fidelity falls as you go down, and cost does not follow it neatly.

One thing is worth reading out of that table. The third column shrinks much faster than the fifth grows, so the middle rungs are where a good number of legacy machines land, and bolt-on sensing is the rung that leaves the original control system untouched, which makes it the starting answer on a machine carrying qualification evidence.

The rung is a property of the machine rather than of the plant. A row of ten machines can easily need three different rungs, and forcing one scheme across all ten is how a programme gets expensive. Where the controller is being replaced for other reasons, the tag list belongs inside that scope, because the alarm structure is being rebuilt anyway. That work is on our PLC migration and upgrade page, and the drive-side signals that arrive with it, torque and following error on every move, are on our servo and drive retrofit page.

Why Is a Dry Contact at the Bottom of the Ladder Not a Failure?

Because a signal is worth what you can trust it to mean at three in the morning, and a contact off a running circuit is either true or the machine is off.

The failure mode of rich data is not that it is wrong on day one. It is that somebody proves it wrong in month nine, after a threshold drifted or a tooling change moved a baseline, and then every number derived from it since is suspect and nobody can say which months were right. A three-state signal is small enough to verify with a stopwatch in an hour, and once verified it stays verified, because there is nothing in it to drift.

That is not a theoretical position. Dry contacts to an existing line, versus recipe download from an MES or ERP, is a scope choice we price on capping, labelling and palletizing work, and it is a real decision with cost on both sides rather than a good option and a bad one. The cheap end gets chosen deliberately, for instance where the neighbouring equipment is somebody else’s and the interface has to survive their changes as well as ours.

What the bottom rung cannot do is tell you why. A total with no reason attached is enough to rank machines against each other and not enough to fix one, so a dry contact scheme is the right first purchase while you still do not know which machine to work on, and the wrong permanent answer on the machine you have decided is the constraint.

One discipline makes or breaks the cheap route. Write down what the contact means before it is wired, in a sentence maintenance would agree with, and check it against the circuit rather than the schematic. A contact off a main contactor says the machine is energised. A contact off the cycle-start latch says something much closer to producing. What that distinction does to every number downstream is the trap covered in our OEE guide.

What Can Bolt-On Sensing Infer, and Where Does It Lie?

Bolt-on sensing sits above a dry contact because it yields a count and sometimes a condition trend, and below a controller tap because everything it produces is an inference. Each method has a characteristic way of being wrong, and knowing that way is the skill.

An item easily cut from a budget is the one that makes the rest work: a baselining period where somebody stands at the machine, records what it is doing, and compares that against what the inference claimed. A day of that is worth more than a second sensor, and it is how you find out that a threshold has to be re-established after a mechanical change, which on a high-mix machine can mean per product family rather than once. Two habits keep it honest afterwards: log the raw quantity alongside the inferred state so a disputed month can be re-derived instead of argued about, and record a re-baselining as a dated event, because a step in a trend that coincides with somebody adjusting a threshold is not a process change.

Which Data Is Actually Worth Collecting?

A common failure here is not collecting too little. It is collecting everything the gateway offers because it is available and then using none of it, which buys storage cost, a slow database and an argument about which of two disagreeing counters is right. The test we apply is one sentence per signal: when this value does X, a named person does Y. If the sentence cannot be finished, the signal should be left in the machine.

The third row is worth seeing in terms of sample rate. Our GMP filling and sealing platform logs the capping torque curve for every container against a torque programmable from 0.5 to 5.0 Nm, and the delivered test equipment logs force, displacement, resistance and continuity per serial number, exported by batch for Cp/Cpk study. A curve captured across a few hundred milliseconds and a shift counter are not the same kind of data, and treating them as one stream is how a scheme ends up too slow for the process or too heavy for the network.

One more thing decides whether a per-unit measurement is worth anything. It has to carry the identity of the unit it came from, captured as it was taken rather than reconciled afterwards, which is the discipline set out on our code reading and traceability page. A measurement with no identity is a statistic. A measurement with one is evidence.

Why Does Clock Discipline Decide Whether Two Machines Can Ever Be Compared?

Because almost every number you want is a difference between two timestamps, and a difference between two clocks is not a difference between two events.

The mechanism is duller than it sounds. Real-time clocks in PLCs, HMIs and industrial PCs run independently, and left alone they separate: two devices on the same machine can be minutes apart after a year in service, which is enough to make a merged event log undefendable, and nothing forces two machines on a line to agree at all. Sync everything that produces a timestamp to one source, store in UTC and display local time, write the convention down where the next engineer will find it, and log clock adjustments as events rather than letting a correction silently rewrite a shift. The regulated version of that requirement is on our 21 CFR Part 11 and electronic records page.

Where the stamp is applied matters more than how fine it is. A timestamp written by the collector when the message arrives measures the network and the polling interval rather than the machine, and it looks perfectly plausible while being wrong by whatever the queue was doing. Stamp at the source, then let the message be as late as it likes.

Resolution follows the question rather than what the hardware can do. On the QA laboratory programme every state transition is stamped at millisecond resolution inside the controller, and not because anyone reads milliseconds: the order of two events happening close together has to be decidable afterwards, which is the difference between knowing a machine starved a downstream station and suspecting it. On a shift-level availability question, seconds are plenty. Before anything is installed, ask two machines you expect to compare what time it is. That gap is the floor on any conclusion about which one waited for the other.

What Belongs at the Edge, and What Belongs Centrally?

Two questions settle it, and neither is about processing power. Does the machine need this answer to keep running, and what does it cost to lose the data while a link is down?

The pattern already appears in delivered work. On the modular carton unloading station built for a consumer goods distribution centre, each station runs its own PLC for local machine control and exchanges data with neighbouring stations over OPC-UA, so a station keeps working when the one beside it stops. That independence is a design choice with a cost, and it is the right one where the alternative is a stoppage propagating for no physical reason. Applied to reporting, the same argument says local event storage should be sized against the longest realistic outage rather than the average one, a point made in full on our code reading and traceability page.

One caution, because it is the decision that cannot be reversed. Summarising at the machine and discarding the raw signal is cheap and often correct, and it also means a question nobody thought of in year one can never be asked of year one’s data. Decide deliberately what gets thrown away, and revisit it when the questions change.

What Changes About a Machine’s Risk the Day It Is Connected?

Its exposure changes and nothing else does, which is why the change gets underestimated. A machine that ran isolated for fifteen years was protected partly by being unreachable. Pull a cable to it and that protection is gone, while the controller, the drives, the firmware and the safety circuits stay exactly as they were, including whatever cannot be patched.

The control that matters first on a data acquisition project is direction. Collecting production data needs a path that reads, and a path that can only read is a different object from one that is merely supposed to only read. Make the upward route incapable of writing where the hardware allows it, rather than relying on a configuration somebody can change during a support call. Then place the collector honestly: a device with one interface on the machine network and another facing the plant is a boundary device whatever the purchase order calls it, and it has to be specified, hardened and owned as one. The zone and conduit reasoning, the security levels worth specifying and the split of responsibility between asset owner, integrator and product supplier are in our guide to IEC 62443 for industrial control systems, which also explains why a safety function must not depend on anything reachable from a general-purpose network.

There is a documentation consequence arriving on a date. Regulation (EU) 2023/1230 replaces the Machinery Directive for machines placed on the EU market from 20 January 2027, and it is the first EU machinery law to put software integrity, updates and connected functions alongside mechanical safety, which changes what a builder has to document for a networked line. Before that date a manufacturer may declare conformity with the Regulation voluntarily, so a machine being built or modernised now can be documented against it early; the European Commission machinery page carries the current position. Whether a modernisation crosses into being new machinery in the first place is a separate judgement made per project, covered on our machine retrofit page.

Our scope is the machine end: the network layout on equipment we build or modify, the interface split, the account and role configuration on controller and HMI, and a handover pack recording what was left enabled. Assessment and certification belong with an accredited body.

What Does the Data Have to Feed to Be Worth the Money?

A dashboard is a display format rather than a decision, and a project justified on having one gets measured by whether the screen is up rather than by whether anything changed.

The usual honest destination is a decomposed view of availability, performance and quality, and the emphasis belongs on decomposed. The arithmetic, the definitions that make it defensible and the ways the number gets flattered are in our OEE explainer, so what belongs here is the collection consequence. Availability losses filed into a single setup bucket hide the thing you are trying to fix: that bucket absorbs the format change itself, waiting for a fitter, waiting for material, first-article approval and cleaning, and those five have different owners, different fixes and different costs. Splitting them is not analysis performed later. It is a collection requirement, because the machine knows which condition it is in at the moment it is in it, and nothing downstream can reconstruct that afterwards.

Two other destinations justify the wiring on their own terms.

Statistical process control. Where the values are process measurements rather than states, the point is a trend with limits on it. On the delivered test equipment those limits and the alarm thresholds are set per test parameter through the HMI, which is what turns a pass or fail into a warning arriving before the rejects do. How the measurements themselves are produced is on our automated test equipment page.

A regulated record. Where a predicate rule requires the record, the scheme stops being a management tool and acquires an audit trail, a retention period and an account model, which is the build described on our electronic device history record page.

One test is worth running before anything is wired. Finish the sentence: when this number moves, we will do X. If the honest answer is that somebody would look into it, the number is not ready to be funded, and the project is smaller than the proposal says.

When Is Connecting an Old Machine the Wrong Project?

We do this work, so read this as the argument against buying it from us.

The machine is not the constraint. Instrumenting a station that is not limiting output produces a number and no shipments. Which machine to measure first is a question about the line rather than about the machine, and it is worth settling before any hardware is quoted.

A week of manual logging would answer the question. Where the question is narrow and current, a paper log and a stopwatch for a week are faster and cheaper than a collection scheme, and they sometimes show the answer was already known. We would rather say that than sell the scheme.

The controller is being replaced within the year. A parallel arrangement bolted onto an obsolete controller buys a few months of data at full price and is then discarded. If a migration or retrofit is already on the plan, the collection design belongs inside it.

Nobody owns the output. A data path with no named owner and no standing meeting produces a database. It is a common reason these systems go quiet in the second year, and no amount of hardware quality prevents it.

The machine is qualified and the change is not scoped. Touching a validated control system to obtain data is a change control project with re-testing attached, which is a legitimate cost and a surprising one after the purchase order. Where that route has to be taken, it runs from user requirements through IQ, OQ and PQ, as set out on our computer system validation page.

The quantity you want was never measured. No gateway invents a value that no device produces. If the process variable was never sensed, this becomes a sensor selection and installation problem, and on some machines there is nowhere to mount one without disturbing the process.

One exclusion stated directly. Where your plant has already standardised on a platform, our job ends at delivering signals it can read rather than at replacing it, and plant-wide network design and security assessment sit with your IT organisation rather than with us.

Which Route Fits the Machine in Front of You?

Four questions, run per machine rather than per plant. The first that gives a hard answer usually settles the rung.

1. Which controller, and what vintage? Whether program source and passwords exist decides the rung on a good number of machines before anything else is considered.
2. What decision is this machine’s data meant to support? One sentence. If it cannot be written, the machine is not ready to be instrumented.
3. Is the machine qualified? If it is, the cost of the top rung is change control rather than hardware.
4. Is there a route to the machine at all, and who administers it? That answer usually belongs outside the engineering department, and finding out late is what delays these projects.

Where two rows disagree, you are usually looking at a line rather than a machine, and the answer is a mixed scheme sharing one clock, one state vocabulary and one definition of a good part. That consistency matters more than fidelity, because a line measured three ways cannot be added up.

Frequently Asked Questions

Can you get production data off a machine that has no network port?

Yes, and the fidelity you get depends on how much of the machine you are allowed to touch. If there is a modern-enough controller with spare capacity, the state and counts it already holds can be read directly. If the controller is closed or obsolete, a gateway can terminate what it does speak and present it upward. Below that, bolt-on sensing infers state from motor current, vibration or the stack light without altering the control system at all. At the bottom, a hardwired dry contact from an existing circuit gives running, stopped and fault. That is a smaller dataset and a fully trustworthy one.

Do we have to replace the PLC to collect production data?

Not usually, and the two decisions are worth keeping apart. If the existing controller has a network port, spare program capacity and a platform still supported by its vendor, collection logic can be added and the tags read where they are. Replacement becomes the better buy for a different reason: when the controller cannot hold the state or the reason codes you need, when it is out of support anyway, or when the alarm structure has to be rebuilt regardless. In that case the tag list belongs in the migration scope rather than in a parallel scheme that gets discarded a year later.

What changes about a machine's risk when we connect it to the plant network?

Its exposure, and nothing else about the machine. A machine that ran isolated for fifteen years got part of its security from being unreachable, and that protection disappears the day a cable goes in, while the controller, the drives and the safety circuits stay exactly as they were. The useful controls are direction and boundary: make the upward path incapable of writing rather than merely forbidden to, keep device-level traffic on its own segment, and treat the collector as the boundary device it now is. Zones, conduits and who owns which requirement are covered in our IEC 62443 article.