基于STM32的多轴步进电机协同控制与自定义动作设计

1. 先把需求拆开看：三轴协同到底难在哪

做基于STM32的多个步进电机协同控制和灵活自定义动作，几乎所有人在动手之前都会想得很简单：几个定时器分别输出脉冲，每个轴给一个目标步数，走完就停。真上手才发现，单个电机转起来只是入门，多个步进电机协同控制的核心难题从来不是"让电机转"，而是"让几个电机在时间上对齐、在空间上到位，并且随时能改动作序列而不用重新烧固件"。

我前后在两个小设备上做过类似的东西：一个是三轴直角坐标的小平台，一个是双轴旋转加一轴升降的机构。第一版固件把动作逻辑直接写死在main的switch里，改一个动作就要改代码、编译、下载、重新对零位，一次调试半小时。第二版我把动作序列抽成文本脚本，通过串口下发，同样的改动只要十几秒。这个转变带来的收益，比把脉冲频率从5kHz提到20kHz大得多。所以这篇内容会围绕三件事展开：多轴之间怎么协同（时间和空间上的同步）、脉冲和加减速怎么算得准、动作怎么做到"灵活自定义"。

适合谁看：手上有一块STM32开发板、几个步进驱动器和电机，想做多轴运动的入门者；已经能单轴跑起来，但一联动就丢步、跑偏、动作改起来很痛苦的中级开发者；以及想把设备动作做成"可配置"而不是"每台定制烧固件"的工程人员。下面所有代码和参数都基于我实际调过的方案，你直接抄过去改引脚和参数就能跑，涉及取舍的地方我会把"为什么这么选"讲清楚。

2. 整体方案选型：三条路线和它们的代价

2.1 主控加驱动器的组合怎么定

步进电机的控制本质是"发脉冲+给方向"，主控只负责时序，电流和细分交给驱动器。所以方案选型其实分两层：主控层和驱动层。

主控层我基本只考虑STM32F103或STM32F407这两个档次。原因很实在：F103主频72MHz，定时器资源够用（4个通用定时器+2个高级定时器），做三到四轴的中断式脉冲发生完全撑得住；如果要跑五轴以上、或者要加LCD界面和文件系统，就上F407，168MHz加上更多的定时器，余量足。低于这个档次的芯片不是不能做，但一旦你要在中断里做点别的事（比如读编码器、跑串口协议），时序就开始抖，脉冲一抖，电机就开始叫。

驱动层看电流和细分需求。小电机（42型，1.5A以下）用常见的A4988类模块就够，便宜、体积小，缺点是细分高了之后力矩下降明显、发热大；中大电机（57型，2A到4A）用带光耦隔离的细分驱动模块更稳，这类模块一般支持拨码设置细分和电流，抗干扰也好得多。这里有个反直觉的点：细分不是越高越好。很多人一上来就把细分拨到32甚至64，觉得"更平滑"，结果发现高速时力矩掉得厉害，甚至直接堵转。原因是细分越高，驱动器对每个脉冲的响应越依赖控制器的脉冲频率，高细分下要达到同样的转速，脉冲频率要成倍提高，主控的中断开销和驱动器的响应能力都吃紧。

我个人的默认选择是"通用版"：F103加三个隔离驱动模块。它在成本、稳定性和开发难度上最平衡，而且隔离驱动模块的输入是光耦，主控那边就算地线处理得糙一点，也不容易把芯片打坏。

2.2 多轴协同的两种同步思路

"协同"这个词容易被理解得太玄。实际工程里它只有两种实现方式，选错了后面全是坑。

第一种是软件同步：所有轴的脉冲都在同一个定时器中断里发，中断一次，每个轴根据自己当前的状态决定这一步走不走。优点是绝对同步——同一个中断周期内，所有轴的时间基准完全一致，插补精度高；缺点是对中断执行时间要求严，轴多了以后中断里代码一长，高频脉冲就跟不上。

