三菱Q系列多轴伺服与多设备通讯实战：从选型到调试避坑全记录

做多轴伺服同步又叠加一堆设备要通讯的项目，选型阶段真的不能只看CPU点数够不够。我接过一条四轴伺服联动外加扫码枪、仪表和上位机数据采集的产线改造，一开始在小型PLC里把轴控制和通讯全塞进去，结果接线乱、调试慢、偶发报警还查不到根因，最后彻底换成三菱PLC Q系列，把多轴伺服和多设备通讯拆成两个独立体系来做，才算把整个项目理顺。这篇就把当时选型、配轴参数、通讯协议搭建和现场调试踩坑的全过程整理出来，给正在做或者准备做类似项目的同行一个参考。

这套东西适合谁看？一是准备在产线上用Q系列加伺服做联动、但不清楚定位模块和伺服放大器怎么搭的；二是设备上既有伺服又要挂一堆串口、以太网设备，想知道各种通讯方案怎么分工的；三是已经在现场调试遇到过伺服轴偶发丢步、通讯偶发断站的，看看我当时一步步定位的过程。

1. 为什么是Q系列：一套设备同时扛多轴伺服和三类通讯

1.1 项目基本盘：四轴伺服加三种通讯协议同时上

这条设备不算特别复杂，但麻烦在什么都有一点。四个伺服轴分别负责送料、切断、搬运、压装，动作顺序互相牵连；设备旁边有一台触摸屏、一把扫码枪、一块数显仪表，还有上位机通过以太网实时采集产量和报警记录。

这些需求单独拿出来都不难，但凑到一起就出现了矛盾：轴与轴之间需要快速联动响应，另外几路通讯又要不停收发数据，如果全部靠CPU扫描周期去轮流处理，定位脉冲的实时性会受到通讯程序的拖累。我上一版方案就是这么翻车的——串口通讯指令一执行，轴响应明显变慢，隔壁设备过来干扰一下，报警信息又乱掉。

后面重新梳理需求后，选型逻辑变成了：CPU只负责逻辑和通讯协调，轴控制全部交给独立的定位模块，让"专业的事归专业模块干"。

1.2 Q系列和常见小型PLC在多轴场景的真实差距

很多人一开始会问：为什么不用脉冲输出型的小型PLC？坦白说，轴数少、动作简单的小设备确实够用，但到四轴联动加插补就有了差距。

首先是硬件层面的差距。Q系列是模块化机架结构，轴控模块、串口模块、以太网模块各占一个槽位，互不干扰。选型时可以按需插入两三个通讯模块再加一个定位模块，不必挤在固定的本体IO上。小型PLC本体自带的脉冲通道通常就2到4路，通讯口也就一两路RS485，扩展起来还得占功能模块的空间。

其次是响应机制的区别。Q系列定位模块（比如QD77或QD75系列）内部是独立CPU，轴脉冲的生成、插补运算、回原点时序都在定位模块内部完成，不受主CPU扫描周期和通讯中断的影响。主CPU只需要通过缓冲存储器下发指令、读取状态就行。这个设计决定了它的动作时序稳定度远超靠本体发脉冲的方案。

最后是维护和排障的差距。定位模块自带详细的轴状态、当前值和报警代码，断在哪一步、为什么停，从缓冲存储器里就能读到数据，不用拿着万用表在端子排上挨个量。跟变频器、伺服放大器混在一个柜子里的时候，模块化布局也更容易做强弱电分离。

我这套项目最终的基础配置如下（供参考，不是唯一解）：

CPU扫描周期当然也不是完全无关，但轴控已经被定位模块包掉了，CPU只要在收到"已完成"信号后切换下一步逻辑即可。材料成本比小型方案高一点，但换来的调试效率和产线稳定度，值这个差价。

2. 多轴伺服系统的硬核配置：从伺服放大器到轴参数逐项落地

2.1 伺服放大器与定位模块的选型组合

选Q系列时最需要先拿主意的是：定位模块用脉冲输出型还是SSCNET光缆型。这两种我都用过，差别挺大。

