企业官网建设流程全解析

入行第14个月，我在凌晨三点接到过一通电话。车间主任说传送带停了，屏幕上一片红色报警，最后补了一句“是不是你那个PLC程序写的有问题”。我赶过去连上电脑一看，程序明明在RUN状态，输出模块的灯也亮着，变频器就是不动。折腾到天快亮才查明白，不是程序，是通讯线被货架压断了。那一次之后我养成了一个习惯：但凡踩过的坑，无论大小，都记成一条经验，按天往下攒。现在我手头一共攒了90条，都来自入行这三年里真实碰上、亲手处理过的问题。这个系列我打算每天更新，从接线、仿真、通讯、触摸屏驱动，到程序结构和宕机排查，一条条讲清楚来龙去脉。

如果你是1到3年的PLC工程师，这些经验应该能帮上不少忙。新手看接线和仿真部分，可以少交一些看不见的“学费”；做了一年左右的人，通讯和上位机那些章节大概率能对号入座；两年到三年这个阶段，更值得关注的是程序架构和系统宕机的问题。我尽量不写那种“教程式”的套话，就以实际干活的口吻说事。

1. 为什么我用“一条条记录”的方式复盘头三年的PLC生涯

1.1 经验这种东西，隔一周不写就真的没了

很多PLC工程师都有这个体会：现场解决问题那会儿思路特别清晰，连线怎么接、参数怎么改、现象怎么反复，全都刻在脑子里。但只要回到办公室开个周会，再补两天的图纸，上个星期那个“灵光一现”的排查思路就模糊了，再过半个月连故障代码都想不全。我之所以坚持记录，就是因为90%的现场问题，第二次遇到时留下的遗忘成本远大于解决成本。

我通常会把经验记成固定格式：现象是什么，影响面有多大，排查过程按什么顺序走的，中间哪些判断是错的，最后根因是哪一句话能讲清的。格式越简单越好，因为复杂格式根本坚持不下去。很多朋友喜欢整理成精美的知识库，配流程图、配截图，结果每整理一条要花半小时，三天就放弃了。我的方式是直接在手机备忘录里写，想到什么写什么，一周之后统一归到PLC实战笔记里。

1.2 1~3年这个阶段，最缺的不是资料而是判断顺序

做过一年以上项目的同仁应该明白，入行前三年真正的问题不是“不会”，而是“不知道该先查哪里”。同样是PLC不上电，可能是电源坏了，也可能是输入公共端没接对，还可能是保险丝被烧了。经验不足的人容易一上来就怀疑程序，改来改去，问题反而越改越多。90条经验里的每一篇，我尽量把“排查顺序”放在第一位，原因就在这里：不是告诉你标准答案，而是告诉你我从“错误答案”里试出来的安全路径。

比如后面会写到的S7-PLCSIM启动问题，网上很多人第一反应是重装软件。可实际上大部分情况只是虚拟网卡配置、实例残留或端口冲突，根本不到重装那一步。这个道理放到硬件接线和通讯协议上也一样——大多数故障的根因都藏在最不起眼的基础环节里。

1.3 关于AI写PLC代码，我的态度有保留但开放

最近“AI PLC代码生成”这个话题很热。我也试过用AI生成红绿灯程序、四层电梯控制逻辑，甚至让它按我的习惯给梯形图块写注释。坦白讲，用来搭模板、梳理顺序功能图、生成某段标准算法的参考代码，效率确实高。但1到3年的工程师千万不要把AI当“老师”，因为它给的程序看起来结构特别规范，往往缺了现场真正要紧的东西：急停逻辑放在哪一级、机封漏水联锁要不要做冗余、复位按钮需不需要同时清除报警和联锁标志位。

这类隐含条件，AI不会替你问，也不会替你想。所以我写这些实战贴的时候，也会尽量把“程序背后那一层设计逻辑”讲出来，而不只是提供一个能跑通的梯形图。

2. 接线和选型：第一步最容易吃暗亏，错得也最隐蔽

2.1 NPN和PNP，先讲清楚再动手

我在上一个项目里给一条包装线换传感器，厂家发过来的是PNP三线制。接上去之后PLC输入灯全不亮，查了半小时，发现上一任用的是NPN传感器，PLC模块对应的公共端接法两边正好相反。这个错在1到3年工程师里特别常见，原因很好理解：大部分人接输入信号时，默认“有信号就有24V”，很少去区分传感器的输出晶体管到底是NPN还是PNP。

