欧姆龙NJ与EtherCAT多轴伺服控制：ST语言编程与调试实战要点

最近刚交付了一条新能源电池方向的产线改造，核心是1台欧姆龙NJ系列PLC，EtherCAT总线挂了24台伺服，程序主体用ST语言来写。整套系统从选型到调试做了将近两个月，中间换过思路、踩过不少坑，也沉淀出一套适合中大型多轴项目的编程套路。今天把这些经历整理成文，重点聊NJ+EtherCAT+ST这套组合的架构思路、轴控封装、总线配置，以及现场调试必须注意的细节。

如果你刚接触欧姆龙NJ，或者过去一直用梯形图，想往结构化ST方向转，这篇能帮你避开不少弯路。就算你做的是西门子、倍福或者三菱的多轴项目，里面关于总线周期、电子齿轮、状态机、波形调试的思路也完全通用。24台伺服听起来规模不小，但把逻辑拆开看，本质上还是“选型、组态、封装、调试”这四件事。

1. 项目整体设计与选型思路

1.1 为什么是“NJ + EtherCAT”，而不是老一套

先交代一下背景。传统多轴设备里，比较常见的做法是PLC加高速脉冲输出模块，或者走模拟量速度控制，再配合外部定位模块。老项目我也做过二十多轴脉冲控制，那个现场排查的过程是真的折磨。脉冲线屏蔽不到位会丢脉冲，伺服一多接线就乱，就算用差分输出，高速脉冲在长距离传输时依然容易受干扰。

这条电池产线24台伺服，还有大量夹紧、顶升、扫码、视觉拍照这类辅助IO。如果继续用脉冲方案，光是屏蔽线敷设和故障点排查就够项目拖半个月。EtherCAT的方案等于把“模拟量+脉冲”全部替换成了数字报文，伺服的位置、速度、转矩、报警都走同一根网线，主站和从站之间实时交换数据，抗干扰能力和接线简洁度完全不是一个级别。

欧姆龙NJ系列对EtherCAT的支持是原生级的。在Sysmac Studio里组态好从站，配置好同步周期，PLC就直接把伺服当作自己的轴来管理，不需要额外的运动控制模块。这种“PLC + 总线伺服”的架构，对这种轴数多、节拍紧、控制要求高的产线非常合适。

从总线周期上看，一般设备设在1ms或2ms足够，没必要盲目压到0.25ms。我也试过0.25ms周期，NJ能跑，但第三方伺服的反应一致性、分布式时钟稳定性都是风险点。正常锂电产线的定位精度要求基本在正负0.05mm以内，1ms周期完全撑得住，还能给ST逻辑留出更多CPU余量。

1.2 为什么把程序主体写成ST语言

做大型产线，梯形图最大的问题不是能不能做，而是把人绕进去。24台伺服、多个工位、无数互锁，如果全部用梯形图表达，光常开常闭触点的排列组合就能铺满几十页。ST语言的好处是表达逻辑特别直接，尤其适合状态切换、数据处理和数学运算。

欧姆龙Sysmac Studio支持IEC 61131-3标准，ST和梯形图可以混用。我的习惯是核心运动控制、工艺流程、轴状态管理用ST，简单的起保停和IO安全互锁用梯形图。这样两种语言的优点都用上，维护的同事看着也不至于头大。

尤其是24轴项目，如果用ST把轴操作封装成功能块，逻辑层调用起来就几行，改动作很快。这一点和TwinCAT的ST、西门子的SCL是相通的，有IEC61131-3经验的人上手NJ的ST几乎没有成本。真正让大项目难维护的，往往不是某个功能不会写，而是重复性代码太多、细节逻辑散落各处，结构化封装就是专门治这个问题的。

2. 24轴运动控制的程序架构

2.1 轴控数据模型与功能块封装

24台伺服听起来多，但千万别一轴一轴平铺到程序里。先按工艺分组：上料侧6轴、过程搬运8轴、检测和成品堆叠10轴，每组轴的逻辑相似，但节拍和互锁条件不一样。

