SOEM控制汇川SV660N实战：PDO映射与CiA402状态机详解-平芜编程栈

1. 从站上电之后：为什么PDO映射是绕不过去的第一道坎

汇川SV660N这台伺服驱动器在EtherCAT圈子里算是比较常见的型号，支持CoE（CANopen over EtherCAT）协议，走的是标准CiA402状态机。很多人第一次用SOEM（Simple Open EtherCAT Master）去控制它的时候，往往会卡在一个很尴尬的位置：SDO能读能写，参数看得见摸得着，但一旦想让它真正转起来，就发现不知道该往哪个地址写控制字，也不知道位置反馈从哪读。

这个问题的根源就在PDO映射上。

EtherCAT的通信模型里，PDO（Process Data Object）负责周期性实时数据交换，SDO（Service Data Object）负责非周期性参数配置。伺服驱动器的控制字、状态字、目标位置、实际位置、目标速度、实际速度这些需要每个周期都刷新的数据，全部走PDO通道。而PDO通道的数据具体是什么内容、放在报文的哪个位置，靠的就是PDO映射来定义。

SOEM本身是一个比较轻量的主站实现，它不会自动帮你解析从站的PDO配置。你需要自己通过SDO把PDO映射参数写进去，然后在SOEM的IOmap里找到对应的偏移量，才能正确地读写数据。这个过程如果没搞明白，就会出现“程序跑起来了但电机不动”或者“电机动了但读回来的位置是乱码”这类问题。

SV660N的PDO映射有几个特点需要特别注意。它默认的PDO配置不一定符合你的应用需求，比如默认可能只映射了控制字和状态字，没有映射目标位置和实际位置。另外，SV660N支持PDO动态映射，也就是说你可以在Pre-OP状态下通过SDO修改映射内容，然后让从站重新进入Safe-OP和OP状态来生效。这个流程如果顺序搞错了，从站会直接报错，进不了OP状态。

我实际调试的时候踩过的一个坑是：先写了PDO映射参数，但没有把从站切回Pre-OP再切回来，结果映射没生效，主站读到的还是旧的PDO数据。后来查了SV660N的手册才发现，PDO映射参数的修改必须在Pre-OP状态下进行，修改完成后需要重新走一遍状态转换流程。

所以这篇文章我会从PDO映射的配置开始讲，然后深入到CiA402状态机的控制逻辑，最后给出一个完整的SOEM控制SV660N的实战流程。不管你是刚接触EtherCAT的新手，还是已经用过其他主站但想转到SOEM的开发者，应该都能从中找到有用的东西。

2. SV660N的PDO映射配置：从SDO写入到IOmap偏移量定位

2.1 先搞清楚SV660N的默认PDO分配

SV660N出厂时的PDO配置一般是这样的：RxPDO（主站发给从站）默认映射了控制字（0x6040）和目标速度（0x60FF），TxPDO（从站发给主站）默认映射了状态字（0x6041）和实际速度（0x606C）。这个配置对于简单的速度控制模式够用，但如果你要做位置控制，就需要把目标位置（0x607A）和实际位置（0x6064）也加进去。

在SOEM里，你可以通过ec_SDOread函数读取从站的PDO分配参数来确认当前配置。SV660N的RxPDO分配参数索引是0x1C12，TxPDO分配参数索引是0x1C13。这两个索引下面有子索引，每个子索引对应一个PDO映射对象。比如0x1C12:01通常指向0x1600，0x1C13:01通常指向0x1A00。

读取的代码大概长这样：

uint8_t rxpdo_assign[2]; int size = sizeof(rxpdo_assign); ec_SDOread(slave_pos, 0x1C12, 0x01, FALSE, &size, rxpdo_assign, EC_TIMEOUTRXM);

读回来的是两个字节，低字节是映射对象索引的低8位，高字节是高8位。比如读回来0x00 0x16，就表示映射对象是0x1600。

然后再去读0x1600下面的子索引，看看具体映射了哪些对象：

uint32_t mapping_entry; size = sizeof(mapping_entry); ec_SDOread(slave_pos, 0x1600, 0x01, FALSE, &size, &mapping_entry, EC_TIMEOUTRXM);