所谓NPN型传感器，输出端是集电极开路，信号导通时把负载拉到0V，所以你必须在PLC输入点与24V之间形成回路；PNP型则是把输出拉到24V。选错以后，PLC输入点要么永远为0，要么直接烧掉模块端子。动手前先确认三个东西：传感器的型号标签、PLC输入模块的漏型/源型定义、公共端COM的接法。宁可花两分钟查手册，也不要凭经验猜。

2.2 西门子PLC输入输出接线里的高频错误

西门子PLC的接线问题，在热搜词里常年排在前面，说明这是大家普遍遇到的坎。S7-1200的输入模块一般支持源型或漏型，但不同型号的公共端定义不一样，CPU本体上的M端和模块上的M端到底谁接0V、谁接24V，必须对照端子图看。我见过有人把220V串进24V输入点，模块当场冒烟；也见过把继电器输出点当成干接点，外接了一个大功率接触器，结果触点寿命不到两周。

更隐蔽的是输出侧感性负载的问题。控制接触器线圈、电磁阀、小型电机接触器时，线圈断电瞬间会产生反向电动势。接交流负载最好并联阻容吸收，接直流负载则在负载两端反向并联续流二极管。不加这些保护，直观结果是模块晶体管被打坏，间接结果是CPU莫名其妙复位，排查起来特别费劲。

2.3 通电前的万用表三查

这是我给自己定的硬规矩，也建议所有刚入行的工程师照抄：第一查电源，用万用表确认24V电源的输出电压稳定在24V附近，正负极没有接反；第二查输入点，把每路传感器的信号状态逐个短接测试，确认输入点对应的地址能正常翻转；第三查输出点，在断开负载的前提下，用万用表测输出触点通断，确认PLC输出地址和实际端子一一对应。这三查看着慢，其实做熟了十分钟就够，但能挡掉一大半的通电后“惊魂时刻”。

3. S7-PLCSIM Advanced启动故障：没有报错的报错最磨人

3.1 现象描述：点了Start就是不起来

很多人用S7-PLCSIM Advanced V5.0跑PLC实例，遇到一个很头疼的现象：新建实例、配置好IP，勾选Start之后界面没有任何报错，但实例状态一直显示停止，或者点了半天只弹出一个一闪而过的小窗。最麻烦的是它不像普通软件那样弹个错误码，而是“安静地失败”，让人无从下手。

我一开始也差点走上重装系统的路。后来仔细对照自己和网友复现的情况，发现问题通常不在软件本体，而在仿真器运行所需的“外围环境”。S7-PLCSIM Advanced本质上是在Windows上虚拟出一块带网卡的PLC，它的启动依赖虚拟网卡、底层服务和端口分配。这三个环节任何一个出问题，都会导致实例起不来且没有明确报错。

3.2 排查链路：从进程、路径到虚拟网卡

面对这种“没报错”的故障，我的排查顺序是固定的，先从最廉价的检查开始：

1. 检查所有S7-PLCSIM相关进程是否完全退出。最常见的情况是上次非正常关闭，PLCSIM进程还驻留在后台，占用了实例名称或端口。打开任务管理器，把所有带PLCSIM或Siemens字样的进程全部结束，再重新打开。
2. 检查安装路径是否有中文或特殊符号。这一步太容易被忽略。仿真器对路径里的非英文字符比较敏感，一旦装在“D:软件S7-PLCSIM”这类路径下，启动逻辑就会异常。卸载后重装到纯英文目录就能解决。
3. 核对TIA博途版本和S7-PLCSIM Advanced版本是否匹配。V5.0对应的是博途高版本，如果你电脑里跑的是老版本项目，实例就会启动失败。版本匹配关系表在安装说明里都有，但很少有人会真的逐条核对。
4. 检查虚拟网卡。S7-PLCSIM Advanced安装时会创建虚拟网卡，如果系统网络管理工具把它禁用了，或者IP被改成了和实体网卡相同的网段，也会出现实例不起动的情况。到网络适配器里找到Siemens PLCSIM Virtual Ethernet Adapter，确保启用状态，并给它一个独立网段的IP，比如192.168.200.1。
5. 最后再去看事件查看器。Windows日志里可能有PLCSIM的底层异常记录，很多时候比界面上的沉默靠谱得多。

