PLC工程师入行三年实战心得：选型、通讯、仿真与故障排查全攻略

入行1-3年，是PLC工程师最分裂的三年。前半年你还在纠结“这个程序会不会把设备搞炸”，后两年你已经能在客户现场一边改程序一边跟产线班长唠嗑了。这三年里，我摸过三菱FX系列、西门子S7-1200，也换到过汇川Easy系列和Codesys平台，踩过的坑比写过的注释还多。所以我把这段时间的实战心得整理成了90条经验，原本是每天更新几条，这篇按主题归置成六个部分，把最常见、最影响交付质量的部分一次性放出来。

这六部分对应入行头三年最该打磨的六块能力：选型与编程规范、仿真工具的正确用法、对外通讯（SCADA、触摸屏、上位机、变频器）、典型工艺控制程序、故障排查思路，以及AI工具和职业习惯。不管你用的是西门子、三菱、汇川还是其他品牌，大部分经验是通用的——通讯参数、接线极性、排查顺序这些东西，换个品牌一样成立。

1. 选型与编程规范：决定项目成败的是前两周的决定

1.1 选型先做三件事：点数、通讯、余量

很多新人拿到需求，第一反应是“哪个品牌熟就用哪个”。我见过只会三菱的工程师，结果设备要跟MES系统走OPC UA通信，老型号FX系列根本不支持，最后硬加一个网关模块才把项目救回来。选型这件事，不该先谈个人习惯，应该先做三个动作。

第一，点数。把所有数字量输入、输出、模拟量通道列成表格，再乘上1.2到1.3的余量。别小看这个余量，客户说“以后要加个料位计”的时候，预留的那两路模拟量通道就是救命稻草。我在一个包装线项目里吃过亏，当时觉得点位刚好够，结果客户上线前突然要加3个光电传感器，程序好改，硬件没地方接，最后只能加扩展模块，还耽误了交货。

第二，通讯。设备未来要跟什么通信？是SCADA、触摸屏、变频器、伺服，还是上位机用C#自己写的程序？不同的连接方式决定了PLC要不要带以太网口、有几路串口、要不要加通讯模块。西门子S7-1200自带Profinet口，连SCADA很轻松；但要跟老设备走Modbus RTU，就得用CM1241这类通讯模块。三菱FX5U自带以太网口支持MC协议，老款FX3U就要加通讯扩展板。

第三，品牌生态与备件。设备交付后，客户的电工只认他们熟悉的品牌，备件采购也倾向于已有的品牌。我做过一个大棚灌溉项目，客户全厂都是西门子，那选型就不会为了便宜去换其他品牌——后期维护顺畅比采购省那点钱重要得多。基于西门子做的大棚灌溉系统，温湿度传感器、电磁阀、水泵都是通过模拟量输入和数字量输出控制的，选型时还要额外考虑户外防护等级。

这个表不是让你照搬，而是让你养成习惯：先列需求，再列平台，最后才谈喜好。经验01说白了就是一句话——选型是工程决策，不是个人偏好。

1.2 写程序前先定规范：I/O表、命名、注释一个都不能少

经验02是我吃了很多亏才得来的。刚入行时我接过一台旧设备的维护任务，打开程序一看，变量名是DB1.DBW4、M0.0、Y0这种东西，梯形图里没有任何注释，唯一的“线索”是在CALL语句边上写了几个字：“有问题看这里”。你根本不知道哪里是“这里”。所以我现在每写一个程序，不管项目大小，都会做三件事。

第一，I/O表和符号表先行。数字量命名用“信号类型_设备名_功能”格式，比如DI_Pump1_Run代表1号泵的运行反馈，DO_Pump1_Start代表启动输出。模拟量用AI_Tank1_Temp代表1号罐温度。三菱的注释写在GX Works的注释栏里，西门子写在PLC变量的符号名里，汇川的软件也支持符号表。花半天定命名规则，编程过程中能少问自己十次“这个点是干嘛的”。

第二，注释写“为什么”，不是写“做了什么”。很多人标注释习惯写“延时3秒”，但真正有用的注释是“延时3秒是为了等气缸完全伸出后再触发夹爪，防止夹空”。前者只搬运代码，后者才记录设计意图。半年后改程序的人（大概率就是你自己）看到这样的注释，才敢放心动，而不是提心吊胆。