第二种是硬件独立、软件对齐：每个轴用各自的定时器产生脉冲，主控只在启动时把它们的计数值对齐，运行中各自跑各自的加减速曲线。优点是中断负担分散，能跑到很高的频率；缺点是对齐只能做在启动瞬间，如果某个轴的曲线参数算错了，跑一段就会积累偏差。

我的做法是混合：三轴以内用软件同步，超过三轴用独立定时器加统一起始时刻。三轴以内中断里那点计算量（每轴几个判断和两次寄存器写入）在72MHz下大概2到3微秒，脉冲频率跑到15kHz完全没问题。

2.3 为什么动作要"脚本化"而不是写死在代码里

这是整个项目里最值得花时间的地方。设备类项目有个特点：机械结构定型之后，动作流程还会被反复调整——某个工位要多停200毫秒，某个轴的回程速度要降一点，某个循环要改成条件触发。如果动作写在C代码里，每次调整都是一次完整的编译下载流程，而且现场调试的人往往不是写代码的人。

脚本化的本质是把"动作描述"和"动作执行"分离。执行引擎（解析器、状态机、脉冲发生器）是稳定的，几个月不动一次；动作描述是易变的，随时可改。这个分离做得好，设备交付之后现场人员自己就能改流程。

代价也要说清楚：脚本化会引入解析开销和错误处理复杂度，你得考虑指令写错了怎么办、执行到一半断电了怎么办、循环嵌套太深会不会栈溢出。这些在写死代码的方案里根本不存在。所以我的建议是：动作数量少于5个、且基本不会变的项目，别搞脚本，直接写死更快；动作超过5个、或者需要现场调整的，脚本化的收益会远远盖过它的复杂度。

3. 硬件层的关键计算与接线细节

3.1 脉冲当量：所有参数计算的起点

动手写代码之前，必须先算清楚一个数：一个脉冲对应多少实际位移。这个数叫脉冲当量，后面所有的速度、加速度、行程计算都从它推出来。

算法很直接：

脉冲当量 = 传动机构的单位行程 / (电机一圈的脉冲数) 电机一圈的脉冲数 = 360 / 步距角 × 细分数

举个我实际用过的例子：42型电机，步距角1.8度，驱动器细分设为16，丝杠导程5毫米（电机转一圈，滑块走5毫米）。

一圈脉冲数 = 360 / 1.8 × 16 = 200 × 16 = 3200 脉冲 脉冲当量 = 5mm / 3200 = 0.0015625mm，约等于1.56微米

有了这个数，速度和脉冲频率的换算就是一句话的事：

脉冲频率(Hz) = 目标速度(mm/s) / 脉冲当量(mm)

想让滑块走10mm/s，脉冲频率 = 10 / 0.0015625 = 6400Hz。反过来，如果你把脉冲频率开到20kHz，滑块速度就是31.25mm/s。

这里有个必须提醒的坑：算完之后一定要回头检查"最高速度需要多高的脉冲频率"。很多人选了高细分加小导程，结果发现要达到设备要求的速度，脉冲频率得跑到80kHz以上，STM32的中断式方案直接崩掉。我踩过这个坑——三轴平台要求快移50mm/s，用16细分加5mm导程，算下来是32kHz，单轴能跑，三轴联动就丢步了。最后把细分降到8、导程换成10mm，同样的速度只需要8kHz，问题解决。选型阶段就把这个数算出来，比调试阶段再返工省事一百倍。

3.2 驱动器电流和供电的取值方法

驱动器的电流拨码不是按电机铭牌上的额定电流直接拨。步进电机的额定电流指的是"每相电流的有效值"，而驱动器拨码通常标的是峰值电流或有效值，各家标法不完全一致。稳妥的做法是从电机额定电流的70%到80%起调，跑起来之后摸电机外壳温度，温热（50到60度）是可以接受的，烫手就往下调。