3.3 Error 11的常见诱因和处理

如果你不是“无报错启动不了”，而是明确弹出“Error 11”或者类似的错误号，那重点就转向许可证和实例状态了。Error 11在PLCSIM Advanced里往往和授权、实例文件冲突有关。常见的处理是先删除出问题的实例文件夹，一般在Documents或ProgramData下的Siemens相关目录里；然后重新创建一个实例，而不是复用旧实例。如果还不行，就用官方安装包做一次修复安装，许可证管理器里确认相关授权处于已启用状态。

还有一种情况是PLC实例IP和电脑物理网卡IP冲突。仿真PLC同样需要通讯，如果它分配的IP被其他网卡占用，底层握手就失败。给仿真器分配一个像192.168.100.1这种专用地址，并且和物理网卡的网段错开，能省掉很多莫名其妙的坑。

3.4 一句话总结仿真器故障的优先级

仿真启动问题的排查优先级，我个人排成这个顺序：先杀残留进程，再查路径字符，再查虚拟网卡和IP冲突，然后看版本和许可证，最后才谈重装。按这个顺序走下来，十次里至少有八次能在前两步解决。重装永远是最后的手段，因为重装之后你需要花大量时间重新配置环境，而且问题大概率还在。

4. 触摸屏和驱动之间的“语言壁垒”：威纶通为什么找不到汇川PLC

4.1 所谓“找不到驱动”其实是没看对眼

网上有个高频问题：威纶通触摸屏软件里找不到汇川PLC的驱动。很多人的第一反应是“威纶通不支持汇川”，但实际情况往往不是硬件不支持，而是大家在驱动列表里找错了名字。威纶通的EBPro软件里，驱动名称通常按照协议或系列命名，不会直接写“汇川PLC”四个字。你搜“厂家”是搜不到的，但搜“INOVANCE”或者“H1U/H2U/H3U/Easy”就能翻出来。

汇川PLC早期很多型号走的是三菱兼容协议，所以部分机型用三菱FX系列的驱动也能通讯。但我要提醒，这不等于可以所有型号都偷懒。Inovance不同代际的产品在底层协议上有差异，比如Easy系列、H1U、H3U、AM系列，与触摸屏对接时选择的驱动是不完全一样的。我自己的处理方法是：先在设备型号手册或触摸屏的驱动列表帮助文件里确认支持型号，再决定选哪个协议，绝不在列表里瞎碰。

4.2 添加汇川驱动的正确姿势

以一个典型的威纶通加汇川H3U项目来说，操作路径大致是：新建工程时选对触摸屏型号，然后在“设备列表”里添加PLC设备，厂家那里选“INOVANCE”，在型号列表里找到对应的协议项。接下来要跟PLC侧保持一致：如果是串口连接，必须核对COM口号、波特率、数据位8、停止位1、校验方式，两边任何一项不一致都连不上；如果是以太网连接，就要给触摸屏和PLC分配同网段的IP，并填上目标PLC的站号或端口。

很多新人栽在“明明驱动选对了还是连不上”上，原因通常是忘了检查PLC侧通讯口参数。PLC默认的通讯参数可能和触摸屏默认值不一致，必须到PLC程序里确认底层通讯协议配置。这种问题最迷惑人的地方在于，触摸屏上一切设置看起来都是对的，程序也能下载，但就是通讯不上。

4.3 MCGS与信捷、以及更多“品牌对不上”的情况

同样的坑在别的触摸屏上也存在。MCGS（昆仑通态）连信捷PLC时，很多人到驱动列表里找“信捷”，结果看到的却是“XC系列”之类的名称。这很正常，因为触摸屏驱动本质上是“协议驱动”，它关心的是通讯协议能不能对上，不关心品牌叫什么。信捷XC和XG系列的协议有所不同，选错也会通讯失败。

所以我的经验是：遇到任何“找不到驱动”，先不要急着吐槽软件，去查PLC支持哪几种通讯协议，再在触摸屏驱动列表里按协议关键词搜索。Modbus RTU、Modbus TCP、串口自定义协议、以太网协议，这些才是列表里的“真实身份”。