脉冲型（QD75系列）输出的是差分脉冲指令，伺服放大器选MR-J4-A，驱动器端需要接脉冲线、方向线，还要接编码器反馈线。接线多，每一步动作都受传输线干扰影响，对柜内布线的要求很高。

光缆型（QD77MS系列）走SSCNET III，光缆直接从定位模块串接到各个MR-J4-B伺服放大器，编码器反馈也走同一根光缆，柜内布线干净得多。而且光缆不受电磁干扰，伺服动力线哪怕跟光缆靠近一点，问题也不大。我这次选的QD77MS加MR-J4-B，接线量少一半，调试时省了很多事。

选模块时还要注意轴数上限。QD77MS有2轴、4轴、8轴版本，四轴设备选4轴模块刚好合适，留点余量可以选8轴，但成本和占用槽位也要算进去。插补功能方面，QD77MS支持2到4轴线性插补、2轴圆弧插补，做常见的搬运轨迹和飞剪同步都够用。项目里搬运轴和压装轴要走一段斜线轨迹，用的就是两轴线性插补，效果很稳。

2.2 电子齿轮：把指令单位换算成机械移动量

伺服系统里最容易被忽略、但又最影响定位精度的参数，就是电子齿轮比。很多人看到伺服放大器参数表里PA06、PA07就头大，其实思路很清晰——把"定位模块发出去的脉冲数"和"机械实际移动量"换算到用户能直接使用的单位上。

拿我项目里的送料轴举例。电机通过联轴器直连丝杠，丝杠导程10mm，MR-J4伺服编码器分辨率是131072脉冲/转。我希望工程师在程序里或者触摸屏上直接输"多少毫米"就能控制位置，于是把用户单位定义为1脉冲对应0.001mm（1μm）。那么电机转一圈要走10mm，也就是10000个用户单位；而编码器反馈一圈是131072个计数脉冲。伺服放大器的电子齿轮比就应该设成：

• 电子齿轮比分子（PA06）= 131072
• 电子齿轮比分母（PA07）= 10000

这样伺服内部每收到10000个指令脉冲，就会驱动电机转一圈，刚好走10mm。换算逻辑就这么简单：分子分母分别等于"编码器反馈分辨率除以一圈对应的用户脉冲数"对应的两个值。

真正容易出错的是带减速机的轴。比如搬运轴带1:5减速机，丝杠导程还是10mm，那电机转一圈工作台只走2mm。一圈对应2000个用户单位，电子齿轮比分母就得改成2000，分子还是131072。如果按直连算，这个轴的位置就会放大5倍，一开机对原点就跑飞。

2.3 回原点方案的取舍：近点DOG与绝对位置系统的运维账

回原点是多轴设备开机后的第一道坎。Q系列定位模块提供三种方式：挡块式、近点DOG式、机械式绝对位置。

挡块式最简单，靠伺服碰到硬挡块产生扭矩极限信号确认原点，适合精度要求不高的轴。近点DOG式是主流选择：轴上装金属感应块，接近开关碰到DOG后减速，减速后再找伺服电机Z相脉冲，重复精度高。绝对位置系统则是伺服放大器配电池，断电后编码器位置靠电池保持，开机不用回原点，直接接着上次位置继续干。

我项目里送料和压装用了绝对位置系统，因为这两轴位置和配方强相关，开机马上干活能省不少时间。但这里要给各位提个醒：绝对位置系统的电池寿命一般在两到三年，电池欠压报警必须接进PLC报警逻辑里，否则某天电池耗尽原点全丢，整台设备等于要重新对刀。搬运和切断轴我用近点DOG，每天开机回一次原点，动作不多，但胜在结构简单、维保省心。

回原点参数设置上，快速接近速度我设了300mm/s，碰到DOG后爬行速度降到10mm/s。爬行速度不能太快，太快容易冲过零点，导致每次原点位置有偏差；但如果DOG感应距离很短，爬行速度太低又会停在感应区外，干脆回不了原点。这个速度和感应片长度的匹配，调试现场要用试错法调两三轮，别指望一次到位。

3. 多设备通讯：三种协议在同一条产线上各司其职

3.1 CC-Link：轴间通讯主干道之外的远程IO扩展