供电电压的影响更大。步进电机的输出力矩随转速上升而下降，供电电压越高，高速段的力矩保持得越好。24V和36V在低速时差别不大，但到了800rpm以上差别非常明显。不过电压也不能乱加，受驱动器上限和电机绝缘等级限制，常见的42、57型电机用24V到36V是比较安全的区间。

有个细节容易忽略：驱动器的电源输入端必须并一个大容量电解电容，一般1000微法以上，靠近驱动器放置。步进电机是感性负载，换向瞬间会产生反向电动势，没有电容吸收，电压会瞬间抬高，轻则驱动器保护重启，重则炸管。我第一次做的时候没加，结果一给高速指令，主控就复位——不是电源功率不够，是电压尖峰把稳压芯片打懵了。

3.3 接地、布线和抗干扰的实际处理

步进系统的干扰主要来自两处：电机相线上的高频开关噪声，以及脉冲信号线上的串扰。这两类问题的处理方式不一样。

电机相线（驱动器到电机那四根）是主要噪声源，原则是越短越好、越粗越好、远离信号线，最好双绞。信号线这边，脉冲和方向线如果长度超过20厘米，我就用双绞加屏蔽，屏蔽层单端接地（接主控侧），不要两端都接，否则形成地环路反而更糟。

关于地线，有个说法在网上流传很广："主控和驱动器必须共地"。这话只对了一半。如果你用的是光耦隔离驱动器，主控地和驱动器地本来就应该是隔离的，强行共地反而破坏了隔离。如果用的是非隔离驱动器（比如普通的A4988模块），那确实必须共地，否则脉冲信号没有参考电平，电机行为会非常诡异——有时候能动，有时候完全不动，这种"时好时坏"的故障最难查。

我在一个双轴项目上遇到过一个典型现象：单轴运行完全正常，双轴同时运行时偶尔丢步，而且丢步的轴不固定。查了两天，最后发现是两个驱动器的地线走的是同一条细线，双轴同时换向时电流叠加，地线上产生了毫伏级的波动，把脉冲信号的判决电平顶掉了。改成每个驱动器单独一根地线回到电源端子，问题消失。这类问题没有理论可推，只能靠布线上留余量。

3.4 限位、原点和急停的硬件兜底

软件写得再好，也必须有硬件兜底。三个东西是必须的：行程限位开关、原点开关、急停按钮。

限位开关的作用不是"让程序知道到头了"，而是"在程序失控时切断脉冲"。所以我的做法是双保险：软件里轮询限位状态，触发就立即停止该轴运动；同时把限位开关的常闭触点串在驱动器的使能回路上，硬件直接断使能。这样即使程序跑飞，机械也不会撞坏。

原点开关（回零用）和限位开关是两回事，别混用。回零流程一般是：先以较高速度朝原点方向走，碰到原点开关后停止，再以很低的速度（比如脉冲频率500Hz）反向退出开关，然后再慢速靠近，直到开关信号变化的那一刻记为绝对零点。这个"两次逼近"的流程是为了消除开关动作点的重复性误差，普通机械开关的重复精度可能有好几毫米，慢速逼近能压到0.05毫米以内。

急停按钮接法上，我建议接常闭触点加外部上拉，主控检测到高电平就认为急停按下。常闭的好处是断线也能被检测到——线断了，信号同样变成高电平，程序一样停，这叫失效安全。

4. 软件骨架：时基、状态机、动作队列

4.1 脉冲发生器：中断翻转还是PWM加DMA

这是软件架构里第一个要做的决定，影响后面所有代码的写法。

中断翻转法：用一个定时器产生周期性中断，中断里翻转GPIO电平，同时更新下一次的重载值（也就是下一个半周期的时间）。优点是逻辑直观、加减速容易做（每次中断改重载值就行）、任意轴数都能加；缺点是中断频率等于脉冲频率的两倍，脉冲频率上到20kHz就是每秒4万次中断，CPU基本被吃满。