4.4 通讯连不上的硬件侧检查

把软件参数全核对完之后还是不通，就该摸线了。串口通讯最常见的问题是接线收发交叉：触摸屏的发送要接PLC的接收，触摸屏的接收要接PLC的发送，不是一一对应直连。很多串口线做起来要交叉，没有交叉就直接沉默。以太网通讯则要检查线缆是否通、交换机端口有没有亮起来、防火墙是否拦截了目标端口。

5. 通讯与上位机：三菱协议、SCADA轮询和C#读数的坑

5.1 三菱PLC通讯协议：别被“协议详解”吓退

“三菱PLC通讯协议详解”是热搜词，说明大家都很想搞懂这套东西。三菱目前常见的上位机通讯方式包括MC协议、QnA兼容协议以及Modbus。MC协议帧格式乍一看很复杂，又是子头又是块号，但实际用起来只需要抓住核心：先判断是ASCII模式和二进制模式，再按协议把请求帧填对。

举个例子，读D100这个数据寄存器，二进制模式下请求帧的长度是固定的，命令名、起始地址、读取点数都有明确字节位。新手最容易犯的错误是地址换算。D100对应的软元件编号换算到MC协议的地址时，需要按区块偏移量来算，而不是直接填100。如果地址错一位，PLC要么返回异常码，要么默不吭声。我的建议是不要凭记忆写帧格式，直接去PLC编程手册的通讯章节里查地址映射表，然后再对着实际返回的数据做一次验证。

5.2 SCADA连接PLC：先搞清楚你的SCADA走什么通道

SCADA和PLC的连接方式，大体上分三种：组态软件自带驱动直连、走OPC UA/DA、走Modbus协议。很多人集成SCADA时连不上，不是因为网络不通，而是没有搞清楚该用哪条“通道”。自带驱动最省事，但必须在SCADA的驱动管理器里装对应的PLC驱动；OPC UA最通用，但需要PLC固件和SCADA都支持，并且证书配置得当；Modbus则要PLC侧把数据映射到Modbus寄存器区。

如果SCADA只提供Modbus TCP通道，而PLC那边没有开好Modbus服务器，那不管你在SCADA里怎么填IP地址都没用。反过来也一样。所以我通常建议项目初期就确定通讯架构：谁来当主站，谁做从站，走什么端口，数据区是哪个地址段。SCADA连PLC根本不复杂，复杂的是头三天没人愿意把这几个参数定下来。

5.3 C#读取PLC：读取频率与线程占用

有人问C#读PLC频率设多少合适。这个问题没有唯一答案，但有通用经验。假设你写了个循环，每50毫秒去调一次通讯函数读取几十个点位，初看很快，但一旦PLC那边响应慢了一点，线程就开始堆积。用不了多久，你的上位机界面卡顿，PLC通讯模块也可能出现过载。

做上位机开发，我的建议是把“读取频率”和“数据用途”挂钩：如果只做监控画面，500毫秒到1秒的刷新完全够，眼睛看不出延迟；如果要做趋势曲线和报警记录，200到500毫秒也够了；只有在伺服位置追踪或者高速数据采集之类的场景下，才需要考虑50到100毫秒级。另外，千万不要在循环里反复创建新的连接对象，C#里应该维持一个长连接，用一个独立线程去定时轮询，把结果写入共享变量或者缓存，UI线程只负责显示。这个坑，项目上线时间越长体会越深。

5.4 ABB变频器与西门子PLC：从站编号和尾电阻

ABB变频器和西门子PLC的通讯，不管是USS协议、Modbus RTU还是Profinet，首先要解决的是“地址对不上”的问题。ABB变频器的参数表里有专门的通讯地址参数，比如站号，要和PLC侧配置的从站地址完全一致。其次，串口通讯的两端要约定好波特率、校验方式、数据格式，包括ABB变频器的某些参数要设置为“允许写入”，否则PLC发过来的控制指令会被变频器拒绝。

还有一个很“物理”的坑：RS485总线的终端电阻。走Modbus RTU时，总线上必须在物理末端接终端电阻，否则通讯信号会发生反射。很多项目通讯时好时坏，报故障代码一会儿是一会儿没，排查了一圈发现就是终端电阻没接。ABB变频器有些型号自带终端电阻跳线，使用前一定要看手册确认跳线位置。