每个映射条目是4个字节，格式是：索引（2字节）+ 子索引（1字节）+ 位长度（1字节）。比如0x60400010表示控制字0x6040，子索引0，长度16位。

2.2 修改PDO映射的完整流程

如果你需要修改PDO映射，比如要把目标位置0x607A加到RxPDO里，把实际位置0x6064加到TxPDO里，流程是这样的：

第一步，确保从站在Pre-OP状态。如果从站已经在OP状态，先通过ec_slave[slave_pos].state = EC_STATE_PRE_OP然后调用ec_writestate切回来。

第二步，修改映射对象的内容。比如要把0x1600:01改成控制字，0x1600:02改成目标位置，需要先写0x1600:00为0（表示映射条目数为0，相当于清空），然后逐个写入映射条目，最后再把0x1600:00写成实际的条目数。

// 清空映射 uint8_t zero = 0; ec_SDOwrite(slave_pos, 0x1600, 0x00, FALSE, sizeof(zero), &zero, EC_TIMEOUTRXM); // 写入控制字映射 uint32_t entry1 = 0x60400010; // 控制字，16位 ec_SDOwrite(slave_pos, 0x1600, 0x01, FALSE, sizeof(entry1), &entry1, EC_TIMEOUTRXM); // 写入目标位置映射 uint32_t entry2 = 0x607A0020; // 目标位置，32位 ec_SDOwrite(slave_pos, 0x1600, 0x02, FALSE, sizeof(entry2), &entry2, EC_TIMEOUTRXM); // 设置映射条目数 uint8_t count = 2; ec_SDOwrite(slave_pos, 0x1600, 0x00, FALSE, sizeof(count), &count, EC_TIMEOUTRXM);

第三步，确认0x1C12:01指向的是0x1600。如果不是，需要修改0x1C12:01的值。

第四步，让从站重新进入Safe-OP再进入OP状态。这时候SOEM会重新配置FMMU和SM通道，PDO映射才会真正生效。

注意：修改PDO映射之前一定要确认从站支持动态映射。SV660N是支持的，但有些低端从站可能不支持，修改后会报错。另外，映射的总位数不能超过SM通道的容量，SV660N的RxPDO和TxPDO各支持最多10个映射条目，总位数一般不超过32字节。

2.3 在SOEM的IOmap里找到正确的偏移量

PDO映射配置好之后，SOEM在进入OP状态时会把所有从站的PDO数据拼接到一块连续的内存里，这就是IOmap。每个从站的数据在IOmap里有一个偏移量，分别记录在ec_slave[].Ibytes、ec_slave[].Obytes、ec_slave[].Ioffset、ec_slave[].Ooffset这几个字段里。

Ibytes和Obytes表示输入和输出的字节数，Ioffset和Ooffset表示在IOmap里的起始偏移。比如你的SV660N映射了控制字（2字节）+目标位置（4字节）=6字节的输出，实际位置（4字节）+状态字（2字节）=6字节的输入，那么Obytes就是6，Ibytes也是6。

在代码里访问的时候，输出数据用ec_slave[slave_pos].outputs指针，输入数据用ec_slave[slave_pos].inputs指针。比如要写控制字：

uint16_t control_word = 0x0006; memcpy(ec_slave[slave_pos].outputs, &control_word, 2);

要读状态字：

uint16_t status_word; memcpy(&status_word, ec_slave[slave_pos].inputs, 2);

这里有一个很容易搞错的地方：IOmap里的数据排列顺序是按照PDO映射条目的顺序来的，不是按照索引大小排序的。比如你先映射了控制字再映射目标位置，那输出数据的前2字节是控制字，后4字节是目标位置。如果你搞反了顺序，写进去的数据就全乱了。

我建议在代码里定义好结构体来对应PDO映射，这样不容易出错：

typedef struct { uint16_t control_word; int32_t target_position; } rxpdo_t; typedef struct { int32_t actual_position; uint16_t status_word; } txpdo_t;

然后用memcpy或者直接指针转换来访问。不过要注意字节对齐问题，有些平台对非对齐访问会报错，最好用memcpy。

3. CiA402状态机：SV660N使能、运行与故障复位的控制逻辑