第三，理解你用的定时器和计数器的平台特性。S7-1200用IEC定时器，TON、TOF的每个定时器是独立DB块，没有编号冲突问题；三菱FX系列用T0到T255，同一个编号在程序里不能重复使用，否则后一个指令会覆盖前一个的设定值和当前值。计数器同理，三菱的C0~C255要管理好编号。还有一个新人常犯的错：用扫描周期数自己凑延时——“扫描1000次就等于延时多少毫秒”，这绝对不要做。扫描周期会随程序大小、通讯负载变化，这样延时等于给自己埋定时炸弹。

这里必须提一下西门子的EN和ENO。EN是使能输入，ENO是使能输出。很多从三菱转西门子的工程师，会在每个功能块外面都套ENO判断，程序变得又长又难读。正确的是只在需要传递块内部错误状态的场景使用，比如除法溢出、访问越界这类异常。ENO是用来传播异常的，不是用来做业务逻辑跳转的。把EN/ENO用对地方，程序能省下一大半网络。

2. 仿真环境：能省三小时，也能坑你三整天

2.1 S7-PLCSIM Advanced启动不了？按这个顺序排查

S7-PLCSIM Advanced v5.0，很多人装了之后在TIA Portal里点启动虚拟PLC，结果实例状态一直是红色，或者干脆没反应，而且没有任何报错弹窗。我第一次遇到时，重装了三次软件都没解决，最后发现根本不是软件问题。这里把排查顺序分享出来，按顺序走一遍，大概率能定位。

第一步，打开设备管理器，展开“网络适配器”，找有没有“Siemens PLCSIM Virtual Ethernet Adapter”。PLCSIM Advanced靠这个虚拟网卡跟TIA Portal通信，安装时如果驱动没装上（常见于精简版系统、杀毒软件拦截），虚拟PLC就起不来。没有这个网卡，就用管理员身份重新运行PLCSIM Advanced安装程序，选择修复安装。

第二步，检查防火墙。PLCSIM Advanced和TIA Portal之间的通信走特定端口，防火墙拦截后会出现“实例建立失败但不报错”的诡异现象。暂时关闭防火墙测试一次，如果好了，就把相关程序加入白名单。

第三步，确认版本搭配。PLCSIM Advanced v5.0一般配TIA V16或V17，如果装的是TIA V18还配旧版PLCSIM，兼容性问题会以各种奇葩方式出现。查看TIA Portal的“已安装软件”和PLCSIM的描述文档，确认版本匹配，这是最容易被忽视的一点。

第四步，处理Error 11。启动实例报Error 11，我遇到的情况多半是虚拟PLC实例名跟项目里的设备名对不上，或者后台已经有一个PLCSIM进程在运行但窗口不见了。打开任务管理器，结束所有PLCSIM相关进程，重新创建实例，用与项目中PLC设备相同的名称。还有人问“PLCSIM实例启动不了且没有报错”，多半就是这四步里的某一个。

提示：仿真工具是辅助手段，不是交付手段。真机调试时间在项目计划里必须单独列出来，别指望仿真压缩这部分工作量。

2.2 仿真能帮你验证逻辑，但骗不了自己

经验07。仿真最大的价值是让你在没有硬件的情况下验证程序逻辑：红绿灯时序对不对、报警联动对不对、状态切换有没有死锁。逻辑层面的东西，仿真能很快帮你查出来。但它有明确的天花板，下面这几类问题仿真绝对不能交付结论。

第一，模拟量标定。真实传感器的4-20mA或0-10V信号，量程、零点、温漂，只有真实硬件上才能标定。仿真里给一个“完美的模拟量值”，你验证的只是换算公式，不是现场的真实数据。

第二，高速计数与运动控制。编码器的高速计数、伺服的脉冲输出、高速中断，仿真对时序的模拟跟真实硬件差着量级。仿真里跑得再顺，现场伺服一动，时序抖动、脉冲丢失就冒出来了。

第三，通讯时序。仿真里跟触摸屏、SCADA通讯通常顺利得不像话，但真实现场有广播风暴、有通讯线缆干扰、有对方设备协议栈的不标准实现。这些只有在联调时才会暴露，所以做项目计划时，把“真机调试”作为独立阶段留时间，不要指望仿真压缩这部分工作量。