6. 程序结构里的“老套路”：红绿灯、四层电梯和抢答器教会我的事

6.1 十字路口红绿灯：时序图画清楚再写定时器

红绿灯程序为什么总被当成经典入门题，因为它涵盖了两个核心能力：时序拆分和输出互锁。很多人一开始就开好几个TON定时器，结果绿灯切换的时候闪烁混乱，问题往往出在“相序”没有理清楚。正确做法是先画一张时序图，把南北直行、南北左转、东西直行、东西左转这几组信号的起止时间列出来，再决定定时器的连接关系。

我特别想提醒的是双线圈问题。在梯形图里，同一个输出点如果被多个网络赋值，程序扫描到最后一次赋值的网络才生效，前面写的相当于白写。红绿灯这种程序里稍微没注意就会出现“红灯亮一下就灭了”的怪现象。解决方式很笨但很管用：每个输出点在全程序里只保留一次“线圈赋值”语句，或者把所有判定条件合并到一个输出控制网络里。

6.2 四层电梯：把状态机思想用起来

四层电梯控制程序也是经典项目。刚入行时我很喜欢用一长串中间继电器和定时器去模拟电梯逻辑，写得又长又难调。后来才明白，电梯程序最适合的模型是状态机：待机、运行、减速、开门、保持、关门、再出发。每个状态对应一组允许条件，状态切换必须有明确的事件触发。这样编写出来的程序可读性高，排障也容易得多。

状态机不一定非要用SCL或者GRAPH来实现。梯形图里完全可以用一个字节型的“当前状态”寄存器，配合多个比较指令和置位复位指令来建模。当电梯在某层触发限位时，先判断当前状态是什么，再决定合适的目标楼层和运行方向。这样做的好处是，任何时刻你都知道电梯到底“在干什么”，而不是面对一圈“辅助继电器像一团乱麻”看不清楚。

6.3 抢答器和数字孪生：互锁与刷新节奏

抢答器程序的核心是“抢先锁定”。多个按钮同时或几乎同时按下时，系统只能接受第一个有效信号，并且之后所有迟到信号都失效。关于这个逻辑，梯形图的执行顺序有天然优势：先扫描到第一个置位信号的网络，后续网络因为互锁触点已经断开，就无法再覆盖。很多新人在抢答器项目里看不明白为什么已经锁定的应答还能被别的信号“冲掉”，其实就是因为在后续网络里对该输出点再次做了非互锁的赋值。

现在很多实训项目会把抢答器做成数字孪生场景，即PLC程序控制3D模型里的灯和声音。这类项目要注意的不是PLC逻辑，而是上位机和PLC之间的“刷新节奏”——数字孪生场景的动画帧率通常在30到60帧。如果你的上位机以100毫秒周期去读一次PLC，画面看起来就是一顿一顿的。串口或以太网读写周期、3D渲染帧率、PLC扫描周期三者之间要有一个协调机制，而不能各跑各的。

6.4 包装线和灌溉项目中的结构化编程

自动化包装线控制系统设计这类项目，看起来复杂，拆开其实就是“顺序控制”。不同工位有各自的起始条件、动作命令和下位机状态反馈。我推荐的方法是把整条线的工艺拆成若干个设备功能块，每个块封装成独立FB，然后在OB1里按设备启停顺序调用。几个功能块之间的互锁逻辑，单独写在另外的网络里，不要让它们互相打扰。

基于西门子PLC的大棚灌溉项目，则多了模拟量处理和PID调节。温湿度传感器的模拟信号经模块转换成数字量后，在程序里先做工程量换算，再做上下限报警和PID输出。这里有个新手经常忽略的点：PID输出之前一定要做好量程匹配，否则控制阀门的开度不是偏大就是偏小，调节过程震荡得厉害。

6.5 关于AI生成PLC代码的现实体会

AI生成的PLC代码确实能提升效率，但只能用在“人工可控”的场合。我试过让它生成包装线顺序控制的骨架，得到的功能块划分基本合理，直接修改起来比完全手写快不少。但AI很容易忽略急停之后的复位顺序，也会把上位机关联地址写得凭空臆造。我的做法是：把AI当成“高级代码片段库”，让它出结构、出模板、出注释，但所有工艺逻辑和联锁条件必须自己人工对照图纸逐行检查。

