The data already exists. The work is agreeing what it means.
The six fields every signal mapping needs, the four signals worth mapping first, and the errors that produce confidently wrong numbers nobody catches for a month.
Where a machine has a PLC, the data usually already exists — the machine's own logic knows when it is running, how many parts it has made and why it stopped. The work is not acquisition but agreement: deciding which tags represent those things, and recording that decision somewhere it will survive the person who made it.
Signal mapping is unglamorous and it is where PLC-based monitoring projects succeed or produce confidently wrong numbers.
Six fields per signal, and all six matter.
| Field | Example | Why it is needed |
|---|---|---|
| Source address | A tag name, or a register number | Where the value is read from |
| Meaning | 'Cycle running', 'good part complete' | What the value represents in monitoring terms |
| Data type | Boolean, 16-bit signed, 32-bit float | Misreading this produces wildly wrong values |
| Scaling | Value ÷ 10 = degrees C | The most common source of ten-times errors |
| Edge or level | Count on rising edge; state while true | Counting a level as an edge inflates counts enormously |
| Owner and date | Who agreed it, and when | So the next person can trace a disputed number to a decision |
Who needs to be in it.
Skipping the middle column is the classic failure. A perfectly correct technical mapping that counts a four-part cycle as one part is wrong in exactly the way nobody notices until a monthly report is challenged.
Cycle running
The single most valuable signal. Everything about availability derives from it, and it is almost always present in PLC logic already.
Part complete
On a rising edge, once per good part. Establish explicitly whether the machine's own counter includes rejects.
Mode selector
Auto, manual, setup. Without it, setup time is indistinguishable from downtime and both numbers become misleading.
Alarm or fault present
Even as a single bit, it separates a fault stop from an idle stop before anyone has to ask.
Counting a level instead of an edge. If a 'part complete' bit stays true for two seconds and the monitoring system counts while it is true, one part becomes many. This is the largest-magnitude error in PLC mapping and it is instantly visible if anyone compares the dashboard against a shift's actual output.
Mode not mapped. A machine in setup looks stopped. Availability collapses, the supervisor disputes the number, and trust in the whole system goes with it — over a single missing boolean.
Counters that include rejects. The machine counts cycles; quality counts good parts. If the difference is not established at mapping time, quality figures are wrong in a direction nobody checks.
Undocumented changes. A PLC program is modified for a production reason and a tag moves. Monitoring keeps reading the old address and reports plausible nonsense. This is why the owner-and-date field exists, and why a mapping document belongs with the PLC backup rather than in someone's email.
Treat the mapping document as part of the machine's documentation, stored with the PLC program backup. Review it whenever the PLC program changes, and re-verify counts against a shift's real output after any change.
During commissioning we produce this document with your maintenance team rather than for them, because the knowledge that makes it correct sits with the people who maintain the machine. It is also the artefact that makes a monitoring system portable: if you change platforms in five years, a good mapping document is most of the work already done.