还有一个习惯值得养成：在仿真环境里建一个系统性的测试列表，把每个功能点的测试场景、预期结果记录下来。我在仿真里跑四层电梯程序时，写了一个测试清单，把“3楼内选、同时2楼外呼向上”这类组合场景挨个过，比漫无目的地乱按按钮效率高得多。这就是经验08。

3. 通讯实战：SCADA、触摸屏、上位机、变频器全都绕不开

3.1 让SCADA连上PLC，五步走加一条血泪教训

“SCADA如何与PLC连接”是新人问得最多的问题。不管是WinCC、组态王、MCGS还是其他SCADA，连接PLC的流程大同小异，核心五步，我把它总结为经验09。

第一步，确认PLC型号和固件版本，这决定SCADA侧用什么驱动。西门子S7-1200可以选S7协议或Modbus TCP，三菱可以用MC协议或SLMP，汇川Codesys系列可以走Modbus TCP或OPC UA。先确认驱动类型，再往下走。

第二步，在PLC侧把通讯参数配好。以太网就是IP地址、子网掩码，串口就是站号、波特率、数据位、校验位。PLC侧参数不对，SCADA配置得再正确也是白搭。

第三步，在SCADA里添加设备，选择对应驱动，填PLC的IP地址或站号。最容易出的问题不是填错IP，而是驱动版本和PLC固件不匹配。汇川Easy系列在部分SCADA里没有专用驱动时，可以用Modbus TCP通用驱动，但寄存器地址映射要从PLC手册查，不要想当然。

第四步，配置变量表。把PLC的数据区（三菱D区、M区，西门子的DB块）映射到SCADA变量。这里有个坑：DB块变量在SCADA里映射时，偏移地址很容易算错，尤其是结构体里有多种数据类型混排的时候。

第五步，先做连通性测试再做批量建点。这是我踩过最深的坑之一：在包装线SCADA项目里，我一次性导入了几百个变量，结果地址偏移整体漏了一个字节，画面上所有液位、温度数据全部错位，查了整整一个下午。后来养成了习惯，先建5个测试点，确认能读到正确数据，再批量导入。这就是经验10。

MCGS接信捷PLC，很多人反馈“找不到驱动”，多半不是软件问题，而是驱动组件没安装。MCGS的驱动是独立组件包，装完组态软件后还要单独装对应厂商的驱动库。遇到“找不到驱动”，先去官网把对应厂家驱动包下载安装，比在论坛上翻三天帖子管用。

3.2 威纶通找不到汇川PLC驱动，先看软件版本

威纶通触摸屏配汇川PLC是国产设备里的常见组合，但“EBPro软件里找不到汇川驱动”这个问题，我几乎每个月都能看到有人问。其实原因就两个。

第一个原因是EBPro版本太老。威纶通的新驱动跟随软件版本走，老版本里没有新发布的PLC驱动。解决办法很简单：到威纶通官网下载最新版EBPro，更新完再看驱动列表。第二个原因是选错了驱动类型。汇川的AM系列是Codesys平台，Easy系列有一部分是自主平台，不同平台对应不同的驱动。AM系列优先选Modbus TCP驱动或汇川官方发布的AM系列专用驱动，Easy系列则要看具体型号，用对应的以太网驱动或串口驱动。如果驱动列表里确实没有，就用Modbus TCP通用驱动，按汇川手册查寄存器映射。这就是经验11。

顺便说汇川PLC组网。多台汇川PLC组网，通常走Modbus TCP或串口RS485总线。组网时每台站号不能重复，波特率要一致，最后一台设备要加终端电阻。这些是基础，但组网不通的案例里七八成都是站号冲突和终端电阻缺失造成的。松下PLC也常有人问，FP系列串口默认是专用协议Mewtocol，走Modbus RTU要额外配置。通讯参数在编程软件的系统寄存器里设置，改完必须重新上电才生效，这个“改完要断电重启”的细节最容易被忽略。

3.3 三菱PLC通讯协议：别直接抄例程，先看懂帧格式

