New machines are increasingly designed with connectivity built in. Manufacturing data is being gathered left and right, sometimes purely because of our human hoarding instinct. Ones and zeros in a data center keeping shareholders happy and not actually being used on the shop floor. Getting data from newer machines generally gives us more options, although vendor restrictions, licensing, network configuration, and access can still complicate matters.
But that’s just a greenfield fantasy. Most production lines usually contain equipment that’s been reliably running for 20 years or more, yet still does exactly what the business needs and would cost a pretty penny to replace. Getting the right manufacturing data from such legacy machines sometimes takes a more creative approach than just »plug into the PLC and connect it to the IIoT«.
And there’s another layer to legacy machines that we rarely talk about. The experienced operator – let’s call him Hans. He knows the equipment inside and out. He knows how it behaves, what modifications have been done to it over the years, what tends to go wrong, and which parameters actually matter for its smooth operation. He’s an institutional knowledge asset that shouldn’t be overlooked during a connectivity project.
Before starting a legacy machine connectivity project
Start with why. The reason for collecting data from machines in most cases determines what data you need from them.
For example: If the goal is OEE, you need to collect something like machine status, run time, cycle times, total production count, and »good« production count.
If the goal is monitoring the quality, then you should look at the process parameters that affect the product. These may include temperature, pressure, humidity, etc.
If the goal is condition monitoring or predictive maintenance, then you’re looking at data about the machine itself such as vibration or other parameters that could indicate deterioration.
Just wanting data isn’t really a solid foundation for data capture. What matters is the decision, calculation, or process that the data is supposed to support. whether the machine can actually provide it.
Speaking of machines…
Once we understand the goal and what data is required to achieve it, the technical investigation can begin. Now we’re asking questions such as:
- Which machine are we capturing data from?
- Who manufactured it, and what type is it?
- What PLC is inside?
- Is the PLC source code available?
- Can we access it, or is ?
- What communication interfaces already exist?
- Is there documentation?
On paper, these seem like simple questions. But not all manufacturers can reliably answer all of them. That’s when we have to open the control cabinet and look for answers ourselves.
Remember Hans from before? He’s the one that points to that cabinet.
Inside the control cabinet
There’s three possible scenarios here.
The controller already has the data we need and from looking at the hardware, we know exactly how to access it. This is the best-case scenario: identify the PLC/controller, establish what communication is available, find the relevant data values, and get them where they need to go.
In other cases, the machines don’t give us straight data but at least produce signals from which we can derive it. Sometimes though, even the signals simply aren’t being created. That’s where our engineers’ creative logic, additional PLCs, sensors, meters, and transformers come into play.
Legacy machine data collection in this case isn’t really about “extracting” data at all. You’re adding a new observation point to a machine that was never designed to report what you now need to know.
Extracting data in practice
Let’s look at a concrete example from the factory floor.
We want to detect stoppages on an injection moulding machine. The machine itself has no way of telling us that it has stopped producing, so we take a different approach. We monitor a different signal that represents production – for example, a sensor detecting the opening or closing of a tool that releases the part from the machine. If the expected cycle time is 30 seconds and several minutes pass without a new part leaving the machine, our logic interprets that gap as a likely stoppage.
In this case, that sensor only gives us a raw signal, but by comparing it to the expected production cycle, we get useful manufacturing information.
Conclusion
Getting the right data for your goal from your machines can be as simple as connecting to an existing controller, or it can mean adding instrumentation and creating logic that turns basic signals into meaningful information. Regardless, the most important part is knowing what the right data looks like and what goal it supports, only then can we focus on where and how to access it.
Making the data available is just the first step in the process, though. After we get it out of the machine, we still need to make it reliable, understandable, available quickly enough, and accessible to the right people and systems. That is the difference between just connecting a machine and actually solving a data problem.
We help manufacturers answer that question in our manufacturing data decision-readiness scorecard: From Data-Scarce to Decision-Ready
