企业官网建设流程全解析

我最早被 EtherCAT 折腾到崩溃，不是因为它跑不起来，而是因为它"看起来太容易跑起来了"。网线一插、站号一配、伺服一点动，电机就转了；可真到 24 个轴一起上 CSP 运动时，一个 DC 时钟补偿没做对，整个产线都跟着抖。后来我把主站配置、从站对象字典、分布式时钟、FSoE 安全通信这些内容逐步整理成系列文章，才发现大多数坑其实不是设备质量问题，而是对协议层的理解还停在"插线就能用"的层面。

这个系列文章的核心就围绕两件事：一是 EtherCAT 主站和从站怎么配置、怎么用 STM32 做从站、CSP 模式下怎么带多轴；二是把安全功能考虑进去时，FSoE（FailSafe over EtherCAT）这套安全通信协议到底怎么落地。适合刚接触 EtherCAT、准备用 PLC 或单片机方案做从站的工程师，也适合正在部署多轴运动控制项目的自动化从业者。

1. 为什么我会把 EtherCAT 和 FSoE 写成一系列文章

1.1 运动控制项目里，EtherCAT 已经成了默认选项

EtherCAT 之所以能成为现在运动控制领域的主流总线，关键在于它处理报文的方式。主站发一个以太网帧出去，帧不是到每个从站都被完整复制一遍，而是像传送带一样从第一个从站穿到最后一个从站。每一个从站在报文经过自己时，只把"给我的数据"拿下来，再把"我的反馈数据"塞进去。这个机制叫 Processing on the Fly，中文常翻译成"飞读飞写"或"处理数据"。

这个设计带来的好处非常直接。第一个是效率高：一个帧里可以串几十个从站，不需要像传统工业以太网那样一主一从单独问答。第二个是同步精度高：配合分布式时钟（DC），可以让所有从站在同一个微秒甚至亚微秒级别的基准时刻采样指令和反馈。第三个是硬件成本低：很多从站控制器（ESC）芯片集成度很高，一颗芯片加个单片机就能做从站。

对比一下老的脉冲方案就更直观了。脉冲+方向控制一个伺服轴至少需要两根高速信号线，24 个轴就要拉几十根线，还要考虑长距离衰减、接线错误、共地干扰。用 EtherCAT 之后，一根标准网线把所有轴串起来，拓扑可以是菊花链、树形或者星形，现场布线的工作量减少一大截。这也是为什么我现在做多轴项目，第一反应就是问"要不要走 EtherCAT"，而不是"要不要加点脉冲轴卡"。

1.2 这个系列关注的不是"能跑"，而是"跑得稳"

网上关于 EtherCAT 的资料其实不少，但多数都是协议规范级别的介绍，讲清楚"帧结构是什么、状态机是什么"就结束了。真正到了项目现场，你会发现难点全在配置和排查上：为什么从站进不了 OP？为什么 PLC 扫描不到伺服？为什么多轴跑起来后同步误差越来越大？为什么急停信号还要单独拉一根硬线？

这个系列文章就是想把这些工程问题补齐。我整理了几条主线，不同背景的读者可以按自己的需求对号入座：

之所以把 FSoE 和 EtherCAT 放进同一个系列，是因为它们在实际项目里根本分不开。你可以在一个柜子里看到 H5U 做运动控制，旁边还有一个安全 PLC 通过同一根 EtherCAT 网线配置 FSoE 安全连接，急停信号不再需要单独拉几十根安全继电器线。理解和掌握这套组合，对自动化工程师来说是一门必修课。

2. EtherCAT 主站/从站配置：先别急着插网线

2.1 主站侧：汇川 H5U 的整个配置链路

汇川 H5U 是很多国内设备商选用的支持 EtherCAT 主站的中型 PLC，配合 SV660 系列伺服，在 24 轴以内的项目里很常见。它的配置思路和 TwinCAT、CODESYS 平台类似，但界面和操作路径是 AutoShop 那套，新手容易被细节卡住。

我一般按这个顺序走：先建工程，在设备树里添加 660 伺服，导入厂商提供的 ESI/XML 文件；然后设定从站站号、轴类型（实轴、虚拟轴等）；接着选择运行模式为 CSP，配置过程数据（PDO）映射；再设定总线周期和同步方式；最后编译下载，主站会生成 ENI 文件并写入运行环境。上电后主站按拓扑顺序扫描从站，把每一个从站从 Init 状态逐步拉到 Operational 状态。

