In PLC projects, the slowest and most error-prone step is usually not drawing the circuits — it is compiling the I/O list. Once signals spread over ten pages, the question "which sensor is on which address" becomes a hunt through the pages; the table is maintained by hand and reverts to a stale state with every change to the project.
What makes an I/O plan trustworthy?
The programmer and the field crew work from this table. For every row it needs four things:
- Signal name — what it measures or controls.
- Type — digital or analog; input or output (DI/AI/DO/AO).
- Address — the position on the PLC module (e.g. A1.00.0).
- Device — the tag of the device that produces or consumes the signal.
All four already exist as the project's own data; the real problem is keeping them in sync with the drawing.
Where the errors start
A hand-compiled I/O table makes these mistakes a matter of course:
- Address conflict: two signals are mapped to the same address; the program will not run, or it reacts to the wrong signal.
- Type mismatch: an analog sensor is written to a digital input; the field notices only after the cable has been pulled.
- Stale row: a device changes in the drawing, the row in the table stays old.
The common thread: the table is produced separately from the drawing.
The fix: the I/O list as a report
In EupCAD, the PLC I/O list is produced from the same source as the other reports: the devices, terminals and connections in the drawing. It downloads as CSV in one click; every row carries the signal's type, address and device mapping. When a signal changes in the drawing, you re-download the list — you never touch the table by hand.
Structural errors such as an address conflict are caught by the design rule check (DRC): if two or more signals are mapped to the same address, the check report shows it together with the page. The error is found in the office, before the field pulls the cable.
Practical scenario: commissioning day
On commissioning day, the field crew arrives with a current I/O list in hand. Every cable matches a row in the list; the programmer takes addresses from the same source as the drawing, not from a table. When an address question comes up, the answer is searched in a single source: the project file.
The result: the label at the end of the cable and the address in the PLC are verified in the same moment — no more wondering which sensor a row belongs to.
Next step
In the demo project (ZONE1_PUMPS), browse the PLC pages and download the I/O list: see every row's address and device mapping match the drawing exactly. Run the design rule check and look at how the address-conflict check reports.