Many shops track jobs on a whiteboard, then type run times and part counts into the ERP at the end of the shift, or on Monday morning. The numbers are late, rounded and sometimes invented. Getting them straight from the machine sounds simple. It can be, for some machines. For others it is a project. This guide explains the pieces so you can judge which kind of shop you are.
What you actually want from a machine
Start with the question, not the protocol. People usually want some of these:
- is the machine running, idle, faulted or in setup right now;
- what program is loaded, and which job it belongs to;
- how many parts have been made, and how many cycles have finished;
- how long each cycle takes, compared with the quote;
- why it stopped: tool change, no material, alarm, operator break.
Each item is a different level of difficulty. Running or stopped is almost always available. The reason for a stop usually needs an operator to press a button or choose a code, because the controller knows that it stopped but not why.
The protocols you will hear about
MTConnect is an open standard that describes machine data in a common vocabulary: availability, execution state, program name, part count, spindle speed, alarms. A small piece of software called an adapter reads from the controller and an agent publishes the data over a local network address. Many newer controllers and some retrofit boxes speak it.
OPC UA is a broader industrial standard. It exposes named values and lets you read them securely, with sign-in and encryption. Many controllers from the larger makers offer it as an option, sometimes as a paid license.
MQTT is a lightweight messaging method. A device publishes small messages to a broker, and anything that is subscribed receives them. It is common on sensors and gateway boxes and a good way to move data once you have it.
Older routes still matter on older machines: Modbus, serial ports, discrete input and output signals, or a vendor's own interface. A signal tower light wired to a small input device can tell you running, idle and alarm with no controller access at all.
None of these is "better." The right one is the one your controller supports with the options you already own.
Step 1: take inventory
Before anyone writes software, make a table with one row per machine:
| Column | Example | |---|---| | Machine and age | Vertical mill, bought used | | Controller make and model | The label on the control panel | | Software or option level | Is an Ethernet option installed | | Network | On the shop network, or not connected | | Protocols it can speak | MTConnect, OPC UA, other, none | | What you want from it | Run state, part count, program name |
This one page decides the cost more than anything else. A shop of eight machines will often find three that offer data over the network, three that need a gateway box, and two that only give a signal from a light or a relay.
Step 2: get the data off the machine
For each machine, there are three routes, from least to most effort.
- The controller already publishes data. Turn on the option, give it an address, and read it. The work is configuration and a check that the values mean what the name says.
- An adapter or gateway sits between. A small device or program reads the controller's own interface and republishes it as MTConnect, OPC UA or MQTT. This takes some setup per controller family, and then repeats for the next machine of the same kind.
- Sensors and signals. Current clamps on the spindle, a light tower input, a part-count switch. Less detail, but it works on any machine and is often enough to answer "is it making parts."
Network safety belongs here. Machine controllers are not built to face the open internet. Put them on a separate network segment, allow only the collector to talk to them, and make reads one-way where you can.
Step 3: collect and store
A collector program polls or listens, adds a timestamp, and writes each reading to a database. Two details matter more than they look:
- Clock and timing. Every reading needs a trustworthy time, or cycle times are meaningless.
- Gaps. Networks drop. The collector should record that data is missing rather than carry the last value forward and pretend.
From the database you can draw a dashboard: a row per machine with a colored state, today's parts, and the current job. That alone replaces the walk to the floor.
Step 4: tie it to a job
Raw data says that machine 3 ran program O1234 for 41 minutes. The ERP wants to know that job 5521, operation 20, took 41 minutes against 35 quoted. The bridge between them is a mapping you must define:
- program name or number to job and operation;
- machine to work center;
- operator login or badge, if you want labor tracked;
- a rule for what counts as setup, run and idle.
Expect to settle this with the people on the floor, not at a desk. The best rule is the one an operator will follow on a bad day. If an operator must press one button to start a job at the machine, the data will be good. If it takes six taps, it will not be.
Step 5: write back, carefully
Reading is safe. Writing into your ERP or job system needs more care. Decide:
- which fields the machine data may fill, and which stay human-entered;
- whether a human approves times before they post;
- what happens when the machine reports something that does not match a job;
- how the link behaves when the ERP is down for an hour.
A good first version posts run time and part counts to the job, flags anything it could not match, and leaves costing alone.
Where shops get stuck
- Buying a monitoring product before checking whether the controllers can feed it.
- Measuring everything and acting on nothing. Pick two numbers you will review weekly.
- Skipping the baseline. Without a week of measurements from before the change, you cannot show what improved.
- Treating the shop floor network like the office network.
A sensible first project
Start small: one to three machines, a written baseline, and a pass or fail criterion agreed in advance, such as "run state matches the operator log within an agreed margin for two weeks." That tells you what the data is worth before you pay for the rest.
Next step: a shop walk-through
We offer a shop walk-through and machine data inventory: we look at your controllers, protocols and current job system, and give you the table described above in writing. It leads to a plan and a price for one connector or dashboard, working alongside the job and accounting systems you already use rather than replacing them.
This is early work for us in this area, and we will say so plainly. Read about it on the fabrication and shop automation page, or send us your machine list through the contact form.