这里最容易踩的第一个坑，是 ESI/XML 版本不对。不同固件版本的 SV660，对象字典里支持的 PDO 长度和功能可能有差异。如果你手里的 XML 文件和伺服实际固件不匹配，主站可能能扫到设备，但配置 CSP 模式时找不到对应的 PDO，甚至进入 Operational 之后位置环不工作。我的建议是：每次拿到新批次设备，先核对厂商提供的 XML 版本号，并且保留一个专门的配置模板工程。

第二个坑是"网线一插就让 24 个轴全上"。EtherCAT 虽然是串行链路，不存在多主站冲突的问题，但一旦后面的从站物理掉线，主站扫到一半就断了，报警信息会指向"拓扑中断"，而不会直接告诉你"第 17 台坏了"。所以新手阶段一定先接 2 台设备跑通流程，再逐步扩展到 24 台，这个习惯能帮你省大量时间。

2.2 从站侧：ESI/XML 与对象字典

很多做 PLC 的工程师对从站的理解是"伺服驱动器"这个硬件箱子，但做 EtherCAT 从站开发时，你必须知道箱子里面有一个 ESC（EtherCAT Slave Controller），它负责在硬件层面解析报文；真正执行控制算法的是应用控制器（比如 STM32、DSP 或者伺服芯片）。主站和从站应用层之间，靠对象字典（Object Dictionary）来通信。

对象字典沿用了 CANopen over EtherCAT（CoE）的体系。常见的对象包括：0x1000 设备类型、0x1600 系列接收过程数据映射（RPDO，主站发给从站）、0x1A00 系列发送过程数据映射（TPDO，从站反馈给主站）、0x6040 控制字、0x6041 状态字、0x6060 运行模式、0x6064 实际位置、0x607A 目标位置等。

从站的 ESI 文件（XML）本质上是告诉主站"我有哪些对象、哪些 PDO 可以映射、同步方式支持哪些"。主站读取 ESI 后，生成 ENI（EtherCAT Network Information）文件，也就是整条网络的"地图"。ENI 里包含了每个从站的地址、PDO 配置、同步参数、周期时间等运行时信息。所以你会看到：换了一个从站型号或者改了 PDO 映射后，必须重新生成 ENI 并下载到主站。如果漏了这一步，最典型的现象就是你在配置软件里加了轴，但实际跑起来报文还是旧的。

2.3 想让轴按位置跑起来：同步模式与 CSP 模式

在 CiA 402 标准里，伺服驱动有 Profile 位置、Profile 速度、CSP、CSV、CST 等多种运行模式。CSP 全称 Cyclic Synchronous Position，也就是周期同步位置模式。这种模式下，主站每个周期给从站发一个目标位置，从站内部的位置环、速度环、电流环自己闭环，主站只负责轨迹规划和周期同步。

CSP 模式下典型的 PDO 映射大概是这么一组：

这只是最精简的一组，实际项目中通常还会加入跟随误差、报警代码、数字量 IO 状态等。映射多了以后，周期数据帧变大，但以太网带宽通常不是瓶颈，真正的瓶颈是主站应用循环能不能稳定地在周期时间内完成轨迹计算和报文发送。

同步模式上有三种：Free Run 是从站自由运行，不推荐用于多轴；SM 同步是通过同步管理器的触发事件让从站锁存数据，精度比 Free Run 好；DC 同步则是所有从站通过分布式时钟对齐到参考时钟，由 SYNC0 中断决定执行时刻。做多轴 CSP，我基本都是先看从站支不支持 DC，再决定用不用。支持 DC 的系统里，24 个轴能真正在同一个时刻执行目标位置，这是"同步"二字的工程含义。

3. 基于 STM32 的 EtherCAT 从站：硬件、状态机与那条 objdef.c 警告

3.1 先从硬件说起：ESC 选型和 STM32 怎么配合

用 STM32 做 EtherCAT 从站，通常不是直接用 STM32 的网口去跑协议，而是用一个专门的 ESC 芯片负责报文解析，STM32 作为应用处理器。这个组合里，STM32 的优势是生态成熟、开发环境顺手、外设丰富，做电机控制或者 IO 控制都方便。

目前常见的方案有三种，我列个对比表供参考：

