This article is for plant managers, production managers, continuous improvement leads and maintenance managers who are planning, or already running, a plant-floor data integration project, and who keep running into the same question: what do we do with the machines that have no usable PLC connection? It explains where stop data comes from on those machines, how a non-intrusive sensor layer fits next to a full integration architecture, and how to decide machine by machine which path makes sense.
- Many plants mix networked lines with legacy machines that have no usable PLC data.
- A full plant-floor integration is the right path when clean controller tags exist.
- A non-intrusive sensor layer captures stops on the machines integration cannot reach yet.
- Shared stop definitions keep OEE comparable whichever layer produced the data.
Two kinds of machines on the same shop floor
Walk through almost any plant that has been running for a few decades and you will find two populations of equipment side by side. On one side, recent lines with modern controllers, a clean tag structure and a network connection that a controls engineer can reach. On the other, presses, lathes, packaging machines and test benches that still do their job perfectly well, but whose controller is obsolete, locked, undocumented, or simply not there because the machine runs on relays.
The first population is the natural territory of a plant-floor integration project: read the tags, contextualize them, exchange data with the MES and the ERP. The second population is where many projects stall. The machines are not strategic enough to justify a controller upgrade, but they are often exactly where the stops, the micro-stops and the long changeovers hide. Leaving them out of the data means the picture of the plant stays incomplete, and the improvement work keeps relying on handwritten logs for part of the floor.
What a full plant-floor integration brings
DMC, Inc., the Chicago engineering and systems integration firm, recently published a detailed technical walkthrough by Pruitt Urbanczyk: Using FactoryTalk Optix for MES, ERP, and Plant-Floor Data Integration. The article explains how a software layer can sit between ERP/MES systems and PLC/SCADA applications, covers communication drivers, OPC UA, MQTT and databases, and shows how to bridge data between controllers and business systems. It also states plainly why the effort is worth it: “full MES and ERP integration reduces manual data entry and improves traceability.”
The article is equally practical about the conditions this requires. It recommends importing only the tags you actually need from a PLC to keep the project lightweight, notes that a changed PLC namespace means reimporting it, and shows how handshakes protect sensitive exchanges between the software layer and the controller. In other words, a well built integration starts from a PLC that exposes reliable, documented data. That is the right foundation for the machines that have it, and it is the reason the integration architecture deserves careful design rather than shortcuts.
The question this article addresses is the complement: how do you get trustworthy stop data from the machines where that foundation does not exist yet, without waiting for a controls upgrade and without touching the controller?
Why some machines have no usable PLC data
“No usable PLC connection” covers several situations, and it helps to name them, because each one leads to a different decision:
| Situation on the machine | What it means for stop data | Typical path |
|---|---|---|
| Relay logic or no controller at all | There is no tag to read; run and stop states exist only as electrical signals | Non-intrusive sensor layer |
| Obsolete controller, no communication card | Data exists inside the controller but cannot be reached without hardware changes | Sensor layer now, integration if the machine is upgraded |
| Controller locked by the machine builder or under warranty | Reading or modifying the program is not allowed or carries risk | Sensor layer, no change to the program |
| Accessible controller, but no meaningful status tags | Tags exist, but nobody can say which one reliably means “producing” | Sensor layer to establish a reference, then integration once tags are mapped |
| Modern, documented, networked controller | Clean tags available for run state, counts and alarms | Full plant-floor integration |
The last row is where an integration project shines. The first four rows are where a sensor layer can start delivering data quickly, without competing with the integration roadmap.
What a non-intrusive sensor layer actually captures
A non-intrusive sensor layer does not read the controller. It observes the machine from the outside: an electrical signal in the cabinet that tells whether the machine is powered and running, and a sensor at the line that sees each part or each cycle go by. From those two signals you can rebuild what matters for stop analysis:
- Run and stop states, with the exact start and end time of every stop, including the short ones nobody writes down.
- Cycle counts and cycle time, which show slowdowns as well as full stops.
- Stop durations by period, shift or day, ready to be compared across machines.
- Stop reasons, entered by operators on a terminal at the moment the stop happens, so the cause is captured while it is still fresh.
What it does not do is write anything back to the machine, change the program, or replace the controls work that a full integration involves. That limit is also its strength: because nothing in the control logic changes, the risk to production is very low, and the maintenance team does not need to requalify the machine.
How the two layers work together
The useful way to think about this is not “sensor layer or integration”, but “which source of truth for which machine, and for how long”. A practical sequence looks like this:
- Classify every machine using the table above, with the controls engineer and the maintenance lead in the room. Be honest about the “accessible but meaningless tags” category; it is often larger than expected.
- Instrument the machines without usable PLC data with the sensor layer first. They usually represent the biggest blind spot, and they can produce stop data within days.
- Use the measured stop data to prioritize. Once you see where the hours are lost, you know which machines justify a controller upgrade and a full integration, and which ones are well served by the sensor layer for the rest of their life.
- Integrate the machines that justify it, following a solid architecture such as the one DMC describes, with only the necessary tags and proper handshakes.
- Agree on shared definitions (what counts as a stop, planned time, ideal cycle time) so that OEE and stop figures mean the same thing whichever layer produced them.
Step 5 is the one that is most often skipped. Two data sources are only complementary if a stop of five minutes on a legacy press is counted with the same rules as a stop of five minutes on a networked line. Settle the definitions before comparing machines.
Common pitfalls when mixing data sources
A few mistakes come up repeatedly when plants combine sensor data and controller data:
- Different stop thresholds. If one source counts any interruption and the other ignores anything under a minute, micro-stops appear only on half the floor.
- Different time references. Shift boundaries and clock synchronization must match, otherwise daily figures drift apart.
- Reason codes that do not match. Use one reason list for the whole plant, whichever layer captures the state.
- Treating the sensor layer as temporary by default. For many legacy machines, it is the right long term answer, not a stopgap.
Where TEEPTRAK fits
TEEPTRAK is a measurement solution, not an MES and not an integration platform. On each machine, a module is wired into the electrical cabinet and a sensor is mounted at the line, without any connection to the PLC. Installation takes about one hour per machine, and OEE is available within 48 hours. Stops, micro-stops and cycle times are measured automatically, and operators qualify stop reasons on the spot. TEEPTRAK is used in more than 700 plants in over 30 countries, where customers see on average a gain of 10 to 15 OEE points and 30% fewer unplanned stops. On a floor that also runs a plant-floor integration, it covers the machines the integration cannot reach yet, and the measured data helps decide where integration effort pays off first.
Further reading
- Using FactoryTalk Optix for MES, ERP, and Plant-Floor Data Integration (DMC, Inc., Pruitt Urbanczyk)
- How to Collect Machine Data for OEE: Methods, Sensors and Best Practices (2026)
- Adding a monitoring module to an existing control cabinet: what to check before wiring
FAQ
Can I get downtime data from a machine that has no PLC at all? Yes. A non-intrusive sensor layer reads an electrical signal in the cabinet and counts cycles at the line, which is enough to rebuild run and stop states, stop durations and cycle times without any controller.
Does a sensor layer replace a plant-floor integration project? No. Integration remains the right approach for machines with modern, documented controllers and for exchanges with the MES and the ERP. The sensor layer covers the machines where usable PLC data does not exist, and its measurements help prioritize which machines to integrate.
How do I keep OEE comparable between sensor data and PLC data? Use the same definitions everywhere: one stop threshold, one planned time rule, one ideal cycle time per product, one reason list and synchronized shift boundaries. Then a stop counts the same way whichever layer recorded it.
0 Comments