1. 这套20轴产线项目到底在做什么从设备布局看控制需求做大型PLC项目的第一个习惯是先别急着写程序而是把整个产线的设备布局和信号清单铺开看。这个项目标题里的关键词很密伺服20轴、modbus、RS232、MES、气缸、机械手、模拟量。粗看是个杂烩实际上它覆盖了绝大部分自动化产线的典型控制维度——运动控制、逻辑控制、模拟量采集、底层现场通讯、上层信息化对接。标题所指向的正是一条中等规模自动化装配或检测产线的完整控制系统核心任务就是把这些不同通讯协议、不同响应速度、不同控制精度的设备统一到一套PLC体系里协调运行。先说清楚这套系统的骨架。20台伺服驱动器走的是高速运动控制总线负责产线里需要精确定位的工位比如机械手的各轴、搬运模组、转盘定位、压装机构。气缸则承担那些只有两个位置的简单动作比如夹紧、阻挡、顶升用电磁阀控制配合磁性开关反馈到位信号。模拟量通道通常用于压力检测、位移传感器、温度采集这类需要连续读数的场景。而modbus和RS232这两条线面向的是产线上的第三方设备——变频器、智能仪表、称重模块、条码枪、老式温控器。MES通讯则是往上走把产量、报警、工艺参数、产品追溯数据交给工厂管理层。把控制需求摊开之后有一个非常现实的问题摆在面前不同设备对PLC扫描周期和处理方式的要求完全不同。伺服的插补和定位需要毫秒级响应气缸只需要在IO扫描周期内完成就行modbus轮询几十毫秒甚至上百毫秒都无所谓MES哪怕是秒级延迟也能接受。所以整个项目的核心矛盾是实时性和非实时性任务的隔离。这个矛盾怎么解会贯穿后面所有程序架构和硬件选型的决策。换句话说如果只是把20轴伺服、一堆气缸、模拟量模块、多个通讯口全塞进去然后按顺序一轮一轮扫描那伺服大概率会跟不上节拍通讯也容易超时。所以第一步必须先做分层哪些任务走高速同步循环哪些任务走普通OB1扫描哪些任务靠中断和时间片触发。这套架构想清楚了后面组态、写程序、调试才不会反复翻工。2. 20轴伺服控制的硬件选型大型项目的第一个分水岭伺服轴数一多硬件平台基本就限死了。中小型PLC带个三四轴没问题但20轴的情况下建议直接上大型PLC平台配合高速运动控制接口否则CPU扫描周期会被轴控制任务吃掉一大部分剩下的逻辑控制、通讯任务很容易被挤得喘不过气。我在类似规模的项目里用的方案是PLC运动控制模块伺服全部走高速总线连接轴控制指令由运动控制模块独立处理CPU只负责下发运动任务和接收状态这样轴数增加不会拖慢整个控制器的逻辑扫描。2.1 轴的分类规划这20个轴并不是一视同仁的拿到20轴的需求时第一件事是先给轴分类。机械手本身可能就占了6到8个轴其中有几个是联动插补的比如XYZ三轴加上旋转轴另外十几个轴则是独立的定位轴比如各个搬运工位、转盘、压装机、点胶头。这两类轴对控制的要求完全不同——插补轴需要协调运动轨迹是连续空间里的路径规划独立定位轴只需要点到点移动给个目标位置和速度就行。我的经验是在项目启动阶段就把轴表做出来每行一轴列清楚轴名称、电机功率、编码器类型、减速比、行程范围、速度上限、对应的伺服驱动器型号、挂在哪个驱动总线接口上、归属哪个设备区域。这张表既是组态的依据也是后期调试的索引。没有这张表的20轴项目调试现场基本靠猜。2.2 组态与调试工具里的关键动作伺服组态这个环节有几个特别容易出问题的小细节。第一个是电子齿轮比的设置。很多伺服驱动器的默认电子齿轮比是按整圈脉冲数设计的但机械结构一旦经过减速机PLC侧移动单位必须换算成工程单位比如毫米或度。这个换算关系写在轴参数里写错的结果就是轴跑得飞起但实际位置完全不对更麻烦的是这种错误不一定报故障它会在运行一段时间后才暴露。第二个是每根轴的硬限位和软限位。硬限位接在驱动器上软限位写在PLC轴参数里。理论上这两个都该配但现场经常出现只配硬限位不配软限位或者反之的情况。软限位写错的话轴会自动停在错误的位置上质量事故就是这么来的。我在每次上电后的第一件事就是把所有轴的限位状态、回零状态、使能状态通过变量表刷一遍。第三个是回零方式的统一。20个轴如果回零方式不统一产线一启动就是灾难——有的轴用脉冲回零有的轴用绝对值编码器免回零有的靠撞块加编码器Z相。我建议在项目初期就规定好有绝对值编码器的轴直接设成上电免回零增量式的轴统一用撞块回零并且回零方向、速度、找Z相的顺序都要一致。这样以后换伺服电机、换编码器电池维护人员不用翻图纸也能把轴找回零状态。2.3 运动控制程序的框架状态机比一坨梯形图可靠20轴项目里最怕的就是把运动控制逻辑全部写成一段段的梯形图轴一多互锁关系乱七八糟改一处漏三处。我习惯的做法是给每根轴单独建一个轴功能块功能块内部做成状态机待机、回零、运行、暂停、报警、手动。每个状态里只处理该状态该做的事状态与状态之间通过触发条件切换。这样不管轴的数量增加多少程序结构都是复制粘贴再改参数不会出现轴多了就乱的情况。轴功能块对外只暴露几个接口目标位置、速度、加速时间、启动命令、停止命令、状态反馈、报警码。上位逻辑比如机械手流程、工位流程只需要调用这个接口不需要关心轴内部怎么实现。这也是我在多个轴项目里能快速交付的原因——轴控制层一旦稳定工艺逻辑层写起来相当于搭积木。3. Modbus和RS232在老设备与第三方设备通讯里的分工标题里同时出现了modbus和RS232这其实是两种完全不同性质但经常被放在一起的通讯需求。让我先理清思路modbus是协议层的家伙它定义了数据怎么组织、怎么寻址、怎么校验而RS232只是物理层的一种电气接口标准。也就是说modbus可以跑在RS232上也可以跑在RS485上甚至可以通过以太网跑modbus TCP。所以这个项目里应该存在两类通讯场景——一类需要和变频器、仪表等modbus设备对话另一类需要直接对接只提供串口协议的设备比如老式条码扫描枪、某些专用控制器。3.1 Modbus轮询策略与从站响应时间modbus RTU通讯在PLC项目里算是基本功但20轴项目的现场环境比较特殊因为设备多、干扰大、通讯对象杂。最常见的问题不是协议本身不会写而是轮询策略设计得不好。比如只用一个通讯端口下面挂着十几台变频器每台都要读取频率、电流、状态还有的要做写操作。如果轮询顺序不对或者某个从站的响应超时时间设置过长整个通讯周期会被拖到几百毫秒。我的做法是分优先级。把必须实时监视的从站放前面每轮都扫把偶尔才需要读写的从站放后面几轮才扫一次状态字这种关键数据单独用快速轮询组。程序里给modbus通讯单独开一个功能块负责扫描调度数据全部先落到DB块里工艺逻辑只从DB块取值不直接和通讯功能块耦合。这样哪怕某个从站突然掉线工艺逻辑也不会跟着崩溃最多是读到旧数据或者一个无效标志。3.2 RS232的坑波特率、接线和第三方协议的不确定性RS232在工业现场的地位比较尴尬——现在新设备基本都换以太网或者RS485了但产线上总有几个老设备还留着九针串口。标题里点名RS232说明现场确实有这类设备。RS232通讯最大的特点是短和慢一般也就15米以内波特率往往限制在9600或者19200。这不是什么大问题问题是第三方设备的协议经常不在你的控制范围内。我就遇到过一款老式称重仪表接口是RS232协议是厂家自定义的ASCII格式数据帧里既没有起始符也没有固定长度全靠读取超时来判断一帧结束。你没法改对方的程序只能在PLC侧适应。这种情况下建议不要用PLC自带的自由口功能硬写而是先拿串口调试工具把真实报文抓下来逐字节分析之后再做解析逻辑。凡是RS232对接的第三方设备我都要先问三件事波特率、数据位停止位校验位、报文格式。这三个参数任何一个不对通讯都是白扯。还有一个容易被忽略的地方PLC的RS232口通常是9针公头而第三方设备的串口有的也是公头中间必须接交叉线2号线和3号线对调地线直连。这个细节能让现场调试少折腾半天。实际项目里我用过带隔离的串口模块尤其是通讯走线离变频器比较近的时候隔离能挡掉不少共模干扰。4. MES通讯上层数据交互的重头戏MES通讯是现在大型产线的标配需求标题里把它单列出来说明这个项目不是单机自动化而是全厂信息化的一环。MES和PLC之间通常走以太网协议层面五花八门有的MES直接开放OPC UA接口有的要求PLC主动通过TCP/IP上报自定义JSON格式报文有的必须调用MES提供的动态链接库还有的用数据库中间表方式让PLC往SQL Server里写数据。对这个项目来说关键不是选哪种协议而是先搞清楚MES方到底提供了什么。4.1 通讯方式选型的真实思考如果MES那边能提供OPC UA接口我个人最推荐这种方案。OPC UA的好处是标准化程度高数据模型清晰而且PLC侧有现成的功能块能用不用自己去拼报文、处理粘包、解析字符串。但现实里很多制造业老工厂的MES都是早年定制开发的OPC UA没那么好打通反而是自定义TCP报文更常见。自定义TCP报文的方式意味着PLC要作为客户端主动往MES的服务器端口发数据然后接收MES的下发指令。这里面的核心工作就两件一是报文组帧二是状态机的管理。报文设计需要双方坐下来定——帧头、功能码、数据长度、数据域、CRC校验、帧尾每一项都不能有歧义。我参与过的项目里数据域通常是JSON格式虽然解析JSON对PLC来说比较费劲但好处是MES那边改字段时不用改协议结构双方程序改起来都方便。4.2 握手与断线重连MES通讯里真正要命的地方MES通讯很少有一上来就跑得顺的多数问题出在握手协议和异常处理上。生产现场的网络不可能永远稳定千兆交换机偶尔也会闪断MES服务器要重启升级网线会被维护师傅踢掉。如果PLC和MES之间的通讯只做正常流程的报文收发不做断线检测和重连机制那一次网络波动就能让整条产线停下来。我的处理思路是维护一个通讯状态机状态包括空闲、连接中、已连接、发送中、等待应答、重连延时。每次发送报文后启动一个超时定时器定时时间到了没收到应答就把这条报文标记为失败并进入重连流程。重连不能太频繁建议加一个退避延时比如首次3秒、二次10秒、三次30秒避免在MES服务器还没恢复时反复撞击。数据交互按照流水号对应每条报文都带一个递增的帧序号MES回包时也回同样的序号PLC才能确认是这条报文的应答。这种机制看起来笨但实际现场运行起来非常稳。4.3 数据上传的时机与缓冲机制MES通讯里另一个容易被工艺人员忽视的问题是数据填报时机。产线上MES需要的数据有实时数据当前工位状态、当前报警、事件数据过站记录、检测结果、以及累积数据产量、良率。事件数据必须在事件发生时立刻上传否则过了这个村就没这个店了。但网络可能刚好卡顿所以PLC侧必须做本地缓存。我在程序里专门划了一块数据缓冲区存最近几笔还没成功上报的事件。每笔数据带一个上传状态标志待发送、发送中、已确认、发送失败待重试。这个缓冲区的深度不用做很大三五十条足够了但必须保证掉线时数据不丢恢复后自动补传。很多项目验收时MES通讯看着通了但一跑就会发现产量统计不对原因就是事件数据在网络闪断的瞬间丢了。缓存机制一加上这类问题基本绝迹。5. 气缸时序与机械手联动把逻辑控制做稳的工程方法气缸在产线里就是干糙活的夹紧、顶升、阻挡、定位、换向动作简单直接。但气缸多了之后时序问题就暴露出来了。很多初学者觉得气缸就是输出一个电磁阀、再读回一个磁性开关有什么难的真到现场你会发现气缸动作的先后顺序、互锁条件、超时报警才是产线稳定运行的关键。5.1 气缸动作的标准化功能块我把每个气缸也做成标准功能块输入是动作请求输出是到位反馈和故障标志。气缸功能块内部自己管着伸出、缩回、等待到位、超时检测这些逻辑。工艺程序里面只要调用这个功能块不需要每次都在梯形图里重复画电磁阀输出和到位检测的回路。设计气缸功能块的时候有几个细节值得注意。第一个是到位超时时间一般给3到5秒视气缸行程和气压而定。超时之后要报警提示工艺人员检查气路、磁性开关和机械卡滞而不是让产线默默停在那边没动静。第二个是磁性开关的滤波时间气缸动作瞬间会产生抖动如果直接用磁性开关信号去触发下一步动作经常会出现误触发。我在程序里给磁性开关加了一个20到50毫秒的稳定时间滤波大多数情况下能挡住抖动误报又不至于影响节拍。第三个是气缸动作的安全条件这和机械设计强相关比如某个工位没有工件时压紧气缸不能被触发——这些互锁条件要提前列个清单写进功能块里。5.2 机械手的握手协议比你想的更简单也更严格标题里的机械手在这个项目里我理解为一台独立的多轴机械手可能是直角坐标式也可能是关节式。它和PLC之间的关系通常是PLC负责给机械手派活机械手干活然后回报完成。这种关系用一套握手信号就够启动请求、机械手忙、完成信号、故障复位。握手看似简单但细节决定成败。最容易被忽视的是信号沿的问题。PLC输出一个启动信号给机械手机械手收到后开始动作但机械手程序可能扫描周期比较慢如果PLC长时间保持这个信号不撤机械手可能会认为又来了一轮新任务。所以我的惯例是脉冲式握手——启动信号保持200毫秒后自动撤销机械手那边只检测信号的上升沿。反过来机械手回报完成信号时也要遵循同样的原则。两侧的信号处理如果不统一就会出现要么任务重复执行要么完成的信号被漏掉。机械手和PLC的数据交互也不只是互锁信号通常还要下发位置参数或配方号。这就要定义一套数据块明确每个区域存什么、谁写谁读、什么时候有效。我在实际项目中有一套规矩只允许PLC写任务下发区机械手侧的回读状态写在任务反馈区两区域完全分开不允许互相越界。这套规矩在联调时能省掉大量相互扯皮的时间。5.3 全产线节拍平衡程序架构的最终试金石气缸、机械手、伺服全部联动之后程序最考验人的地方是节拍平衡。我一般会做一个主流程状态机从上一工位完成信号出发依次触发本工位的气缸动作、伺服定位、机械手请求然后等待所有反馈条件满足后进入下一步。这个状态机用步号来驱动每一步完成什么动作、等待什么条件、超时跳到哪个报警步都在一张步进表里写清楚。步进表的设计是调试时的最大利器。现场跑不起来的时候先看当前步号停在哪一步再去看等待的条件为什么没满足直接就能定位到是传感器没到位、气缸没动作还是机械手没回报完成。没有步进表的产线程序一报警就是一片乱麻。我见过不少现场程序是几百行线圈输出互相套着写的报警之后维修师傅根本无从下手只能全手动一步步点。6. 模拟量信号处理压力、位置、温度的读数与滤波实战模拟量在伺服和通讯项目里经常被当作配角但它恰恰是很多质量问题的根源。产线上需要监测气路压力是否足够、气缸推力是否正常、压装位置是否到位、温度是否超限。这些东西不是简单的0或1而是一个连续变化的数值都要靠模拟量通道采集上来。标题里单独提到了模拟量说明这套系统里模拟量点位还不算少而且有些可能直接参与闭环逻辑比如根据压力值判断是否允许进入下一步工艺。6.1 硬件接线与量程匹配先别急着写程序模拟量采集的第一个拦路虎是量程和接线。传感器输出信号常见的有4到20mA电流、0到10V电压、以及某些特殊的毫伏级信号。PLC模拟量模块的输入类型必须和传感器匹配电流信号接电流端电压信号接电压端接错了轻则读数不准重则烧模块。模块内部量程卡也要拨对——现在很多模拟量模块是软件组态的但在组态里也要选对量程范围。举个最典型的例子压力变送器输出4到20mA量程是0到1MPa。PLC侧组态时如果模块支持0到20mA或者4到20mA两种选择一定要选4到20mA并把超出量程下限的故障报警打开。因为4到20mA的传感器在断线时电流会掉到0mA如果按0到20mA组态程序会把断线误读成0MPa然后一路压装下去轻则报警重则设备损坏。组态时把量程下限故障检测打开断线就能立刻被捕捉到。6.2 工程量换算PLC里最常见的差之毫厘谬以千里模拟量通道采集到的原始值是一个整数范围取决于模块分辨率常见的是0到27648对应0到10V或0到20mA。这个原始值必须换算成工程量才有意义。换算公式其实很简单工程量 原始值 / 量程上限 × 工程量上限。以4到20mA、0到1MPa为例当原始值是5530时对应4mA工程量应该是0MPa当原始值是27648时工程量是1MPa。但是这个线性关系里有个偏移量很多人在这一步漏掉了4mA对应的5530这个零点偏移。我建议在功能块里把零点原始值一线市场上通常叫raw zero和满量程原始值raw full作为输入参数让程序自动做线性换算。同时把换算结果再做一个工程量上下限的钳制防止传感器超量程时读出一个离谱的大数参与后续逻辑。这个钳制操作很便宜但能在现场避免很多莫名其妙的连锁反应。6.3 滤波策略平均值滤波不是万能的模拟量信号在现场总是带着噪声的尤其是变频器密集的区域未屏蔽的传感器线会感应出一堆乱七八糟的东西。处理噪声的手段无非两个硬件上用屏蔽线并单端接地软件上做滤波。很多PLC程序里默认做循环平均值滤波取最近N个周期的平均值作为当前值。这个办法对缓慢变化的信号有效但对快速变化又需要及时响应的信号就不合适了。我的经验是分两种场景。对压力、温度这类变化较慢的信号可以采用移动平均值滤波窗口长度建议10到20个扫描周期效果明显且延迟可接受。对位移传感器这类需要实时参与位置判断的信号平均值滤波会带来相位延迟可能造成超调或者到位判断滞后。这时候适合用一阶惯性滤波或者干脆只做限幅滤波——也就是如果当前值和上次值的差值超过设定阈值就认为这是毛刺用上次值否则更新当前值。6.4 模拟量的报警阈值与迟滞最后再聊聊报警。模拟量参与报警判断时如果只有一个上限阈值现场会出现报警值附近反复触发、反复恢复的现象。解决这个问题必须加迟滞区间比如压力上限报警值是0.85MPa恢复值设成0.80MPa。这样压力上升到0.85触动报警低于0.80才消除报警中间的0.05MPa就是迟滞带。迟滞的意义在于避免信号在阈值附近波动时给操作员造成报一下就恢复恢复又报的烦躁感。凡是带报警的模拟量点位我建表时都会同时写上报警值和恢复值两个参数。7. 调试期间的实战心得从纸上谈兵到联机运行的必经路项目写到这里程序架构、硬件组态、模块化功能块都说完了但真正的考验永远是现场调试。每个项目的调试阶段都是问题的高发期很多在图纸上和程序里看不出来的问题一通电一运行就全暴露了。这个项目涉及的设备种类多通讯协议杂调试周期也比单类型设备的项目长得多。7.1 先做静态测试别急着跑整线拿到通电条件后的第一件事我建议是所有IO点逐个点一遍。数字量输入用短接线短接信号确认PLC侧对应位闪烁数字量输出直接给强制确认继电器动作、电磁阀动作、接触器动作。模拟量输入在传感器端加标准信号源确认模块读数和实际值对得上。这一步听起来枯燥但在20轴伺服项目里绝对不能跳过——它能把所有接线错误、地址配置错误和模块通道分配错误一次性捞出来。做通讯测试也是类似的思路。modbus先挂一台从站确认读写都通了再挂第二台每多挂一台就验证一次轮询有没有把周期拖慢。RS232先拿串口调试助手模拟第三方设备把收发报文的时序摸清楚再让PLC和现场设备对接。MES通讯先在测试环境走通一个完整的事务流程再拿生产环境的数据做验证。任何跳过中间步骤直接全线联调的操作最后都会付出更多的时间代价。7.2 伺服调试的顺序问题从单轴手动开始20轴伺服调试必须一根轴一根轴来不能贪快。每根轴先切到手动模式点动正转、反转确认方向正确、限位有效、紧急停止生效。然后做回零操作确认参考点找得对。最后再试自动运行从小速度、小距离开始逐步加大。一根轴的状态确认完再记录在轴表里这根轴就算可以信任了。多轴联调的时候我习惯先让相关的轴一组一组动起来比如机械手的三轴先做一次简单的插补路径看看空间轨迹是否符合预期。千万别一上来就把20根轴全部丢给自动程序跑万一某根轴的限位配置写错了伺服一冲出去就是机械事故。现场调试的速度永远取决于你前面铺垫了多少可靠的底子。7.3 程序备份与版本管理项目后期保命的习惯大型项目的调试不是一两天的事期间程序会被反复修改。我发现很多工程师有个坏习惯——改完程序不归档等到出了问题也不知道是哪一版改坏的。我自己的做法是每天调试结束前把当前PLC程序完整备份一次命名上带上日期和版本号同时在注释里写明今天改了哪些内容。微信或者网盘传一份到本地电脑并不费什么事但关键时刻能救命。版本管理配合我前面提到的步进表尤其有效。某一个工位之前跑得好好的突然不行了翻一下版本记录看看今天改过哪几个功能块基本就能锁定问题源。我见过太多的现场事故最后查来查去问题就是前一天程序覆盖的时候把一个优化好的版本搞丢了。这不是技术问题这是工作习惯问题。7.4 文档输出让项目交付不留尾巴最后一个心得是关于文档的。很多工程师觉得把程序写出来、能跑起来就算完成了但我每次交付项目时都会整理一份控制说明文档内容包括硬件配置表模块安装位置、IP地址、站号、轴参数总表、模拟量通道对应关系、通讯协议报文格式modbus地址映射、MES报文定义、RS232协议说明、报警代码表、以及操作流程的简述。这份文档的意义不只是给业主方维护人员看的更是给自己留的一份记忆备份。半年后产线改造、工艺调整你翻出这份文档能快速想起来当初设计时的思路和坑点。否则一个20轴的项目半年后你可能连哪根轴接在哪个模块的第几通道都记不清楚了。项目做多了之后你会发现技术能力固然重要但把经验沉淀成文档才是一个自动化工程师真正增值的地方。