LAN9252 是我用得比较多的方案。STM32 作为 SPI 主机，LAN9252 作为 SPI 从机；STM32 通过 SPI 读写 LAN9252 的寄存器，LAN9252 检测到 EtherCAT 帧到达后通过中断脚通知 STM32。接线时别忘了把 ESC 的 EEPROM 烧好，里面存的就是从站的 ESI 信息。很多同学第一次做从站，插上网线后主站扫描不到设备，十有八九是 EEPROM 没烧录或者烧录了空配置文件。

另一个容易忽略的细节是同步中断。如果你想让从站真正参与 DC 同步，LAN9252 的 SYNC0/SYNC1 信号需要接到 STM32 的定时器或者外部中断脚，并且在中断服务程序里做输入输出锁存。没有这个硬件连接，软件里再怎么配 DC 也没用。

3.2 AL 状态机和对象字典的工作流程

从站开发绕不开 EtherCAT 状态机。主站会把从站从 Init 拉到 Pre-Operational，再拉到 Safe-Operational，最后拉到 Operational。每走一步，从站都需要完成对应的初始化动作：

• Init：只允许配置命令，邮箱通信尚未建立；
• Pre-Operational：邮箱和对象字典已可用，SDO（CoE 服务数据对象）可以读写；
• Safe-Operational：PDO 数据开始传输，但应用层不能输出，保证安全；
• Operational：应用层正常工作，伺服可以输出力矩，IO 可以真正驱动负载。

主站对从站的每一次状态请求都写在 ESC 的 AL Control 寄存器里，从站完成相应工作后更新 AL Status 寄存器。如果无法完成，就必须把错误原因写到 AL Status Code 寄存器里，主站根据这个代码报错。

一个非常朴素的从站主循环是这样：读 AL Control 寄存器，发现目标状态变了，就执行对应的转换动作，然后更新 AL Status。比如进入 Safe-Operational 之前，要检查同步管理器（SM）是否配置好；进入 Operational 之前，要确认过程数据里有没有有效数据。示意代码大概长这样：

void esc_process_al_state(void) { uint16_t req = lan9252_read_reg(LAN9252_AL_CONTROL); uint8_t target_state = req & 0x000F; if (target_state != current_state) { switch (target_state) { case STATE_PREOP: init_mailbox(); update_al_status(STATE_PREOP); break; case STATE_SAFEOP: config_sm2_sm3(); update_al_status(STATE_SAFEOP); break; case STATE_OP: enable_outputs(); update_al_status(STATE_OP); break; } } }

这只是一个示意，真正工程代码里还要考虑看门狗、同步中断、初始化失败回退等逻辑。但核心思想就是：从站不要无条件答应主站的状态请求，每一步都要确认自己真的准备好了，再写状态寄存器。

3.3 objdef.c 的 #767-d 警告：出处、根因与处理方式

如果你用 IAR 配合倍福系的 SSC（Slave Stack Code）工具生成 STM32 从站工程，几乎都会在 objdef.c 这类自动生成文件里看到一条警告：

warning: #767-D: conversion from pointer to small integer

网上不少人直接说"忽略它"，但我觉得还是要弄清楚它为什么会出现，否则真被它坑到的时候，你连从哪里排查都不知道。

这条警告的典型场景是在对象字典定义代码里，某些对象的数据访问方式用了指针，而模板代码又把指针取值后赋值给了一个比较窄的整型变量。在 32 位平台上，指针是 32 位宽，而像 UCHAR、USHORT 这类"small integer"可能只有 8 位或 16 位。编译器看到这种跨宽度转换，就会给出 #767-D 警告。IAR 的警告编号体系里，#767-D 属于"可诊断信息级别"里的警告，默认不中断编译，但会刷屏。

处理办法要看具体情况。如果是 SSC 自动生成的固定模板，且该处只是把一个固定对象地址强制转成整型偏移量，那么这条警告通常不影响功能，可以保留；如果你自己改了对象字典定义，把某个指针变量错误地赋给了小整型变量，那就必须改代码，不要指望编译器糊涂。