我在项目里习惯先定义一个轴信息结构体，把每台轴的状态统一管理起来。类似这样：

TYPE ST_AxisInfo : STRUCT bEnabled : BOOL; // 伺服使能状态 bReady : BOOL; // 轴准备好 bBusy : BOOL; // 运动指令执行中 bDone : BOOL; // 运动完成 bError : BOOL; // 轴故障 wErrorId : WORD; // 故障代码 fActualPos : LREAL; // 反馈位置 fCmdPos : LREAL; // 给定位置 eHomeState : INT; // 回零状态 END_STRUCT END_TYPE

有了这个结构体，就能在ST里建一个大小为24的全局数组，所有轴的数据集中管理，画面上显示、报警处理、逻辑判断都用同一份数据。

运动指令也要封装。欧姆龙自带MC_MoveAbsolute、MC_MoveVelocity这些功能块，在使用时建议再包一层自己的FB，把使能、状态、错误输出都统一处理。示意一下：

// 运动库功能块实例 stMoveAbs.Execute := bExecute; stMoveAbs.Axis := AxisRef; stMoveAbs.Position := fTargetPos; stMoveAbs.Velocity := fMoveVel; stMoveAbs.Acceleration := fMoveAcc; stMoveAbs.Deceleration := fMoveDec; stMoveAbs(); bDone := stMoveAbs.Done; bError := stMoveAbs.Error; wErrorID := stMoveAbs.ErrorID;

封装之后最大的好处是统一。伺服使能、回零、绝对定位、速度模式全部做成FB，工艺逻辑只关心轴号和目标位置，不用关心底层参数叫什么。后续如果换伺服品牌，也只需要改底层FB，工艺层基本不动。

这里提醒一句，封装功能的内部变量一定要命名规范。我当时吃过亏，有个FB里面用了短变量名a、b、c，两个月后再回去看，根本想不起来是干什么的。大项目里，变量的可读性比代码量重要得多。

2.2 多轴业务流程与状态机编写

状态机是我做大项目一定会用到的工具。24轴产线不是所有轴都在做同一个动作，而是分工位协作，一个轴没到位就会影响下一步。如果把流程放在普通继电器逻辑里，出了问题很难判断流程卡在哪，状态机直接看当前状态变量就行。

ST里写状态机最常用的是CASE语句，例如单个工位搬运轴的核心动作：

CASE byState OF IDLE: IF bStart THEN byState := HOME_CHECK; END_IF; HOME_CHECK: IF NOT AxisInfo[1].bHomed THEN bDoHome := TRUE; END_IF; IF AxisInfo[1].bHomed AND bReady THEN byState := MOVE_TO_SOURCE; END_IF; MOVE_TO_SOURCE: IF bExecuted THEN byState := WAIT_PICK; END_IF; WAIT_PICK: IF bPickDone THEN byState := MOVE_TO_TARGET; END_IF; MOVE_TO_TARGET: IF bTargetArrived THEN byState := WAIT_RELEASE; END_IF; WAIT_RELEASE: IF bReleaseDone THEN byState := MOVE_TO_WAIT; END_IF; MOVE_TO_WAIT: IF bWaitPosDone THEN byState := IDLE; END_IF; END_CASE;

这段逻辑看着简单，但非常稳定。每个步骤都有明确的进入条件和退出条件，故障时可以直接通过HMI看到状态停在哪一步，操作人员和售后都好处理。

24轴项目里，不要把整个流程都挤在同一个循环里。欧姆龙NJ支持多任务，我一般把EtherCAT运动控制放在周期任务中，ST工艺逻辑放在主周期任务里。关键路径上的工位单独建任务，各工位出了问题不会把整个系统拖垮。

