The machine, PLC, HMI, cabinets, sensors, glue stations, knives, drums, accidents, rejects, operators, setups. And only somewhere after all this — ML.

We had the task of preparing data collection from an industrial production line for future models. At first glance, the task sounds simple: find the necessary PLC signals, connect, and start collecting data for subsequent ML model building.

For example, there are several discrete PLC signals. It seems like, here are the data: read them, store them in the database, then train the model.

But that's a trap.

Because the PLC address itself means almost nothing. It's just a bit. Zero or one. To make it useful for ML, you need to understand:

  • where this signal is located on the line;
  • which node it relates to;
  • what the machine is producing at that moment;
  • what recipe is set;
  • what tooling is in place;
  • what physically happened before this signal;
  • why a reject might have appeared after it.

Without this, the model will see not the machine, but a mess of zeros and ones.

And this is where the most interesting engineering part began.

The Main Problem: PLC Speaks Briefly, but the Machine Lives in a Long Chain

PLC signals are very dry. They answer questions at the level of:

  • did the sensor trigger or not;
  • is the drive ready or in an error state;
  • is the glue ready or not;
  • did the product pass or get lost;
  • was there a reject or not.

But a defect on the line almost never appears "in one bit."

It usually arises earlier:

material feed became unstable
→ the layer was placed slightly out of alignment
→ the glue application went out of phase
→ the cutter processed an already defective product
→ the camera detected the defect
→ the product was routed to reject

If we only look at the moment of reject, we see the end of the story. But for ML and for repairs, the beginning is more important.

So I quickly realized: my task is not to "read everything." My task is to gather context around each signal so that I can later explain to the person at the machine what exactly went wrong.

Not "the model saw an anomaly in one of the PLC signals."

But, for example:

It seems the problem arises at one of the previous technological stages. Check the positioning, synchronization, and condition of the corresponding mechanical node.

Now that's a useful conclusion.

The Layout Turned Out to Be Not a Drawing, but a Map for Investigation

The first document I analyzed was a regular layout of the line. It showed the location of the main technological sections, auxiliary equipment, and service areas.

For connecting to the PLC, it’s almost useless. There are no IP addresses, no registers, no sensors, no clear network diagram.

But for engineering work, it’s still a valuable document.

Why? Because it turns the abstract machine into a physical map.

When the model later links an anomaly to a specific technological section, the person needs to understand where to go physically. Not in a philosophical sense, but literally: which part of the line to approach and which node to check.

The second layout was even more useful. It showed not just the placement of equipment, but the technological sequence:

material feed
→ product structure formation
→ component joining
→ process operation
→ inspection
→ reject or finished-product output

And after this address from the electrical diagram started to come alive.

For example, different groups of signals relate to material feeding, product formation, component joining, processing, quality control, and rejects. The addresses didn’t change, but they gained meaning.

This is like the difference between "unknown discrete signal" and "sensor that monitors the passage of the product at a certain stage of the process."

For ML, this is a huge difference.

The Recipe is More Important Than It Seems

The next document was a product drawing. It included several product formats.

I won’t retell the sizes and compositions because that’s not needed in this article. What matters is not the table of sizes itself, but the engineering conclusion:

different product formats mean different machine modes.

When switching from one format to another, materials, filler mass, layer widths, knife settings, phasing, operation of unwinders, and glue modes change. For the operator, this is a normal setup. For a dumb ML model without context — a sudden "anomaly."

And this is a classic mistake in industrial data.

If you just lump together data for different formats, the model might start comparing the incomparable. It will see that the behavior of drives, glue, or reject logic has changed and might conclude: "Oh, defect." When in reality, the machine just switched to a different recipe.

Therefore, next to each measurement, there must be an active recipe.

Not somewhere in the technologist's head. Not in Excel later. But right in the data:

  • which SKU is being produced;
  • what product format;
  • what tooling is in place;
  • what line speed;
  • was there a recipe transition;
  • was there a setup.

Then the model will be able to distinguish a real problem from a normal mode change.

For me, this is one of the main lessons: ML in the factory starts not with the model, but with an honest answer to the question "what is the line actually producing right now?"

The Glue Station: One Alarm Can Mean Different Defects

I separately analyzed the configuration of the glue system. The document showed how individual glue nodes are connected to different stages of product formation.

Again, for connection, the document is almost useless: there are no new PLC addresses, no IP addresses, no protocols.

But it gives something else — an understanding of what glue is responsible for what.

Different glue nodes are responsible for joining different components of the product.

And here, an alarm stops being just an alarm.

For example, a signal indicating the unpreparedness of one of the glue nodes is not just a general alarm. It may mean that a specific component of the product will not be secured properly, and the defect will only be detected by the control system later down the line.

So the chain looks like this:

glue station not ready
→ the component joint was disrupted
→ the product element was positioned incorrectly
→ the camera or inspection system detected the defect
→ the product was routed to reject

For a person, this is clear. For the model, it also needs to be made clear.

And here arises an important engineering idea: the signal should be linked not only to the device but also to the part of the product.

Not just:

a general alarm of the glue node triggered.

But:

the alarm relates to the glue node associated with a specific part of the product; if rejects are rising simultaneously, the corresponding technological section needs to be checked.

This is no longer "data collection for the sake of data collection." This is data preparation for diagnostics.

Mechanics Often Explains What Is Not Visible in PLC

The most interesting layer turned out to be in the mechanical drawings of technological and transport nodes.