我的建议做法是：先双击编译输出里的警告跳到 objdef.c 890 行，看一下上下文是取值还是取地址。如果是类似UINT16 x = (UINT16)ptr;这种转换，就改成显式地写UINT16 x = (UINT16)(uintptr_t)ptr;，让编译器明白你的意图是"我就是要把指针当地址数据用"，而不是"我不小心丢了几位"。另一招是在 SSC 生成代码前调整对象字典的数据访问宽度，让生成的代码避免指针到小整型的转换。不到万不得已，不推荐在全局用 pragma 把 #767-D 屏蔽掉，因为同号警告也可能掩盖真正的指针截断问题。

4. 汇川 H5U 带 24 个 SV660 伺服：CSP 模式与总线周期规划

4.1 24 轴的报文能不能塞进一个周期

很多人一听到 24 轴 EtherCAT，第一反应是"带宽够吗？"。先做一个粗算，结论会非常明确。

假设每台 SV660 的 RPDO 是 12 字节，TPDO 也是 12 字节。为什么是 12 字节？比如控制字占 2 字节、目标位置占 4 字节、运行模式或附加状态占 6 字节，实际以 XML 为准。那么每轴输入输出合计 24 字节，24 台就是 576 字节有效过程数据。每个 EtherCAT 子报文自带头部和 WKC，大概有 12 字节左右的额外开销，24 台就是 288 字节。两者加起来约 864 字节，加上以太网帧头、EtherCAT 头和帧校验，大约 900 字节左右。常规以太网帧上限是 1518 字节，所以 24 轴这种配置，即使 500us 周期在带宽上也完全放得下。

当然，实际工程里 PDO 往往会加诊断信息、驱动器报警字、转矩值等，数据量会更大。如果每个轴配到 32 字节输入输出，24 轴就会超过一个标准以太网帧。这时候可以用 EtherCAT 的大帧模式，或者把从站分组、用多个周期子报文来处理。但通用结论是：常见 24 轴 CSP 配置，瓶颈不在报文长度，而在主站每周期内的处理抖动、从站是否支持 500us 周期、以及分布式时钟补偿算法有没有生效。

更重要的是，周期时间不是越短越好。H5U 在 AutoShop 里可以配置周期，有些工程为了追求响应速度直接设 250us，结果主站循环的任务调度跟不上，反而产生周期抖动。我处理 24 轴项目时，如果设备是贴装、转盘、包装这类应用，1ms 周期通常已经足够；只有做高速飞拍、高精度轨迹插补才考虑 500us。新手起步先用 1ms 跑通，再往下压周期，会稳妥得多。

4.2 CSP 模式下，24 个轴怎么做到"同时动"

刚才说的是"报文装得下"，那"所有轴同时动"靠什么？靠分布式时钟。EtherCAT 主站会把第一个支持 DC 的从站作为参考时钟，或者自己作为参考时钟，其余从站通过读取系统时间和接收同步帧来校准本地时钟。校准完成后，每个从站在同一个 SYNC0 信号触发下，把新收到的目标位置锁存进位置环。这样即使从站内部时钟有细微晶振偏差，主站也会周期性补偿，不会越跑越偏。

在 SV660 上做 CSP 模式，你需要确认几件事：第一，0x6060 运行模式被写入 8（CSP）；第二，控制字 0x6040 正确走使能和运行位序；第三，目标位置 0x607A 的数据单位与电子齿轮比匹配。24 个轴里如果有一台电子齿轮设错了，表现就是"这台轴跑到一半，其他轴走完了但它在慢慢走"，或者干脆报跟随误差过大。

DC 同步开启后，建议多观察主站诊断里的时钟补偿值。正常情况下补偿量应该稳定在纳秒到几百纳秒量级。如果你看到补偿值一直在几百微秒量级跳，说明从站固件版本、SYNC0 周期或者物理拓扑有问题。这时候不要急着调增益，先把同步基线修好。

另外，CSP 模式不是"主站不管位置环"，而是"主站只给位置目标，从站自己闭环"。所以伺服增益、惯量辨识、前馈补偿这些工作仍然要做。多轴项目里，我会先让每台轴单独走一个简单 CSP 波形，确认位置反馈没问题，再交给上位机做多轴联动。这样即使最后同步出问题，也能快速区分是通信问题还是驱动整定问题。

4.3 从"2 轴能跑"到"24 轴能跑"：扫描顺序和现场接线

EtherCAT 没有总线终端电阻的概念，标准做法是一根网线把从站串成菊花链。主站的扫描顺序就是物理链路顺序：第一个从站是 0x1000 位置地址，第二个是 0x1001，以此类推。这个顺序一旦物理接线变了，所有站号都会跟着变。