三菱PLC的通讯协议绕不开MC协议。Q系列、L系列、FX5U都支持，但帧格式有好几种：A兼容1E帧、QnA兼容3E帧、4E帧等。新人在网上找一个例程就改IP地址去用，结果CRC校验算对了也连不上。原因往往是帧头、网络号、站号、请求数据长度，有一个字节对不上。

我的建议是，第一次调三菱通讯时，把电脑当上位机，用串口助手抓一次PLC的回复帧，拿协议手册逐字节比对。做过一次，你就能理解为什么帧头是D0、站号为什么要填FF（表示任意站），比背十遍协议都管用。

串口通讯还有一组“三板斧”检查清单：站号是否冲突、波特率是否一致、数据位/停止位/校验位是否匹配。三菱FX系列的编程口默认是422接口，跟普通232串口不一样，要用USB转422的线才能通讯。很多人拿USB转232线接FX3U编程口，怎么都通讯不上，就是这个原因。这就是经验12。

3.4 上位机C#读PLC，轮询频率别太贪

用C#写上位机读PLC数据的项目很多，“C#读取PLC频率多少合适”被反复问。我一般分两种场景回答。

如果是Modbus TCP轮询，单次请求读取的寄存器数量越少，允许的轮询频率就越低，因为每个请求都有协议开销。实践经验是：单站轮询频率控制在100ms到500ms一次，也就是每秒2到10次，变量尽量用一条03功能码批量读取。一次读50个寄存器、500ms读一次，比一次读5个寄存器、100ms读一次对PLC的压力小得多。PLC的通讯处理器有处理上限，发得太快，PLC响应不过来，要么丢包，要么通讯队列被占满，触摸屏跟着卡。

如果数据更新频率要求高，比如伺服状态要几十毫秒刷新，不要靠上位机高频轮询，应该让PLC主动上报，或者走OPC UA的订阅模式，上位机监听变化事件，效率完全不同。这就是经验13。

还有一个容易忽略的点：C#上位机跟PLC通讯的异常处理一定要健壮。PLC重启、网线断开、对方程序升级，都会造成通讯中断。写好重连机制和超时处理，否则现场PLC一重启，上位机就卡死，这种故障特别掉价，留给客户的印象也特别差。这是经验14。

4. 典型工艺控制：从红绿灯到电梯，练的是状态机思维

4.1 十字路口红绿灯和抢答器，都是状态机的入门课

网上关于十字路口红绿灯PLC程序的版本很多，有只用定时器“硬堆”出来的，也有用状态机写的。我建议新手直接学状态机写法，因为它能迁移到任何“有多个阶段、按条件切换”的工艺场景。

思路是这样的：把信号灯的循环拆成多个状态，每个状态对应一组输出。比如状态0是东西绿灯加南北红灯持续30秒，状态1是东西绿灯闪烁加黄灯持续5秒，状态2是东西红灯加南北绿灯持续30秒。用一个周期脉冲（三菱的M8013或西门子TIA里配置的时钟存储器位）做时基计数，计数值达到当前状态的持续时间，就切到下一个状态。这么做的好处是以后调整绿灯时长，只改状态表里的时间常数，不用翻梯形图里层层嵌套的定时器。这就是经验15。

抢答器也是经典状态机训练题。抢答器的本质是“锁定第一个有效输入”：多人抢答，只有第一个按下有效。用自锁触点能做，但用置位/复位指令写出来逻辑更清晰——检测到某个输入上升沿，立即复位其他所有参与者的输出，并置位当前这位，同时用一个“已锁定”标志禁止后续输入。数字孪生项目里做抢答器程序，逻辑跟实体PLC完全一样，正好用来练状态机思维。

4.2 四层电梯程序：把召唤和登记分开，就成功了一半

四层电梯控制程序是培训学校和企业面试的经典题，也是入行1-3年练手的好项目。看着复杂，拆开之后是三部分：内选登记、外呼登记、方向决策。

内选登记很简单，每层一个内选按钮，按下去登记该层，到达时清除登记。外呼登记稍复杂，因为除了顶层和底层，每层有两个方向的召唤按钮，召唤信号要区分方向。最关键的难点是方向决策：电梯到底继续向上还是掉头向下？