另外提一下ST语言里的定时器，和梯形图不一样，ST里使用TON、TOF这类指令时需要先声明对应的功能块实例，比如stTonTimer，然后调用stTonTimer(In:=bCondition, PT:=T#500MS, Q=>bTimerDone, ET=>tElapsed)。新手容易直接写一个延时变量，结果发现根本不准确，就是因为没有实例化定时器功能块。

3. EtherCAT总线配置与现场调试要点

3.1 从站配置与轴参数映射

配置部分先强调一个观点：硬件选型做好只是第一步，真正决定现场能不能顺利跑起来的，是轴参数和伺服参数的一致性。

EtherCAT从站配好后，在Sysmac Studio里要对每台伺服做参数映射。如果是欧姆龙自家的伺服驱动器，基本一键配置就完成。如果是第三方伺服，就要仔细核对站号、同步模式、PDO映射。我的习惯是把轴号和站号绑死，比如轴1对应站1，轴2对应站2，以后看报警报文里的站号，就能直接找到对应的机械位置。

轴参数里面最容易搞错的是“电机每转的指令单位”和“电机每转的移动量”。举个例子，丝杠导程10mm，电机转一圈走10mm，希望程序里的位置单位是0.01mm，那电机每转对应的指令单位数就是1000。这个1000不是拍脑袋来的，它就是10mm除以0.01mm。

遇到国产伺服时会发现，不少驱动器的编码器默认分辨率是262144，也就是2的18次方，还有的是8388608。很多人一上来就想改编码器线数，这种思路其实不对。正确做法是修改电子齿轮比，或者通过总线映射里的命令单位比例来做匹配。核心原则很简单：PLC侧1个指令单位对应的位移，和伺服侧1个命令单位对应的位移，必须完全一致。换算的思路和传统脉冲轴一模一样，只是数字走的是网线而已。

3.2 伺服参数匹配的几个常见坑

调试时很多人喜欢一上来就调增益，但按我的经验，最该先看的是基础参数。先确认编码器分辨率、电子齿轮比、速度限制、转矩限制、正反限位，然后让轴空转，确认方向正确、回零方向正确，再谈增益。

常见坑之一：驱动器的内部电子齿轮和PLC轴参数的换算不一致，导致定位距离偏一半或者偏一倍。排查方法很简单，让轴走固定10000单位，用千分表打实际位移，确认换算关系对不对。

常见坑之二：机械反向间隙没处理。在电池产线里，很多丝杠结构换向时会有零点几毫米的间隙，如果不补偿，重复定位精度永远做不好。在NJ轴参数里有反向间隙补偿，填入实测间隙值就能明显改善。注意补偿值不能太大，补偿量过大会引起正反两方向衔接时的过冲。

常见坑之三：急停后没有合理的轴恢复流程。直接重新使能再发定位指令，很可能让轴以当前位置为目标猛冲，甚至撞机。急停恢复要分步骤，先清除运动指令状态，再读取当前位置，判断是否需要重新回零，最后逐轴使能并移动到安全位置。ST写这个状态机非常合适，梯形图会很痛苦。

3.3 伺服增益、滤波与前馈的实际调试逻辑

伺服调试不是玄学，它有清晰路径。伺服有三个环，最外层位置环、中间速度环、最内侧电流环。调试顺序永远是先内后外，先确认电流环和速度环稳定，再去动位置环。

位置环比例增益决定整体刚度，增益太低会跟不上指令，太高会在停止时来回震荡。速度环比例和积分决定了动态响应速度，响应太慢会让运动指令滞后太多，响应太快会引起啸叫。如果现场出现抖动，先别急着加减增益，用Sysmac Studio的Data Trace工具抓位置偏差曲线和速度曲线，判断问题到底是机械共振、负载惯性太大，还是增益不合适。

滤波和前馈是对增益的补充。机械共振明显时，可以启用驱动器或NJ轴参数里的滤波功能，把共振频率附近的增益压下来。前馈则是为了减小轨迹跟踪误差，尤其在走圆弧、高速定位时，前馈调好了可以让实际位置紧贴着目标位置走。

我记得有一台轴定位完成后总是有0.02mm左右的漂移，一开始怀疑编码器有问题，后来波形里看得很清楚，是机械间隙加增益偏低共同造成的。填了反向间隙补偿，再把速度环增益稍微提一点，波形立刻就不一样了。调试这事，光靠感觉不行，一定要会看波形。

4. 电池产线应用中的特殊处理与问题排查

4.1 高节拍场景下的轨迹规划与并行控制

电池产线普遍节拍紧，一款设备的整线节拍经常要求在30秒以内，关键工位甚至要求几秒内完成多段动作。24轴并不都在关键路径上，编程时要优先优化关键路径上的轴，不要把所有轴都搞成同步联动。

可以简单估算节拍余量。某个搬运动作行程300mm，峰值速度1.5m/s，加减速度按20m/s2算，加速段用时0.075秒，加速和减速总距离约112mm，剩余匀速距离188mm，匀速用时约0.125秒，整个单程动作大约0.275秒。要把这个动作塞进0.5秒的节拍里完全没问题。实际要算的还有夹爪闭合、视觉拍照、扫码确认这些时间，最好让这些辅助动作和运动路径重叠起来。

在程序架构上，MC功能块是异步执行的，发出“开始运动”后不会等运动完成，而是在Done输出位给出完成信号。所以编程框架最好是“一个状态块发起运动，另一个状态块等待完成”，两段分离。如果按传统梯形图的顺序思维把几十个轴的移动串成一条长链，节拍永远提不上去。

处理这种高节拍场景，并行性非常关键。只要机械允许，尽量让不同的轴同时动，而不是一台一台依次走。把工位拆分成独立任务后，在任务里并行发给各轴运动指令，再把完成信号汇总到工艺状态机，这样整线节拍才能压得下来。

4.2 报警、干扰与位置漂移的排查实录

现场调试中，各种报警和位置问题几乎不可能避免。我把这条产线遇到比较典型的问题整理成一张速查表，方便大家对照：

排查位置漂移，我习惯先用波形代替万用表。把目标位置、反馈位置、位置偏差同时记录，看是稳态偏差还是动态偏差。稳态恒定偏差优先查电子齿轮和机械原点，动态尖峰偏差优先查伺服增益和负载惯量比。很多现场一出现定位不准就要换编码器，实际上大部分时候不是硬件问题，是参数没对上。

还有一个经常被忽略的坑是网络线。EtherCAT网线不要自己手工压，直接买厂家或大厂的成品STP网线，抗干扰和端接质量都比手工网线可靠很多。现场如果发现偶发掉站或者从站分布时钟抖动，多半是线缆质量、布线路径和动力电缆靠太近的问题。

5. 大型PLC项目的工程化管理经验

5.1 版本管理与程序备份

24轴项目的程序量已经不小了，如果还是“改一次覆盖一次”的管理方式，后面绝对会有麻烦。我最开始也吃过亏，现场调试时改了几行逻辑，没有及时另存版本，第二天发现新问题想回退，结果找不到上一版文件，只能凭记忆重改。

后来养成了固定习惯：核心程序每次修改后，都另存一个带日期和功能描述的文件名，比如BatteryLine_V20250111_AddSpeedLimit。每天的调试晚上统一备份到项目共享盘，隔几天再打包一次完整工程，包括PLC程序、HMI画面、伺服配置文件。

这个动作看起来简单，但真的能救命。现场调试到后期，问题往往不是你眼前这几行代码，而是某一次改动引入的回归bug。有版本可以对比，直接找出两版差异，定位问题比从头查快得多。

5.2 程序交接与维护文档

大项目交付时，程序本身再漂亮，如果没人能维护，也算不上成功。我一般会做一份精简版交接文档，包含架构图、轴号与站号对照表、ST功能块清单、关键状态机说明、常见报警处理流程。

这张轴号和站号对照表尤其重要。24台伺服，如果现场没有一张准确的对照表，售后人员排查故障基本是靠猜。参数表要写清楚每台轴的指令单位、电子齿轮比、增益参考值，越细越好。

最后再多说一个实用习惯：程序里所有手写的工艺参数，尽量通过全局变量或结构体集中管理，不要散落在几十个FB里。这样其他工程师接手时，只需要看一个参数区，就能理解大部分动作逻辑。参数分散是大型AC项目里最隐蔽的维护障碍，我在调试后期吃够了这个苦，所以特别建议早做规划。