1. 为什么要整理这90条经验
1.1 入行头三年的真实处境
入行1-3年这个阶段，说难听点就是"什么都摸过，但什么都不精"。我当年也一样，学校里把梯形图、指针、通信都学了一遍，觉得自己什么都会了，结果一到现场，直接被一个接近开关的常开常闭问题打懵。
后来才发现，这个阶段最大的问题不是能力不够，而是经验严重碎片化。今天在A项目上踩了个坑，明天在B项目上又踩一遍。没有人系统性地告诉你：PLC编程不只是把逻辑写对，还包括IO规划、数据类型选择、程序架构设计、现场抗干扰处理、安全回路搭法、调试顺序……这些散落的东西，才是决定你能不能独立扛项目的关键。
我在头三年里踩过的坑，远比想象中多。端子松了导致信号偶发丢失，模拟量线没屏蔽导致数值跳得像过山车，程序里多个线圈重复输出导致逻辑诡异……每一个坑都不大，但加在一起，足以让人连续加班到凌晨。
所以我决定把这些实战经验系统整理出来。这个系列不追求讲高深算法，也不聊什么云端工业互联网，就是踏踏实实把每天在现场会碰到的问题、判断思路和解决办法记录下来。90条听着很多，其实拆开就是设计、编程、接线、调试、维护这五个维度，每条都是真实场景里能直接落地的东西。
1.2 这套经验的整理思路和适用人群
如果你正处于以下这几种状态中的任意一种，这个系列大概率对你有用：
- 刚入行接触第一个真实项目，连IO表都还没人带你规范写过；
- 已经能独立改程序，但一遇到现场干扰、通信丢包就心里没底；
- 要开始自己负责一个设备或者一条小产线的调试，怕漏掉关键环节；
- 做过一两个项目，想系统梳理自己的知识体系，补齐盲区。
我在整理这90条经验的时候，用的不是"知识清单"的思路，而是"故障回溯"的思路。也就是说，每一条经验都源于真实发生的现象或者问题，先记录现场表现，再拆原因，最后给出处理办法和预防措施。这样哪怕你只看一条，也能完整理解一个问题的全貌，而不是只会记住一个孤立的口诀。
另外，这些经验不会只针对某一种PLC品牌。虽然不同品牌在软件操作上有差异，但底层逻辑和工程习惯是通用的。你用日系还是欧系，用某国产主流品牌还是老式继电器控制柜，核心方法论都适用。遇到品牌专有操作的时候，我会尽量泛指思路，你拿到具体手册里查对应的按钮位置就行。
2. 程序编写与逻辑设计：决定设备下限的关键
2.1 IO分配与命名规范：前期省一小时，后期省三天
IO分配这件事，几乎所有初学者都轻视。进公司第一个项目，导师多半会把一份做好的IO表扔给你，让你照着写程序。这时候你可能觉得，这不就是个地址对应关系吗，把X0.0对应到启动按钮、Y0.0对应到接触器就行。
但实际上，IO分配直接决定后期维护的难度。我见过最夸张的一个设备，IO点号完全没有规律，X2.3是气缸A的前限位，X5.7又是同一个气缸的后限位，中间隔着几十个点。现场调机的时候，找点位找到怀疑人生。
我自己后来养成了一个习惯：所有输入输出点的符号名，必须遵循"设备名_信号类型_功能"的规则，比如cylinder1_fwd_limit，然后在程序中一律用符号名编程，不直接使用物理地址。好处非常明显——三个月后回头改程序，你不用先去翻IO表才知道某个地址是什么，程序本身就是文档。
IO分配还有一个原则叫"分块预留"。也就是说，不要把IO地址填得严丝合缝，每个设备区域、每个功能区块中间要留出备用点。实际项目中经常出现这种情况：前期设计的IO点数算好了，到调试现场发现还要加两个检测传感器，结果PLC的物理点已经用完了。如果当初按区块预留了备用点，这种改动就是换根线、补个符号的事，而不是重新设计整个接线方案。
2.2 数据类型与数值转换：程序不报错不代表没出错
这一节应该是初学者在编程中碰到最多隐性bug的地方。PLC里最典型的坑就是整数和浮点数混用。
举个实际例子，一台设备要做转速显示，编码器反馈值经过计算后是浮点数，你把它放到一个整数型变量里准备传给触摸屏。结果触摸屏上显示的数值永远是0，或者永远是一个奇怪的整数。原因很简单——浮点数转整数的过程中，如果你的计算结果是2400.6，转成整数就是2400，损失掉的小数点可能刚好是你要显示的精度的关键部分。更严重的是，某些PLC品牌里，浮点数直接赋值给整数寄存器，会产生完全无法预期的结果，甚至编译都能过，但运行时数值就是错的。
模拟量处理的坑也不少。4-20mA信号，PLC内部一般是0到27648或者0到4000这样的原始值，要根据量程换算成实际的压力、温度、流量值。很多初学朋友换算完就直接拿去用了，结果发现显示值与现场仪表差了一截。为什么？因为PLC的模拟量模块有精度误差、外部传感器有零点漂移，你不做校准就直接用理论换算公式，偏差是必然的。
我的习惯是：模拟量通道在首次投用前，一定要在无信号和有标准信号源的情况下各读一次原始值，记录实际偏差，然后做偏移修正（offset）和增益修正（gain）。这个步骤在手册上叫"标定"，但很多初学者根本不知道有这个操作，导致设备出厂后数据不准，被甲方质疑。
定时器和计数器的时间单位也是经典雷区。三菱的定时器单位有100ms、10ms、1ms之分，西门子的TON/IEC定时器用的是S5TIME格式，不是所有定时器的设定值单位都是"秒"。我当初就在一个快速气缸动作上栽过跟头：程序里写的定时值是5，本意是5秒，但因为定时器类型选的是100ms规格，实际动作时间是0.5秒，气缸还没到位就往下个工序走了，直接把工件撞废了一个。
2.3 程序架构思维：别把PLC程序写成三千行毛线团
如果说IO和数据类型是细节问题，那程序架构就是决定你职业生涯高度的关键问题。1-3年的工程师写的程序，普遍有一个通病：一个主程序里堆了几千行，从头scan到尾，线圈重复输出、逻辑互相干扰，改一个动作牵连三个工位。
我自己后来从一位老工程师那里学到并坚持至今的架构，可以概括为三层结构：
第一层是主任务（Main Routine），负责调用各功能块，设定扫描框架；第二层是各功能块（Function Block / Function），比如"送料机构控制""压装工位控制"这样的独立模块；第三层是公共逻辑，包括报警处理、手动操作、安全联锁、模式切换。
这样的好处是：每一个功能的逻辑只在它自己的功能块里出现一次，程序之间低耦合。调试时你只需要监控某一个功能块的内部变量，排障速度快得多。
另一个关键架构是"手动自动分离"。这个话听起来简单，90%的初学者却做不到。最常见的错误是：手动模式和自动模式共用一套输出线圈控制逻辑，你手动点一下按钮把气缸伸出去，切到自动后程序又基于旧的状态去判断下一步动作，导致设备乱走。
我推荐的做法是：手动模式不允许直接控制输出点，而是通过内部标志位（例如manual_valve_cmd）去联动公共输出逻辑；自动模式也一样，每个动作的触发条件都集中在状态逻辑里。这样一来，手动/自动切换的瞬间不会产生输出跳变，安全性也大幅提升。
如果你还没有用过状态机的思路，我可以告诉你它的威力。把一个设备的工作周期拆成"初始、等待启动、进料、加工、卸料、完成"这些状态，每个状态只处理当前应该做的事，而且只有明确的条件满足时才会迁移到下一个状态。相对于传统的一步步置位复位的办法，状态机的可读性、可修改性、排障性都强得多。
2.4 模拟量滤波与超限判断：没有过滤波器的模拟量都是薛定谔的
我第一次写模拟量程序时，直接读取了现场压力传感器的4-20mA信号去触发电机动作。结果设备试机时就出现了匪夷所思的情况：实际压力稳在6.2MPa，PLC判断压力低于下限5.0MPa偶尔会误报警。折腾了一下午，最后查出来是电柜里的变频器干扰叠加到了模拟量信号上，PLC读到的原始数值在快速抖动，偶尔跌破阈值。
从此之后，任何模拟量接入PLC，我都遵循三个原则：
第一，程序里必须加数字滤波。最简单有效的是平均值滤波——连续读5次，去掉最大值和最小值，取剩下3次的平均值。这个办法在软件上只需要几行代码，却能过滤掉大部分脉冲干扰。如果现场干扰严重，可以再加一阶惯性滤波，相当于软件层面的RC低通。
第二，设定双阈值判断。正常工作中模拟量值的跳变是允许的，只有持续超过上限或者下限一定时间，才算真正的报警。具体做法是利用定时器做计时判断，比如"压力低于4.0MPa持续2秒"才触发报警，而那些瞬时毛刺，虽然触发了判断条件，但因为持续时间不够而被忽略。
第三，模拟量必须做断线检测。很多人不知道，4-20mA信号断续时PLC读到的值会掉到0mA，也就是原始值显示为0或者负值，这时候如果你的程序逻辑是"压力0MPa就继续加压"，那设备就会朝着完全错误的方向动作。正确做法是：正常量程的最低值对应4mA，如果你的读数掉到3.5mA以下，基本可以判定是断线，这时候应该触发报警并禁止相关动作执行。
3. 硬件接线与电气设计：细节决定设备是否安全稳定
3.1 PNP与NPN传感器：选错不只是信号反了这么简单
这个坑几乎每个工程师都踩过，而且踩的姿势五花八门。PNP传感器输出的是高电平信号（正极输出），NPN传感器输出的是低电平信号（负极输出），你得根据PLC输入模块的类型去配套。如果PLC的输入模块是漏型（sink），你接了PNP传感器，大概率什么反应都没有；反过来，如果模块是源型（source），接NPN传感器，同样也读不到。
问题在于，很多初学者在最初做BOM（物料清单）的时候根本没有考虑这个匹配关系，到现场才发现接不了。在设计阶段就应该把"PLC输入模块类型"和"传感器输出类型"同时确定下来，而不是等设备都装配好了再去改。
我自己习惯的做法是：统一选用PNP型传感器搭配正公共端PLC输入模块。为什么这么选？因为大多数欧系PLC和相当一部分国产PLC的输入模块默认是源型输入，PNP传感器适配度最高，而且PNP传感器在断线故障时更容易被检测到——信号线对地短路会直接拉低输入信号，而NPN传感器的故障表现往往更隐蔽。
如果项目里确实混用了两种传感器，尽量不要直接接在同一组公共端上。需要做信号转换时，用一个中间继电器做隔离转换，或者加一个PNP/NPN转换模块。千万别图省事把NPN传感器信号直接并在PNP信号的输入端上，那不只是逻辑错误的问题，还可能烧掉输入点。
3.2 24V电源容量与配电设计：为什么一上电PLC重启，一动作电压就掉
电源容量不足是现场最常见的"神秘故障"来源之一。我经历过一个设备，手动操作每个气缸都正常，但一到自动运行，几个气缸同时动作，PLC就重启或者触摸屏黑屏。最后用万用表量24V电源电压，动作瞬间电压跌到18V——一个标称5A的开关电源，实际负载电流已经到8A了，过载直接让输出电压掉出了PLC的工作范围。
计算电源容量的正确姿势是：把所有耗电元件的电流加起来，包括PLC本体、输入模块、输出模块、继电器线圈、电磁阀、传感器、触摸屏，还有安全余量。注意，电磁阀这种东西的动作瞬间电流往往是维持电流的好几倍，计算时不能只用稳态电流，要按动作峰值电流预留。
同时，24V电源的"地"和柜内接地的关系也要处理好。最安全稳妥的做法是：直流24V的负极在电源处单点接地，避免形成地环路导致干扰。如果在多个设备之间形成了环路，模拟量信号和通信信号很容易受到地电位差的影响。
电缆敷设也要有讲究。动力线（如变频器输出、接触器到电机的线）和信号线（如模拟量、编码器、通信线）必须分槽走线，就算是短距离平行也不行。变频器的输出线缆本身就是一个大干扰源，跟信号线并排走20厘米，就足以让模拟量读数完全不可用。我在现场见过太多"信号线缠了两圈磁环还是不稳"的问题，最后把线分开走槽后，问题自己消失了。
3.3 继电器、接触器与感性负载：没有吸收保护的线圈都是电磁干扰制造机
继电器线圈、接触器线圈、电磁阀这些感性负载，在断开瞬间会产生很高的反向电动势，这个尖峰电压如果不做处理，轻则干扰其他信号，重则直接击穿PLC输出点或者驱动电路。
最常用的处理办法是：在直流感性负载两端并联一个续流二极管，方向要反接，让线圈断电时电流有一个释放回路。交流感性负载则用RC吸收电路并联在线圈两端。这两个小东西成本就几块钱，但很多设备厂商偷懒不做，结果就是现场频繁出现莫名其妙的干扰报警。
如果你的PLC输出点控制的是中间继电器，那继电器的线圈本身也要加吸收保护。虽然PLC输出点标称有保护电路，但频繁动作的项目里，长期的反向冲击还是会缩短输出点的寿命。别省这个几块钱的元件钱，拆换一个PLC输出模块的时间和成本远不止这些。
另外，感性负载的控制有一个容易被忽视的细节：不要用同一个输出点去同时控制多个并联线圈。并联线圈的电流是叠加的，如果叠加后的电流超过了PLC输出点的额定电流，输出点就会过热甚至烧毁。更好的做法是，PLC输出点只控制中间继电器，中间继电器的触点再去控制接触器或者电磁阀，实现电流隔离和放大。这个小习惯能极大降低输出模块的故障率。
3.4 急停与安全回路设计：PLC程序里的联锁永远不能替代硬件安全
如果说上面这些问题最多让人加个班、挨顿骂，那安全回路设计不好，就是出大事的隐患。初学者的一个典型误区是：急停按钮接进去PLC，然后在程序里用常开触点来写急停逻辑，以为这样就能实现急停。
大错特错。急停回路的硬件设计，是整个电气设计的红线：急停按钮应该使用常闭触点，并且串接在控制回路的硬线里，直接切断执行机构的使能电源，而不是只靠PLC程序里的逻辑去断开输出。为什么？因为如果PLC死机了、程序跑飞了、输出模块击穿了，你的急停功能必须依然有效。
我参与的每一个设备的柜子，都有清晰的硬件安全链：急停按钮常闭触点串联一起，经过安全继电器的输入回路，再由安全继电器输出到所有危险执行机构的使能回路。PLC只是在安全链之外负责一般的报警显示和状态判断。这个回路在断电、断线、按钮损坏的任何情况下，都处于断开状态——也就是失效安全（fail-safe）设计。
在写程序逻辑时，还要注意"常闭触点进PLC"这个老生常谈的问题。急停信号如果是用常闭点接入PLC输入端，正常工作时程序里这个点位就是1，只有按下急停或者线路断了才变成0。不少人恰恰写反了，用常开触点的逻辑去接常闭信号，结果设备一上电就报急停，或者急停已经断了PLC却认为正常。
4. 现场调试与故障排查实录
4.1 上电前的检查清单：宁可多看十分钟，不要炸机修一周
我亲眼见过一个同事给新设备上电，通电三秒，电柜里"啪"一声，一个24V电源冒烟了。原因很简单：电源的正负极输出线在端子排上接反了，整柜的传感器、PLC输入模块的公共端全部反向供电。这是一个非常低级但代价很大的错误。
上电前的检查，我建议你哪怕再赶时间，也必须走完这套流程：
先看电源接线：用万用表二极管档或者电阻档确认每路电源的正负极没有短路，确认PLC的24V输入没有和220V接混。再确认输入输出模块的公共端接线与模块类型匹配，PLC输入模块的公共端是接了正极还是负极，决定了你的传感器是选PNP还是NPN。然后查所有执行机构的动力线：接触器的主触点有没有错相，电机的保护器整定电流有没有按铭牌设置。最后查急停回路：按下急停，用万用表确认安全回路的控制电源确实被切断了，不确认这一点绝不允许上电。
上电后的第一步也不是直接按启动，而是逐个手动强制测试输出点。每次强制一个输出点，去现场看对应的执行机构是不是对的设备动作、方向是否正确。这个步骤虽然繁琐，但它能一次性把所有接线错误暴露出来。我见过太多工程师跳过这一步，直接在自动程序里测试，结果某个气缸动作方向反了，直接把工装撞坏了才知道接线有问题。
4.2 程序在线监控与强制：神仙也怕被强制
在线监控是PLC调试的基本功，但很多初学者连"监控"和"强制"的区别都没搞清楚。监控只是看程序当前值，强制是直接给某个位或者寄存器赋一个固定值，让它忽略程序逻辑。
强制的合理用法是：在没有执行机构风险的情况下，临时验证某一小段逻辑的正确性。比如一个传感器坏了还没换上，你想测一下后续逻辑，这时候强制一下信号点是合理的。
但强制也是最容易引发事故的操作。被强制的信号你自己可能记得，别人不知道，三天之后程序交接，谁也不知道这个点为什么一直在ON状态。更危险的是，强制了一个关键安全信号（比如急停复位、限位到位），设备在没有保护的前提下运行，一旦机械上出了状况，程序根本不会响应。
我的铁律是：所有强制操作必须登记在调试记录表里，写明强制点位、强制时间、强制原因、执行人，并且调试完成、故障排除后立即取消强制。最严格的现场甚至要求强制操作必须两人确认才能执行。你自己一个人调试时，至少要做到"强制前想三秒，强制后记一笔"。
排查信号问题时，还要善用PLC的输入/输出状态指示灯。很多初学者一上来就开着软件监控在线，其实最优先的排查手段是看PLC端子上的LED。比如你按了按钮但程序里输入点没亮，那就是外部接线或传感器的问题，跟程序无关；如果LED亮了但程序里读不到，那可能是模块接线端的问题；如果程序里能读到但逻辑不执行，才是真正需要查程序逻辑的地方。这个顺序能帮你快速缩小问题范围。
4.3 通信与网络调试：不是所有"断联"都是线没插好
现在的设备十有八九要走通信，触摸屏与PLC之间、PLC与变频器之间、PLC与上位机之间。通信问题占了现场调试时间的很大比例。
Modbus RTU的参数设置是第一个坑：站号要唯一、波特率、数据位、停止位、校验位要完全一致。这套东西看起来简单，但实际项目中经常出现"参数看起来一样"的情况。比如一个设备里有两个从站，一个从站的校验位设成了偶校验，另一个设成了无校验，这会导致主站去读从站时时而通时而不通。
Modbus地址还有一个著名的"偏1"问题：协议内部的数据地址是0开始，而触摸屏或者组态软件上看到的地址是1开始，所以在交叉引用时经常出现地址错位。比如你在程序里想读保持寄存器地址40001，实际上协议层面发送的是地址0000。各种专业工具里如果你基础设置不对，就会差一个地址，读回来的数据跟你预期完全对不上。
以太网通信的坑则更多体现在"分不清物理层还是协议层"。当触摸屏与PLC断联，不要上来就怀疑是IP地址冲突，先看交换机或者PLC网口的指示灯——如果网口灯都在正常闪，那大概率不是物理连接问题，而是通信参数、防火墙或者PLC里面的连接数占满了。很多PLC的通信连接数是有上限的，如果你的程序里反复建立连接而不释放，连接数被占满后触摸屏就再也连不进去了。这个问题的典型现象是：设备刚上电时触摸屏正常，运行一段时间后断联，重启设备又好了。
我的建议是：现场调试时准备一台笔记本电脑，装好对应品牌的通信测试工具，keyence、proface这类都有调试助手，能直接ping通或者用通信诊断命令去查询底层状态。学会用这些工具，比盲目拔插网线高效得多。
4.4 干扰与信号异常：从"看现象"到"找源头"的排查思路
信号干扰属于现场最难排查的问题之一，但它的排查思路是有迹可循的。规律是：既然是干扰，就一定是偶发的、有规律的。你要做的第一件事不是拿示波器去测，而是仔细观察干扰发生的时机。
比如，某变频器一启动，模拟量读数就开始跳动；某气缸一动作，另一个工位的接近开关就误触发。这种"同时发生"的规律，基本可以锁定干扰源就是对应的那个执行机构。
处理干扰，从干扰源、传播路径、敏感接收端三个方向入手。最有效的是在源头消除：变频器的输出端加电抗器或者输出滤波器；感性负载两端加吸收电路；接触器触点加灭弧。如果源头上暂时无法处理，就在传播路径上做文章：信号线单独走线、加屏蔽层且单端接地、模拟量信号线用双绞屏蔽线、通信线用工业等级的超五类或网线并且做好两端接地（注意屏蔽层单端接地原则）。
接收端也有一层软件防护：前面提到的数字滤波、阈值延时判断，还有很多人忽视的"输入点硬件滤波时间"。PLC大部分型号的输入点都支持设置滤波时间，从0.1ms到几十毫秒不等，如果你的传感器信号本身动作不快，把滤波时间调大一些，能有效过滤掉脉冲干扰。但也要注意，滤波时间过大，会延迟信号的响应速度，在安全相关的信号上不要使用大滤波。
4.5 程序丢失与后备电池：数据说没就没
很多PLC在断电后，用户程序靠内部电池保持RAM，电池寿命一般在3到5年。电压掉到一定程度，程序和数据就可能丢失。我见过一台老设备，因为电池电量耗尽，断电一次，整个程序消失，现场连源程序备份都没找到，只能花钱重新外包恢复，停产了一周。
预防办法极其简单：每年更换一次CPU电池，并且在每次修改程序后，同步把源程序导出备份到多个位置，包括移动硬盘、网盘、Git仓库。同时，在PLC内部把参数块和数据块使用程序存储区（比如闪存区域），尽量减少对电池的依赖。
调试结束项目交付前，还有一个必做动作：把最终的程序、参数、配方、注释完整备份到存储文件，并在设备铭牌上贴好程序版本与日期。别嫌麻烦，你永远不知道三个月后会接到什么电话。
5. 工程师好习惯与避坑清单
5.1 注释、文档与设备维护的底层逻辑
写注释这件事，说破天也是老生常谈。但你观察一下周围，有多少程序里是大片大片没有注释的？我见过最夸张的程序，每个网络就是一个灰扑扑的梯形图块，里面只有一个线圈和触点，功能全靠猜。更离谱的是，原作者离职了，这份程序就成了全公司的"天书"。
我的规则很简单：在程序里，每一个功能块上线处都要用文字注释写明功能、接口、逻辑要点；每一个报警输出点，注释里写清楚可能的原因排查方向。不是你记性好，是三个月后你大概率忘了当初为什么要这样写。我曾经半年后回看自己写的程序，有几个逻辑看着特别绕，怎么都想不通当初为什么这么设计，后来翻聊天记录才知道是为了规避一个只有当时才存在的机械限位干涉问题。
每次调试过程中的修改，也要留下记录表格：修改点、修改人、修改日期、修改原因。这不只是公司流程要求，更是让你在出现问题的时候能够回溯"上次改了什么才导致的故障"。
刀具磨损、气缸密封圈老化、传感器检测面脏污——设备的很多"软故障"跟程序无关，而是机械部件自然劣化导致的。如果你处理过几次这类问题就会明白，判断问题要从机械、电气、程序三个维度都过一遍，不要只盯着PLC程序上下死功夫。
5.2 网线、标签与图纸：现场管理是工程师的门面
我真的见过这样一个项目：电柜里几十根网线全部长得一模一样，没有标签，连到哪个设备全靠猜。调试的时候需要拔对某一根网线，结果拔错了，直接把正在运行的另一台设备的通信给断了，停产二十分钟。
电柜里的每一根线，不只是网线，包括电源线、信号线、通信线，都要有唯一编号和对应的线号管。线号管要用激光打码机或者专业的打号机做，不要用记号笔写——一是不容易持久，二是字迹潦草看不清。图纸上怎么编号，实际线缆上就怎么编号，身份一一对应。
图纸的同步更新也很重要。现场改过线的位置，必须当天就在电气图纸上标注出来。你可能会碰到这种情况：一张设备电气图，画了好几个版本，每个版本都不一样，谁也说不清现场跟哪版相符。结果排查问题的时候，对着图纸操作，完全对不上，最终只能趴在柜子里一条一条地捋线。
如果你还没养成整理图纸的习惯，建议从第一个项目开始，就建立自己的项目资料夹，里面放：电气原理图、IO分配表、PLC程序源码（不同版本都要保留）、通信参数表、触摸屏画面工程文件、调试记录表、验收记录。这个习惯坚持一年，你就会发现自己对项目的掌控力完全不一样。
5.3 与现场各方的配合：工程师要会沟通，而不是只会写程序
1-3年这个阶段，你很大概率不是一个人埋头干，而是要跟机械工程师、装配电工、操作工、甲方设备科的人打交道。但很多年轻工程师容易犯的最大问题，就是"程序是我的，其他我不管"——结果机械没到位、电气没接线，你的程序再好也动不起来。
我的做法是，在项目启动的时候，就把各方的接口确认下列出来，和白纸黑字地过一遍。比如：机械方面确认气缸动作顺序和节拍要求、传感器安装位置与检测对象；电气方面确认IO分配、安全回路、动力电源规格；软件方面确认PLC型号、通信协议、触摸屏画面结构。在调试前就互相确认，比在现场出了事再扯皮强一百倍。
跟操作工打交道也不能忽视。调试结束后，设备要交给操作工实际使用，他们的反馈其实比你的测试更能暴露问题。我养成的习惯是设备验收前，特意找操作工聊一聊，请他们现场试操作，看哪里不方便、哪里容易误操作。他们提出的很多问题，都不是"程序bug"，而是"人机交互设计不合理"——按钮位置、指示灯颜色、触摸屏画面跳转逻辑。这些问题如果不改，设备会被他们拿胶带贴住急停、拿铁丝绑住按钮，用各种"土办法"去规避，最终影响的是设备的正常运行和你们公司的口碑。
5.4 零散经验与自我迭代：把错误变成成长燃料
90条经验，说到底是90个"从错误中提炼"的样本。我自己有一个习惯，每次踩完坑或者解决完问题，会花十分钟在手机备忘录里记一份"问题档案"：现象是什么、排查了哪些方向、最后怎么解决的、下次怎么预防。这个档案积累到上百条之后，你再看一个设备，直觉会告诉你"这里大概会出什么问题"。
项目复盘时，要敢于面对自己造成的问题。你可能因为漏写了一个注释导致同事接手困难，因为接线图没确认导致上电炸了电源，因为参数没备份导致程序丢失。每一条都是成长的机会，只要不重复犯，就是赚到的经验。
作为入行1-3年的工程师，你可能觉得还有好多东西不会，还要拼命学很多新知识。但根据我个人经验，最值得投入时间去打磨的，恰恰是那些看起来最基础的"规矩"——IO表做得干不干净、硬件接线检测认不认真、强制登记做没做、程序注释写不写。这些工作短期内看不到什么成果，但长期看，它们才是决定你能不能从"会写程序"升级到"能扛项目"的分水岭。
这90条经验，如果你能真正吸收其中的哪怕二三十条化为自己的习惯，你对设备的理解、对故障的判断力、对项目流程的掌控感，都会和现在拉开明显差距。后面我会按这个系列继续往下更新，一条一条地讲，有具体问题的朋友欢迎在评论区抛出来，看到都会回复。