多轴伺服真正要联网时，CC-Link是Q系列最常见的现场总线。它不是必须用来带伺服的——伺服走SSCNET，CC-Link我用来带产线侧边的远程IO站和几个变频器。但它在整体通讯架构里的位置很关键：IO点和变频器控制不占CPU物理输入输出，全部通过总线刷新。

做CC-Link配置时核心把握三个参数：站号、波特率、终端电阻。站号是设备在总线上的身份，重复或跳号都会导致通讯建立失败。波特率决定传输速度和最大总延长，10Mbps时总延长只能做到100米左右，降到2.5Mbps能到400米。我柜子到远端IO站的距离大概80米，选5Mbps，留了余量也保证了刷新速度。

CC-Link的刷新机制是把每个从站的输入输出数据映射到主站的缓冲存储器里，然后Q系列CPU通过智能功能模块软元件直接读写这些数据。在程序里用FROM/TO指令或者配置好自动刷新后，远程IO点就像本地IO一样用。很省心。

不过这里不得不提一句：变频器挂在CC-Link下要特别注意总线刷新周期和设备响应时间的匹配，定位模块的轴状态刷新是微秒级，变频器运行频率的刷新是毫秒级，这两种速度差完全不能当成一回事，做程序联锁时千万不要把远程变频器的"运行反馈"当成实时信号去联锁伺服轴。

3.2 串口无协议通讯：和扫码枪、仪表打交道最省心的办法

扫码枪、电子秤、温度表这类仪表型设备，最常见的通讯方式就是RS485或RS232串口。Q系列上一般用QJ71C24-N这个模块，支持无协议通讯，也就是你想发什么帧就发什么帧，完全由上位设备定义的协议决定，PLC这边不掺和解析，只负责收发字节流。

这种模式最大的好处是不受品牌限制。我的扫码枪协议是一串ASCII字符，仪表协议是十六进制报文，两者完全不一样，但我只要在程序里分别组帧、按各自格式解析就行。如果用了三菱自家的专用协议反而会两边对不上。

模块配置时要设定波特率、数据位、停止位、校验位，这些必须跟对方设备保持一致，对不上就是乱码或者完全收不到。我踩过一次：扫码枪默认9600波特率，仪表用19200，结果我在同一个串口模块的两个通道上设错了波特率，扫码枪的数据终端上显示全部乱码，排查了半天才发现是通道参数互相覆盖。QJ71C24-N每个通道是独立的，配置时不要嫌麻烦，一定要逐通道保存并核对。

发送和接收的编程逻辑是这样的：发送时用专用指令发出缓冲区的帧数据；接收可以设定起始码和结束码，比如扫码枪以换行符结束，那模块收到回车换行就自动置位接收完成标志，PLC再通过缓冲存储器读取整帧数据。读走数据后要把接收区清空，否则下一帧覆盖进来会丢数据。这个小细节我一开始漏了，偶尔会出现上一帧和下一帧拼在一起的情况。

3.3 以太网Socket通讯：与上位机/MES对接的关键

产线数据要进上位机或者MES，绕不开以太网。Q系列配QJ71E71-100模块后，最简单的方式是用三菱MC协议，让上位机直接读写PLC的软元件；如果上位机有自己的通讯协议，比如要发JSON字符串，那就用无过程控制的Socket通讯指令从PLC主动发数据。

MC协议对很多搞上位机开发的同事来说是最省事的：上位机按协议格式发请求帧，PLC模块自动应答，不需要在PLC程序里写额外收发逻辑。协议帧的核心字段包括副头部、网络编号、PLC编号、IO编号、站号、请求数据长度、监视定时器、指令和子指令、设备起始编号、设备点数，这一串对好后就能稳定读写D寄存器、M继电器这些软元件。

要注意一个问题：MC协议占用的是PLC软元件地址，多台设备共用同一台Q时，地址规划要提前做。我在程序里把D区的规划画了一份表，产量数据、报警码、伺服当前位置各占哪些区间，全部写清楚贴在控制柜门上。不然几个月后有人来改程序，对着地址表一脸懵。

