CODESYS keeps your logic and your hardware apart. The device tree describes the physical setup — the target, its fieldbus, the I/O modules — and an I/O mapping ties each physical channel to a variable. Your program reads the variable, never the channel. Swap the target and your logic doesn't flinch; only the mapping moves.
The tree shows a target with an EtherCAT master and an 8-point input module; the table maps its channels to your variables (xStartPB, xLevelHi…). Press 🔄 Re-target to move the whole project to a different vendor's controller — watch the target and channel addresses change while your variable names stay identical. That's portability in one click.
| Variable (your logic) | Channel (this target) |
|---|
Notice what didn't change: every variable name. Your POUs, languages and logic are written against names; the device tree and mapping are the only place hardware lives. Re-target, remap, download — the valuable part (your program) comes along untouched. This is the mechanism behind Track 01's "write once, run anywhere."
🎯 Target / Device — the controller you're running on. Swapping it re-points the whole project; CODESYS recompiles for the new runtime.
🔌 Fieldbus master — EtherCAT, PROFINET, Modbus… added under the target. Imports device descriptions (ESI/GSDML) for the slaves below it (Track 06).
📟 Slave / module — an I/O block, drive or sensor on the bus, with its channels exposed for mapping.
🔗 The mapping — the thin layer binding a channel to a variable. The only thing that's truly hardware-specific in your project.
You re-target a finished project from a Raspberry Pi to an industrial controller. What needs attention?