电话/手机：联系客服
TwinCAT3 系统，EK1100 后面带了 8 个 EL 模块。
运行中偶尔报：‘E-Bus Current consumption exceeded’（E总线电流超限）。
查了手册，我这几个模块电流加起来才 600mA，电源模块是 2A 的。
换了耦合器，换了末端盖板，没用。
最奇怪的是，只要我在控制柜旁边打个电话（手机信号干扰？），它就更容易报错。
难道 E-Bus 的底板通信电流这么容易受电磁波干扰？还是其中某个模块内部短路了但没完全坏
优质评论内容
这不像 MB_MASTER 内部缓存清不掉，更像是你的轮询状态机“提前切到下一步”了。
最关键线索是：
你把 1 号表挪到最后读，结果变成最后那个表慢半拍。
这说明问题不是某一个温控表，也不是 1 号表地址，而是“轮询队列的边界条件”有问题。也就是每轮最后一次读到的数据，没有在正确时机被搬运或锁存，下一轮才显示出来，所以看起来像永远慢一拍。
最常见原因有三个。
第一，DONE 一出现就马上切换从站号和接收区
很多程序是这样写的：
当前站 MB_MASTER
DONE 后 站号加一
下一扫描周期开始下一站
问题是，如果你在 DONE 同一个扫描周期里就改了从站号、寄存器地址或接收缓冲区，可能导致数据还没被你正确搬走，就已经进入下一步逻辑。
正确做法是：
DONE 后先把本次接收数据复制到对应表的数据区
再延时一拍
再切换到下一个站
也就是说流程应该是：
发送请求
等待 DONE
复制接收数据
清 REQ
等待一拍
切换站号
再发下一次 REQ
不要在 DONE 当拍同时做太多事。
第二，接收缓冲区共用，但显示区更新慢一拍
如果 5 个温控表共用一个 MB_DATA_PTR 接收区，然后你再根据站号把数据搬到 1 到 5 号表显示区，最容易出现错位。
比如程序实际效果变成：
读 1 号，收到数据，但还没搬
读 2 号时，才把上一次数据搬到 1 号
读 3 号时，才把上一次数据搬到 2 号
于是就会出现“数据漂移”。
解决方法是：
每个从站使用独立接收区，或者 DONE 后立即按当前站号锁存数据。
第三，REQ 信号不是干净的上升沿
MB_MASTER 这类通信块非常依赖一次触发逻辑。如果 REQ 一直保持，或者在 DONE 后没有完全断开一个扫描周期，就容易出现状态机混乱。
建议：
每次请求只给一个脉冲
BUSY 期间不要改参数
DONE 或 ERROR 后复位 REQ
等待一个扫描周期以上再发下一条
你可以重点检查这几个变量：
当前轮询站号
MB_MASTER 的 REQ
BUSY
DONE
ERROR
MB_DATA_PTR 指向的接收区
DONE 后搬运数据的时机
最建议你这样改：
每个站做固定步骤。
步骤 0，准备参数，站号和寄存器地址写好
步骤 1，REQ 给一个上升沿
步骤 2，等待 BUSY 结束
步骤 3，如果 DONE，立刻把接收缓冲区复制到该站专用数据区
步骤 4，清 REQ，等待 50 到 100ms
步骤 5，站号加一，进入下一站
注意一个关键原则：
在 BUSY 为 1 的时候，绝对不要修改 MB_MASTER 的站号、功能码、地址、数据指针。
另外，不要用“当前站号已经加一之后”的值去搬运数据。很多慢半拍问题就是这里造成的。
比如错误写法是：
DONE 后先 Index 加一
然后按 Index 搬数据
这样最后就一定错位。
正确写法是：
DONE 后先用 OldIndex 搬数据
搬完再 Index 加一
一句话总结：
你这个不是西门子内部 Buffer 玄学，而是轮询程序里“完成信号、数据搬运、站号切换”的顺序错了。谁放在队列最后，谁就慢半拍，已经证明是轮询状态机边界问题。