Socket通讯则适合自定义协议的场景。Q系列能用专用指令打开TCP或UDP端口，然后发送和接收字符串。我上位机的数据采集系统要求每隔两秒主动上报一次设备状态，就是PLC定期组帧字符串，通过Socket指令发到上位机指定IP和端口。注意字节序和帧结束判定，上位机解析是字符串方式，那PLC发送时就要在末尾拼接好分隔符，两端约定一致，通讯才稳。

三种通讯方式在一条产线上各有分工，我按这个原则分的：

4. 程序架构：让四轴程序不失控的FB封装与状态机设计

4.1 轴控制FB：把使能、点动、定位、回原点收进一个接口

四轴设备最怕的就是程序里到处散落着轴控制指令，今天改这个轴，明天改那个轴，改一处忘三处。我的做法是把每个轴的控制逻辑全部封装成功能块（FB），程序里只留一个统一的调用接口。

轴控制FB的输入输出大致是这个思路，用结构化文本(ST)描述比较直观：

FB_AxisControl 输入： AxisNo : 轴号 bEnable : 使能信号 bHomeStart : 回原点启动 bJogPlus : 正转点动 bPosStart : 绝对定位启动 iTargetPos : 目标位置（单位mm） iTargetSpeed : 目标速度 输出： bReady : 伺服就绪 bHomeDone : 回原点完成 bPosDone : 定位完成 bAlarm : 轴报警 iCurrentPos : 当前实际位置

FB内部做的事情是：先检查伺服就绪和急停状态，然后根据输入信号决定执行回原点、点动还是定位，最后把完成标志和报警代码回传给主程序。主程序里四根轴各调用一次这个FB，分别传不同的轴号和参数就行。以后要改某个轴的速度曲线，只需要改FB内部参数或者调用处的参数，不用翻几百行梯形图找触点。

Q系列用GX Works2/3做标签化编程时，FB的接口变量记得用标签而不是裸软元件，这样跨程序复制和后续维护都省心。我甚至把一批常用的设备控制逻辑都做成了FB库，后面做第二条相似产线时，直接复用这四轴FB，时间至少省了三分之一。

4.2 报警联动与手动自动切换的细节处理

四轴设备的程序核心除了动作顺序，还有一个不能马虎的系统：报警联动。我的原则是"故障不叠加、动作有互锁、报警要分级"。

报警不叠加的意思是：一根轴报警时，在屏幕只显示根因报警，不把一堆联动报警同时弹出来。伺服报警从定位模块缓冲存储器读出来之后，我会先做一次"轴根因判断"，比如伺服过载报警就不去额外推送"定位超时"这些衍生报警，否则操作工会被报警信息淹没。

动作互锁则体现在自动流程每个工步的启动条件里。比如送料轴到达位置后，切断轴才能启动；搬运轴的夹爪要确认夹紧到位，压装轴才允许下降。这些互锁写在FB内不比写在主程序里差，因为主程序梯形图长了之后，谁都不能保证每个调用处都记得加互锁条件。把互锁收进FB接口，调用处想漏都难。

手动和自动切换也是需要用心处理的地方。手动模式下面板点动按钮直接操作伺服点动，自动模式下点动按钮全部禁用。这个切换逻辑如果处理不好，会出现在自动运行中途操作工误触点动按钮导致轴飞车的情况。我的做法是增加一个设备模式状态变量，手动模式下调用的点动指令全部带模式判断条件，自动模式触发时强制把点动允许标志清零。

轴报警处理还要和通讯断站做联动。电柜里的远程IO如果偶发断站，Q会报通讯异常，此时自动程序必须中止等待复位，而不是继续往下跑。我在通讯异常处理里做了一段小逻辑：当CC-Link主站刷新异常时，自动流程立刻停到安全工步，所有轴进入暂停状态，屏幕弹出提示。这样即使不在现场，操作工也知道发生了什么。

5. 现场调试两周踩到的坑：干扰断链与原点丢失的完整排查链

5.1 第一坑：伺服启动瞬间定位偶发偏差，查到最后是编码器线缆受扰

设备联调第三天开始出现随机问题——某轴偶发定位到目标位置后实际机构还有零点几毫米的偏差，不是每一次都有。这种偶发问题最折磨人，因为没有固定的复现路径。

