PLC实战避坑指南：从IO分配到西门子1200程序框架的90条经验

1. 入行前三年我把PLC实战踩过的坑都翻了出来刚入行那会儿我总觉得PLC编程就是“把梯形图连起来让设备动起来”这么简单。直到第一次独立负责一条包装线的程序调试才发现事情远没有想象中那么顺利——IO分配表改了七版、模拟量信号跳得像个心电图、通讯偶尔断得莫名其妙。后来带过几个新人发现他们踩的坑和我当年几乎一模一样。所以我把入行1到3年这段时间里关于PLC编程、IO分配、梯形图逻辑、西门子1200程序框架这些方面积累的90条实战经验整理出来每天更新几条既是给自己做复盘也希望能帮到刚入行或者正在被项目折磨的朋友。这些经验不聊虚的全是现场调试时真正会遇到的问题。比如为什么你的梯形图输出和输入逻辑总是对不上、西门子1200的程序框架怎么搭才不容易乱、IO分配表怎么做才能让接线和编程都不打架。适合谁看如果你刚入行1到3年能独立写一些简单程序但遇到复杂项目就发怵或者你正在从三菱、信捷往西门子平台转那这些内容应该能帮你少走不少弯路。每条经验我都会尽量说清楚“为什么这么做”和“不这么做会怎样”毕竟现场调试的时候一个细节没注意到可能就是半天的返工。2. 先搞明白PLC程序框架到底在搭什么2.1 为什么你的程序越写越乱很多人写PLC程序是从“设备动作”出发的按下启动按钮气缸伸出电机转动阀门打开。这种写法在单台设备上没问题但一旦项目稍微复杂一点比如一条线上有十几个工位、几十个气缸、好几台变频器程序就会变成一团乱麻。我见过最夸张的一个项目主程序里塞了三千多步梯形图没有任何子程序划分后来设备要加一个报警提示原作者自己都找不到该往哪里加。问题的根源在于没有提前规划程序框架。PLC程序框架说白了就是给程序搭一个“骨架”让不同的功能模块各归各位。就像盖房子你不能先把家具搬进去再砌墙得先有承重结构再填砖加瓦。一个合理的框架应该包含几个基本部分初始化模块、手动/自动切换模块、报警处理模块、通讯模块、以及各个工位或设备的独立控制模块。每个模块各司其职互相之间通过清晰的接口变量来传递状态。以西门子1200为例我习惯把程序分成几个FC功能和FB功能块。FC用来放那些不需要保持状态的逻辑比如IO映射、报警汇总FB用来放需要保持状态的功能比如气缸控制、电机启停。每个FB都有自己的背景数据块这样即使同一个FB被调用多次各自的状态也不会互相干扰。这个习惯一旦养成后面维护起来会轻松很多。2.2 西门子1200的程序框架怎么搭才顺手西门子1200的编程环境和三菱、信捷有比较大的区别尤其是块的概念和数据类型的严格程度。三菱的编程软件里你可以随手写一个M0、M100不需要提前定义但在西门子1200里你最好先规划好变量表把每个IO点、每个中间变量都定义清楚。刚开始会觉得麻烦但项目稍微大一点这个习惯能救命。我一般会按这样的结构来组织1200的程序OB1主循环只放各个功能块的调用不写具体逻辑。这样一眼就能看出整个程序的执行顺序。OB100启动初始化放上电初始化的内容比如复位一些标志位、给某些变量赋初值。FC1IO映射把所有物理输入输出点映射到中间变量。这样做的好处是后面如果硬件接线改了只需要改这一个FC不用满程序去找I0.0、Q0.1。FC2报警处理汇总所有报警信号做统一的报警输出和复位逻辑。FB1到FBn设备控制每个工位或每台设备一个FB内部包含手动、自动、报警、互锁等逻辑。DB块数据存储用来存配方、参数、累计产量这些需要掉电保持的数据。这个框架不是死的你可以根据项目大小调整。但核心思路是让每一块逻辑都有明确的归属不要让任何一段程序变成“孤儿”。我见过有人把所有逻辑都塞在OB1里结果后来要加一个手动模式改了十几处地方还漏了两处调试的时候设备直接撞机。2.3 程序框架搭好之后调试效率能差多少说一个真实的对比。我之前带过两个新人做类似的项目都是控制一台简单的装配机。A新人没有框架概念程序从头写到尾调试的时候发现气缸动作顺序不对改了主程序里的几行结果影响了另一段逻辑又得回头改。B新人先花了一个小时画框架图把气缸控制封装成FB每个气缸调用一次。调试的时候发现某个气缸动作不对只需要改那个FB所有调用它的地方自动生效。最后A新人调试用了两天B新人用了半天。程序框架的价值在项目初期看不出来甚至会觉得“搭框架浪费时间”但到了调试和维护阶段差距就非常明显了。而且框架搭得好程序的可读性会高很多别人接手你的项目时能很快看懂逻辑这对团队协作来说非常重要。3. IO分配这件事做对了能省一半调试时间3.1 IO分配表不是随便填填就行IO分配表看起来简单就是把每个输入输出点对应什么信号写清楚。但实际操作中我见过太多因为IO分配没做好导致的返工。最常见的问题是输入点和输出点混在一起排、没有预留备用点、没有考虑信号类型分组。先说输入输出混排的问题。有些工程师为了“省线”把输入点和输出点交叉排列比如I0.0、Q0.1、I0.2、Q0.3这样。接线的时候可能觉得没什么但调试的时候就会发现万用表量电压要来回换位置查线效率很低。我习惯把输入点集中排在一起输出点集中排在一起中间留出明显的分隔。这样接线的时候输入端子排和输出端子排是分开的查线也方便。再说预留备用点。很多项目在初期规划的时候觉得“我就这几个信号不用留备用”。但实际做项目甲方临时加一个传感器、加一个指示灯是常有的事。如果IO点已经用满了要么换更大的PLC要么加扩展模块成本和时间都上去了。我的经验是输入输出各预留至少10%的备用点。比如你算下来需要20个输入点那就选24点的输入模块或者用32点的模块留出余量。3.2 输入和输出在梯形图里的区别新手最容易搞混经常有新人问我“为什么我的梯形图里输入点用常开触点输出点用线圈但设备就是不动作”这个问题往往出在对输入和输出物理特性的理解上。输入点I点反映的是外部信号的状态。比如一个常开按钮不按的时候是断开的按下的时候是接通的。所以在梯形图里如果你想让按钮按下时执行某个动作就用常开触点| |。但如果你接的是一个常闭按钮不按的时候是接通的按下时断开那梯形图里就要用常闭触点|/|才能实现“按下时执行”。输出点Q点则是PLC去驱动外部负载的信号。梯形图里输出线圈得电对应的Q点就有输出。但这里有个坑输出点的初始状态。有些设备要求上电时输出不能立即接通否则可能造成危险。这时候就需要在程序里做处理比如用初始化脉冲或者安全条件来限制输出。还有一个容易混淆的地方是模拟量输入输出。模拟量输入比如IW64读回来的是一个数值不是简单的0或1。你需要根据传感器的量程和PLC的转换精度把这个数值换算成实际的物理量。比如一个4-20mA的压力传感器量程是0-10barPLC读回来的数值是0-27648那你就需要写一个换算程序把27648对应到10bar。这个换算过程如果搞错了设备可能就会误动作。3.3 一个实用的IO分配表模板我一般用Excel来做IO分配表包含这几列地址、信号名称、信号类型、信号来源/去向、常开/常闭、备注。下面是一个简单的示例地址信号名称类型来源/去向常开/常闭备注I0.0启动按钮数字量输入操作面板常开绿色按钮I0.1停止按钮数字量输入操作面板常闭红色按钮I0.2气缸1前限位数字量输入磁性开关常开I0.3气缸1后限位数字量输入磁性开关常开Q0.0气缸1电磁阀数字量输出电磁阀-单电控Q0.1运行指示灯数字量输出指示灯-绿色这个表格看起来简单但实际做项目的时候我会把它打印出来接线的时候对着表格接编程的时候也对着表格写。这样能最大程度避免“接错线”和“写错点”的问题。而且项目做完之后这个表格就是一份完整的文档后面维护的时候直接查表就行。提示IO分配表一定要在项目开始前就做好不要边接线边改。改一次表格可能就要改接线、改程序、改触摸屏牵一发而动全身。4. 梯形图编程的那些实战细节4.1 梯形图不是“画出来就行”逻辑顺序很重要梯形图编程看起来直观但里面的逻辑顺序非常关键。PLC执行梯形图是从上到下、从左到右扫描的。这意味着如果你把一段逻辑放在另一段逻辑的后面前面的逻辑结果会影响后面的判断。举个例子假设你要实现“按下启动按钮电机运行按下停止按钮电机停止”。如果你先写停止逻辑再写启动逻辑那么当启动按钮和停止按钮同时按下时停止逻辑先执行电机停止然后启动逻辑执行电机又启动。最终结果是电机启动这显然不符合“停止优先”的安全要求。正确的做法是把停止逻辑放在启动逻辑的后面这样停止信号会覆盖启动信号。这个细节在简单的程序里可能不明显但在复杂的互锁逻辑里顺序错了可能导致设备误动作甚至安全事故。我个人的习惯是安全相关的逻辑急停、限位、故障放在最前面操作逻辑启动、停止、手动放在后面。这样即使操作逻辑写错了安全逻辑也能兜底。4.2 定时器和计数器的使用陷阱定时器和计数器是梯形图里最常用的指令但也是坑最多的。先说定时器。西门子1200的定时器有TON、TOF、TP、TONR几种类型每种的行为都不一样。TON是接通延时TOF是断开延时TP是脉冲定时器TONR是保持型接通延时。如果你用错了类型设备动作的时序就会完全不对。比如你要实现“按下按钮后电机运行5秒后自动停止”。这个逻辑应该用TON按钮按下TON开始计时5秒后TON输出接通用这个输出去断开电机。但如果你用了TOF按钮按下时电机立即运行按钮松开后TOF开始计时5秒后电机停止。这跟你的需求完全不一样。计数器也有类似的问题。西门子1200的计数器有CTU加计数、CTD减计数、CTUD加减计数。用CTU的时候要注意计数脉冲的宽度。如果脉冲太窄PLC可能扫描不到导致计数丢失。我遇到过一个问题用光电传感器计数产品通过的速度很快脉冲宽度只有几毫秒结果计数总是少几个。后来换了一个高速计数器模块才解决。注意定时器和计数器的编号不要重复使用。有些工程师习惯用T1、T2、T3这样顺序编号但如果在不同的程序块里用了同一个编号可能会互相干扰。我习惯在编号前面加上功能前缀比如T_Conveyor1、C_Product这样一眼就能看出用途。4.3 模拟量处理的几个关键参数模拟量处理是很多新手的噩梦。4-20mA信号、0-10V信号、热电偶、热电阻每种信号的换算方式都不一样。但核心逻辑其实很简单把PLC读回来的整数值线性映射到实际的物理量程。以西门子1200为例4-20mA信号对应的整数值是0-27648。假设你的压力传感器量程是0-16bar那么换算公式就是实际压力 (读取值 / 27648) * 16这个公式看起来简单但有几个细节要注意。第一读取值的范围。如果传感器断线读取值可能是负数或者超过27648这时候需要做断线检测。第二滤波。模拟量信号容易受干扰读回来的值可能会跳动。我一般会做一个简单的滑动平均滤波比如取最近10次的平均值这样显示出来的数值会稳定很多。第三量程对应关系。有些传感器的4mA对应的是负值比如-10bar到10bar那换算公式就要调整。还有一个容易忽略的点是模拟量输出的反向换算。如果你要控制一个比例阀PLC输出0-27648对应阀的0-100%开度那你就需要把目标开度换算成整数值再输出。这个换算和输入是反过来的写程序的时候要特别注意。5. 通讯和SCADA连接中容易卡住的地方5.1 PLC和SCADA连接为什么总是连不上SCADA和PLC连接是很多项目里绕不开的环节。但实际操作中经常遇到“SCADA显示通讯失败”或者“数据读回来是乱码”的情况。根据我的经验问题通常出在几个地方通讯协议不匹配、IP地址或端口号错误、数据地址映射不对。先说协议。西门子1200支持多种通讯协议比如S7通讯、Modbus TCP、OPC UA。SCADA软件支持的协议也各不相同。如果你用的SCADA只支持Modbus TCP那PLC这边就要配置成Modbus TCP服务器。配置的时候要注意Modbus的寄存器地址和PLC的DB块地址不是一一对应的需要做一个映射表。我见过有人直接把DB1.DBD0映射到Modbus的40001结果读回来的数据完全不对因为Modbus的寄存器是16位的而DBD是32位的需要拆成两个寄存器来读。再说IP地址和端口。这个看起来简单但实际调试的时候经常因为IP地址冲突或者端口被防火墙挡住而连不上。我的习惯是在项目开始前就规划好IP地址段PLC、触摸屏、SCADA服务器、交换机都分配固定的IP并且记录在文档里。调试的时候先ping一下确认网络通不通再检查端口。5.2 不同品牌PLC的通讯设置差异不同品牌的PLC在通讯设置上差异很大。三菱的PLC常用MC协议信捷的PLC支持Modbus和以太网汇川的PLC有Codesys平台和自家协议倍福的PLC基于EtherCAT。如果你在一个项目里混用了不同品牌的PLC通讯配置就会变得很复杂。我做过一个项目主控是西门子1200下面挂了三菱FX系列和信捷XD系列。西门子1200通过Modbus TCP读三菱和信捷的数据。三菱这边需要配置以太网模块设置好IP和端口然后在PLC里写通讯程序信捷这边相对简单直接支持Modbus TCP服务器只需要把要通讯的寄存器地址整理出来就行。但调试的时候发现三菱的Modbus TCP和信捷的Modbus TCP在寄存器地址的编排上不一样三菱的地址是从0开始信捷的地址是从1开始差了一位。这个细节如果不注意读回来的数据就会错位。所以我的建议是混用不同品牌PLC的时候一定要先查清楚每个品牌的通讯手册把地址映射表做出来再开始写程序。不要凭经验想当然不同品牌的“惯例”可能完全不一样。5.3 通讯中断的排查思路通讯中断是现场调试最常见的问题之一。我的排查思路一般是这样的先看物理层网线插好了吗交换机指示灯亮不亮如果是串口通讯接线对不对终端电阻有没有再看网络层IP地址能不能ping通端口能不能telnet通然后看协议层用调试工具比如Modbus Poll模拟SCADA去读PLC看能不能读到数据。最后看应用层SCADA里的地址映射对不对数据类型对不对这个顺序看起来简单但实际排查的时候很多人会跳过前面几步直接去改程序结果越改越乱。我个人的经验是80%的通讯问题都出在物理层和网络层真正协议层和应用层的问题反而比较少。所以遇到通讯中断先检查网线、交换机、IP地址往往能快速定位问题。提示如果通讯偶尔中断但重启后又正常很可能是电磁干扰导致的。检查一下通讯线有没有和动力线走在一起屏蔽层有没有接地。这个问题在变频器附近特别常见。6. 那些年我踩过的坑和总结的避坑技巧6.1 程序下载后设备不动先查这几个地方程序下载到PLC之后设备不动这是新手最常遇到的问题。我总结了一个排查清单按顺序查下来基本能覆盖90%的情况排查项可能的问题解决方法PLC运行模式PLC处于STOP模式切换到RUN模式输入信号输入点没有信号检查传感器、按钮、接线输出信号输出点没有输出检查程序逻辑、输出模块供电程序逻辑互锁条件不满足在线监控看哪个条件没满足硬件接线输出负载没接好检查继电器、接触器、电磁阀接线安全条件急停、安全门未复位检查安全回路这个表格我一般会打印出来贴在工位上遇到问题就按顺序查。看起来简单但实际调试的时候人容易慌一慌就乱查。按清单来效率会高很多。6.2 程序备份和版本管理别等丢了才后悔我吃过一次大亏。一个项目调试了半个月程序改了好几版但没有做备份。结果有一天笔记本电脑硬盘坏了程序全没了。只能凭记忆重新写花了三天才恢复到之前的版本。从那以后我养成了几个习惯每天下班前备份程序按日期命名比如“20250115_包装线_v3”。用Git做版本管理虽然PLC程序是二进制文件但可以记录每次修改的内容和原因。重要节点做归档比如“调试完成版”、“客户验收版”、“最终交付版”。这些习惯看起来麻烦但真到了需要回退版本的时候能省下大量时间。而且程序备份不仅仅是防丢也是对自己工作的记录。过几个月回头看能清楚地知道当时为什么这么改。6.3 和机械、电气配合的那些门道PLC工程师不是孤立的你需要和机械工程师、电气工程师配合。配合得好项目顺利配合不好互相甩锅。我的经验是在项目开始前一定要和机械、电气一起过一遍IO分配表和动作流程图。机械工程师知道每个气缸、电机的动作顺序和时序要求电气工程师知道每个传感器的安装位置和信号类型。你把IO分配表拿出来让他们确认能提前发现很多问题。比如机械工程师说“这个气缸的动作时间只有0.5秒”那你就要考虑PLC的扫描周期和传感器的响应时间能不能跟上。电气工程师说“这个传感器是NPN的”那你就要注意输入模块的公共端接法。我见过一个项目机械设计了一个气缸行程很短动作时间只有0.3秒。PLC程序里用了普通的定时器结果气缸还没到位程序就判断超时报警了。后来换了高速定时器并且调整了传感器的安装位置才解决问题。如果前期沟通到位这个问题在编程阶段就能避免。6.4 新手最容易忽略的细节注释和文档最后说一个看起来不重要但实际上影响深远的事情注释和文档。很多新手写程序不喜欢写注释觉得“我自己看得懂就行”。但实际情况是过三个月你自己都看不懂了更别说别人接手。我的习惯是每个变量都写注释每个FB/FC都写功能说明每个网络段都写逻辑说明。注释不需要很长但要能说清楚“这个变量是干什么的”、“这段逻辑实现了什么功能”。比如一个气缸控制FB我会在开头写清楚输入信号有哪些、输出信号有哪些、手动模式怎么操作、自动模式怎么操作、有哪些报警条件。文档方面除了IO分配表我还会整理一份程序结构说明把每个FB/FC的功能、调用的位置、相关的DB块都列出来。这样即使项目交付很久之后有人来维护也能快速上手。提示西门子1200的变量注释可以直接在PLC变量表里写梯形图里的网络注释可以在每个网络上方添加。这些注释会跟着程序一起下载到PLC里在线监控的时候也能看到非常方便。7. 从入门到能独立做项目中间差了什么7.1 独立做项目和跟着别人做区别在哪里跟着别人做项目的时候你只需要负责一部分逻辑遇到问题有人兜底。但独立做项目你需要考虑的事情多得多硬件选型、IO分配、程序框架、通讯配置、触摸屏画面、调试计划、文档整理每一项都不能少。我刚开始独立做项目的时候最不适应的是“没有人告诉你下一步该做什么”。跟着别人做的时候师傅会说“你今天把这个气缸的逻辑写了”你只需要执行。独立做项目的时候你需要自己规划先做什么、后做什么、哪些可以并行、哪些必须等前面完成。我的经验是独立做项目之前先做一份详细的计划表。把项目拆成几个阶段硬件选型和IO分配、程序框架搭建、各模块编程、通讯配置、触摸屏画面、联调、文档整理。每个阶段再拆成具体的任务估算时间。这样即使遇到问题也能清楚地知道进度到了哪里不会手忙脚乱。7.2 遇到没做过的功能怎么快速上手做项目难免遇到没做过的功能比如第一次做PID控制、第一次做伺服定位、第一次做Modbus通讯。这时候不要慌我的方法是先找官方手册和示例程序再找类似项目的参考最后自己动手试。官方手册是最权威的资料尤其是西门子的手册写得很详细还有示例程序。比如你要做PID控制西门子1200有专门的PID指令块手册里会告诉你每个参数怎么设置、怎么整定。先照着示例做一遍理解了基本原理再根据实际项目调整。如果官方手册看不懂可以找一些技术论坛的帖子看看别人是怎么做的。但要注意论坛里的内容质量参差不齐有些方法可能已经过时了或者不适合你的项目。所以最终还是要以官方手册为准。7.3 怎么判断自己已经能独立做项目了这个问题没有标准答案但我觉得有几个标志可以参考能独立完成IO分配和程序框架设计不需要别人帮你规划。遇到问题能自己排查而不是第一时间问别人。能看懂别人的程序并且能在此基础上修改和扩展。能写出清晰的文档和注释让别人能看懂你的程序。能预估项目周期并且按计划推进。如果你能做到这几点基本上就可以独立做项目了。当然独立做项目不代表不需要学习每个项目都会遇到新的问题保持学习的心态很重要。8. 关于每天更新这90条经验的一些说明这90条经验不是一次性写完的而是我在实际项目中遇到问题、解决问题、总结问题之后一条一条积累下来的。有些是技术细节比如定时器的使用陷阱有些是工作方法比如程序备份和版本管理有些是沟通技巧比如和机械、电气配合。每条经验背后都有一个真实的故事要么是我自己踩过的坑要么是我看到别人踩过的坑。每天更新几条一方面是给自己一个持续复盘的动力另一方面也是希望能和更多同行交流。PLC这个行业技术更新不算快但应用场景千变万化每个人的经验都有独特的价值。如果你在看这些经验的时候能想起自己曾经遇到过的类似问题或者能帮你避免一个即将踩到的坑那这些内容就有意义了。后面我会继续更新剩下的经验包括伺服控制、变频器通讯、安全PLC、程序加密这些话题。如果你有特别想了解的内容也可以告诉我我会根据大家的反馈调整更新的方向。毕竟经验这东西分享出来才有价值。