我见过不少人的电梯程序把“谁先按”和“当前往哪走”混在一起，结果电梯在中间层反复横跳。正确的思路是：先按运行方向分类，同方向近处的召唤先响应，响应完再掉头。用数组记录每层召唤状态，用循环扫描找最近的召唤楼层。把“电梯当前楼层”“当前方向”“召唤表”这三组变量定义清楚，程序写起来反而比一团乱麻更快。仿真里跑电梯程序时，把“3楼内选，同时2楼外呼向上”“4楼内选，同时1楼外呼向下”这类组合场景分别测试，就是前面说的测试清单法。这是经验16。

4.3 变频器与PLC联调：ABB和西门子的搭配先定控制方式

ABB变频器与西门子PLC的联调，是设备改造项目里很常见的组合。新人的普遍困惑是：变频器一堆参数，PLC程序里一堆指令，到底哪个对哪个？我的建议是，动手之前先回答一个问题：你用端子控制还是通讯控制？

端子控制，就是用PLC的数字量输出接变频器的DI端子控制启停，用模拟量模块（或变频器上的电位器）给频率给定。优点是指挥直观、可靠、调试快，缺点是频率给定精度受模拟量模块精度影响，且走线多。比较实用的是“启停用硬线、频率给定用通讯”的混合方式：启停信号走数字量端子，频率给定通过Modbus RTU或Profibus DP读写频率寄存器。既保证控制可靠，又减少模拟量走线。这就是经验17。

如果走通讯控制，参数组态的顺序很关键。ABB变频器侧要设好通讯协议、站点号、波特率；西门子S7-1200侧要组态GSD文件，或配置Modbus指令块。最容易出的问题是两边地址映射不一致，变频器的频率给定寄存器在PLC侧映射错地址，现场表现就是频率写不进去。调之前把两边的寄存器地址表打印出来，对照着填，能省一半时间。

4.4 FANUC系统和AB系统的“看不懂符号”问题

FANUC数控系统PMC程序里的R035.1这类地址，经常被截图发到群里问“代表什么意思”。这类地址不能孤立看含义，它是系统内部继电器区域的一个位。R开头的是系统内部继电器，G开头的是来自NC侧（数控系统）的信号，F开头的是发往NC侧（系统对外）的信号，A、K等开头则是保持/非保持的不同区域。

看到R035.1，第一反应不是猜含义，而是在FANUC的PMC编辑软件里搜索这个地址的交叉引用，看它在梯形图的哪些地方被读写。结合上下文，才能判断它是“当前运行中”标志，还是“主轴正转”反馈，又或者是报警触发条件。系统地址和自定义地址的区别在于：自定义地址你能在程序里看到赋值和使用的全过程，系统地址的初始含义要查FANUC的操作手册或PMC维护手册。把R、G、F、A、K这几类区域的划分记清楚，排查PMC问题会顺利很多。这是经验18。

类似的还有美国AB（罗克韦尔）PLC里的“SWJ”这类符号。AB的RSLogix/Studio 5000里并没有一个叫SWJ的标准指令，所以看到它第一反应同样是用交叉引用查它在程序里的使用位置。AB PLC的程序文件和数据文件分配方式跟三菱、西门子差别很大，很多“看不懂”的符号其实是项目里自定义的标签名或文件类型。用交叉引用和帮助文档去查，比问群友快。

5. 故障排查实录：宕机、干扰、接线，三座大山一次说清

5.1 PLC宕机无响应，先查电源、接地、程序三个方向

导致PLC宕机的原因很多，但现场经验告诉我，大部分都不是程序bug，而是物理层面的问题。排查顺序我固定为三步。

第一步，查电源。用万用表测24V电源模块输出电压是否稳定，有没有在设备运行时出现电压跌落。很多设备启动瞬间电流大，电源功率不够，电压一下拉低，PLC就会重启或无响应。我遇到过一台设备老“死机”，排查到最后是开关电源容量按总电流刚刚好选的，一点余量都没留，设备一启动就过载保护。换大一级电源后一切正常。经验值是电源容量至少留30%的余量。这是经验19。