PWM加DMA法：用定时器的PWM输出直接产生脉冲，用DMA把一组预先算好的周期值搬进定时器的自动重载寄存器，硬件自动改变频率。优点是CPU几乎不参与，能跑到几百kHz；缺点是实现复杂，加减速必须提前算好整条曲线存进内存，中途改参数麻烦，而且每个轴要占用一个定时器通道加一个DMA流，资源有限。

三轴以内的项目我毫无犹豫选中断翻转法。代码量小、调试直观、随时能改。中断里的代码必须极简：只做"翻转引脚、取下一个重载值、写寄存器"这几件事，任何浮点运算、任何判断分支多的逻辑都挪到中断外面预先算好。这是硬性纪律，违反了就会出现"单轴好好的，加轴就丢步"的经典问题。

定时器的配置思路：把定时器时钟分频到1MHz，也就是每个计数代表1微秒（72MHz主频，预分频设为71）。这样重载值的单位就是微秒，算起来最直观。

// 定时器基础配置思路（以常见的通用定时器为例） // 时钟72MHz，预分频71 -> 计数频率1MHz，1个计数=1us void pulse_timer_init(void) { // 预分频 = 72 - 1 TIMx->PSC = 71; // 初始重载值先给个低速值 TIMx->ARR = 999; // 使能更新中断 TIMx->DIER |= TIM_DIER_UIE; // 使能定时器 TIMx->CR1 |= TIM_CR1_CEN; }

重载值和脉冲频率的关系要推一遍，别记结论：

半周期时间(us) = 1000000 / (2 × 脉冲频率) 重载值 = 半周期时间 - 1

举例：脉冲频率1000Hz，半周期500微秒，重载值499。脉冲频率10000Hz，半周期50微秒，重载值49。可见高频时重载值很小，中断服务程序的执行时间必须远小于这个值。10kHz时只有50微秒的余量，中断里做20条指令（大概1微秒）没问题，做200条（10微秒）就危险了。

4.2 加减速曲线：为什么必须做，怎么做才不抖

步进电机不能瞬间从静止跳到高速，否则要么丢步（电机跟不上），要么产生冲击（机械抖）。所以必须有加减速过程。这里说清楚三种曲线的取舍。

梯形曲线是最常用的：加速段匀加速、匀速段、减速段匀减速。实现简单、参数直观（只需加速度和最大速度两个参数），缺点是加速度在起点和终点是突变的，机械上会有一点冲击感，低速时能听出来。对于大多数定位机构，梯形曲线完全够用。

S形曲线在加减速的两端做了加速度的平滑过渡，机械冲击小很多，适合负载较大或者对振动敏感的场景。代价是参数计算复杂，实现代码量大概是梯形的三倍。

指数曲线介于两者之间，起步快、末端柔和，在需要快速响应的场合不错，但参数不好调。

我实际项目的默认选择是梯形曲线，只有当机械出现明显抖动或者负载惯性大（比如带了个大转盘）时才换S形。不要一上来就上S形，那是在给自己找麻烦。

梯形曲线的参数计算过程必须写清楚，因为有一步很容易算错。已知起始频率f0、目标频率f1、加速度a（单位：Hz每秒），求加速段需要多少个脉冲：

加速脉冲数 N = (f1² - f0²) / (2 × a)

推导过程：加速度a的定义是频率对时间的变化率，即 a = df/dt。位移（脉冲数）是频率对时间的积分。从f0加速到f1，用v-t图理解，横轴是时间，纵轴是频率，面积就是脉冲总数。梯形面积 = (f0 + f1) / 2 × t，而 t = (f1 - f0) / a，代入整理就得上面的公式。

具体算一次：f0 = 500Hz，f1 = 5000Hz，要求0.3秒加速到位。 先算时间验证：t = (5000-500)/a = 0.3，a = 15000 Hz/s。 再算脉冲数：N = (5000² - 500²)/(2×15000) = (25000000 - 250000)/30000 = 24750000/30000 = 825脉冲。

