In the years of factory automation, I have seen too many beginners complicate simple issues. Today, let’s talk about PLC input and output. Many people think it’s simple at first glance, but there are numerous cases of failure when actually implementing it. Just the other day, I visited a paper factory where the so-called engineer had a chaotic I/O mapping configured for the Siemens S7-1200, and the variable names looked like hieroglyphs, leading to a night of troubleshooting.
To be honest, seeing those poorly named I/O variables annoys me. Names like IN_001 and OUT_33 are completely meaningless; who knows what they are connected to? I always insist that input and output variable names should be closely related to the device’s function, like “Pump1_Run_Feedback”—it’s immediately clear that it refers to the running feedback of Pump 1.
Now, let’s talk about hardware configuration. Many people don’t even consider what the actual input voltage is; they just connect a 24V sensor to a 24V input card. That’s fine, but some low-voltage sensor signals must use the PLC’s built-in 24V input module, adding a bunch of intermediate relays for level conversion. Isn’t that just asking for trouble? It would be much simpler to use an analog input card directly.
By the way, speaking of input cards, in 2019, I went to a plastic injection factory where a technician configured all sensors using high-speed counting cards. When I asked why, he said, “I’m afraid the regular input card won’t capture the signal.” I just laughed… using a high-speed card for regular switch sensors is a waste! That factory spent at least an extra 30,000 yuan unnecessarily.
plcio
Pitfalls of PLC I/O Mapping
Many people do not understand the PLC scanning cycle and I/O refresh mechanism, leading to confusion. PLC is not a real-time system! Signals that change multiple times within the scanning cycle may not be read at all. I once saw a technician from an automation equipment factory using a standard input card to capture high-frequency pulses, which simply didn’t work. The problem was solved by switching to a high-speed card, but he didn’t understand how to change the program scanning method, resulting in data processing still being a mess.
Then there are those who misuse absolute addressing. They directly use I0.0, Q0.1, etc., all over the program, thinking they have a great memory. Wait until you come back to modify the program in two months, and I guarantee you’ll be lost. After being burned by this in my early years, I started using symbolic names exclusively. Whether it’s pump start or valve switch, I always use variable names with actual meanings, making the code easy to understand.
I had a client who previously used AB PLCs, but later switched to domestic ones to save money, resulting in a completely different I/O address allocation method, making them question their life while modifying the program. This is the result of not doing proper symbolic programming. I have told them countless times, program using symbolic names instead of hard addresses; this makes platform migration easier, but they just wouldn’t listen and had to regret it after the fact.
Don’t think I’m making it sound easy; I made mistakes myself in 2018. Once, while working on a production line at an automotive factory, a signal was transmitted from one PLC to another via PROFINET, and during transmission, some bits were inexplicably flipped. After several days of searching, I discovered it was due to different byte orders in PLCs from different manufacturers, which is known as the “endianness” problem. I wasted three whole days, working late into the night, and my wife almost divorced me.
// Example of S7-1500 mapping
"Tank1_Level_High" AT %I0.0; // High level switch for Tank 1
"Tank1_Level_Low" AT %I0.1; // Low level switch for Tank 1
"Pump1_Start" AT %Q0.0; // Start for Pump 1
io
Correct I/O Handling Methods
First, regarding variable naming, my habit is to use “DeviceName_Function_SignalType,” such as “Mixer1_Motor_Run.” This way, when you modify the program later, you can easily find the variable. I have maintained this naming standard for 15 years, whether it’s Siemens or AB, I do it this way.
Next, let’s discuss I/O organization. I generally try to group related I/O signals together, for example, all signals for a pump station in one place, and all signals for a conveyor belt in another. This way, when you perform fault analysis, you don’t have to search through a large number of I/Os for a long time.
By the way, particularly regarding AB’s ControlLogix, many people like to use the Producer/Consumer model to organize I/O data, which is fine, but the trouble is they don’t know how to handle communication loss issues. Last year, we took over a production line and encountered sporadic communication failures, only to find that the original programmer hadn’t considered communication timeout detection, leading to upstream and downstream devices getting out of sync, wasting a lot of materials!
Another pitfall is that different types of PLCs have different input filtering times. I remember once at a steel mill using the Siemens 1500 series, I set the digital input filtering time to the minimum for quick response, but when the arc welding machine started, the input signals went haywire, full of interference… I had to adjust the filtering time to resolve it. On-site debugging is always more complex than theory; the theoretical conditions in books fall apart under harsh working conditions.
// Communication monitoring example - Don't copy directly, the idea is more important than the code
if Timer.DN and not CommOK then
AlarmBit := 1; // Communication failure alarm
StopSystem(); // Safe shutdown
end_if;
Ultimately, good I/O variable definitions make your program maintainable. I have seen too many programmers who only care about getting it to run without considering future maintenance; when the equipment runs for five or ten years, making changes or upgrades becomes a nightmare. A paper factory contacted me two years ago, saying their equipment was aging and needed to replace some I/O modules, but the original program was written directly with addresses and had no documentation, which was a painful experience… I ended up rewriting half the program to get it done.
What annoys me the most are those who, to save time, stuff all variables into a global table. Classification is important! Store I/O variables and internal variables categorized by function blocks; this is basic skill. Especially in large projects, with thousands of I/O points, if you don’t categorize, you can expect to be overwhelmed.
By the way, remember to document well! Not the kind of formalistic nonsense, but a solid I/O reference table that clearly indicates what device each physical point is connected to, what the variable names are, and what special processing logic exists. It may seem tedious, but it saves a lot in maintenance later.
Back when I first entered the industry, I spent a whole week working overtime at an automotive factory, chasing down all the wrong information provided by the client, tracking each I/O point one by one. Since then, the first thing I do on a project is establish a complete I/O table, print it out, and carry it with me; it has saved me so much trouble.
Lastly, let me say, don’t expect a perfect solution. Every factory environment is different, and each PLC platform has its own characteristics; blindly copying experiences can sometimes lead to disaster. Experiment more, ask questions, and consult experienced mentors; mastering the principles is far more important than rigidly applying rules. I’ve gone through this, and so should you.
Before you leave, remember to click “Looking”~