3.1 CiA402状态机的核心状态和转换条件

CiA402定义了一套标准的状态机，SV660N完全遵循这个规范。状态机的核心状态包括：

Not Ready to Switch On：从站上电后的初始状态，此时驱动器还没准备好。
Switch On Disabled：驱动器初始化完成，但输出级还没使能。
Ready to Switch On：驱动器准备好使能，等待主站发送命令。
Switched On：输出级已经使能，但电机还没通电。
Operation Enabled：电机通电，可以接受运动指令。
Fault：驱动器检测到故障，需要复位。

状态之间的转换靠控制字（0x6040）的位组合来触发。控制字的关键位定义如下：

位	名称	说明
0	Switch On	使能输出级
1	Enable Voltage	使能电压
2	Quick Stop	快速停止（低电平有效）
3	Enable Operation	使能运行
7	Fault Reset	故障复位（上升沿有效）

从Switch On Disabled到Operation Enabled的典型转换序列是：

写控制字0x0006（Enable Voltage + Quick Stop），进入Ready to Switch On。
写控制字0x0007（Enable Voltage + Quick Stop + Switch On），进入Switched On。
写控制字0x000F（Enable Voltage + Quick Stop + Switch On + Enable Operation），进入Operation Enabled。

每一步都需要等待状态字（0x6041）确认状态转换完成。状态字的关键位：

位	名称	说明
0	Ready to Switch On	准备好使能
1	Switched On	输出级已使能
2	Operation Enabled	运行已使能
3	Fault	故障标志
6	Switch On Disabled	使能已禁止

3.2 在SOEM里实现状态机切换的代码逻辑

在SOEM里实现状态机切换，核心就是周期性地发送控制字并读取状态字，根据状态字判断当前处于哪个状态，然后决定下一步写什么控制字。

我一般会写一个状态机处理函数，每个周期调用一次：

typedef enum { STATE_NOT_READY, STATE_SWITCH_ON_DISABLED, STATE_READY_TO_SWITCH_ON, STATE_SWITCHED_ON, STATE_OPERATION_ENABLED, STATE_FAULT } servo_state_t; servo_state_t get_servo_state(uint16_t status_word) { if (status_word & 0x0008) return STATE_FAULT; if ((status_word & 0x004F) == 0x0040) return STATE_SWITCH_ON_DISABLED; if ((status_word & 0x006F) == 0x0021) return STATE_READY_TO_SWITCH_ON; if ((status_word & 0x006F) == 0x0023) return STATE_SWITCHED_ON; if ((status_word & 0x006F) == 0x0027) return STATE_OPERATION_ENABLED; return STATE_NOT_READY; }

然后在主循环里根据当前状态决定控制字：