所以现场经验第一条：把每一段网线的两端都贴上物理标签，写清楚是"从站 N 到从站 N+1"，不要只靠颜色区分。24 台伺服的柜子，如果中间一根线掉了，主站诊断显示"拓扑中断"，工程师拿着网线测试仪从头找一遍是很崩溃的。

第二条经验：先 2 轴，再 8 轴，最后 24 轴。我并不是说非要机械地分三步，而是你在每个阶段都要完成一次完整的配置验证。2 轴跑通能证明 XML、ENI、CSP 模式都对了；8 轴跑通能提前暴露总线周期和 DC 同步的问题；24 轴再上，重点就是看长时间运行稳定性。一上来就接满 24 台，一旦报错，你根本分不清是第 3 台的 PDO 配错，还是第 17 台的网线松动。

第三条经验：不要只靠"伺服能不能转"来判断总线健康。我给项目组定的惯例是，把最后一个从站的状态字映射到 PLC 的一个全局变量，作为"总线末端健康位"。只要这个状态字能正常刷新到 1，说明整条链路至少是通的；如果它突然归零，哪怕中间某个轴还能动，也要优先查物理链路。

5. FSoE 安全通信：一条网线把急停也带走

5.1 FSoE 的本质："不安全"网络上的"安全"通信

FSoE 全称 FailSafe over EtherCAT，也叫 Safety over EtherCAT。它和普通 EtherCAT 报文跑在物理上同一根线上，但它本身是一套独立的功能安全协议，不要求 EtherCAT 网络硬件本身是"安全硬件"。

这里有个很核心的概念叫"黑通道"（Black Channel）。什么意思？就是你把 EtherCAT 网络当成一条普通的公路，公路上可能堵车、可能丢包裹、货物可能被震坏，甚至可能被故意调包。安全通信要做的是在包裹层面加保护：防拆封条、唯一编号、签收回执、超时报警。只要运输环节出了任何问题，收件方都能立刻察觉并大喊"不对劲"。

FSoE 的帧上就有这么几层保护机制：连接 ID 用来区分这是哪一条安全连接，防止数据错发到别的从站；序号（Sequence Number）递增，防止丢帧、重放；一个 4 字节的 CRC 覆盖安全数据，能检测出绝大多数的比特翻转；看门狗时间用来约束"多久没收到合法帧就算通信故障"；还有一套专门的连接状态机，一旦异常就跳回安全状态。

用一句话总结：FSoE 不保证网络永远不出错，但保证一旦出错，安全功能一定知道，并且能及时把机器带入安全状态。

5.2 FSoE 连接如何配置：STO、安全地址和看门狗

实际项目里，FSoE 主站通常是安全 PLC 或支持安全功能的主站模块，FSoE 从站则是带安全认证的伺服驱动器或安全 IO。SV660 这类产品如果要走安全通信，需要选用支持 FSoE 的型号，并且明确安全功能范围，比如 STO（安全转矩关断）、SS1（安全停止 1）、SLS（安全限速）等。

配置 FSoE 连接时，常见参数大致有这些：

• FSoE 连接 ID：每条安全连接唯一，不能重复；
• 源地址和目的地址：也就是安全通信双方的地址，这个地址和 EtherCAT 的站号不是一回事；
• 看门狗时间：多久没收到对方的安全帧就报通信超时；
• 安全数据内容：下发的"安全使能"、反馈的"安全状态"等。

以 STO 为例，安全主站通过 FSoE 周期下发一个安全状态字，驱动器只有在收到"允许运行"且满足安全校验时，才允许功率级输出。急停按钮按下或者安全门打开，安全主站立刻给所有安全从站下发 STO 请求，驱动器不管 PLC 里的目标位置是不是还在更新，都会在硬件层面切断力矩输出。

这个环节里最容易翻车的几个地方：第一，连接 ID 配重复了或者安全地址填错，启动时直接报"wrong connection ID"，一查一个准；第二，看门狗时间设得太短，比如 10ms，而总线周期是 1ms，只要偶发丢一帧就触发了安全停，现场会觉得设备"莫名其妙急停"；第三，以为配置了 FSoE 就能自己写安全逻辑，这是绝对不行的事情。功能安全涉及的 SIL/PL 等级评估、安全验证、诊断覆盖率，必须交给经过认证的整机和系统方案，普通工程师能做的是在合规框架里做应用配置和调试。FSoE 的价值是给你一条合规、可靠的安全通信链路，而不是让你绕开安全设计。