There are no new PLC registers there either. But there is an answer to the question: how is the product physically born.

First, the main part of the product is formed. Then it is transferred between technological sections, joined with other components, processed, and undergoes quality control.

For ML, this is almost a ready causal chain:

product element formation
→ transfer
→ joining with other components
→ process operation
→ inspection
→ reject

The story with periodic defects is especially useful.

Some mechanisms operate cyclically and have several repeating working positions. If a defect appears after a consistent number of products, it’s no longer "random noise."

For example, if the problem appears with a stable periodicity, it’s a strong hint at a defect in one of the working positions of the cyclic mechanism or related tooling.

This is a very elegant engineering thing.

The model can notice periodicity in rejects. But without knowledge of mechanics, it won’t understand that this resembles a problem with one of the repeating working positions. An engineer with a drawing will understand.

The same applies to transport mechanisms. If a product element shifts during transport, the defect may not manifest immediately but only in subsequent operations or controls. Therefore, signals of transportation, positioning, and control need to be viewed not separately but as one story.

What I Ultimately Gather from the Machine

After analyzing the documents, it became clear: the strategy of "let's read everything every second" doesn’t work.

The machine is fast. Some events last very briefly. If you poll important bits too infrequently, you might simply miss a short pulse. It was there, affected the process, but it’s not in the data.

So I divide the collection into several levels.

1. Fast Events

This includes signals that may briefly flash but significantly affect quality:

  • run/stop;
  • safety readiness;
  • glue ready/alarm;
  • servo ready/alarm;
  • reject;
  • interlock;
  • door/guard;
  • product transfer;
  • cutter states;
  • phase-related flags;
  • important operator buttons.

For such signals, a separate high-frequency collection loop is needed with a short priority list. Not on thousands of signals, but only on the most important ones.

If the signal is very short, it’s better to make a latch or counter on the PLC side to avoid losing the event between polls.

2. Main Line Slice

There is a large block of signals that don’t necessarily need to be read ultra-fast but need to be seen regularly: statuses, most X/Y/M/L, some drives, current technological parameters.

For this, a separate main loop with a lower polling frequency is suitable. It’s a compromise: fast enough to monitor the process but without unnecessary load on the network and storage.

3. Analog Parameters

Analog signals are often the most valuable for ML because they show not "broken/not broken," but gradual deterioration:

  • tension of the webs;
  • vacuum;
  • speed references;
  • servo trim;
  • phase drift;
  • glue temperature;
  • indirect signs of overload and wear.

Some of these parameters make sense to read quickly, while others less frequently. There’s no need to fanatically pull everything at maximum frequency. If a parameter physically changes slowly, there’s no point in reading it like a pulse sensor.

4. Context

This is the layer that is most often forgotten, and then people wonder why the model is useless.

You need to store:

  • active recipe;
  • product format;
  • line speed;
  • roll change;
  • transitions of glue machines;
  • operator actions;
  • accidents;
  • reasons for rejects;
  • stop/start;
  • maintenance actions;
  • SKU;
  • batch of raw materials;
  • shift;
  • downstream quality, if available.

Without this, you can collect terabytes of signals and still not understand what happened.

How to Store Data So You Don’t Suffer Later

I don’t want to store just "the current value of the signal." That’s not enough for ML.

For bits, the moment of change is important. Not just "now 1," but:

  • when it switched;
  • which signal;
  • from what value to what;
  • on which recipe;
  • at what speed;
  • in which product cycle, if available.

For analogs, a time series is needed: raw value and engineering value, if the scaling rules are known.

For alarms — a separate event log: when it started, when it ended, when the operator confirmed.

For HMI and operator commands — a separate log. Because "the machine started behaving differently by itself" and "the operator pressed a button" are different stories.

For quality — separate product/cycle records. Ideally, when you can link a specific product cycle with what the camera or downstream control later saw.

Such a design allows building both supervised models and anomaly detection, as well as proper diagnostics from logs.

Where the Engineering Elegance Lies

On the surface, the task looks like "connect to the PLC and dump the signals."

But the real solution turned out to be different:

not just reading the machine, but building a translator between the PLC and the physical process.

The electrical diagram tells what to read.

The layout tells where it is located.

The technological diagram tells at which stage of the process it operates.

The product drawing tells what the normal mode should be now.

The glue configuration tells which layer will be affected during an alarm.

The mechanical drawings tell where to look for periodic defects.

And data collection ties all this together over time.

In the end, it results in a simple chain:

PLC address
→ machine zone
→ process stage
→ recipe
→ tooling
→ potential defect
→ physical location to inspect

Now that’s data for ML.

Not pretty graphs for the sake of graphs. Not thousands of nameless tags. But a proper engineering database where each signal can be explained.

The Main Conclusion

Most of the documents I analyzed didn’t provide a single new PLC register. From the connection standpoint, they are almost useless.

But they gave the most important thing — meaning.

And now, for me, preparing data for ML in the factory looks like this:

  1. First, understand the physical process.
  2. Then link the signals to the nodes of the line.
  3. Then add the recipe and tooling.
  4. Then correctly gather fast events, analogs, alarms, and operator actions.
  5. And only after that think about the model.

Because ML shouldn’t just say: "you have an anomaly."

A good system should say something like this:

The problem seems to be a violation at one of the previous technological stages. Reject appears later, but the cause likely arose earlier down the line. Check the positioning, synchronization, and condition of the related mechanical nodes.

And that’s a conclusion that can actually be taken to production.