7. PLC宕机排查：先别急着怀疑程序，从这几个地方入手

7.1 先看灯：RUN、SF、BATF各自的指向

PLC“宕机”这个词在网上很火，但很多人把不同现象都叫宕机。有人是RUN灯灭了，有人是SF灯闪烁，有人是模块上的端子灯不亮。接到现场第一件事一定是看灯，灯比报警文本诚实得多。RUN灯熄灭说明CPU停止运行，可能是程序写入了停机指令、硬件组态错误或者看门狗超时。SF灯点亮或闪烁，说明系统自诊断发现故障，如模块组态与实际不一致、外设总线错误等。BATF灯亮则是电池电压不足或背板总线问题。

我见过最典型的“假宕机”就是操作员急停拍下之后没有复位，导致CPU跳到STOP状态。这时候不要急着改程序，先把急停回路复位，再用钥匙把CPU拨到RUN。灯不亮但通讯也不通的场景，更要先确认电源侧是否真的送电，不要被某个开关的位置骗了。

7.2 程序写崩PLC的两种典型方式

第一种是指针或地址越界。使用间接寻址、数组索引、指针操作时，如果索引超出了定义范围，CPU可能直接进入STOP。这个问题在做配方管理和履历跟踪时容易出现。第二种是看门狗超时。OB1的执行时间如果超过设定值，比如默认150毫秒，系统会认为程序卡死并触发停机。常见诱因是FOR循环里套了死循环，或者某个通讯指令在等待响应时阻塞了程序扫描。

排查时可以把OB1的执行时间监控打开，看扫描周期是不是异常升高。如果扫描周期从10毫秒暴涨到300毫秒，就要重点检查最近新加的通讯块和循环块。先回退版本，等系统稳定后再逐个功能块地加回来，这条经验看着笨，但能最快锁定问题。

7.3 外部干扰和接地：最容易被忽略的凶手

随机宕机里更常见的是外部因素。变频器启动瞬间、大型接触器吸合、电焊机工作时，一旦PLC宕机，十有八九是干扰串进了信号回路。典型路径是：信号线缆和动力电缆同槽走线，接地线松动或接地电阻过大，通讯总线缺少屏蔽层，屏蔽层单端没接地。

有些项目抗干扰做得不行，现场变频器一启动，PLC就莫名其妙重启。处理方法是把通讯线改用屏蔽双绞线并单端可靠接地，PLC机柜单独接到接地铜排上，和变频器保持足够的空间距离。信号线和动力线分开走线看起来是常识，但在很多紧凑线槽里被直接忽略了。

7.4 随机宕机的标准排查清单

我把“随机宕机”的排查动作整理成一个清单，供大家贴在机柜门上参考：

我给自己定了一条纪律：随机故障一律先看诊断缓冲区。西门子PLC的诊断缓冲区会记录最近几次停机的原因，很多时候能直接指出是模块故障、程序看门狗还是外部故障。1到3年的工程师只要习惯性地先看诊断，再推理，排障时间能缩短一半以上。

8. 后记：这90条经验我会怎么更新下去

8.1 更新节奏

这个系列我计划每天更新几条，按80条左右的经验内容倒推，九十个编号里有相当一部分会结合最近项目重新修订。更新顺序大致按照“硬件接线—仿真调试—触摸屏—通讯—程序—运维排查”的路线走，有条件的话会把真实故障代码、通讯报文和程序片段贴出来供参考。因为涉及不少现场信息，我会做脱敏处理，但原理部分不求“全面”，只求“有用”。

8.2 留下一句话给一起成长的同行

我个人在这三年里的最大体会是：PLC工程师的价值不在于背下来多少指令，也不在于手速多快能画完一张图，而在于面对一个“说不清楚的问题”时，能不能快速缩小范围。这个能力的养成，靠的正是平时一条一条的记录、一次一次的复盘。如果你也刚入行不久，我建议你也从今天开始，把每天遇到的第一个技术小坑记下来，一个月后回看就会惊讶于自己的进步。

下一篇更新，我会先从“现场故障记录表怎么设计”这条写起，因为有了统一格式的记录，后面的排查经验才有地方沉淀。