5.3 为什么在 EtherCAT 合集里要把 FSoE 单独立项

很多做 24 轴项目的新手，一开始脑子里只有"让伺服转起来"，完全没考虑安全通信。等到客户现场验收，突然说"你这设备急停怎么还是靠硬接线？需要 STO 功能"，这时候再回头改结构，会发现多轴安全回路的硬接线量非常夸张：每台驱动器一个 STO 输入，几十根线要重新走，故障点也会成倍增加。

EtherCAT + FSoE 的设计思路，是把运动控制和功能安全放在同一根网线上。急停、安全门、光栅状态进入安全 PLC，安全 PLC 通过 FSoE 告诉每一台安全型驱动器"继续跑"还是"停"，驱动器内部完成安全转矩切断。这样既减少了硬接线，也让每个轴的安全状态可以被主站实时诊断。这个系列文章把 FSoE 和 EtherCAT 放在一起讲，就是想强调一件事：真正成熟的多轴系统，通信协议和安全协议是一个整体工程，不能拆开来看。

6. 我实际调试中反复用到的几个习惯

6.1 先看 AL Status Code，再猜原因

从站进不了 Operational 的时候，我不建议一上来就翻伺服驱动器手册，也不建议盲目改 PLC 配置。第一件事是看主站诊断里从站的 AL Status Code。EtherCAT 从站的 0x0134 寄存器会给出一个十六进制错误代码，主站软件通常会把它展示出来。不同的代码对应不同的失败阶段：有的代表邮箱通信还没准备好，有的代表 PDO 长度和同步管理器设置不一致，有的代表从站应用层主动拒绝状态请求。

记录几个常见的代码值，你会发现排查方向非常清晰。比如 PDO 长度对不上，那就去检查 XML 里映射的字节数和主站配置的 RPDO/TPDO 长度；如果是应用层拒绝，那大概率是从站自己初始化失败，比如伺服参数还在复位中。比起用万用表量信号、拿着示波器看波形，先读状态码通常能直接省掉一半时间。

我调试时还有一个分诊习惯：先看网络状态，再看应用状态。EtherCAT 主站把从站跑到 OP，只能说明"报文层面正常"；伺服实际能不能动，还要看控制字、使能位、模式字这些应用层数据有没有正确下发。这两个问题经常混在一起，但排查手段完全不一样。

6.2 配置改动后，主站必须重新生成并下载 ENI

这个坑我在多个项目里都遇到过，自己也犯过。在 AutoShop 里改了 PDO 映射、加了轴、换了从站型号，然后只做了编译下载，但主站运行配置文件还是老的 ENI。现象是：配置软件里看到的网络和你实际跑起来的报文完全不是一回事，伺服半天不动，主站也不报错。

所以我现在给自己定了一条死规矩：凡是动了 ESI/XML、从站顺序、PDO 映射、周期时间这些底层配置，第一步是重新生成 ENI，第二步是重新下载主站运行配置，第三步是断电重启主站和部分从站，最后再检查从站是否全部进入 OP。不要图省事"在线更新"一下就完事，尤其是 24 台伺服的大工程，旧配置残留造成的间歇性故障非常难查。

6.3 最后留一个我自己的调试顺序：从 2 轴到 24 轴

这个合集里写了非常多细节，但我最想让你记住的其实是这个最朴素的调试顺序：

1. 2 轴 CSP 跑通，确认位置反馈和控制字正常；
2. 增加到 8 轴，检查总线周期抖动和 DC 补偿值；
3. 固定物理线序，给每一段网线做标签；
4. 24 轴全跑，观察最后一个从站的健康状态字；
5. 做 FSoE STO 安全测试，确认急停时所有轴真正切断力矩。

说句实在话，EtherCAT 和 FSoE 看着是两套协议，但在项目层面是一套工程。把主站配置、从站对象字典、CSP 同步、安全连接这几件事串起来理解，再遇到 24 台伺服这种项目，心里会稳很多。这个合集后面我会继续把 STM32 从站的代码逐段拆开讲，也会把 FSoE 安全参数在 SV660 上的实际整定过程写出来，等于是把这条链路每一颗螺丝都拧给你看。