第二步，查接地。PLC的FG端子要接柜体接地排，模拟量信号线屏蔽层要单端接地（通常在PLC侧或柜体侧，不要两端都接，否则形成接地环路）。不接地或接地方式不对，在干扰大的环境，PLC会不定期出现输入跳变、通讯偶发中断，查程序怎么都查不出来，最后往往是接地问题。

第三步，查程序。电源和接地都正常，再看程序里有没有异常逻辑。重点怀疑：不合理的循环等待（用死循环等一个信号，占满扫描周期）、间接寻址越界、数组下标越界。西门子S7-1200的DB块访问越界会触发诊断缓冲区，三菱的间接寻址越界会在特殊寄存器记录错误编号。查看诊断缓冲区和错误寄存器，比翻梯形图快得多。

还有一个容易被忽视的“宕机”原因：通讯风暴。第三方设备通过交换机频繁发广播包，把PLC通讯队列堵满，PLC虽然没死，但对外通讯全部超时，看起来就像宕机。排查方法是查看交换机端口流量，或拔掉可疑设备逐台测试。解决思路是用交换机划分VLAN、做端口隔离。这是经验20。

5.2 输入输出接线：九成的“程序错误”出在线路上

西门子PLC的接线是新人重灾区。先说数字量输入，要区分漏型和源型：漏型输入是电流从模块流向传感器公共端，适合NPN型传感器（输出低电平有效）；源型输入是电流从传感器公共端流向模块，适合PNP型传感器（输出高电平有效）。很多“传感器没信号”的现场问题，其实是传感器类型和输入模块极性不匹配，换类型或调整公共端接线就好了。这是经验21。

数字量输出也有讲究。PLC的输出点（继电器型或晶体管型）不能直接驱动大负载，接触器线圈、电磁阀这类感性负载要经过中间继电器过渡，触点容量不够直接烧输出点的案例太多了。晶体管输出还要注意负载极性，防止感性负载关断时的反电动势打坏输出管，感性负载两端并接续流二极管或阻容吸收是常规操作。这是经验22。

第三个问题是公共端。三菱PLC的输入COM端要按说明书把正极或负极接对，输出COM端的电源根据负载类型接24V或220V。接错公共端，轻则信号不动作，重则烧模块。很多“程序写对了但设备不动作”的问题，最后都回到接线图核对上。

注意：涉及安全回路的逻辑（急停、安全门、光栅）必须用硬接线和经过评审的安全逻辑实现，绝不能让程序逻辑单独承担安全职责。

5.3 时间到期自动停机：设备管理的合规实现

“PLC怎么设置时间到期自动停机”的需求，常见于设备租赁、分期付款、试用期管理场景。实现思路不复杂：利用PLC的实时时钟（RTC）读取当前日期时间，跟程序里设定的到期时间比较，到期后把设备置入锁定状态——停止主输出，触摸屏显示到期提示。

具体来说，西门子S7-1200可以用READ_RTC指令读取系统时钟和设定值比较；三菱FX5U有内置RTC，也能读特殊寄存器获取日期时间。比较结果置位一个锁定标志，用这个标志切断运行允许电路。如果业务流程允许到期后延续使用，可以设计解锁授权方式，比如输入授权码延长使用期，或通过远程通讯从厂家服务器获取授权。

这里的关键提醒是，不能只在程序里写一个简单比较就完事。CPU的RTC可以手动修改，操作人员把系统时间改回一个月前，锁定就失效了。要做就把到期锁定标志放在带电池保持的存储区，同时写日志记录。更重要的是，这类功能的启用一定要和合同、法务确认清楚，涉及设备所有权和合同义务，技术实现之外要有授权协议支撑。这是经验23。

从工程伦理角度补一句：这类功能的设计初衷是保障设备厂商的合法权益，不是让你给正常设备做恶意后门。任何控制功能都要以合法合规为前提，技术方案之外，协议和授权流程必须先行。

5.4 干扰问题：程序偶发跳变的真凶

有一种故障特别折磨人：程序逻辑检查无数遍没问题，设备运行几个小时偶尔“抽风”一次，输出莫名动作，输入莫名多跳一个脉冲。这种偶发故障，我优先怀疑电磁干扰。

