1. 汇川PLC程序结构到底怎么理解1.1 从“一坨梯形图”到“搭积木”的思维转变刚接触汇川PLC那会儿我最怕接手别人写的程序。打开工程一看主程序里密密麻麻几百个网络段输入输出映射、逻辑判断、报警处理、通讯配置全搅在一起改一个气缸动作得翻半天才能找到对应的线圈。后来用上中型PLC尤其是带EtherCAT总线的那批机型我才慢慢琢磨明白一件事程序结构设计的好坏直接决定了后期调试和产线换型的效率。汇川PLC的用户程序结构本质上和搭积木是一个道理。你手里有各种形状的积木块——有的负责逻辑判断有的负责驱动伺服有的负责和触摸屏交换数据——关键不在于积木本身多花哨而在于你怎么把它们组织成一个稳固又灵活的结构。这个结构在IEC 61131-3标准里对应的是POU的概念也就是Program Organization Unit程序组织单元。汇川的PLC编程环境支持这种标准化的组织方式让你能把程序拆成一个个独立的功能块再按需组装。为什么非要这么折腾因为实际项目里设备不是一成不变的。今天做一台六轴机械手明天可能改成四轴加视觉检测后天客户又要加两个工位。如果程序是一整块铁板每次改动都等于重新开模但如果程序是积木结构你只需要替换或增减几个模块就行。这就是程序结构设计的核心价值——让变化变得便宜。1.2 POU、FB、FC到底有什么区别很多刚上手的朋友分不清POU、FB、FC这几个概念我刚开始也迷糊。用最直白的话说POU是个统称就像“交通工具”这个词FB和FC是具体的两种POU类型就像“汽车”和“自行车”。FC全称Function也就是函数。它最大的特点是没有自己的记忆。你给它一组输入它算出一组输出算完就忘下次再调用还是从头开始。适合做纯计算类的活儿比如把脉冲数换算成毫米、做个简单的逻辑组合、算个平均值。FC不占用背景数据块调用起来轻量但没法保存状态。FB全称Function Block也就是功能块。它有自己的“记忆”每次调用都会分配一块背景数据区用来保存这次调用的状态。比如你写一个轴控FB里面要记录轴当前的位置、速度、报警状态这些数据在FB执行完后还得留着下次调用接着用。FB适合做设备控制、状态机、通讯处理这类需要“记住上次干到哪儿了”的逻辑。Program也就是程序是最高层级的POU。它相当于整个项目的总调度负责调用各个FB和FC把数据串起来。一个项目里通常有一个主程序下面挂若干个功能块。我个人的习惯是能用FC解决的绝不用FB因为FC轻量、好调试、不占内存。只有需要保存状态的时候才上FB。这个原则在小型项目里可能感觉不明显但到了中型PLC上几十个轴、上百个IO点的时候FB的背景数据块会吃掉大量内存能省则省。1.3 为什么汇川中型PLC特别强调程序结构汇川的中型PLC比如AM系列、AC系列主打的就是多轴同步和EtherCAT总线控制。这类设备动辄带十几二十个伺服轴每个轴都有自己的使能、回零、定位、报警处理逻辑。如果你把这些逻辑全写在主程序里光是轴控部分就能把程序撑爆更别提后期改参数、加轴、换电机了。而且EtherCAT总线的特性决定了它对程序执行周期有要求。总线通讯是周期性的每个周期要刷新过程数据如果程序结构混乱导致扫描周期波动大总线通讯就可能出问题。把程序拆成独立的FB每个FB执行时间可控整体扫描周期就稳定。这也是为什么汇川的官方例程里轴控、IO映射、报警处理都是分开的FB——结构清晰不只是为了好看更是为了实时性。2. 多任务配置的核心逻辑与实操2.1 任务、程序、功能块的三层关系汇川PLC的任务配置可以理解成公司里的组织架构。任务是部门程序是岗位功能块是具体干的活儿。一个任务下面可以挂多个程序每个程序里再调用各种FB和FC。任务分几种类型最常用的是循环任务和事件任务。循环任务按固定周期执行比如1ms、2ms、10ms事件任务由特定条件触发比如某个输入信号来了才执行一次。中型PLC通常支持多个任务并行但要注意这里的“并行”是宏观上的微观上还是按优先级分时执行。我一般这么分配高速任务跑轴控和总线通讯周期设1ms或2ms中速任务跑逻辑控制和IO处理周期设5ms或10ms低速任务跑报警处理、数据记录、触摸屏通讯周期设20ms或50ms。这样既保证了关键逻辑的实时性又不会让CPU被琐碎任务拖垮。2.2 任务优先级怎么定才不打架任务优先级是个容易踩坑的地方。优先级高的任务可以打断优先级低的任务但如果高优先级任务执行时间太长低优先级任务就可能被“饿死”导致触摸屏卡顿、报警延迟。我的经验法则是优先级和周期挂钩周期越短优先级越高。1ms的任务优先级最高2ms的次之10ms的再低一档。但有个例外——如果某个低速任务里有不能被打断的操作比如写Flash、做数据校验那就要临时提高它的优先级或者干脆放到独立的任务里单独处理。还有一个坑是任务间的数据共享。两个任务如果同时读写同一个变量就可能出现数据不一致。汇川的编程环境里可以用原子操作或者标志位来保护共享数据但最简单的办法是能不用共享变量就不用每个任务管好自己的数据需要交换的时候通过专门的接口FB来传递。2.3 一个多轴项目的任务划分实例拿我之前做的一个六轴机械手项目来说程序结构是这样的任务11ms周期最高优先级EtherCAT总线通讯、六轴伺服的位置环控制、急停信号处理任务22ms周期高优先级六轴的运动规划、插补计算、速度前馈任务310ms周期中优先级气缸逻辑、真空检测、安全门监控任务450ms周期低优先级触摸屏数据刷新、报警记录、生产统计每个任务下面挂独立的程序程序里再调用对应的FB。比如任务1里调用AxisControl_FB六次每个轴一个实例任务3里调用Cylinder_FB若干次每个气缸一个实例。这样结构清晰调试的时候哪个轴有问题就盯哪个FB的实例不用在几千行代码里大海捞针。注意任务周期不是越短越好。1ms周期意味着每毫秒都要执行一次任务CPU负载会明显上升。如果轴数少、逻辑简单2ms甚至4ms也够用。我一般先用2ms跑起来看CPU负载率超过70%就适当放宽周期。3. EtherCAT总线配置的最佳实践3.1 从站扫描与PDO映射的实操细节EtherCAT配置的第一步是扫描从站。汇川的编程环境里你点一下“扫描设备”总线上的伺服、IO模块、网关就会被自动识别出来。这一步看着简单但有几个细节要注意。从站顺序必须和物理接线顺序一致。EtherCAT是菊花链拓扑数据从主站出发依次经过每个从站再绕回来。如果扫描出来的顺序和实际接线对不上通讯就会报错。我遇到过好几次因为网线插错口导致从站顺序乱掉的情况排查了半天才发现是硬件接线的问题。PDO映射决定了每个周期交换哪些数据。伺服驱动器的PDO通常包含控制字、状态字、目标位置、实际位置、目标速度、实际速度、扭矩等。映射的PDO越多每个周期传输的数据量越大总线负载越高。我的原则是只映射用得到的数据。比如一个轴只做位置控制那速度前馈和扭矩数据就可以不映射能省不少带宽。汇川的伺服一般支持两种PDO配置模式默认映射和自定义映射。默认映射是厂家预设好的包含常用数据上手快但不够灵活自定义映射可以精确控制每个PDO的内容适合对性能有极致要求的场景。我一般先用默认映射跑通确认功能没问题后再根据实际需要精简。3.2 分布式时钟与同步周期的设置EtherCAT的分布式时钟DC是实现多轴同步的关键。简单说它让所有从站共享一个系统时间这样多个轴就能在同一时刻执行动作而不是各跑各的。配置DC的时候同步周期要和任务周期匹配。比如你的轴控任务周期是1ms那DC同步周期也设1ms。如果设成2ms轴控任务每1ms执行一次但DC每2ms才同步一次中间那次任务用的就是旧的时间基准同步精度会下降。还有一个参数叫同步窗口它定义了从站允许的时间偏差范围。设得太小从站稍微有点抖动就报同步错误设得太大同步精度又不够。我一般从默认值开始调如果报同步错误就适当放宽但不超过周期的10%。比如1ms周期同步窗口最大设100微秒。实测下来汇川的伺服在DC配置正确的情况下多轴同步误差可以控制在微秒级做插补和电子凸轮完全够用。但如果DC没配好轴与轴之间可能差出几毫秒做出来的轨迹就是歪的。3.3 总线负载与通讯周期的平衡EtherCAT总线的负载率是个容易被忽视的指标。负载率太高通讯就会丢包或者延迟表现为伺服偶尔报通讯错误、IO响应慢半拍。负载率的计算公式大致是负载率 每周期传输的字节数 × 8 / 总线速率 × 周期时间。比如总线速率100Mbps周期1ms每周期传1000字节那负载率就是1000×8/100×10^6×0.001 8%。这个水平很轻松。但如果从站多、PDO映射多负载率可能冲到30%甚至更高。我的经验是控制在50%以下比较稳妥超过60%就要考虑优化。优化的手段包括精简PDO映射、降低非关键从站的通讯频率、把一些慢速IO从EtherCAT转到普通IO模块。提示汇川的编程环境里有总线负载率的实时显示调试的时候盯着这个数值心里有底。4. 常见问题与排查技巧实录4.1 汇川PLC报ER75怎么处理ER75是汇川PLC比较常见的报警通常和EtherCAT总线通讯有关。报这个错的时候先别急着改程序按下面的顺序排查第一步看硬件。检查网线是否插紧、水晶头是否氧化、从站供电是否正常。我遇到过好几次是网线被伺服电机干扰换根屏蔽网线就好了。第二步看从站状态。在编程环境里查看每个从站的通讯状态哪个从站掉线了就重点查那个从站前面的线路和接头。第三步看DC同步。如果所有从站都在线但报ER75很可能是DC同步出了问题。检查同步周期和同步窗口的设置适当放宽同步窗口试试。第四步看总线负载。负载率过高也会导致通讯错误精简PDO映射或者降低通讯频率。第五步看程序。如果以上都没问题那可能是程序里对从站的操作有问题比如在总线还没初始化完成的时候就发指令。检查程序初始化部分的逻辑确保总线就绪后再启动轴控。4.2 任务周期抖动大导致伺服异响这个问题我踩过坑。现象是伺服在运行过程中偶尔发出“咔咔”的异响位置曲线有毛刺。查了半天发现是任务周期抖动太大——本来应该1ms执行一次的轴控任务有时候拖到1.5ms甚至2ms才执行。原因通常是高优先级任务执行时间太长把轴控任务挤到后面了。解决办法是把高优先级任务里耗时的操作挪到低优先级任务或者把大循环拆成小段每次只执行一部分。还有一个原因是任务里调用了阻塞式函数比如等待某个条件成立才返回。这种写法在PLC里是大忌会直接卡死整个任务。正确的做法是用状态机每次执行检查一下条件不满足就退出下次再进来接着判断。4.3 EtherCAT从站掉线重连的处理从站掉线是现场调试的常客。掉线后能不能自动重连取决于你的程序怎么处理。汇川的PLC一般支持从站掉线后自动重连但重连过程中轴会失去使能如果程序里没有相应的保护逻辑轴可能会因为重力或者惯性滑落。所以掉线处理的核心是安全。我的做法是在轴控FB里加一个“通讯正常”的标志位每个周期检查这个标志。一旦发现通讯中断立即触发轴的快速停止同时置位报警。等通讯恢复后不自动恢复使能而是等操作人员确认后再手动复位。这样虽然麻烦一点但安全。如果从站频繁掉线那就要查硬件了。重点查网线屏蔽层是否接地良好、从站供电是否稳定、是否有大功率设备干扰。我遇到过变频器干扰EtherCAT通讯的情况把变频器输出线加磁环、网线走线远离动力线之后掉线问题就解决了。4.4 常见问题速查表现象可能原因排查方向解决措施报ER75总线通讯异常网线、从站状态、DC同步换屏蔽网线、放宽同步窗口、精简PDO伺服异响任务周期抖动高优先级任务耗时、阻塞函数拆分任务、改用状态机从站掉线硬件干扰或供电不稳网线屏蔽、供电、干扰源加磁环、远离动力线、稳压轴不同步DC配置错误同步周期、同步窗口周期与任务匹配、窗口不超10%触摸屏卡顿低优先级任务被饿死任务优先级分配调整优先级、拆分耗时操作程序改不动结构混乱程序组织方式拆FB、分任务、模块化5. 程序结构优化的几个实战心得5.1 命名规范比你想的重要我见过太多项目FB实例命名是FB1、FB2、FB3程序里调用的时候根本分不清哪个是哪个轴。等过了半年再回来改自己都看不懂。我的命名习惯是功能_设备_编号。比如AxisControl_X1表示X1轴的控制FBCylinder_Clamp01表示1号夹紧气缸的功能块。程序里调用的时候一目了然调试的时候也能快速定位。变量命名也一样。输入变量用i_前缀输出用o_内部变量用m_常量用c_。这样在程序里看到变量名就知道它的方向不用来回翻定义。5.2 把调试接口做进FB里每个FB我都习惯留几个调试用的变量比如b_Enable、b_Error、n_State、r_CurrentPos。这些变量在正常运行时可能用不到但调试的时候能省很多事。比如轴控FB里的n_State我用一个整数表示轴当前的状态0未使能1使能中2就绪3运行中4报警。调试的时候盯着这个数值就知道轴卡在哪一步了。比看一堆布尔量直观得多。还有r_CurrentPos和r_CurrentVel实时显示轴的位置和速度。调参数的时候不用开示波器直接在变量表里看就行。5.3 版本管理和程序备份PLC程序不像PC软件没有Git那么方便的版本管理工具。但程序改来改去没有备份就是灾难。我的做法是每次大改之前先备份备份文件名带上日期和改动说明。比如Project_20250115_加了第七轴。这样万一改出问题可以快速回退。另外汇川的编程环境支持导出源程序我习惯把导出的源文件也存一份。有时候工程文件损坏了源文件还能救回来。提示备份不只是存文件还要记录改动内容。我见过有人备份了十个版本但分不清哪个是哪个等于没备份。5.4 从单轴到多轴的扩展思路刚开始做单轴项目的时候程序怎么写都行反正就一个轴。但项目一旦扩展到多轴如果还是单轴的写法程序就会爆炸。我的扩展思路是先写一个通用的轴控FB然后在主程序里实例化多次。这个FB要设计得足够通用能适应不同轴的不同参数——比如有的轴是旋转轴有的是直线轴有的轴带抱闸有的不带有的轴需要回零有的用绝对值编码器不需要回零。通用FB的设计要点是把所有差异都做成输入参数。轴的类型、软限位、回零方式、速度加速度全部通过参数传入。这样同一个FB可以驱动所有轴改参数就行不用改代码。等轴数再多还可以把多个轴的FB封装成一个“轴组FB”统一管理轴组的使能、停止、报警。这样程序结构就是三层主程序调轴组FB轴组FB调单轴FB单轴FB调底层运动指令。层次分明扩展起来很轻松。6. EtherCAT从站开发与第三方设备接入6.1 从站描述文件怎么用EtherCAT从站设备接入汇川PLC需要对应的ESI文件也就是EtherCAT Slave Information文件。这个文件描述了从站的身份信息、PDO配置、同步模式等。没有ESI文件主站就认不出从站。汇川的编程环境里把ESI文件放到指定目录重新扫描设备就能识别。但有时候从站厂家提供的ESI文件版本不对或者PDO配置和实际设备不匹配就会导致扫描到了但配置不了。遇到这种情况我的处理办法是先用厂家提供的默认ESI跑通基本通讯确认从站能正常读写数据后再根据实际需要修改PDO映射。如果厂家没有ESI文件那就只能手动配置从站信息这个过程比较繁琐需要对照从站的手册逐个参数填写。6.2 第三方从站接入的注意事项接入第三方EtherCAT从站比如正点原子RK3568做的EtherCAT主站方案或者STM32做的从站设备有几个地方要特别注意。同步模式要匹配。EtherCAT支持自由运行、SM同步、DC同步三种模式。汇川PLC默认用DC同步如果第三方从站只支持自由运行那就得把主站也改成自由运行或者让从站支持DC同步。模式不匹配的话通讯能建立但数据会漂移。PDO映射要一致。主站和从站的PDO映射必须完全对应主站映射了控制字和状态字从站也得有对应的对象字典条目。如果从站的PDO里没有主站要的数据配置就会报错。看门狗要设好。EtherCAT从站一般都有通讯看门狗主站超过一定时间没发数据从站就进入安全状态。这个时间要设得比任务周期大一些但也不能太大否则通讯断了从站还不知道。6.3 总线诊断工具的使用汇川的编程环境自带总线诊断功能可以查看每个从站的通讯状态、错误计数、同步偏差等。调试的时候我经常开着这个界面一边跑程序一边看数据。重点关注的指标有通讯错误计数如果持续增长说明线路有问题同步偏差如果超过同步窗口说明DC没配好总线负载率如果接近50%就要考虑优化。还有一个实用的功能是总线报文抓取可以记录一段时间内的总线通讯数据分析通讯异常的时候特别有用。不过这个功能会占用一定CPU资源平时不用开只在排查问题时开。7. 从程序结构到项目交付的完整思路7.1 项目初期的结构规划接手一个新项目我一般先花半天时间做结构规划而不是急着写代码。规划的内容包括设备有多少个轴、多少个气缸、多少个传感器哪些逻辑是高速的哪些是低速的哪些功能可以复用哪些需要单独写。然后画一个简单的结构图主程序下面挂几个任务每个任务下面挂几个程序每个程序里调用哪些FB。这个图不用很正式手画就行但一定要有。有了这个图写代码的时候思路清晰不会写着写着就乱了。7.2 调试阶段的程序组织调试阶段程序会频繁改动这时候结构清晰的优势就体现出来了。哪个轴有问题直接找到对应的FB实例改参数或者改逻辑不影响其他轴。哪个任务周期不对单独调整那个任务的周期不用动整个程序。我习惯在调试阶段加一些临时的调试代码比如强制某个输出、模拟某个输入。这些代码用条件编译或者标志位控制调试完就关掉不会留在最终程序里。7.3 交付前的程序整理项目交付前我会做一轮程序整理删掉调试代码、统一命名规范、补充注释、整理变量表。注释特别重要尤其是FB的输入输出参数每个参数什么意思、取值范围、单位都要写清楚。不然过几个月客户问起来自己都忘了。还有一点是程序的默认状态。交付前要确认上电后所有轴是未使能状态、所有气缸是复位状态、所有报警是清除状态。这些默认状态要在程序初始化部分明确设置不能依赖硬件的默认值。7.4 后续扩展的预留设计好的程序结构不仅要满足当前需求还要为后续扩展留余地。我一般会预留10%到20%的IO点和轴数程序里也留好对应的FB实例位置需要的时候直接启用就行。比如一个项目现在用六轴但机械结构上留了第七轴的位置那程序里就先把第七轴的FB实例建好只是不调用。等客户要加轴的时候把调用打开、配置好参数就行不用重新改程序结构。这种预留设计在产线项目里特别有用因为产线经常要改造升级每次改造都重新写程序成本太高。结构设计得好改造就是搭积木换几个块就行。提示预留不是越多越好。预留太多会导致程序臃肿、扫描周期变长。我一般根据客户的实际规划来定客户明确说以后要加轴的才预留没提的就不留。8. 几个容易忽视的细节8.1 变量作用域的管理汇川的编程环境里变量有全局和局部之分。全局变量在整个项目里都能访问局部变量只在当前POU里有效。我见过有人把所有变量都设成全局结果程序里到处都能改变量出了问题根本查不到是谁改的。我的原则是能用局部变量就用局部。FB内部的逻辑用局部变量只有需要和其他FB交换的数据才用全局变量。全局变量也要分类管理比如轴控相关的放一组IO相关的放一组报警相关的放一组。这样找起来方便也不容易冲突。8.2 数据类型的选择PLC里的数据类型选择也有讲究。能用BOOL的不用INT能用INT的不用DINT能用DINT的不用REAL。数据类型越大占用的内存越多处理起来也越慢。但也不能一味求小。比如计数器如果最大计数值不超过32767用INT就行但如果可能超过就得用DINT。选小了会溢出选大了浪费资源。我一般根据实际范围留20%的余量来选。浮点数要特别小心。REAL是32位的精度有限做位置计算的时候如果累积误差大了轴就会跑偏。高精度的位置计算我一般用LREAL64位浮点精度高很多但计算速度会慢一些。8.3 程序注释的写法注释不是写给现在的自己看的是写给半年后的自己看的。我写注释的习惯是每个FB的头部写功能说明和参数列表每个关键逻辑段写一句为什么这么写每个不直观的变量写清楚含义。比如一个轴控FB头部注释会写这个FB控制一个伺服轴支持使能、回零、绝对定位、相对定位、停止、报警复位。输入参数包括轴号、软限位、回零速度、定位速度等。输出参数包括当前位置、当前速度、状态、报警码。关键逻辑段比如回零部分注释会写先找原点开关找到后反向找Z信号然后设置当前位置为零。这样即使过了很久一看注释就知道回零逻辑是怎么走的。8.4 程序加密与知识产权保护有些项目客户要求程序加密防止被复制或者修改。汇川的编程环境支持程序加密可以设置密码保护也可以把程序编译成不可读的格式。但加密也有代价。加密后的程序没法在线调试出了问题只能看报警码猜原因。所以我的建议是如果客户没有明确要求不要主动加密。如果必须加密那就在加密前把程序调试到最稳定的状态并且保留一份未加密的版本自己存档方便以后维护。9. 写在最后的一些个人体会做汇川PLC这些年最大的感受是程序结构设计的能力比会写多少指令重要得多。指令不会可以查手册但结构设计不好程序就是一团乱麻改不动、扩不了、调不通。EtherCAT总线配置也是同样的道理。参数就那么多手册上都有但怎么配才能让多轴同步稳定、通讯可靠靠的是对总线原理的理解和实际调试的经验积累。我刚开始配EtherCAT的时候也是照着例程一步步来出了问题就查手册、问厂家、自己试。试得多了慢慢就有感觉了。最后分享一个小技巧每次调试完一个项目花半小时写个总结。记录这个项目用了什么结构、遇到了什么问题、怎么解决的、有什么可以改进的。这些总结积累下来就是自己的经验库。下次遇到类似的项目翻翻总结就能少走很多弯路。程序结构这件事说到底是让复杂的事情变得简单。搭积木的乐趣不在于积木本身而在于你能用有限的积木搭出无限的可能。汇川PLC的程序结构设计也是同样的道理。 汇川PLC程序结构与EtherCAT总线配置实战指南
1. 汇川PLC程序结构到底怎么理解1.1 从“一坨梯形图”到“搭积木”的思维转变刚接触汇川PLC那会儿我最怕接手别人写的程序。打开工程一看主程序里密密麻麻几百个网络段输入输出映射、逻辑判断、报警处理、通讯配置全搅在一起改一个气缸动作得翻半天才能找到对应的线圈。后来用上中型PLC尤其是带EtherCAT总线的那批机型我才慢慢琢磨明白一件事程序结构设计的好坏直接决定了后期调试和产线换型的效率。汇川PLC的用户程序结构本质上和搭积木是一个道理。你手里有各种形状的积木块——有的负责逻辑判断有的负责驱动伺服有的负责和触摸屏交换数据——关键不在于积木本身多花哨而在于你怎么把它们组织成一个稳固又灵活的结构。这个结构在IEC 61131-3标准里对应的是POU的概念也就是Program Organization Unit程序组织单元。汇川的PLC编程环境支持这种标准化的组织方式让你能把程序拆成一个个独立的功能块再按需组装。为什么非要这么折腾因为实际项目里设备不是一成不变的。今天做一台六轴机械手明天可能改成四轴加视觉检测后天客户又要加两个工位。如果程序是一整块铁板每次改动都等于重新开模但如果程序是积木结构你只需要替换或增减几个模块就行。这就是程序结构设计的核心价值——让变化变得便宜。1.2 POU、FB、FC到底有什么区别很多刚上手的朋友分不清POU、FB、FC这几个概念我刚开始也迷糊。用最直白的话说POU是个统称就像“交通工具”这个词FB和FC是具体的两种POU类型就像“汽车”和“自行车”。FC全称Function也就是函数。它最大的特点是没有自己的记忆。你给它一组输入它算出一组输出算完就忘下次再调用还是从头开始。适合做纯计算类的活儿比如把脉冲数换算成毫米、做个简单的逻辑组合、算个平均值。FC不占用背景数据块调用起来轻量但没法保存状态。FB全称Function Block也就是功能块。它有自己的“记忆”每次调用都会分配一块背景数据区用来保存这次调用的状态。比如你写一个轴控FB里面要记录轴当前的位置、速度、报警状态这些数据在FB执行完后还得留着下次调用接着用。FB适合做设备控制、状态机、通讯处理这类需要“记住上次干到哪儿了”的逻辑。Program也就是程序是最高层级的POU。它相当于整个项目的总调度负责调用各个FB和FC把数据串起来。一个项目里通常有一个主程序下面挂若干个功能块。我个人的习惯是能用FC解决的绝不用FB因为FC轻量、好调试、不占内存。只有需要保存状态的时候才上FB。这个原则在小型项目里可能感觉不明显但到了中型PLC上几十个轴、上百个IO点的时候FB的背景数据块会吃掉大量内存能省则省。1.3 为什么汇川中型PLC特别强调程序结构汇川的中型PLC比如AM系列、AC系列主打的就是多轴同步和EtherCAT总线控制。这类设备动辄带十几二十个伺服轴每个轴都有自己的使能、回零、定位、报警处理逻辑。如果你把这些逻辑全写在主程序里光是轴控部分就能把程序撑爆更别提后期改参数、加轴、换电机了。而且EtherCAT总线的特性决定了它对程序执行周期有要求。总线通讯是周期性的每个周期要刷新过程数据如果程序结构混乱导致扫描周期波动大总线通讯就可能出问题。把程序拆成独立的FB每个FB执行时间可控整体扫描周期就稳定。这也是为什么汇川的官方例程里轴控、IO映射、报警处理都是分开的FB——结构清晰不只是为了好看更是为了实时性。2. 多任务配置的核心逻辑与实操2.1 任务、程序、功能块的三层关系汇川PLC的任务配置可以理解成公司里的组织架构。任务是部门程序是岗位功能块是具体干的活儿。一个任务下面可以挂多个程序每个程序里再调用各种FB和FC。任务分几种类型最常用的是循环任务和事件任务。循环任务按固定周期执行比如1ms、2ms、10ms事件任务由特定条件触发比如某个输入信号来了才执行一次。中型PLC通常支持多个任务并行但要注意这里的“并行”是宏观上的微观上还是按优先级分时执行。我一般这么分配高速任务跑轴控和总线通讯周期设1ms或2ms中速任务跑逻辑控制和IO处理周期设5ms或10ms低速任务跑报警处理、数据记录、触摸屏通讯周期设20ms或50ms。这样既保证了关键逻辑的实时性又不会让CPU被琐碎任务拖垮。2.2 任务优先级怎么定才不打架任务优先级是个容易踩坑的地方。优先级高的任务可以打断优先级低的任务但如果高优先级任务执行时间太长低优先级任务就可能被“饿死”导致触摸屏卡顿、报警延迟。我的经验法则是优先级和周期挂钩周期越短优先级越高。1ms的任务优先级最高2ms的次之10ms的再低一档。但有个例外——如果某个低速任务里有不能被打断的操作比如写Flash、做数据校验那就要临时提高它的优先级或者干脆放到独立的任务里单独处理。还有一个坑是任务间的数据共享。两个任务如果同时读写同一个变量就可能出现数据不一致。汇川的编程环境里可以用原子操作或者标志位来保护共享数据但最简单的办法是能不用共享变量就不用每个任务管好自己的数据需要交换的时候通过专门的接口FB来传递。2.3 一个多轴项目的任务划分实例拿我之前做的一个六轴机械手项目来说程序结构是这样的任务11ms周期最高优先级EtherCAT总线通讯、六轴伺服的位置环控制、急停信号处理任务22ms周期高优先级六轴的运动规划、插补计算、速度前馈任务310ms周期中优先级气缸逻辑、真空检测、安全门监控任务450ms周期低优先级触摸屏数据刷新、报警记录、生产统计每个任务下面挂独立的程序程序里再调用对应的FB。比如任务1里调用AxisControl_FB六次每个轴一个实例任务3里调用Cylinder_FB若干次每个气缸一个实例。这样结构清晰调试的时候哪个轴有问题就盯哪个FB的实例不用在几千行代码里大海捞针。注意任务周期不是越短越好。1ms周期意味着每毫秒都要执行一次任务CPU负载会明显上升。如果轴数少、逻辑简单2ms甚至4ms也够用。我一般先用2ms跑起来看CPU负载率超过70%就适当放宽周期。3. EtherCAT总线配置的最佳实践3.1 从站扫描与PDO映射的实操细节EtherCAT配置的第一步是扫描从站。汇川的编程环境里你点一下“扫描设备”总线上的伺服、IO模块、网关就会被自动识别出来。这一步看着简单但有几个细节要注意。从站顺序必须和物理接线顺序一致。EtherCAT是菊花链拓扑数据从主站出发依次经过每个从站再绕回来。如果扫描出来的顺序和实际接线对不上通讯就会报错。我遇到过好几次因为网线插错口导致从站顺序乱掉的情况排查了半天才发现是硬件接线的问题。PDO映射决定了每个周期交换哪些数据。伺服驱动器的PDO通常包含控制字、状态字、目标位置、实际位置、目标速度、实际速度、扭矩等。映射的PDO越多每个周期传输的数据量越大总线负载越高。我的原则是只映射用得到的数据。比如一个轴只做位置控制那速度前馈和扭矩数据就可以不映射能省不少带宽。汇川的伺服一般支持两种PDO配置模式默认映射和自定义映射。默认映射是厂家预设好的包含常用数据上手快但不够灵活自定义映射可以精确控制每个PDO的内容适合对性能有极致要求的场景。我一般先用默认映射跑通确认功能没问题后再根据实际需要精简。3.2 分布式时钟与同步周期的设置EtherCAT的分布式时钟DC是实现多轴同步的关键。简单说它让所有从站共享一个系统时间这样多个轴就能在同一时刻执行动作而不是各跑各的。配置DC的时候同步周期要和任务周期匹配。比如你的轴控任务周期是1ms那DC同步周期也设1ms。如果设成2ms轴控任务每1ms执行一次但DC每2ms才同步一次中间那次任务用的就是旧的时间基准同步精度会下降。还有一个参数叫同步窗口它定义了从站允许的时间偏差范围。设得太小从站稍微有点抖动就报同步错误设得太大同步精度又不够。我一般从默认值开始调如果报同步错误就适当放宽但不超过周期的10%。比如1ms周期同步窗口最大设100微秒。实测下来汇川的伺服在DC配置正确的情况下多轴同步误差可以控制在微秒级做插补和电子凸轮完全够用。但如果DC没配好轴与轴之间可能差出几毫秒做出来的轨迹就是歪的。3.3 总线负载与通讯周期的平衡EtherCAT总线的负载率是个容易被忽视的指标。负载率太高通讯就会丢包或者延迟表现为伺服偶尔报通讯错误、IO响应慢半拍。负载率的计算公式大致是负载率 每周期传输的字节数 × 8 / 总线速率 × 周期时间。比如总线速率100Mbps周期1ms每周期传1000字节那负载率就是1000×8/100×10^6×0.001 8%。这个水平很轻松。但如果从站多、PDO映射多负载率可能冲到30%甚至更高。我的经验是控制在50%以下比较稳妥超过60%就要考虑优化。优化的手段包括精简PDO映射、降低非关键从站的通讯频率、把一些慢速IO从EtherCAT转到普通IO模块。提示汇川的编程环境里有总线负载率的实时显示调试的时候盯着这个数值心里有底。4. 常见问题与排查技巧实录4.1 汇川PLC报ER75怎么处理ER75是汇川PLC比较常见的报警通常和EtherCAT总线通讯有关。报这个错的时候先别急着改程序按下面的顺序排查第一步看硬件。检查网线是否插紧、水晶头是否氧化、从站供电是否正常。我遇到过好几次是网线被伺服电机干扰换根屏蔽网线就好了。第二步看从站状态。在编程环境里查看每个从站的通讯状态哪个从站掉线了就重点查那个从站前面的线路和接头。第三步看DC同步。如果所有从站都在线但报ER75很可能是DC同步出了问题。检查同步周期和同步窗口的设置适当放宽同步窗口试试。第四步看总线负载。负载率过高也会导致通讯错误精简PDO映射或者降低通讯频率。第五步看程序。如果以上都没问题那可能是程序里对从站的操作有问题比如在总线还没初始化完成的时候就发指令。检查程序初始化部分的逻辑确保总线就绪后再启动轴控。4.2 任务周期抖动大导致伺服异响这个问题我踩过坑。现象是伺服在运行过程中偶尔发出“咔咔”的异响位置曲线有毛刺。查了半天发现是任务周期抖动太大——本来应该1ms执行一次的轴控任务有时候拖到1.5ms甚至2ms才执行。原因通常是高优先级任务执行时间太长把轴控任务挤到后面了。解决办法是把高优先级任务里耗时的操作挪到低优先级任务或者把大循环拆成小段每次只执行一部分。还有一个原因是任务里调用了阻塞式函数比如等待某个条件成立才返回。这种写法在PLC里是大忌会直接卡死整个任务。正确的做法是用状态机每次执行检查一下条件不满足就退出下次再进来接着判断。4.3 EtherCAT从站掉线重连的处理从站掉线是现场调试的常客。掉线后能不能自动重连取决于你的程序怎么处理。汇川的PLC一般支持从站掉线后自动重连但重连过程中轴会失去使能如果程序里没有相应的保护逻辑轴可能会因为重力或者惯性滑落。所以掉线处理的核心是安全。我的做法是在轴控FB里加一个“通讯正常”的标志位每个周期检查这个标志。一旦发现通讯中断立即触发轴的快速停止同时置位报警。等通讯恢复后不自动恢复使能而是等操作人员确认后再手动复位。这样虽然麻烦一点但安全。如果从站频繁掉线那就要查硬件了。重点查网线屏蔽层是否接地良好、从站供电是否稳定、是否有大功率设备干扰。我遇到过变频器干扰EtherCAT通讯的情况把变频器输出线加磁环、网线走线远离动力线之后掉线问题就解决了。4.4 常见问题速查表现象可能原因排查方向解决措施报ER75总线通讯异常网线、从站状态、DC同步换屏蔽网线、放宽同步窗口、精简PDO伺服异响任务周期抖动高优先级任务耗时、阻塞函数拆分任务、改用状态机从站掉线硬件干扰或供电不稳网线屏蔽、供电、干扰源加磁环、远离动力线、稳压轴不同步DC配置错误同步周期、同步窗口周期与任务匹配、窗口不超10%触摸屏卡顿低优先级任务被饿死任务优先级分配调整优先级、拆分耗时操作程序改不动结构混乱程序组织方式拆FB、分任务、模块化5. 程序结构优化的几个实战心得5.1 命名规范比你想的重要我见过太多项目FB实例命名是FB1、FB2、FB3程序里调用的时候根本分不清哪个是哪个轴。等过了半年再回来改自己都看不懂。我的命名习惯是功能_设备_编号。比如AxisControl_X1表示X1轴的控制FBCylinder_Clamp01表示1号夹紧气缸的功能块。程序里调用的时候一目了然调试的时候也能快速定位。变量命名也一样。输入变量用i_前缀输出用o_内部变量用m_常量用c_。这样在程序里看到变量名就知道它的方向不用来回翻定义。5.2 把调试接口做进FB里每个FB我都习惯留几个调试用的变量比如b_Enable、b_Error、n_State、r_CurrentPos。这些变量在正常运行时可能用不到但调试的时候能省很多事。比如轴控FB里的n_State我用一个整数表示轴当前的状态0未使能1使能中2就绪3运行中4报警。调试的时候盯着这个数值就知道轴卡在哪一步了。比看一堆布尔量直观得多。还有r_CurrentPos和r_CurrentVel实时显示轴的位置和速度。调参数的时候不用开示波器直接在变量表里看就行。5.3 版本管理和程序备份PLC程序不像PC软件没有Git那么方便的版本管理工具。但程序改来改去没有备份就是灾难。我的做法是每次大改之前先备份备份文件名带上日期和改动说明。比如Project_20250115_加了第七轴。这样万一改出问题可以快速回退。另外汇川的编程环境支持导出源程序我习惯把导出的源文件也存一份。有时候工程文件损坏了源文件还能救回来。提示备份不只是存文件还要记录改动内容。我见过有人备份了十个版本但分不清哪个是哪个等于没备份。5.4 从单轴到多轴的扩展思路刚开始做单轴项目的时候程序怎么写都行反正就一个轴。但项目一旦扩展到多轴如果还是单轴的写法程序就会爆炸。我的扩展思路是先写一个通用的轴控FB然后在主程序里实例化多次。这个FB要设计得足够通用能适应不同轴的不同参数——比如有的轴是旋转轴有的是直线轴有的轴带抱闸有的不带有的轴需要回零有的用绝对值编码器不需要回零。通用FB的设计要点是把所有差异都做成输入参数。轴的类型、软限位、回零方式、速度加速度全部通过参数传入。这样同一个FB可以驱动所有轴改参数就行不用改代码。等轴数再多还可以把多个轴的FB封装成一个“轴组FB”统一管理轴组的使能、停止、报警。这样程序结构就是三层主程序调轴组FB轴组FB调单轴FB单轴FB调底层运动指令。层次分明扩展起来很轻松。6. EtherCAT从站开发与第三方设备接入6.1 从站描述文件怎么用EtherCAT从站设备接入汇川PLC需要对应的ESI文件也就是EtherCAT Slave Information文件。这个文件描述了从站的身份信息、PDO配置、同步模式等。没有ESI文件主站就认不出从站。汇川的编程环境里把ESI文件放到指定目录重新扫描设备就能识别。但有时候从站厂家提供的ESI文件版本不对或者PDO配置和实际设备不匹配就会导致扫描到了但配置不了。遇到这种情况我的处理办法是先用厂家提供的默认ESI跑通基本通讯确认从站能正常读写数据后再根据实际需要修改PDO映射。如果厂家没有ESI文件那就只能手动配置从站信息这个过程比较繁琐需要对照从站的手册逐个参数填写。6.2 第三方从站接入的注意事项接入第三方EtherCAT从站比如正点原子RK3568做的EtherCAT主站方案或者STM32做的从站设备有几个地方要特别注意。同步模式要匹配。EtherCAT支持自由运行、SM同步、DC同步三种模式。汇川PLC默认用DC同步如果第三方从站只支持自由运行那就得把主站也改成自由运行或者让从站支持DC同步。模式不匹配的话通讯能建立但数据会漂移。PDO映射要一致。主站和从站的PDO映射必须完全对应主站映射了控制字和状态字从站也得有对应的对象字典条目。如果从站的PDO里没有主站要的数据配置就会报错。看门狗要设好。EtherCAT从站一般都有通讯看门狗主站超过一定时间没发数据从站就进入安全状态。这个时间要设得比任务周期大一些但也不能太大否则通讯断了从站还不知道。6.3 总线诊断工具的使用汇川的编程环境自带总线诊断功能可以查看每个从站的通讯状态、错误计数、同步偏差等。调试的时候我经常开着这个界面一边跑程序一边看数据。重点关注的指标有通讯错误计数如果持续增长说明线路有问题同步偏差如果超过同步窗口说明DC没配好总线负载率如果接近50%就要考虑优化。还有一个实用的功能是总线报文抓取可以记录一段时间内的总线通讯数据分析通讯异常的时候特别有用。不过这个功能会占用一定CPU资源平时不用开只在排查问题时开。7. 从程序结构到项目交付的完整思路7.1 项目初期的结构规划接手一个新项目我一般先花半天时间做结构规划而不是急着写代码。规划的内容包括设备有多少个轴、多少个气缸、多少个传感器哪些逻辑是高速的哪些是低速的哪些功能可以复用哪些需要单独写。然后画一个简单的结构图主程序下面挂几个任务每个任务下面挂几个程序每个程序里调用哪些FB。这个图不用很正式手画就行但一定要有。有了这个图写代码的时候思路清晰不会写着写着就乱了。7.2 调试阶段的程序组织调试阶段程序会频繁改动这时候结构清晰的优势就体现出来了。哪个轴有问题直接找到对应的FB实例改参数或者改逻辑不影响其他轴。哪个任务周期不对单独调整那个任务的周期不用动整个程序。我习惯在调试阶段加一些临时的调试代码比如强制某个输出、模拟某个输入。这些代码用条件编译或者标志位控制调试完就关掉不会留在最终程序里。7.3 交付前的程序整理项目交付前我会做一轮程序整理删掉调试代码、统一命名规范、补充注释、整理变量表。注释特别重要尤其是FB的输入输出参数每个参数什么意思、取值范围、单位都要写清楚。不然过几个月客户问起来自己都忘了。还有一点是程序的默认状态。交付前要确认上电后所有轴是未使能状态、所有气缸是复位状态、所有报警是清除状态。这些默认状态要在程序初始化部分明确设置不能依赖硬件的默认值。7.4 后续扩展的预留设计好的程序结构不仅要满足当前需求还要为后续扩展留余地。我一般会预留10%到20%的IO点和轴数程序里也留好对应的FB实例位置需要的时候直接启用就行。比如一个项目现在用六轴但机械结构上留了第七轴的位置那程序里就先把第七轴的FB实例建好只是不调用。等客户要加轴的时候把调用打开、配置好参数就行不用重新改程序结构。这种预留设计在产线项目里特别有用因为产线经常要改造升级每次改造都重新写程序成本太高。结构设计得好改造就是搭积木换几个块就行。提示预留不是越多越好。预留太多会导致程序臃肿、扫描周期变长。我一般根据客户的实际规划来定客户明确说以后要加轴的才预留没提的就不留。8. 几个容易忽视的细节8.1 变量作用域的管理汇川的编程环境里变量有全局和局部之分。全局变量在整个项目里都能访问局部变量只在当前POU里有效。我见过有人把所有变量都设成全局结果程序里到处都能改变量出了问题根本查不到是谁改的。我的原则是能用局部变量就用局部。FB内部的逻辑用局部变量只有需要和其他FB交换的数据才用全局变量。全局变量也要分类管理比如轴控相关的放一组IO相关的放一组报警相关的放一组。这样找起来方便也不容易冲突。8.2 数据类型的选择PLC里的数据类型选择也有讲究。能用BOOL的不用INT能用INT的不用DINT能用DINT的不用REAL。数据类型越大占用的内存越多处理起来也越慢。但也不能一味求小。比如计数器如果最大计数值不超过32767用INT就行但如果可能超过就得用DINT。选小了会溢出选大了浪费资源。我一般根据实际范围留20%的余量来选。浮点数要特别小心。REAL是32位的精度有限做位置计算的时候如果累积误差大了轴就会跑偏。高精度的位置计算我一般用LREAL64位浮点精度高很多但计算速度会慢一些。8.3 程序注释的写法注释不是写给现在的自己看的是写给半年后的自己看的。我写注释的习惯是每个FB的头部写功能说明和参数列表每个关键逻辑段写一句为什么这么写每个不直观的变量写清楚含义。比如一个轴控FB头部注释会写这个FB控制一个伺服轴支持使能、回零、绝对定位、相对定位、停止、报警复位。输入参数包括轴号、软限位、回零速度、定位速度等。输出参数包括当前位置、当前速度、状态、报警码。关键逻辑段比如回零部分注释会写先找原点开关找到后反向找Z信号然后设置当前位置为零。这样即使过了很久一看注释就知道回零逻辑是怎么走的。8.4 程序加密与知识产权保护有些项目客户要求程序加密防止被复制或者修改。汇川的编程环境支持程序加密可以设置密码保护也可以把程序编译成不可读的格式。但加密也有代价。加密后的程序没法在线调试出了问题只能看报警码猜原因。所以我的建议是如果客户没有明确要求不要主动加密。如果必须加密那就在加密前把程序调试到最稳定的状态并且保留一份未加密的版本自己存档方便以后维护。9. 写在最后的一些个人体会做汇川PLC这些年最大的感受是程序结构设计的能力比会写多少指令重要得多。指令不会可以查手册但结构设计不好程序就是一团乱麻改不动、扩不了、调不通。EtherCAT总线配置也是同样的道理。参数就那么多手册上都有但怎么配才能让多轴同步稳定、通讯可靠靠的是对总线原理的理解和实际调试的经验积累。我刚开始配EtherCAT的时候也是照着例程一步步来出了问题就查手册、问厂家、自己试。试得多了慢慢就有感觉了。最后分享一个小技巧每次调试完一个项目花半小时写个总结。记录这个项目用了什么结构、遇到了什么问题、怎么解决的、有什么可以改进的。这些总结积累下来就是自己的经验库。下次遇到类似的项目翻翻总结就能少走很多弯路。程序结构这件事说到底是让复杂的事情变得简单。搭积木的乐趣不在于积木本身而在于你能用有限的积木搭出无限的可能。汇川PLC的程序结构设计也是同样的道理。