我的排查链路是这样走的：先在触摸屏上手动重复跑同一个定位动作，看当前值反馈，排除程序逻辑问题。然后把动作放到低速，问题消失；恢复高速，问题又出现。这时候基本锁定是干扰而不是程序。

接下来借了一台手持示波器，夹在编码器反馈线出口处，让伺服反复启停，看到启动瞬间有明显的振铃干扰叠加在脉冲信号上。再顺着布线查原因，发现伺服放大器动力线在柜内和编码器线走了同一个线槽，距离不到15厘米。

处理办法：编码器线全程换成双绞屏蔽线，屏蔽层在伺服放大器端单端接地；动力线和编码器线彻底分槽走，并拉开30厘米以上距离；伺服放大器动力线输出端加一套磁环。彻底整改后同样的动作跑了两天，偏差没有再出现过。所以配柜子的时候，强弱电分离不是一句口号，是实打实的可靠性保障。

5.2 第二坑：CC-Link远程IO偶发断站，一步步定位到布线长度

第二个坑发生在通讯侧。产线上到远端IO柜的距离有80米左右，运行几天后偶发断站，每次都是几秒后自动恢复，不规律，特别像接触不良。

一开始我的判断是某处端子接线松动，把所有接头重新压了一遍，还是偶发。接着怀疑终端电阻，把两端110欧电阻换新，问题依然没有消除。再用万用表量通讯线A、B之间的波形，发现波形在远端明显畸变，有反射现象。CC-Link在波特率5Mbps时的实际安装距离裕量已经不高，两端站数又多，反射造成了偶发误码。

最终解决方式是降低波特率到2.5Mbps，对应总延长距离更宽裕，同时把中间的一处T型分支线缆整改成逐站串联结构，波形恢复正常。CC-Link的布线规则是手拉手结构，T型分支会破坏阻抗匹配，现场不太合规的接法一定会用某种方式还回来，别心存侥幸。

5.3 第三坑：回原点偶尔多走一段，根因居然在DOG感应距离和爬行速度

第三个坑是回原点偶尔多走一小段。送料轴用近点DOG回原点，正常情况下偏差在正负2μm以内，但偶尔会出现回原点后比标准位置多了大概0.5mm。0.5mm这个数字很微妙，正好接近电机转半圈左右的距离。

分析后基本确认是回原点时，爬行阶段的零点搜索出了问题。近点DOG回原点原理是：快速碰DOG后停下来转为爬行，爬行中等待伺服Z相零点信号，Z相一来就锁停。如果我爬行速度偏高，导致Z相零点过冲后伺服来不及急停，就会锁定在Z零点之后若干脉冲的位置，这个位置就是那段多出来的偏移。

现场用示波器看DOG信号和Z相脉冲的时序后发现：DOG感应片安装位置太靠前，爬行距离长，速度还没降到位Z相就到了，等于没有真正减速就锁停。解决方式是：把回原点爬行速度从40mm/s下调到10mm/s，同时把接近开关的安装位置往前挪了2厘米，让DOG感应更早开始，在Z相到来前充分降速。改完后再跑了几十次，回原点位置偏差稳定回到正负2μm以内。

回原点参数的经验可以总结成一句话：爬行速度宁可慢，等Z相等久一点，别追求那点回原点的效率。产线上这类问题反复出现时，先怀疑机械安装位置，再怀疑速度参数，最后怀疑编码器硬件。

做完这套项目，我的体感是Q系列的优势不在于某一个单项参数有多强，而在于它把轴、总线、串口、以太网这些复杂需求拆成了独立模块，各自稳定运行，逻辑层只做协调和判断。遇到轴控制问题就去查定位模块，遇到通讯问题就去查对应通讯模块，边界清晰，调试和故障定位快。

最后分享一个我实际现场攒下来的小习惯：程序里给每根轴、每路通讯都建立独立的运行状态字，包含就绪、忙碌、报警、当前值、最近一次报警代码五个字段，同时显示在触摸屏的工程师监控页上。这样不管是谁在维护这台设备，不用翻程序就能定位问题出在哪一环节。对于多轴加多通讯的设备，这种"可观察性"比什么技巧都值钱。