How Production Data Gets from a PLC into an MES
Which signals you need for OEE, what to do with a machine that has no network port, how raw signals become machine states, and how the counts stay right through rollovers, restarts and network drops.
Written for controls and engineering managers. It describes how 10in6 does it, but the principles apply to any MES.
How do you collect production data from a PLC?
Read the signals the machine already produces (a cycle-complete pulse or part counter, a running or fault state, a reject signal if there is one) over its existing interface, read-only. Turn them into machine states, counts and times close to the machine, where timing is exact. Then store each record with the shift and product that were active, so every report can be filtered by them. Most of the engineering goes into keeping the count right when a counter rolls over, a PLC restarts or the network drops.
Three questions that decide how a machine gets connected
There is no single way to connect a machine. The answers to these three questions set the signals, the hardware and most of the cost.
1. What do you want to know about it?
Counts, cycle time and stops need one or two signals. A full picture of a cell (temperatures, pressures, torque on every cycle) means reading many values from the PLC. The first can often be wired in; the second usually needs a network connection to the controller.
2. What is the machine running?
A newer PLC already on the plant network can usually be read as it is. An older PLC with no Ethernet port may need a communication module, or its outputs wired to an I/O module. A machine with no PLC needs a sensor, such as one on the part ejection or the stack light.
3. Does the signal you need exist yet?
A cycle-complete bit often exists in the program but isn't brought out anywhere. Sometimes it doesn't exist at all, like a reject that drops into a bin with nothing to count it. Then a signal has to be added before that loss can be measured. Find out which it is before you budget.
From the machine to the report, in four steps
- 1 · Machines
Machine PLCs and field devices
Cycle-complete pulses, part counters, fault and state bits, reject signals. Read over OPC UA, Ethernet/IP, Modbus or a native driver, or wired in through I/O modules for older machines. Read-only.
- 2 · Concentrator
A dedicated PLC for data collection
One controller gathers signals from up to 200 machines, works out each machine's state every scan, accumulates counts and times, handles counter rollover, and buffers stoppages.
- 3 · Logging service
From controller to database
A service reads the concentrator over OPC UA, writes a record every 30–60 seconds and at every change of shift or product, drains the stoppage buffer, and keeps the controller's clock in sync with the database.
- 4 · Database & reports
SQL Server, then everything else
Reports, OEE, real-time boards and the Operator Console all read the same database, and your team can query it directly or connect Power BI.
Why a separate concentrator PLC? Real-time state and timing belong close to the machines, where a scan takes milliseconds and nothing depends on the network or a server being up. The logging service only stores what the controller has already worked out. That split is what makes a server restart safe: the controller keeps counting, and the service picks up where it left off.
Which machine signals you need for OEE
One signal is enough to start. Each additional one makes the losses easier to explain.
| Signal | What it gives you | Needed? |
|---|---|---|
| Cycle complete (pulse) or part counter | Part count, actual cycle time, and stops as gaps longer than the expected cycle. Enough for Availability and Performance. | Required for automatic counting |
| Ideal cycle time per product | The rate Performance is measured against. A setting rather than a signal, but OEE is meaningless without it. | Required |
| Reject / bad-part signal or count | Automatic scrap counts for the Quality factor. Without it, operators enter scrap at the console. | Recommended |
| Fault or running state | Separates a real fault from a slow cycle, and gives an exact stop start time. | Recommended |
| Starved and blocked | Shows whether a stop was the machine's own fault or caused by the line around it. Valuable on connected lines. | Optional |
| Product or job identifier | Tells the system which product is running, so counts and rates switch automatically. Can come from the schedule or the console instead. | Optional |
| Fault codes | The machine's own fault number, recorded with each stop, so stops can be grouped by what the machine reported. | Optional |
If a machine only gives you one signal
Use the cycle-complete pulse. On a press with a 30-second ideal cycle, pulses arriving every 33 seconds mean it is running slow, and no pulse for several cycles means it has stopped. The operator adds scrap at the console. Many older machines are connected this way.
If a machine gives you nothing usable
A sensor on the part ejection, a light curtain or the stack light usually gives a clean enough signal, and an I/O module can pick up a discrete output without anyone touching the controls. Where neither is practical, the operator enters counts at the Operator Console and the machine reports next to the connected ones.
Why "running or stopped" isn't enough
A machine that isn't cycling might be broken, waiting for material, unable to unload, in a changeover, or simply not scheduled. Each of those is a different loss with a different owner. Treat them all as "down" and the downtime report blames maintenance for problems that belong to material handling or scheduling.
So the concentrator works out one state for every machine on every scan. When more than one condition is true, a fixed priority decides: a machine that isn't scheduled is no demand, not idle, and a machine in changeover isn't counted as starved.
Changeovers get special treatment. A change of product starts a setup phase and then a startup phase, each measured against its allowance, and counts under the old product never bleed into the new one.
- CyclingRunning and producing at or near its expected cycle.
- Over-cyclingStill running, but slower than its cycle threshold: a slow-cycle loss rather than a stop.
- StarvedReady to run but waiting for material or parts from upstream.
- BlockedReady to run but unable to release parts downstream.
- ChangeoverSetting up for the next product, measured against setup and startup allowances.
- IdleNot cycling, and not explained by starved, blocked, changeover or no demand.
- No demandNot scheduled to run, so it isn’t counted against the machine.
- Comms faultThe connection to the machine is lost; flagged separately so it isn’t mistaken for running or stopped.
Rollovers, restarts and network drops
Homegrown data collection usually breaks on one of these six.
Counter rollover and resets
An unsigned 16-bit counter wraps to zero after 65,535, and some counters go back to zero at power-up. Take the raw value at face value and the report shows a negative count or a spike of thousands of parts. The concentrator tracks the change between readings, and a reading that comes in below the last one gets the rollover value added before the subtraction.
Server or service restarts
The controller keeps counting and timing whether or not the logging service is running. Each snapshot carries a sequence number, so the service knows exactly which records it hasn't stored yet. Up to 200 stoppages are held in the controller until the service writes them.
Lost connection to a machine
When the link between a machine and the concentrator drops, the machine sits in a communications-fault state for the length of the gap. A failed network switch shows up as a switch failure, and nobody's line gets charged the downtime.
Shift and product boundaries
Whenever the shift, product, job identifier or production run changes, the controller forces an immediate record at the boundary. Every stored record has one consistent shift and product, which is what makes run history and per-product OEE accurate.
Clock drift
The logging service writes the database server's time back to the controller, so timestamps on the floor and in the database agree. Stop times and shift boundaries line up.
Write volume
Logging every pulse as a database row buries the server. The controller accumulates continuously and the service stores a snapshot every 30–60 seconds, plus the boundary records above. Counts stay exact and the database stays small.
“Being able to analyze cycle time losses was a big win for us. Before 10in6 we would have hours with no downtime, where we still didn’t hit our target. We have caught issues where 20 second cycles were taking 21 or 22 seconds, that we never would have seen without 10in6.”
That kind of finding only exists when the actual cycle is measured from the machine signal. See OEE Tracking for how Performance loss is calculated, and Machine, PLC & Device Connectivity for the equipment and protocols 10in6 connects to.
Set up around how your plant runs
Standardized platforms expect the plant to change to fit the software. Do-it-yourself platforms leave your team to build and maintain everything. With 10in6, we configure the system around your equipment, codes and reports, and your team runs it day to day.
Your equipment, codes and reports
Your machines, your ERP, your part numbers, your shift structure and your reports.
Your team runs it day to day
Operators, downtime and scrap codes, products and targets, shift schedules, checks, alerts, emailed reports and real-time boards are managed by your own people. Everyday changes need no support ticket and no invoice.
A project manager for the bigger things
New machines, new modules and custom reports go through a 10in6 project manager who already knows your deployment, so nothing starts from scratch. If you would rather we made everyday changes too, we can.
Still here years later
The system keeps being refined after go-live, and new capabilities are added without rebuilding it. Some of our customer relationships have run for 12 years, and 97% of customers say they would never go back.
“Our 10in6 Project Manager has been very responsive and the software is flexible enough to be configured to our specific needs.”
How the 10in6 delivery model works →
Machine data collection questions
- How do you collect production data from a PLC?
- Read the signals the machine already produces (a cycle-complete pulse or part counter, a running or fault state, and a reject signal if there is one) over the PLC's existing communication interface, such as OPC UA, Ethernet/IP or Modbus. Turn those signals into states, counts and times, save them to a database with the shift and product that were active, and build reports from that record. In 10in6, a dedicated concentrator PLC does the real-time work and a logging service stores the results in SQL Server.
- Do you need to change the machine PLC program to collect data?
- Usually not. 10in6 reads from machine PLCs over their existing ports and protocols, read-only, without altering ladder logic. Where a machine has no usable interface, discrete outputs such as a running or cycle-complete signal can be read through I/O modules without touching the control system.
- What is the minimum machine signal needed for OEE?
- A cycle-complete signal or a running part counter. From that one signal you get the part count, the actual cycle time, and stops (gaps longer than the expected cycle). With an ideal cycle time for each product and scrap entered by the operator, that is enough to calculate all three OEE factors. Extra signals such as fault, starved, blocked and reject make the picture sharper, but they aren't needed to start.
- What if a machine has no PLC or usable output at all?
- There are three options: add a simple sensor (for example on the part ejection or a stack light), read a discrete output through an I/O module, or have the operator enter counts at the Operator Console. 10in6 supports manual-entry machines alongside automatically connected ones, so a plant doesn't have to wait until every machine is connected.
- What happens to production data if the network or the logging service goes down?
- In 10in6, the concentrator PLC keeps counting and timing through an outage of the logging service, and stoppages are held in a buffer of up to 200 events until they can be written. When the service comes back, it picks up where it left off. A lost connection to a machine is flagged as its own communications-fault state, so it isn't silently recorded as the machine running or stopped.
- How are PLC counter rollovers and resets handled?
- Hardware counters eventually roll over back to zero, and some reset on power-up. The concentrator calculates the difference between readings rather than trusting the raw value: if the new reading is lower than the last one, it adds the counter's rollover value before subtracting. The database only ever receives clean part counts.
Send us your equipment list.
Tell us what's on your floor, old and new. We'll tell you, machine by machine, what can be connected, which signals you'll get, and what it takes.
Free 30–60 minute call with one of our engineers.