825个脉冲、0.3秒，平均频率2750Hz，跟(500+5000)/2=2750对得上，说明算对了。

然后是关键的实现技巧。在中断里实时算"下一个重载值"如果用浮点，会带来两个问题：浮点运算耗时长（F103没有FPU，一次浮点除法几十个周期）、中断时间不确定。我的做法是预计算加速段的重载值表：

// 加速段重载值表，运行中只查表不计算 #define ACC_STEPS_MAX 1024 static uint16_t acc_table[ACC_STEPS_MAX]; static uint16_t acc_steps; // 实际使用的表长度 void build_acc_table(uint32_t f0, uint32_t f1, uint16_t steps) { // 均匀插值：第i步的频率 = f0 + (f1-f0)*i/steps // 严格等加速度应按时长积分，这里用等频差近似，步数多时误差可忽略 for (uint16_t i = 0; i < steps; i++) { uint32_t f = f0 + (uint32_t)((uint64_t)(f1 - f0) * i / steps); uint32_t reload = 1000000UL / (2UL * f); acc_table[i] = (uint16_t)(reload > 1 ? reload - 1 : 1); } acc_steps = steps; }

用等频差近似替代严格的等时间间隔，会引入一点偏差，但825步的情况下偏差在千分之几，肉眼和机械都感受不到。这一步用近似换来的收益是中断里只需要一次数组访问，非常值。

注意：重载值表要判断下界。当脉冲频率超过500kHz时，重载值会算成0，写进寄存器会导致定时器行为异常。加一个reload > 1的保护是必要的，哪怕你觉得永远不会跑到那个频率。

减速段可以直接复用加速段的表，倒着索引就行。这样一张表管两段，RAM占用减半。825步每步2字节，才1.6KB，F103的20KB RAM完全放得下。

4.3 多轴插补：让几个轴"同时到"

两个轴同时启动、同时停止，但要走不同的距离，这就是最简单的协同问题。比如X轴走1000步、Y轴走500步，要求同时到达。做法是：谁需要的脉冲多，谁就是主轴，主轴按自己的速度曲线走；从轴每走一步都要判断"该不该走"，判据用Bresenham算法。

// 两轴直线插补的简化实现（在定时器中断里调用） typedef struct { int32_t remain; // 剩余步数 int32_t total; // 总步数 int32_t error; // Bresenham误差累计 uint8_t dir; // 方向 } axis_t; void bresenham_step(axis_t *master, axis_t *slave) { // 主轴无条件走一步 master->remain--; // 从轴按误差累计判断 slave->error += slave->total; if (slave->error >= master->total) { slave->error -= master->total; slave->remain--; // 这里输出从轴的一个脉冲 } }

这个算法的精妙之处在于它用纯整数运算实现了"从轴的步数按比例均匀分布到主轴的每一步之间"，误差永远不会累积超过一步。跑1000步的X轴和500步的Y轴，Y轴会在X轴的第2、4、6……步各走一步，最终精确同时到达。

三轴以上的做法是：算出所有轴里步数最多的那个当主轴，其余轴各自跑一个Bresenham，互不干扰。代码结构上就是给每个从轴维护一个误差累加器。

这里有个容易忽略的细节：加减速曲线只作用在主轴的时间间隔上。从轴不受自己的速度曲线控制，它的节奏完全由主轴脉冲驱动——主轴快它就快，主轴慢它就慢。所以从轴不需要单独算加减速，只需要跟着主轴的节拍判断走不走。这个设计让代码简化了很多，也避免了"两个轴各自做加减速导致不同步"的问题。

如果是圆弧或者更复杂的轨迹，Bresenham就不够用了，得上DDA（数字微分分析）或者预先离散化轨迹点。但我的经验是，绝大部分设备项目里的"协同"就是直线插补加同时启停，圆弧插补的需求十有八九是过度设计。先问清楚"这个圆弧精度要求多少、能不能用多段直线逼近"，能省掉大量工作。

4.4 状态机：每个轴都有自己的小世界

