Recently, I have been frequently asked by newcomers about I/O mapping, which is quite annoying. After working in this field for over ten years, I have seen too many people who can’t even understand such basic concepts, constantly complicating simple issues. So today, I will discuss I/O mapping in PLCs, so please stop asking about it.
First, let’s talk about what I/O mapping is. Simply put, it is the process of mapping physical I/O points to internal registers or variables, allowing programmers to use variable names directly. If the wiring changes later, there is no need to modify the program. It’s unbelievable that some people can mess this up, it’s truly frustrating.
io
Why use I/O mapping?
Back in 2018, I went to a car parts factory in Suzhou to troubleshoot, and the programmer wrote code directly using physical addresses like I:1/2 and O:3/4. I was ready to yell at him. Later, when the factory expanded and needed to switch to a larger PLC, guess what happened? The entire program had to be modified! When the hardware address changed, hundreds of references in the program had to be changed one by one, which made that young guy work for three days and nights.
If they had used mapping, this wouldn’t have happened. Just define it as START_BTN = I:1/2, and use START_BTN throughout the program. If the hardware changes, you only need to change one place. Do I really need to teach this?
By the way, this issue is not just about hardware changes. I remember last winter at a paper mill in Hebei, a machine control cabinet suddenly exploded, and during the emergency replacement of the I/O module, the new module’s slot position changed, causing all the addresses to change. Debugging took until 3 AM. If I/O mapping had been standardized from the beginning, it could have been resolved in half an hour.
plc
Differences Between PLCs
When it comes to I/O mapping, there are significant differences among various PLCs. The old Siemens S7 makes this process very smooth; once the symbol table is established and the tags are defined, you can drag them directly into the program, making modifications easy. Siemens’ approach is engineering-oriented, and although it may be a bit troublesome at first, it saves a lot of effort in maintenance later on.
AB’s ControlLogix is also decent; at least the separation of Controller Tags and programs is correct. However, the interface is truly user-unfriendly. Even after using it for so many years, I still sometimes spend ages looking for a tag. But at least it is separated, so when the hardware changes, the program doesn’t need to be modified.
As for domestic PLCs… let’s not get into that. Some older versions of software don’t even have a decent variable table, just directly using %I0.1, %Q0.2 in the program, as if they have never learned programming. A couple of years ago, I worked on a project using a certain domestic PLC, and it was a nightmare…
By the way, regarding communication mapping, this is also a big pitfall. In some projects, the MODBUS addresses are modified on-site without a unified address table, making it extremely painful to connect third-party devices later, as you can’t even find where the addresses are.
1
My Best Practices
Years of hard-earned experience have led me to summarize a few points:
First, maintain consistent naming conventions! Don’t mix things up; sometimes use START_BUTTON, sometimes start_btn, and sometimes StartBtn. It hurts my eyes. I generally use prefixes for analog signals like AI_ and AO_, and for digital signals like DI_ and DO_, along with device abbreviations and functional descriptions, such as DI_CONV1_START.
Here is a naming structure I used in a previous automated line project for your reference:
// Siemens S7-1500 Example
"DI_CONV1_START" AT %I0.0 : BOOL; // Conveyor 1 Start Button
"AI_TEMP_ZONE1" AT %IW64 : INT; // Zone 1 Temperature Sensor
// Some signals don't need comments, I know what they are
"DO_MOTOR1_FWD" AT %Q2.0 : BOOL;
Second, group and isolate properly. Group by functional blocks; don’t pile all signals together. Control cabinet signals in one group, field station signals in another, safety signals in another… This way, when issues arise, you can easily identify which area has a fault. I remember in 2020 at a factory in Shiyan, they had clear separations, and faults were directly located to the safety circuit, resolving the issue in half an hour; in contrast, at a project in Nanjing, all signals were mixed together, and it took a whole day to find the problem.
Third, don’t be lazy and use addresses directly. I’ve seen the most ridiculous cases where both I0.1 and START_BTN are mixed in the program, sometimes using physical addresses and sometimes variable names, it’s simply brainless.
And I won’t even mention the dirty work, like leaving reserved points or writing good comments; these are basic skills. Those who write programs without comments will eventually run into trouble. A colleague of mine was scolded by the boss for this; when an issue arose, no one could understand the program, leading to an 8-hour production halt and losses of over a hundred thousand.
Speaking of comments, some people write comments that are as good as not writing them at all:
// AB RSLogix 5000 Example
Motor1_Run // Motor 1 Running
Motor1_Speed // Motor 1 Speed
// Such garbage comments are worse than not writing anything, wasting screen space
2
Finally, a few words
In the industrial control field, instead of working overtime to troubleshoot every day, it’s better to establish rules from the start. If you can’t even handle small matters like I/O mapping, the entire system will definitely be a mess. I want to say more, like state machine programming and system integration, but seeing that you can’t even understand this, it would be pointless to say more.
That’s all for now. If you don’t like it, tough luck. Anyway, I haven’t had any major accidents in my projects over the years, so young folks, learn well. Oh, and if you want to excel in PLCs, stop daydreaming about AI and Industry 4.0, and focus on mastering the basics first.
Before you go, remember to click “Looking“~