void servo_state_machine(uint16_t *control_word, uint16_t status_word) { servo_state_t state = get_servo_state(status_word); switch (state) { case STATE_SWITCH_ON_DISABLED: *control_word = 0x0006; break; case STATE_READY_TO_SWITCH_ON: *control_word = 0x0007; break; case STATE_SWITCHED_ON: *control_word = 0x000F; break; case STATE_OPERATION_ENABLED: // 保持使能，可以在这里更新目标位置 *control_word = 0x000F; break; case STATE_FAULT: *control_word = 0x0080; // 故障复位 break; default: *control_word = 0x0000; break; } }

这个逻辑看起来简单，但实际调试的时候有几个细节很容易出问题。

第一个细节是故障复位的处理。控制字的bit 7是上升沿触发复位，也就是说你需要先写0x0080，然后写0x0000，再写正常的控制字。如果一直保持0x0080，复位不会重复触发。我一般会在检测到Fault状态时，先写0x0080持续一个周期，然后下一个周期写0x0006重新走使能流程。

第二个细节是状态转换的等待时间。从Switch On Disabled到Ready to Switch On可能需要几十毫秒，从Switched On到Operation Enabled也需要时间。如果你在每个周期都切换控制字，可能会导致状态机混乱。我的做法是加一个状态转换的超时计数器，如果超过一定时间还没转换成功，就报错或者重试。

第三个细节是Quick Stop的处理。控制字的bit 2是低电平有效的快速停止，正常情况下应该保持为1。如果你不小心写成了0，电机会紧急停止。我在代码里一般用宏定义来组合控制字，避免手动算错：

#define CW_SWITCH_ON_DISABLED 0x0006 #define CW_READY_TO_SWITCH_ON 0x0007 #define CW_SWITCHED_ON 0x000F #define CW_OPERATION_ENABLED 0x000F #define CW_FAULT_RESET 0x0080

3.3 位置模式和速度模式的切换

SV660N支持多种运行模式，通过0x6060（Modes of Operation）来设置。常用的有：

模式1：位置模式（Profile Position Mode）
模式3：速度模式（Profile Velocity Mode）
模式6：回零模式（Homing Mode）
模式8：周期同步位置模式（CSP）
模式9：周期同步速度模式（CSV）

在SOEM里切换模式，需要通过SDO写0x6060。比如要切到CSP模式：

int8_t mode = 8; ec_SDOwrite(slave_pos, 0x6060, 0x00, FALSE, sizeof(mode), &mode, EC_TIMEOUTRXM);

切换模式之前，最好先把伺服切回Switch On Disabled状态，设置完模式后再重新使能。如果在Operation Enabled状态下直接切换模式，有些固件版本可能会报错。

CSP模式是最常用的模式，主站每个周期发送目标位置，从站内部做插补。这种模式对主站的实时性要求比较高，SOEM的周期时间一般设置在1ms到4ms之间。如果周期时间太长，电机会出现抖动或者响应迟钝。

在CSP模式下，目标位置通过0x607A写入，实际位置通过0x6064读取。需要注意的是，目标位置的单位是脉冲数，具体一圈多少脉冲取决于电机的编码器分辨率和电子齿轮比。SV660N默认的编码器分辨率是23位，也就是一圈8388608个脉冲。如果你设置了电子齿轮比，实际脉冲数会变化。

4. 用ethercatdbg验证PDO映射和状态机：调试阶段最省时间的做法

4.1 ethercatdbg的基本用法

SOEM自带了一个叫ethercatdbg的命令行工具，在Linux下编译SOEM之后会在build/test/linux/ethercatdbg目录下生成。这个工具可以直接跟从站交互，读写SDO、查看PDO映射、监控状态机，调试阶段非常有用。

最基本的用法是指定网卡名称：

sudo ./ethercatdbg eth0

进入交互界面后，常用的命令有：

slaves：列出所有从站，显示从站数量和基本信息。
sdo <slave> <index> <subindex>：读取SDO。
sdow <slave> <index> <subindex> <value>：写入SDO。
pdo <slave>：查看从站的PDO映射。
state <slave> <state>：设置从站状态。
monitor <slave>：监控从站的状态字和实际位置。

比如要查看第一个从站的PDO映射：

pdo 1

输出会显示RxPDO和TxPDO的映射条目，包括索引、子索引和位长度。这个信息可以用来跟你的代码里的映射配置做对比，确认是否一致。

4.2 用ethercatdbg排查PDO映射不生效的问题

如果你发现代码里配置了PDO映射，但实际读写的数据不对，可以用ethercatdbg来逐步排查。

第一步，用pdo 1确认从站当前的PDO映射内容。如果显示的还是默认映射，说明你的SDO写入没有生效。

第二步，用sdo 1 0x1C12 0x01确认PDO分配参数是否正确。如果读回来的值不是0x1600，说明分配参数没写对。

第三步，用sdo 1 0x1600 0x00确认映射条目数。如果读回来是0，说明映射被清空了但没重新写入。

第四步，检查从站状态。用state 1查看当前状态，确认是否在OP状态。如果从站一直在Safe-OP或者Pre-OP，PDO映射不会生效。

我遇到过一次比较诡异的情况：PDO映射参数都写对了，从站也在OP状态，但读回来的实际位置一直是0。后来用ethercatdbg的monitor 1命令监控状态字，发现状态字一直是0x0000，说明从站根本没在刷新PDO数据。最后查出来是SM通道的配置有问题，SOEM在进入OP状态时没有正确配置SM2和SM3的看门狗时间。解决办法是在ec_config_map之前手动设置ec_slave[1].SM[2].SMflags和ec_slave[1].SM[3].SMflags，把看门狗使能位打开。

4.3 状态机调试中的常见问题

用ethercatdbg调试状态机的时候，最常遇到的问题是状态字一直不变，或者状态转换到一半就卡住了。

如果状态字一直是0x0000，说明从站没有正确响应控制字。可能的原因包括：PDO映射里没有包含控制字和状态字、SM通道配置错误、从站固件版本不兼容。

如果状态字能变但转换不到Operation Enabled，一般是控制字的序列不对。可以用ethercatdbg手动写控制字来测试：

sdow 1 0x6040 0x00 0x0006

等几毫秒，再读状态字：

sdo 1 0x6041 0x00

如果状态字变成了0x0021，说明进入了Ready to Switch On。然后继续写0x0007、0x000F，逐步确认每一步的状态转换。

这种手动测试的方式虽然慢，但能帮你快速定位问题出在哪个环节。等确认了正确的控制字序列，再回到代码里实现自动状态机。

提示：ethercatdbg的SDO读写是通过邮箱通道走的，不依赖PDO映射。所以即使PDO配置有问题，SDO依然能正常工作。这也是为什么很多人发现SDO能读能写但PDO数据不对的原因。

5. 从站进不了OP状态：排查思路和几个容易忽略的配置项

5.1 先确认从站是否支持OP状态

不是所有EtherCAT从站都支持OP状态。有些简单的IO从站只支持到Safe-OP，不支持OP。SV660N是支持OP的，但如果你在代码里看到从站一直停在Safe-OP，首先要确认从站的ESI文件里是否声明了OP状态支持。

用ethercatdbg的slaves命令可以看到每个从站的状态。如果从站显示的是SAFEOP而不是OP，说明从站没有进入OP状态。

5.2 SM通道和FMMU配置检查

从站进入OP状态需要SM通道和FMMU正确配置。SOEM在ec_config_map函数里会自动配置这些，但有时候自动配置的结果不符合从站的要求。

SV660N的SM2通道用于RxPDO（主站输出），SM3通道用于TxPDO（主站输入）。这两个通道的配置参数包括：

起始地址
数据长度
控制字节
状态字节
看门狗时间

如果看门狗时间设置得太短，从站可能会因为看门狗超时而拒绝进入OP状态。我一般会把看门狗时间设置成周期时间的3到5倍。比如周期是1ms，看门狗时间设成5ms。

在SOEM里可以通过修改ec_slave[].SM[].SMflags来调整看门狗使能位。具体做法是在ec_config_map之前：

ec_slave[slave_pos].SM[2].SMflags |= 0x0100; // 使能看门狗 ec_slave[slave_pos].SM[3].SMflags |= 0x0100;

5.3 分布式时钟和传播延迟的影响

SV660N支持分布式时钟（DC），如果主站也启用了DC，从站会要求主站测量传播延迟并补偿。SOEM提供了ec_configdc函数来配置DC，但传播延迟的测量需要额外的步骤。

如果DC配置不正确，从站可能会报错或者进不了OP状态。我一般会在调试阶段先关闭DC，确认PDO和状态机都能正常工作之后，再开启DC。

关闭DC的方法是在ec_config_init之后不调用ec_configdc，或者在调用之前把ec_slave[].hasdc设为0。

传播延迟的测量可以用ethercatdbg的dc命令来查看。如果延迟值异常大（比如超过1000ns），说明网络拓扑或者线缆有问题，需要检查网线质量和连接器接触。

5.4 从站固件版本和ESI文件的匹配

SV660N有不同的固件版本，不同版本的PDO映射能力和状态机行为可能有差异。如果你用的ESI文件跟从站固件不匹配，可能会出现PDO映射写入失败或者状态机转换异常。

确认固件版本的方法是通过SDO读取0x1018（Identity Object）的子索引2（Revision Number）。然后跟汇川官网提供的ESI文件做对比，确保版本一致。

如果版本不匹配，最直接的解决办法是找汇川要对应版本的ESI文件，或者升级从站固件。不过升级固件有风险，建议在测试台上先验证。

6. 一个完整的SOEM控制SV660N的代码框架

6.1 初始化和配置流程

下面是一个简化的代码框架，展示了从初始化到使能电机的完整流程。这个框架基于SOEM的Redundancy示例修改而来，去掉了冗余相关的部分，专注于单从站控制。

#include "soem/ethercat.h" #define SLAVE_POS 1 #define CYCLE_TIME_NS 1000000 // 1ms typedef struct { uint16_t control_word; int32_t target_position; } rxpdo_t; typedef struct { int32_t actual_position; uint16_t status_word; } txpdo_t; int main(int argc, char *argv[]) { if (argc < 2) return 1; // 初始化SOEM if (ec_init(argv[1]) <= 0) return 1; // 扫描从站 if (ec_config_init(FALSE) <= 0) return 1; // 配置PDO映射 // 先切到Pre-OP ec_slave[SLAVE_POS].state = EC_STATE_PRE_OP; ec_writestate(SLAVE_POS); ec_statecheck(SLAVE_POS, EC_STATE_PRE_OP, EC_TIMEOUTSTATE); // 写入PDO映射（参考第2节的代码） // ... // 配置IOmap ec_config_map(&IOmap); // 配置DC（可选） // ec_configdc(); // 切到OP状态 ec_slave[SLAVE_POS].state = EC_STATE_OPERATIONAL; ec_writestate(SLAVE_POS); ec_statecheck(SLAVE_POS, EC_STATE_OPERATIONAL, EC_TIMEOUTSTATE); // 主循环 rxpdo_t *rxpdo = (rxpdo_t *)ec_slave[SLAVE_POS].outputs; txpdo_t *txpdo = (txpdo_t *)ec_slave[SLAVE_POS].inputs; uint16_t control_word = 0x0000; int32_t target_pos = 0; while (1) { // 接收过程数据 ec_receive_processdata(EC_TIMEOUTRET); // 状态机处理 servo_state_machine(&control_word, txpdo->status_word); // 更新输出数据 rxpdo->control_word = control_word; rxpdo->target_position = target_pos; // 发送过程数据 ec_send_processdata(); // 等待下一个周期 osal_usleep(1000); } ec_close(); return 0; }

6.2 周期任务的时间管理

SOEM本身不提供实时调度，它依赖操作系统的定时器。在Linux下，osal_usleep的精度取决于内核的HZ配置，一般只能达到毫秒级。如果你需要更精确的周期控制，可以考虑用clock_nanosleep配合CLOCK_MONOTONIC。

我实测下来，在普通的Linux桌面系统上，1ms的周期会有几十微秒的抖动。如果对实时性要求高，建议用Xenomai或者PREEMPT_RT补丁。不过对于大多数伺服应用来说，1ms周期加上几十微秒的抖动已经够用了。

另外，ec_receive_processdata和ec_send_processdata的调用顺序也很重要。正确的顺序是先接收再发送，这样能保证每个周期都能拿到最新的从站数据。如果顺序反了，你读到的可能是上一个周期的数据。

6.3 位置数据的单位换算

SV660N的位置数据单位是脉冲数。如果你想让电机转一圈，需要写入的脉冲数等于编码器分辨率乘以电子齿轮比。默认情况下，电子齿轮比是1:1，编码器分辨率是23位，也就是8388608。

假设你要让电机以1000rpm的速度运行，在CSP模式下，每个周期需要增加的位置量是：

每圈脉冲数 = 8388608 每秒圈数 = 1000 / 60 = 16.67 每秒脉冲数 = 8388608 * 16.67 = 139810133 每毫秒脉冲数 = 139810133 / 1000 = 139810

所以每个1ms周期，目标位置增加139810个脉冲。这个数值需要在代码里根据实际周期时间做调整。

如果觉得脉冲数太大不好计算，可以通过0x6091（Gear Ratio）来调整电子齿轮比。比如设置成1:100，那么每圈脉冲数就变成83886，计算起来方便很多。

7. 调试过程中积累的几个实用经验

7.1 先让电机转起来再优化

很多人一开始就追求完美的PDO映射和最优的周期时间，结果卡在配置阶段好几天。我的建议是先用最简配置让电机转起来：只映射控制字、状态字、目标速度和实际速度，用速度模式测试。确认电机能正常使能、能调速之后，再逐步加入位置相关的PDO映射，切换到CSP模式。

这种渐进式的调试方法能帮你快速定位问题。如果一开始就上完整的PDO映射，出了问题很难判断是映射配置错了还是状态机逻辑错了。

7.2 保存一份能工作的配置

一旦调通了一个配置，马上把PDO映射参数、SM通道配置、状态机控制字序列这些关键信息保存下来。可以用ethercatdbg的sdo命令把所有相关参数读出来，存到一个文本文件里。下次再调试同型号的驱动器，直接照着这份配置来，能省很多时间。

我自己的做法是给每个型号的驱动器建一个配置档案，记录以下内容：

参数	索引	值	说明
RxPDO分配	0x1C12:01	0x1600	默认映射对象
TxPDO分配	0x1C13:01	0x1A00	默认映射对象
RxPDO映射1	0x1600:01	0x60400010	控制字
RxPDO映射2	0x1600:02	0x607A0020	目标位置
TxPDO映射1	0x1A00:01	0x60640020	实际位置
TxPDO映射2	0x1A00:02	0x60410010	状态字
运行模式	0x6060:00	8	CSP模式

7.3 注意从站的看门狗行为

SV660N的看门狗默认是使能的，如果主站超过一定时间没有发送过程数据，从站会触发看门狗超时，进入Fault状态。这个时间一般在SM通道的配置里设置，默认可能是100ms左右。

在调试阶段，如果你在断点处停留太久，从站可能会因为看门狗超时而报错。解决办法是在调试时先把看门狗时间设长一点，或者暂时关闭看门狗。不过在生产环境里一定要使能看门狗，否则通信中断时电机会失控。

7.4 用Wireshark抓包分析通信问题

如果ethercatdbg也查不出问题，可以用Wireshark抓EtherCAT报文来分析。需要安装Wireshark的EtherCAT解析插件，然后在主站的网卡上抓包。

抓包能看到每个周期的PDO数据内容、SDO读写请求和响应、状态机的转换过程。如果发现某个周期的PDO数据不对，可以对照代码里的IOmap偏移量来排查。

不过EtherCAT的报文比较密集，1ms周期下每秒有1000个报文，抓包文件会很大。建议只抓几秒钟的数据，然后用过滤器只看特定从站的报文。

7.5 不同主站平台的移植注意事项

SOEM支持Linux、Windows和RTOS等多种平台。如果你从Linux移植到其他平台，需要注意以下几点：

字节序：EtherCAT协议是大端序，SOEM内部会做转换。但如果你直接操作IOmap里的数据，要注意主机的字节序。
定时器精度：不同平台的定时器精度不同，Windows下osal_usleep的精度可能只有15ms左右，需要改用高精度定时器。
网卡驱动：SOEM在Linux下用raw socket，需要root权限。在Windows下需要安装WinPcap或者Npcap。

我在RK3568上移植过SOEM，用的是Linux系统，整体比较顺利。需要注意的是RK3568的网卡驱动可能不支持某些高级特性，比如硬件时间戳。如果要用DC，需要确认网卡是否支持。

7.6 关于状态机的三段式和一段式写法

网上关于状态机的写法有一段式、两段式、三段式几种。在SOEM控制伺服的应用里，我推荐用一段式：把状态判断和输出更新放在同一个函数里，每个周期调用一次。这种写法简单直接，不容易出错。

三段式状态机（状态寄存器、次态逻辑、输出逻辑分开）更适合FPGA或者Verilog的场景，在C语言里用三段式反而会增加代码复杂度，而且SOEM的周期任务本身就是顺序执行的，没有必要做那么复杂的分离。

如果你之前写过Verilog的状态机，转到C语言的时候不用刻意保持三段式的结构。C语言的状态机更注重可读性和可维护性，而不是严格的时序逻辑分离。

8. 从站开发视角：如果你要自己做一个EtherCAT从站

虽然这篇文章主要讲的是用SOEM做主站控制SV660N，但如果你对从站开发也感兴趣，这里简单提几个关键点。

EtherCAT从站的核心是ESC（EtherCAT Slave Controller）芯片，常用的有Beckhoff的ET1100、ET1200，或者Microchip的LAN9252。ESC负责处理EtherCAT协议栈的底层通信，包括FMMU、SM通道、DC等。

从站固件需要实现的对象字典（Object Dictionary）和PDO映射逻辑。对象字典可以用XML文件（ESI文件）来描述，然后通过代码生成工具生成C代码。PDO映射的处理需要在ESC的中断服务程序里完成，把接收到的PDO数据解析出来，更新到应用层。

状态机的实现需要严格遵循CiA402规范，包括状态转换的条件、控制字的位定义、状态字的位定义。如果状态机实现有问题，主站就无法正常使能从站。

从站开发的难点在于实时性和兼容性。不同主站的行为可能有差异，比如有些主站会在进入OP状态之前先读一遍PDO映射，有些主站则直接写。从站需要能兼容这些不同的行为模式。

如果你只是想用SOEM控制现成的伺服驱动器，不需要深入了解从站开发的细节。但如果你要自己做一个从站设备，建议先买一块ESC的开发板，从最简单的IO从站开始做起，逐步加入PDO映射和状态机。

9. 关于SOEM测量传播延迟和DC配置的补充

SOEM提供了ec_configdc函数来配置分布式时钟，但传播延迟的测量需要额外的步骤。在ec_configdc之后，SOEM会读取每个从站的DC参数，包括接收时间、发送时间、系统时间等。传播延迟的计算是基于这些参数做的。

如果传播延迟测量不准确，DC同步就会有问题，表现为从站之间的时间偏差过大。在伺服应用中，DC同步不好会导致多轴之间的位置不同步。

测量传播延迟的代码大概是这样：

ec_configdc(); // 等待一段时间让DC稳定 osal_usleep(100000); // 读取传播延迟 for (int i = 1; i <= ec_slavecount; i++) { printf("Slave %d delay: %d ns\n", i, ec_slave[i].pdelay); }

如果pdelay的值异常大（比如超过1000ns），可能是网线太长或者连接器接触不良。正常的传播延迟一般在100ns到300ns之间。

另外，DC配置需要在从站进入OP状态之前完成。如果从站已经在OP状态，再配置DC可能会失败。正确的顺序是：ec_config_init->ec_config_map->ec_configdc-> 进入OP状态。

注意：不是所有从站都支持DC。如果从站的ESI文件里没有声明DC支持，ec_configdc会跳过该从站。SV660N是支持DC的，但需要在ESI文件里确认。

10. 最后分享几个实际调试中的小技巧

第一个技巧是关于PDO映射的验证。写完PDO映射参数之后，不要急着进OP状态，先用ethercatdbg的pdo命令确认映射内容是否正确。如果映射内容不对，进了OP状态也是白搭。

第二个技巧是关于状态机的超时处理。在状态机切换的每个步骤都加一个超时计数器，比如1秒钟还没转换成功就报错。这样能避免程序卡在某个状态里死循环。

第三个技巧是关于IOmap的偏移量。在代码里用offsetof宏来获取结构体成员的偏移量，而不是手动计算。这样即使PDO映射顺序变了，代码也能自动适应。

#define PDO_OFFSET(type, member) offsetof(type, member) int32_t *target_pos_ptr = (int32_t *)(ec_slave[SLAVE_POS].outputs + PDO_OFFSET(rxpdo_t, target_position));

第四个技巧是关于周期时间的测量。在主循环里加一个计数器，统计每秒实际执行的周期数。如果实际周期数跟设定值偏差太大，说明系统负载过高或者定时器精度不够。

第五个技巧是关于错误处理。SOEM的很多函数返回的是工作计数器（Working Counter），如果返回值不等于预期值，说明通信有问题。建议在每个ec_receive_processdata和ec_send_processdata之后都检查返回值，及时发现通信异常。

这些技巧都是我在实际项目中踩坑之后总结出来的，希望能帮你少走一些弯路。SV660N是一台很成熟的伺服驱动器，SOEM也是一个很稳定的主站实现，两者配合起来能覆盖大多数中小型运动控制场景。关键是要把PDO映射和状态机这两个基础环节搞扎实，后面的应用层开发就会顺利很多。

SOEM控制汇川SV660N实战：PDO映射与CiA402状态机详解