4、拓扑设计实战：基于实际产线需求（30轴伺服+IO）设计线型拓扑，计算最小周期
好，咱们直接进入正题。
30个伺服轴，加上一堆IO点，这是典型的产线配置。比如包装线、组装线，或者印刷设备，差不多就是这个规模。今天我就带你走一遍，怎么从零开始设计一个线型拓扑，并且算出它的最小周期。
4.1 先搞清楚需求：30轴+IO到底意味着什么
先别急着画图。我个人习惯，拿到需求先列个清单：
- 伺服轴数量：30个。每个轴至少需要位置控制字、状态字、目标位置、实际位置，这算下来每个轴大概8-12个PDO对象。
- IO点数：假设是128点输入、128点输出。这不算多，但分布可能比较散。
- 控制周期：客户要求1ms以内。嗯，这个目标不算苛刻，但也不轻松。
- 物理布局：设备是直线排列的，所以线型拓扑最合适。
你想想看，30个轴如果全部挂在一根总线上，数据量其实不小。每个轴按10个PDO对象算，每个对象4字节，那就是40字节。30个轴就是1200字节。再加上IO，大概100字节。总数据量在1300字节左右。
关键点：EtherCAT的帧结构里，每个从站的数据是连续排列的。数据量越大，帧越长，传输时间就越长。这是影响周期的核心因素。
4.2 线型拓扑设计：怎么挂这30个轴
线型拓扑说白了就是一根总线串到底。但怎么串，有讲究。
方案一：全部串在一起
最简单粗暴。从主站出来，第一个轴，第二个轴……一直到第30个轴，最后挂IO。这种方案布线最省，但有个问题：如果中间某个轴断开了，后面所有设备都掉线。
方案二：分段串联
我个人更推荐这个。把30个轴分成3段，每段10个轴，段与段之间用IO模块做中继。比如：
- 段1：轴1-10
- 段2：轴11-20 + 部分IO
- 段3：轴21-30 + 剩余IO
这样做的好处是，如果某段出问题，只影响该段，不会全盘崩溃。我在项目中遇到过类似情况，分段后排查故障快得多。
我的经验：线型拓扑里，每个从站都会引入微小的延迟。一般EtherCAT从站芯片的转发延迟在1微秒以内。30个轴串下来，光转发延迟就30微秒。虽然不大，但算周期时不能忽略。
4.3 计算最小周期：一步步来
好，现在我们来算周期。这是硬功夫，不能含糊。
EtherCAT的周期主要由三部分组成：
- 帧传输时间：数据在物理层上跑的时间
- 从站处理时间：每个从站处理数据帧的时间
- 主站处理时间：主站发送和接收帧的时间
咱们一个一个算。
4.3.1 帧传输时间
EtherCAT用的是100Mbps以太网。帧长度包括：
- 以太网帧头：14字节
- EtherCAT头：2字节
- 数据段：1300字节（我们之前估算的）
- 帧校验：4字节
- 帧间距：12字节
总长度 ≈ 1332字节。
传输时间 = 1332 × 8 / 100,000,000 = 0.10656毫秒 ≈ 107微秒。
嗯，这是理论值。实际上还要考虑线缆长度带来的延迟。100米网线大概延迟0.5微秒，咱们按50米算，也就0.25微秒，可以忽略。
4.3.2 从站处理时间
每个从站芯片（比如LAN9252、ET1100）处理一帧数据，大概需要1微秒。30个轴加上IO模块，算35个从站吧。
总处理时间 = 35 × 1微秒 = 35微秒。
注意：有些从站芯片处理时间更长，比如一些老款的ET1100可能到2微秒。选型时一定要看数据手册。我曾经吃过这个亏，选了一款便宜的从站芯片，结果周期死活压不下来。
4.3.3 主站处理时间
这个取决于主站硬件和软件。用SOEM的话，在普通工控机上，主站处理时间大概在50-100微秒。如果用了实时补丁（比如PREEMPT_RT），可以压到30-50微秒。
咱们按50微秒算。
4.3.4 总周期
总周期 = 帧传输时间 + 从站处理时间 + 主站处理时间
= 107 + 35 + 50 = 192微秒 ≈ 0.2毫秒。
你看，1ms的要求完全没问题。甚至还有余量。
实际建议：设计时留出30%的余量。比如算出来0.2ms，实际跑0.3ms。这样即使有突发数据或者干扰，系统也不会崩溃。
4.4 用SOEM实现：代码片段
理论算完了，咱们看看SOEM里怎么配置。下面是一个简化的初始化代码：
// 初始化SOEM
if (ec_init("eth0")) {
printf("初始化成功\n");
} else {
printf("初始化失败\n");
return -1;
}
// 扫描从站
int slave_count = ec_config_init(FALSE);
printf("发现 %d 个从站\n", slave_count);
// 配置PDO映射
// 这里假设每个轴有8个PDO对象
for (int i = 1; i <= slave_count; i++) {
// 设置PDO映射
ec_config_map(&IOmap);
}
// 配置DC同步
ec_configdc();
// 等待所有从站进入OP状态
ec_statecheck(0, EC_STATE_OPERATIONAL, EC_TIMEOUTSTATE);这段代码看着简单，但实际调试时坑不少。比如PDO映射的顺序必须和从站配置一致，否则数据会错位。我刚开始用SOEM时，就因为这个查了两天bug。
4.5 避坑指南：我踩过的几个雷
- 从站顺序：线型拓扑里，从站的物理顺序必须和配置顺序一致。否则数据全乱。我曾经把两个轴接反了，结果位置数据全对不上。
- DC时钟同步：30个轴如果不同步，运动控制精度会受影响。SOEM里用
ec_configdc()配置，但要注意参考时钟的选择。一般选第一个从站作为参考。 - 帧长度限制：EtherCAT帧最大1518字节。如果数据超过这个值，需要分帧。30个轴一般不会超，但如果每个轴配置了太多PDO，就可能超。我建议每个轴不超过12个PDO对象。
小技巧：调试时先用Wireshark抓包，看看实际帧长度和周期。SOEM自带一个ecx_port结构体，可以实时查看帧统计信息。
4.6 知识体系图
下面这张图总结了本章的核心逻辑：
这张图把整个设计流程串起来了。从需求分析开始，到拓扑设计、周期计算、SOEM实现，再到避坑和验证。每一步都环环相扣。
4.7 总结一下
30轴+IO的线型拓扑，说白了就是算清楚数据量，选好分段策略，然后用SOEM配好PDO和DC。周期算下来0.2ms左右，完全够用。
嗯，这里要注意一点：实际跑的时候，周期可能会比理论值大一些。因为主站CPU还要处理其他任务。所以建议把周期设成理论值的1.5倍，比如0.3ms。这样既保证性能，又留有余地。
好了，这一章就到这里。下一章咱们聊聊环形拓扑和冗余设计，那个更有意思。