近几年在设备改造和新建产线项目中我接触最多的就是三菱PLC。从早期经典的FX3U、FX5U到面向中大型设备的Q系列再到几乎快被行业默认成“中大型项目标准答案”的iQ-R系列很多初次上手的朋友都会问同一个问题iQ-R到底比Q系列强在哪或者更直接一点我手头的项目到底该选FX5U还是iQ-R这篇东西我不打算写成官方手册的复读机就以一个实际做过的“三菱iQ-R系列PLC控制系统项目”为线索把选型逻辑、硬件架构、GX Works3编程、通讯组网以及现场调试里真正会遇到的问题从头到尾过一遍。内容主要围绕iQ-R系列PLC控制系统展开适合正在纠结平台选型、准备从FX系列往中大型方向走、或者接手了iQ-R设备但还没有完整跑通过一个项目的工程师参考。我自己第一次接触iQ-R其实是“被迫”的——客户设备原计划用Q系列结果因为交期和成本原因换成了iQ-R那时候我连GX Works3都还没完全习惯。做完那个项目之后我才发现iQ-R不是简单把Q系列换个壳它的设计思路更偏向“把PLC当成整个设备的大脑而不是一个只会扫梯形图的盒子”。后面陆续用iQ-R做过几台非标专机、一条小型装配线的数据采集站越用越觉得这套系统有很多细节值得展开聊。今天这篇就以一个实际项目拆解的方式把从硬件选型到工程实施再到通讯协议配置的完整链路写出来踩过的坑我也一并整理在里面。1. 项目整体设计与平台选型思路先说这个项目的性质一台非标设备设计节拍大概8秒一件执行机构包括气缸、伺服、变频电机和少量模拟量检测上位机需要实时读取设备运行状态、产量计数和报警记录同时还要和产线的MES系统做数据交互。控制点数不算多DI/DO大概加起来200点以内但设备在不同工艺段有不同的配方参数现场需要支持触摸屏和上位机同时访问而且客户明确要求控制系统必须有较强的扩展能力方便后续加装工位。拿到这个需求很多人第一反应是“FX5U就够了”。确实FX5U在小型设备里性价比很高单CPU自带以太网也能扩展CC-Link IE Field Basic做中小型设备的主站完全没问题。但这个项目有一点不一样设备是给最终客户做量产线用的客户手头的备品备件、维修人员的技术储备都偏向三菱中大型系列而且设备后续可能加视觉工位和多轴运动控制。综合考虑下来我选择了三菱iQ-R系列CPU型号选的是R04CPU配上电源模块、数字量输入输出模块、模拟量模块以及一块用于现场总线的CC-Link IE Field网络模块。选择iQ-R而不是FX5U或者Q系列有三个核心原因。第一个是架构上的差异iQ-R的背板总线跟Q系列完全不同它是真正的“以网络为核心”的设计除了本地IOCC-Link IE、以太网、串口这些通讯接口几乎是标配能力不需要像老Q系列那样反复加特殊模块。第二个是软件平台iQ-R只能在GX Works3里编程GX Works3是标签化、结构化编程的思路变量用名字访问而不是一上来就操心软元件编号这一点在大型项目里优势非常明显。第三个原因最实际——iQ-R的CPU模块自带SD卡槽和内置以太网口日志记录、配方管理、远程维护做起来都很顺手这一点对小团队、少人去现场的项目来说太重要了。当然我不能只夸iQ-R而不说它的代价。iQ-R的成本比FX5U高一个档次而且GX Works3这个软件对习惯了GX Works2、FX3U梯形图的人来说初期有个适应期。另外iQ-R的模块价格不低如果项目控制点数很少、驱动类型简单、没有太多通讯需求老老实实选FX5U反而更合适没必要为了“高级”两个字多花成本。选型本质上是做匹配不是越贵越好。1.1 平台定位iQ-R在MELSEC家族里的位置很多刚从FX系列转到iQ-R的朋友第一困惑是“R系列和Q系列到底什么关系”。简单理解Q系列是三菱上一代的中大型平台主打高速、高可靠性、模块丰富iQ-R是后续推出的新一代平台它沿用了Q系列“模块化”的结构思路但内部总线速度、网络能力、编程环境都做了大版本升级。FX3U是小型一体机FX5U是小型但已经用上了新一代编程软件Q系列是传统中大型iQ-R则是面向中大型、但设计起点更高的新一代平台。iQ-R的CPU模块分了好几档常见有R00、R01、R04、R08、R16、R32这种编号数字越大定位越高但要注意这个数字不代表“处理速度翻了多少倍”更多对应的是程序容量、文件寄存器容量和配套功能的上限。R04这个级别很常用程序步数和数据处理能力足够带几十台设备的中型产线控制再往上R08、R16一般是大型项目或者需要做大量数据运算的场景才需要考虑。这里插一句给FX3U老用户的建议如果你之前用FX3U很熟练跳到iQ-R时不要沿用GX Works2的思维方式。FX3U是“软元件地址”逻辑D0、M0这些编号是固定的程序里直接用地址来写iQ-R在GX Works3里默认是“标签”逻辑你可以给变量起名字比如Motor_Start、Valve_A_OpenCPU会自动分配地址。当然GX Works3里也保留了“软元件直接指定”的模式但那是给移植老程序用的新项目我强烈建议直接用标签。1.2 为什么这个项目选择iQ-R而不是FX5U或Q系列回到这个项目本身除了前面说的客户方技术储备和扩展性要求还有一个实际考虑是CPU的处理能力。这个项目虽然IO点数不算多但有伺服、变频器、模拟量闭环再加上上位机数据采集和配方处理如果全部塞进一个FX5U里CPU扫描周期会变得很紧张尤其是伺服的定位控制和上位机通讯同时跑的时候FX5U的响应抖动会变大。iQ-R的扫描周期可以稳定做到亚毫秒级别配合内置高速总线伺服定位和数据采集的时序抖动小得多。另外就是网络协议的灵活性。这个项目上位机要用C#写一个数据看板软件直接通过以太网读取PLC的生产数据和报警信息。FX5U也支持以太网但FX5U的以太网口更多是走SLMP或者MC协议从功能上说也能用。iQ-R在这方面做得更舒服它的以太网端口支持SLMP、TCP/IP、UDP还能直接做OPC UA服务器上位机如果用OPC UA连接不需要额外写网关程序。虽然这个项目我最终是用MC协议加Modbus TCP来实现的但“多协议同时监听”这个能力给现场调试留了很大的余地。2. 硬件架构与核心模块配置硬件选型这块我一般习惯按“电源- CPU - IO - 网络/通讯- 特殊功能”这个顺序来排。iQ-R的模块全部安装在基板上基板有不同槽位数量可选这个要根据IO点数和扩展模块数量提前估算清楚。我用的是8槽基板缺点是体积稍大优点是以后加模块不用换基板。2.1 CPU、电源和基板的组合方式R04CPU本体自带一个以太网口和一个SD卡槽以太网口支持10M/100M自适应用于上位机连接和程序下载。SD卡可以用来存报警历史、数据日志也可以做程序备份。有些工程师不喜欢用SD卡觉得多此一举但我在这个项目里充分利用了它——设备调试阶段我设置了一个后台任务每小时自动把运行参数、产量、报警代码写到SD卡上的CSV文件里。这个做法在后面排查“偶尔丢料”的隐形故障时帮了大忙因为有一些异常状态转瞬即逝光靠在线监控根本来不及抓。电源模块用的是R61P这是标准配置大家不用纠结。需要注意的一点是iQ-R的基板本身不供电电源模块是单独安装的而且输入电压范围、容量要和后面所有模块的消耗功率做简单的累计。我在一些项目里见过有人把总功率算错了导致系统启动时电压跌落伺服驱动器直接报警。正确的做法是查看每个模块手册里的电流消耗标注预留20%到30%余量。基板和模块安装这些操作层面的事情就不展开了主要说一下背板。iQ-R背板没有Q系列那些“远程IO站”“本地IO站”的复杂概念所有模块直接挂在高速总线上CPU自动识别GX Works3里可以一键完成IO分配。这个体验比Q系列舒服很多老用户应该有体会——Q系列装完模块还要手动分配IO地址模块位置一变就得重来iQ-R基本是零负担。2.2 输入输出模块与模拟量模块选型IO模块我用的是三菱标准DC24V输入模块和晶体管输出模块输入是漏型/源型都支持的那种输出选了晶体管型没有用继电器输出。原因是这个项目里有气缸电磁阀和伺服脉冲信号晶体管输出的响应速度快、触点寿命长继电器输出在频繁动作场景下磨损太快。当然如果负载是220VAC的大功率设备那肯定要选继电器输出或者加中间继电器转接iQ-R模块设计上也有对应的交直流输出类型。模拟量方面现场有两个温度传感器信号和一个变频器反馈电流信号所以加了一块4通道模拟量输入模块。这里有个小提醒iQ-R的模拟量模块分辨率和转换速度可以调但不要上来就把转换速度拉到最高档模拟量滤波才是稳定读数的关键。这个项目里我给温度信号开了数字滤波不然现场变频器一启动温度数值就会上下乱跳。2.3 网络与通讯模块CC-Link IE Field和以太网规划网络这块是这个项目里比较核心的部分。主站CPU自带以太网口用于上位机但现场IO如果全部走本地模块那线缆工程量很大。中间几个分布比较分散的工位我用了CC-Link IE Field总线做远程IO站远程站模块选的是带DI/DO的混合模块一根网线就解决了原本要拉几十根线的走线问题。CC-Link IE Field是三菱目前主推的工业以太网总线传输速率1Gbps最直观的理解就是“用网线跑的现场总线”而且它不是普通以太网那种松散结构是确定性通讯扫描周期很稳定。对于这个项目远程IO站的反应速度完全够用。以太网规划方面我把网络分为两层一层是PLC和远程IO站组成的控制层网络另一层是PLC CPU、触摸屏、上位机组成的监视层网络。严格来说控制层的网络不应该和办公网混在一起我在这个项目里虽然物理上共用了一台交换机但用了不同VLAN把控制流量和上位机流量隔开避免大流量数据上传时影响总线的实时性。这一点很多刚接触总线网络的人容易忽略总觉得几台设备而已接一块就行了实际出问题的时候就后悔了。3. 编程软件与程序架构设计iQ-R的编程环境是GX Works3这个软件从FX5U开始就用也是三菱当前主推的通用编程软件。跟老一代GX Works2比GX Works3最大的变化是“标签化编程”和“结构化工程”。第一次打开GX Works3的人往往会懵一下因为界面上默认看到的是全局标签、局部标签、FB、功能块这些概念不像GX Works2那样直接给一片梯形图画板。3.1 GX Works3下的工程组织与标签化开发这个项目我建立工程时选择了“标签方式”的模式而不是“软元件方式”。这意味着我在程序里写的是Symbol比如Start_Button、Conveyor_Motor、Cylinder_Extend这些有含义的名字而不是X0、Y5这种干巴巴的地址。这么做的好处有很多最直接的好处是程序读起来就像读一份控制流程说明。到了后面客户提出要改工艺把某个气缸的时序调换一下我只要看懂标签名就能快速定位程序段不需要对着IO表反查地址。标签化开发还有一个隐藏优势变量名对于程序监控和故障定位来说简直是救命稻草。在线监控时我看到的不是“M1000变成ON了”而是“气压_低报警为TRUE设备已停机”这种直观程度直接降低了排查门槛甚至客户自己的电气维修工都能对着监控画面判断问题。当然标签化也有一些需要注意的地方标签的数量不能无限膨胀早期不做变量规划后期管理会很难受。比如你给同一个物理信号建了三个不同名字的标签程序里各用各的出问题的时候互相之间没有联系排查起来就变成灾难。我的习惯是在项目开始前先把IO信号表做好每个信号对应唯一的标签名命名规则统一用“设备区域_信号类型_含义”比如MB1_气缸_顶升到位这样可以保持全工程一致。3.2 程序模块划分主任务、子程序和中断任务iQ-R的CPU支持多任务调度这一点跟FX系列差异很大。FX3U/FX5U虽然也有中断程序但本质上还是单一主扫描循环为主。iQ-R的工程里可以建立不同优先级的任务比如主扫描周期任务、定时中断任务、事件中断任务等等。这个项目里我用了几种任务主扫描周期任务用来跑常规逻辑包括IO刷新、气缸动作、报警连锁定时中断任务用来做模拟量读取和闭环计算固定每10ms执行一次还有一个低优先级的后台任务用于数据统计和向SD卡写日志因为这部分不需要实时响应放在后台可以减少对主扫描的压力。这套多任务架构在前期规划时需要想清楚一点实时性要求高的逻辑放高频任务普通逻辑放主循环非实时逻辑放后台任务。如果全部逻辑都塞在同一个任务里扫描周期可能会因为某个大段计算被拉长导致某些急停逻辑响应变慢这是设计问题而不是硬件问题。3.3 核心控制逻辑气缸时序、伺服定位和配方管理这个项目的核心控制逻辑可以拆成三大块气缸动作时序、伺服定位、配方管理。气缸动作时序我用的是状态机写法。状态机这个词听起来玄乎其实本质就是一个变量保存当前状态程序里用跳转条件决定下一个状态是什么。比如设备在一个工位上的动作顺序是“夹紧-钻孔-退刀-放松”传统写法会用一堆置位复位指令去实现一旦条件有变化程序会很累赘。状态机写法是定义Step 0到Step 3每个Step里检测“完成信号”满足条件就跳到下一个Step。后期调整某个工位的动作顺序只是修改跳转条件的逻辑改动范围小不容易引起连锁Bug。伺服定位这里我用了R系列的运动控制模块或者更准确说iQ-R里做运动控制有两种路径一种是通过内置的简易运动控制模块另一种是直接用CPU模块配合驱动器的脉冲控制。这个项目对定位精度要求不算极端用的是脉冲输出控制伺服驱动器的方案主机通过定位指令发脉冲给MR-JE伺服驱动器驱动器控制伺服电机动作。这种方案接线简单、上手快很多非标设备都在用。配方管理这块因为不同产品型号的参数不一样我把配方数据存在CPU的寄存器区并通过触摸屏做一个配方选择画面。每个配方包含几个运动位置值、气缸节拍时间等参数。客户在触摸屏上选好产品型号PLC会把对应配方数据加载到当前工作区。这里有一个常见坑配方参数加载的时机很关键不能在设备运动过程中随便刷新当前值否则伺服会立刻执行新位置可能造成撞机。我的做法是只在设备处于“原点停止”状态下才允许切换配方并重新加载参数。4. 通讯与数据上位的实际实现通讯是这个项目的重头戏因为它直接决定设备能不能和产线系统顺畅配合。这一章我拆成两部分来讲一个是和上位机的数据交换一个是和三菱伺服、变频器以及第三方设备的通讯。4.1 上位机与iQ-R的数据交换方式上位机我这边是用C#写的一个小工具需要实时读PLC的产量计数、当前运行状态和报警信息。通讯协议用的是三菱的SLMP协议也就是老MC协议的以太网版本。SLMP协议本质上是“请求-应答”模式C#程序作为客户端向PLC的端口发请求帧PLC处理完返回响应帧。帧结构不复杂网上也有很多现成库可以用但用库容易忽略一个关键点——SLMP协议里有“子命令号”的区别有的子命令是按字读取有的是按位读取。如果子命令选错了读到的数据完全是乱的这是新手最容易踩的一个坑排查起来也最没有头绪。在这个项目里我专门写了一个类库封装SLMP帧的收发实测下来单次读写响应时间在1到2毫秒左右一秒钟读50次绰绰有余。很多朋友问PLC通讯到底快不快我说一个经验值对于iQ-R来说普通以太网请求应答读写几十个字的数据周期1毫秒到5毫秒都是正常的但如果你的上位机每一帧都要读上千个字的数据响应时间会成倍上涨。这时候最优的做法是让PLC主动拼好数据块上位机一次性读取整个数据块而不是逐条读这样可以把网络开销降一个数量级。上位机数据读取只是单方向真正麻烦的是数据写入的“安全边界”。我在这台设备上做了规定上位机只能写入“允许写入”区比如产量清零指令、配方切换指令而不能直接操作设备运动控制的相关寄存器。原因很简单上位机程序万一有Bug或操作人员误点把伺服目标位置寄存器给写了设备就可能出事故。所以在PLC程序里必须做数据区隔离和运动控制相关、和急停安全相关的寄存器一律不对上位机开放写权限从架构上杜绝风险。4.2 三菱伺服和变频器通讯配置伺服这块前面说了用的是MR-JE系列伺服驱动器通过脉冲方式控制实际上MR-JE也支持串行通讯和CC-Link IE Field Basic网络通讯。这个项目里脉冲控制为主但我也配了通讯连接用于监视伺服电流、负载率、报警状态这些数据。如果驱动器报警PLC可以读到报警代码并在触摸屏上显示维修人员不用打开电柜看驱动器小屏幕了。变频器用的是三菱FR-E800系列通过Modbus RTU协议走RS485和PLC通讯。熟悉三菱的朋友应该知道三菱变频器的Modbus地址和保持寄存器地址有一个映射关系比如运行频率、输出电流都有固定的寄存器编号。只要记住这个映射关系通过PLC写寄存器就能控制变频器启动、停止、设定频率读取电流和报警状态。RS485通讯要注意接线和终端电阻两个设备直接短距离通讯问题不大距离超过几十米或者线上设备比较多时一定要接终端电阻并设置好通讯超时时间的故障处理逻辑。Modbus RTU通讯还会遇到一个经典问题通讯频率太高会占用PLC扫描时间。我见过一些人把Modbus轮询周期设成10ms结果PLC扫描周期被拖到几十毫秒逻辑响应肉眼可见变慢。正确做法是评估实际需求比如温度变化本身就慢500ms轮询一次完全够用真没必要追求极限速度。4.3 SCADA与OPC UA的接入思路很多客户现场除了要设备自己运转还要把数据送进车间级的SCADA系统。这个项目客户用的是第三方上位组态软件让设备PLC作为Modbus TCP服务器SCADA系统通过Modbus TCP读取。这里被问得最多的问题是“SCADA怎么和PLC连接”——其实思路很简单要么走设备厂商自带的专用驱动比如三菱的MC协议驱动要么走通用协议Modbus TCP、OPC UA三菱iQ-R原生支持Modbus TCP和SLMP如果SCADA软件没有三菱驱动选Modbus TCP就一定不会错。如果客户系统要求走OPC UA现在也比较成熟了。iQ-R可以通过参数配置将CPU内的数据暴露为OPC UA节点上位机不需要关心PLC内部地址直接通过节点ID访问变量即可。OPC UA最大的优势是接口标准化上位机开发方不熟悉三菱PLC也能上手而且OPC UA还支持浏览、订阅等多种数据模式。我给不少项目做过类似的配置结论是如果上位机团队水平一般OPC UA是首选如果双方都是工控出身直接用SLMP最快。5. 现场调试实录与常见问题排查调试阶段永远是项目最贴近现实的部分这一章我把我在这个项目以及过往类似项目里遇到的高频问题整理一下每一条都是实际踩过的。5.1 MR-JE报警代码AL10.1这类扩展报警怎么查很多人在三菱伺服报警面前习惯性地慌尤其看到MR-JE系列报警代码像AL10.1这种带小数点的第一反应是翻手册都找不到对应条目。其实这类报警是“报警号加扩展码”的格式AL后面的10是主报警号小数点后的数字是扩展报警码用来区分同类型报警的具体来源。遇到这种报警正确操作是先查主报警号的含义范围再看扩展码定位具体元器件或者信号异常。举个例子AL10在MR-JE里属于欠电压类报警扩展码不同对应的检测电路位置不一样这时最需要做的是量主回路输入电压、检查整流电路和电容看电压跌落是不是发生在伺服加电瞬间。这种扩展码的意义在于把一个大类进一步细分排查起来不用瞎猜。在这里给一个通用建议任何伺服报警优先看报警发生时伺服工作在什么状态是上电报还是在运动中报再量对应的信号线和电源。大概有六成报警的根因都是接线松动、电源容量不足、参数设定不合理真正驱动器硬件损坏的比例反而不高。5.2 FX3U的寄存器保持和固件问题说到FX3U虽然这个项目用的是iQ-R但不少朋友是从FX3U转过来的经常被FX3U寄存器断电保持的问题困扰。FX3U的D0到D8属于普通寄存器默认断电不保持这符合小型PLC的基本逻辑。如果希望断电后数据还能保留可以在PLC参数里设置保持范围。FX3U有一块专门的电池保持区和锁存区设置设置完成后这些寄存器的值在断电后可以通过电池或Flash保持。容易忽略的点是如果电池电量耗尽所有数据会恢复成初始值所以定期监控电池状态也是设备维护的一部分。另外一个经常被问的是“三菱FX3U固件包下载”很多人以为下载更新固件就能解决所有问题实际上FX3U和FX5U的固件是用来修复已知缺陷和增加部分功能的对于正常使用中的PLC如果不是遇到了手册里明确提到的固件Bug不建议随便升级。固件升级操作本身有风险一旦中途断电PLC内部程序可能损坏所以做固件升级之前一定要备份源程序和参数。5.3 程序下载、仿真和在线监控的常见坑GX Works3在线连接iQ-R有好几种方式USB、以太网直连、通过路由器等。常见的问题是以太网连接不上。这个问题八成是IP地址没有配对或者目标CPU的端口被占用了。调试时最好先用USB连接一次确认工程里的网络参数和CPU实际设置一致再切换以太网通讯。还有很多人用仿真功能遇到“启动不了且没有报错”的情况这个在热词里也看到了。GX Works3的仿真器对工程配置有一些限制比如用了某些CPU模块特定的功能时仿真不支持但表面上不报错启动就没反应。遇到这种情况先看工程里的模块配置是不是仿真支持的再看CPU型号是否被仿真器完整支持。仿真只是辅助把它当成“至少能检查语法和逻辑流程”的工具就好真机上的实际通讯和时序还是要靠现场验证。5.4 设备上了电、伺服不动作怎么办“某设备PLC已重置伺服电机不工作”这个现象我见得相当多。原因千奇百怪但排查顺序基本可以固定先用PLC在线监控看伺服使能信号有没有输出再量驱动器控制端子的使能输入有没有电压然后看驱动器有没有报警最后确认位置指令脉冲有没有发出来。很多时候是使能信号逻辑错误——比如急停回路串在使能回路里急停没复位导致驱动器一直收不到使能信号也有的是PLC程序里把使能输出放在某个条件之后条件不满足就一直不输出。这个排查思路对任何品牌的伺服系统都适用。还有一类很隐蔽的坑PLC重置之后原点回归数据丢失。伺服做绝对位置控制的时候如果PLC断电或重置后原点位置寄存器变了伺服会以为自己还在原点结果一启动就往限位方向跑。所以程序里要设计一个“原点回归完成标志”只要这个标志不为真就禁止自动运行。这个细节能避免不少现场事故。5.5 常见问题速查表故障现象排查方向常见根因PLC与电脑连不上IP地址、USB驱动、端口占用工程内网络参数与CPU实际设置不一致伺服AL10.1报警主回路电压、整流模块、电源容量加电瞬间电压跌落、接线端子松动模拟量数值跳变数字滤波参数、屏蔽线、接地变频器干扰、滤波设置不当CC-Link IE Field远程站掉站网线质量、交换机配置、站号VLAN配置错误导致广播报文丢失上位机读不到PLC数据协议子命令、寄存器地址映射、端口SLMP帧格式错误或地址越界FX3U断电数据丢失PLC参数保持范围设置、电池电压保持区未设置或电池耗尽伺服不动作使能信号、急停回路、报警状态急停未复位或原点回归未完成GX Works3仿真启动不了CPU型号、功能支持范围工程模块配置超出仿真器支持范围6. 调试经验结账几点很有价值的技巧聊到这里项目的大体框架和实现路径已经全部走了一遍。最后分享几个在实际调试中我觉得很有价值的技巧这些不属于任何一本手册全是项目现场磨出来的。第一个是关于文档习惯的无论用GX Works3的工程标签管理多方便都要维护一份独立的IO表和标签说明文档。工程文件是程序员的视角而文档是给后来者看的视角。有时候项目交付半年之后客户自己改程序拿着工程文件却看不懂当初设计者的意图文档这时候价值就体现出来了。我做项目时会在每个工程里建一个“README”梯形图段或者注释文件记录下关键模块的用途、报警含义和维护联系方式。第二个是关于旧程序移植的如果你要把Q系列的程序搬到iQ-R上不要试图直接转换完就跑。GX Works3有程序转换向导不假但转换过来的程序地址和标签是乱的用的还是老的软元件方式性能和可维护性都要打折。我的建议是把老程序当成“需求文档”重新用标签和模块化的方式写一遍第一次可能多花两三天时间但后面每一步调试都会省时间。最后一个是关于学习路线的如果你想系统掌握三菱iQ-R建议先啃透GX Works3的框架然后是标签和FB的用法再然后是CC-Link IE和以太网通讯最后才是复杂的运动控制和数据分析。单纯背指令表没有意义iQ-R这种平台的效率提升靠的是结构化架构不是靠某条指令写得有多花哨。对我来说这台iQ-R项目最值得回味的不是那些看起来精巧的程序片段而是用一套清晰的数据流和任务分层把复杂的设备行为理顺。这也正是PLC项目最让人上瘾的地方——外行看到的是硬件的灯在闪内行看到的是整个系统的节奏在有条不紊地运作。