每个轴在同一时刻只可能处于一个状态，状态之间按固定规则迁移。把状态机做清楚，后面加功能才不会乱。

这里的关键判断是"该不该开始减速"。做法很简单：每走一步，检查remain <= decel_steps，如果是，就切到减速状态。减速步数在运动开始前就算好，不需要运行时算。

至于加速段还没走完就要减速的情况（距离太短，加速都来不及），这个必须处理。我的做法是：运动开始前先判断total < acc_steps + decel_steps，如果是，说明距离不够，直接降低目标速度，重新计算加速段步数，让加速和减速刚好接上。这个判断不做的话，短距离运动会走到一半突然从加速跳到减速，脉冲频率断层，电机就会"咯噔"一下。

5. 自定义动作指令集的落地方式

5.1 指令格式怎么定才够用又不出错

指令格式设计的原则是：人好读、机器好解析、错了好定位。我最终定下来的是接近自然语言的行式文本，每行一条指令，参数用空格分隔，#开头的行是注释。

这套指令设计上有几个刻意的取舍。第一，距离用毫米而不是脉冲数——现场改动作的人关心的是"走30毫米"，不是"走19200个脉冲"，换算交给执行引擎。第二，MOVE是相对运动，绝对定位靠先SETPOS再MOVE，这样脚本可以整体平移重复使用。第三，循环用LOOP/ENDLOOP而不是跳转标签，因为跳转标签容易写出死循环，一旦跑飞了设备就停不下来。

MOVEALL的参数固定三个轴，速度取三轴中的最大速度作为主轴的参考。之所以不做成变长参数，是为了解析简单——固定参数个数的解析器代码量只有变长版本的三分之一，出错处理也简单得多。

5.2 解析器：先编译成指令表，再执行

解析器有两种写法：边读边执行，和先编译成指令表再执行。一定要选后者，原因很实际：如果边读边执行，脚本里有个语法错误，可能前十条指令已经执行完了，设备停在一个奇怪的位置，接下来你连"现在在哪"都不知道。先编译成指令表，任何一条指令语法错误都可以在执行前就报出来，一条动作都不动。

// 编译后的指令结构 typedef enum { ACT_MOVE, ACT_MOVEALL, ACT_WAIT, ACT_HOME, ACT_SETPOS, ACT_SPEED, ACT_LOOP, ACT_ENDLOOP, ACT_OUT } act_type_t; typedef struct { act_type_t type; int16_t axis; float p1, p2, p3; // 通用参数槽 int16_t loop_count; // 循环用 int16_t loop_begin; // 循环体起始索引 } action_t; #define ACTION_MAX 256 static action_t actions[ACTION_MAX]; static uint16_t action_num;

解析的过程是逐行扫描：跳过空行和注释，按空格切分token，第一个token匹配指令关键字，剩下的按参数个数解析成数字。遇到LOOP时记录当前位置作为循环体起点，遇到ENDLOOP时把对应LOOP指令的loop_begin字段填上，形成一个"双向链接"。执行时用一个索引指针在指令表上走，遇到LOOP就把循环计数压栈、指针跳到循环体起点，计数到零就跳到ENDLOOP之后。

// 简化的执行引擎主循环（放在主程序，不要放中断里） void engine_tick(void) { if (wait_until > tick_now) return; // 还在延时中 if (motion_busy()) return; // 轴还在运动 if (pc >= action_num) { engine_stop(); return; } action_t *a = &actions[pc]; switch (a->type) { case ACT_MOVE: axis_move_rel(a->axis, a->p1); pc++; break; case ACT_WAIT: wait_until = tick_now + (uint32_t)a->p1; pc++; break; case ACT_LOOP: loop_stack_push(&a->loop_begin, a->loop_count); pc++; break; case ACT_ENDLOOP: if (loop_stack_decrement()) { pc = loop_stack_current_begin(); } else { pc++; } break; // 其余指令类似 } }