干扰源通常有三个：变频器、伺服驱动器、大功率开关设备。解决思路三步走：第一，变频器输入侧加电抗器，输出侧加滤波器（具体看变频器手册），把干扰源抑制在源头；第二，信号线用屏蔽双绞线，屏蔽层单端接地，PLC的通讯线和动力线分开走线槽，间隔至少20厘米；第三，PLC和变频器在柜内保持距离，不要把PLC直接放在变频器正上方或紧挨散热器。做完这三步，大部分偶发跳变都能消失。这是经验24。

还有一个细节容易被跳过：PLC的24V电源和传感器电源最好分开。如果传感器电源和PLC共用一路24V，传感器短路或漏电时会造成电压波动，直接影响PLC工作。输出负载的供电也尽量不要从PLC的24V上取，大电流冲击会让PLC内部电源不稳定。

6. AI辅助编程与职业习惯：工具变了，基本功没变

6.1 AI生成PLC代码，能用但别迷信

“AI PLC代码生成”今年特别热。我实际用过几款AI工具写PLC相关代码，包括Modbus通讯指令块、状态机框架、设备动作时序逻辑。说实话，对于结构化文本（ST）或SCL语言，AI生成的代码质量已经相当可以，尤其是Modbus寄存器读写、CRC校验这类通用算法，AI能直接给出完整可用的代码，能省不少时间。

但AI生成代码有三个明确限制。

第一，硬件相关的代码不能直接信。PLC高度依赖硬件，同样的程序逻辑，西门子S7-1200和汇川AM系列写出来差异很大。AI很容易生成看起来像模像样但你硬件根本不支持的指令。所有AI生成的代码，都要对照你用的PLC型号手册逐条核验。

第二，安全相关的逻辑绝对不能交给AI。急停回路、安全门、光栅联锁，必须经过完整评审、符合设备安全标准的逻辑，最好由硬接线和安全继电器实现，而不是纯程序逻辑。AI生成的安全逻辑哪怕只错一个条件，都不可接受。

第三，AI写不出“为什么”。它可以帮你生成状态机框架，但为什么这个工艺要这么设计、为什么延时设3秒而不是5秒，这些设计意图只有你和懂工艺的老工程师才知道。所以我把AI定位成“高级代码助手”，它输出的是草稿，你负责一行行核验和工艺逻辑把关。这是经验25。

6.2 入行1-3年，最该补齐的短板是这四块

第一，把基础指令彻底吃透。定时器、计数器、比较指令、传送/比较/算术指令，能解决90%的工艺需求。很多新人一上来研究通讯协议、PID自整定，结果连“用定时器做一个闪烁灯”都要想半天，本末倒置。基础指令的灵活运用，才是现场解决问题的最短路径。这是经验26。

第二，建立自己的排错SOP。每次排查故障，把步骤写下来：先看什么、再查什么、最后动什么。我在这篇文章里反复强调的电源、接地、通讯、干扰排查顺序，就是我的排错SOP。有了SOP，在客户现场就不会慌，而“不慌”在现场比“能力”还重要。

第三，文档意识。每次调试完，把I/O表、通讯参数、程序修改记录、遗留问题写到一个文档里。这是老生常谈，但我见过太多工程师，项目交付时觉得“设备都跑了还写什么文档”，结果半年后客户打电话问“当时改的那个参数是多少”，翻遍聊天记录都找不到。调试现场的随手记录，哪个参数改过、为什么改，写下来，半年后能救命。这是经验27。

第四，盯紧工艺而不是盯紧代码。我入行第二年做过一个自动化包装线的改造，程序写了一版又一版，设备就是不顺畅。后来老师傅一句话点醒我：“你以为你在写程序，其实你是在解决工艺问题。”从那以后我拿到需求先问工艺：这个气缸为什么在这个时间点动作？晚0.5秒行不行？懂工艺的PLC工程师和只会写代码的PLC工程师，在客户眼里是两个职业。

写这批经验的过程，其实就是我自己的复盘过程。我原本是把90条经验每天更新几条，今天按主题归置，把最不挑品牌、最能直接上手的部分放在了前面。最后想给还在这条路上的同行一个最朴素的建议：从今天开始准备一个踩坑本，每踩一个坑记一条，三个月以后你再翻这个本子，会比翻任何教程都有用。我自己的很多经验，就是靠这个本子攒下来的。