注意motion_busy()这个判断——它是"协同"在软件层的体现。所有轴都停下来之前，执行引擎不会往下走。所以MOVEALL之后即使某个轴先到，也要等最慢的轴走完才继续，这样动作序列的时序是确定的。

5.3 参数标定：毫米和脉冲之间的那座桥

脚本里写的是毫米，硬件要的是脉冲，中间的换算系数就是脉冲当量。这个数理论上能算，实际上必须标定——丝杠有误差、联轴器有回差、机械安装有偏差，理论值和实际值往往差1%到3%。

标定方法很简单：让轴从一点走到另一点，用卡尺量实际距离，然后反算系数。

新系数 = 旧系数 × (指令距离 / 实际距离)

比如让X轴走100毫米，实测走了98.6毫米，旧系数是1600脉冲/毫米，那么新系数 = 1600 × (100/98.6) = 1622.7脉冲/毫米。再做一次验证，通常两次就收敛了。

这个系数存在Flash里，掉电不丢。存的时候要做校验——我习惯加一个简单的求和校验和魔数，上电时校验不通过就用默认值并报警。为什么？因为Flash写入过程中断电，可能写进去一堆0xFF或者半截数据，没有校验的话，上电后系数变成一个荒谬的值，电机一启动就撞限位，非常危险。

5.4 断电位置管理和"上电后在哪"

步进电机是开环的，断电后位置信息就丢了。所以上电后的第一件事必须是回零，这一点没有捷径。但如果设备加了绝对值编码器，情况就不一样了——不过这已经超出步进电机的范畴，成本也高得多。

我的做法是：上电后强制要求回零才能执行动作。状态机里加一个标志位，没回零就不接受运动指令，返回一个错误码。同时把"上一次断电时的位置"存进Flash（每次运动结束后更新，不要每步都写，Flash有寿命），上电时显示给用户参考，但不作为执行依据。这个信息在调试的时候很有用——"上次停在X=45.2的位置，这次怎么从0开始了"，能帮人快速判断是不是哪里出了问题。

还有一个细节：断电瞬间的减速。如果设备在高速运动中断电，电机是没有减速过程的，靠惯性滑停，位置会偏出去一段。这个偏出量跟速度成正比，在断电前的最后一步很难预测。所以对于需要断电记忆位置的场合，稳妥的做法是每次定位完成后再写Flash，把"运动中断电"当作异常处理，下次上电必须以回零为准。

6. 现场排查：那些文档里不会写的问题

6.1 丢步、异响、抖动怎么定位

这三个症状经常一起出现，但原因完全不同，排查顺序要从"最容易排除的"开始。

先听声音。均匀的"嗡嗡"声是正常的；听到周期性的"咯"一下，通常是丢步；听到尖锐的高频啸叫，多半是共振或者电流过大；听到"沙沙"的摩擦声，检查机械装配。

再用排除法缩小范围：

• 把速度降到极低（比如100Hz脉冲），如果仍然丢步，那就不是速度问题，是接线或电流问题。
• 单轴跑正常、联动就丢步，优先怀疑中断执行时间超了，或者地线处理有问题。
• 空载正常、带载丢步，调电流、降加速度。
• 走短距离正常、走长距离累计偏差，检查脉冲当量标定，或者查有没有脉冲被漏掉（用示波器看脉冲波形是否完整）。

有个特别隐蔽的坑：加减速参数和实际负载不匹配。加速度设得太大，电机在加速段的力矩需求超过了它能提供的，就会丢步，而且丢步发生在加速段的某几个脉冲上，看起来像是"越跑越偏"。判断方法是听加速段的声音——如果加速时电机声音明显变粗、变闷，就是加速度太大了。我做的一个升降轴就吃过这个亏，0.3秒加速到目标速度看着很合理，实际带了个2公斤的负载，加速时丢了几十步，最后把加速时间拉到0.6秒才稳。

6.2 多轴联动"跑偏"的排查思路

联动跑偏指的是两个轴同时启动、同时停止，但走出来的轨迹不是直线。这个问题比丢步难查，因为单轴测试完全正常。

第一个要查的是起始时刻是否真的对齐。软件同步的方案里，如果中断里第一个轴处理完后有延迟才处理第二个轴，长期下来就积累了相位差。解决方法是：在中断里先把所有轴的电平变化一次性算好、写进端口寄存器，而不是一个一个轴地"翻转引脚—更新重载值"。用端口寄存器的位操作，一次写多个引脚，能做到真正的同时。

第二个要查的是主从轴的选择是否正确。谁是主轴取决于谁需要的步数多。如果算错了，从轴的Bresenham误差累计会溢出，轨迹就会偏。可以用一个计数变量做验证：跑完之后检查每个轴的实际步数是否等于目标步数，不等就说明插补逻辑有问题。

第三个要查的是机械回差。两个轴各走一段再折返，折返点之后的轨迹可能偏出去零点几毫米，这是丝杠回差，软件补不了，只能靠机械结构或者单向逼近策略解决。测试方法很简单：让轴从正反两个方向靠近同一个位置，用百分表量差值，超过设计要求就得改机械。

6.3 串口下发脚本的那些坑

脚本通过串口下发是最方便的，但我在这一步踩过的坑最多。

第一坑：收到半截脚本就开始执行。串口通信是多字节的，主控可能在脚本还没收完的时候就开始解析。解决方法是加帧头和帧尾，或者约定一个结束符（比如单独一行END），收全了再解析。

第二坑：缓冲区溢出。一段复杂的动作脚本可能有几千字节，而串口接收缓冲区只开了256字节，超出部分就丢了，解析出来的脚本是残缺的，执行起来行为完全不可预测。我的做法是接收缓冲区开1KB，并且每次接收前先清空，同时解析代码里严格检查行长，超过行缓冲区长度的直接报错。

第三坑：没有回显确认。下发脚本之后，主控必须回一个"已接收N条指令，校验通过/失败"的应答。没有这个应答，发的人根本不知道脚本到底进去没有。我遇到过一次，脚本发完设备没动，查了半天以为是解析问题，最后发现是串口线松了，根本没发出去。

提示：脚本存储在Flash时，建议做一个整体的校验和（比如把所有字节累加取低16位），上电时先验校验和再执行，能挡掉绝大部分存储损坏的情况。

6.4 常见问题速查表

6.5 几个真正省时间的操作习惯

最后一个部分是纯经验，跟技术关系不大，但能省掉大量调试时间。

第一，永远保留一个"手动低速"模式。设备一旦装到机器上，自动模式出问题时，能手动一格一格地动，是最快的定位手段。这个功能实现成本极低（就是几个按键加单步脉冲），但价值极高。

第二，在关键位置打日志。不是printf那种，而是在RAM里开一个环形缓冲区，记录最近几百条事件（指令序号、时间戳、触发的事件）。出问题的时候通过串口把这段日志读出来，能还原出故障前的完整时序。我做的一个双轴项目，客户反馈"偶尔会多走一段"，就是因为有这个日志才发现是脚本里有一个循环的计数边界处理错了，跑满100次之后会多执行一次。

第三，加速度参数留20%余量。调好的参数，在样机上跑得动，到了实际负载上可能就不够。所以最终交付的参数，我会在原基础上把加速度降20%、把速度降10%，代价是节拍慢一点，收益是不用在客户现场返工。

说到底，基于STM32做多轴步进协同，硬件和代码都只是载体，真正决定成败的是两件事：一是在动手之前把脉冲当量、最高脉冲频率、加速步数这几个数算清楚，二是把动作和执行引擎分开，让改动作不再等于改代码。我自己的体会是，第一版永远会写得很难看，但只要把状态机、插补、脚本这三块的结构留对，第二版重构起来会非常顺，后面加轴、加指令、加界面都只是往里填东西，不用推倒重来。