集成EtherCAT、以太网与CAN FD的MCU实战指南：从硬件设计到调试避坑

我接触过的很多工业通信设备以前都有一个共同的尴尬要实现EtherCAT工业以太网控制自动化技术从站、以太网配置通道、CAN/CAN FD带可变数据速率的控制器局域网总线接入板子上往往要塞三套独立硬件——一颗外部EtherCAT从站控制器芯片、一颗以太网PHY、一路CAN收发器再配一颗主控MCU微控制器去忙前忙后。BOM物料清单成本高不说三套软件栈还要各自维护调试实时性问题的时候拿示波器在好几块芯片之间来回追信号那种感觉谁追过谁知道。现在有一类MCU直接把EtherCAT、Ethernet、CAN FD三种能力集成到一颗芯片里板级设计一下子清爽了很多。这篇文章就从这类MCU的实际使用出发聊聊三个接口各自的设计要点、配置方法、调试经验以及在多接口同时工作时那些容易踩的坑。内容会涉及EtherCAT从站的关键配置流程、以太网PHY和协议栈的搭配、CAN FD从经典CAN迁移的实操思路适合做伺服驱动器、PLC、远程IO、工业网关、电池管理系统的工程师参考无论你现在是在选型阶段还是已经拿到样片都可以从中找到对应的落地细节。1. 从三块芯片到一颗MCU三类通信接口为什么会聚到一起1.1 伺服、PLC、远程IO这些设备到底需要哪几种通信口先看设备端的需求。一台伺服驱动器运动控制命令走EtherCAT这已经是目前多轴运动控制事实上的主流方案但它同时需要一个以太网口用于参数配置、固件升级和状态监控产线上如果还有老设备比如变频器或者传感器很多还在用CAN总线那就还得留一路CAN口去兼容。PLC更典型主站侧要跑实时工业以太网协议同时要接上位机做数据采集还要通过CAN/CAN FD下发指令给阀岛、驱动器或者远端IO。远程IO模块和一体式网关就更直接了EtherCAT从站负责把现场设备的IO状态实时上报以太网口用于配置和诊断CAN口则作为遗留系统或第三方便携设备的接入通道。这三种接口在同一个设备里出现不是工程师闲得慌而是实际工位环境里本来就同时存在这几类设备。以前用分离方案每一路通信都要独立的外设控制器、独立的晶振、独立的匹配电路接线和布板都很痛苦。现在MCU原生把这些控制器放进芯片内部至少省掉了外部EtherCAT从站控制器的成本也减少了很多信号完整性问题。1.2 集成不只是省BOM更重要的是软件栈的收敛很多人在评估这类MCU时第一反应是省了几颗芯片嘛。但用下来我发现更值钱的是软件栈的收敛。以前外部EtherCAT从站控制器挂在SPI串行外设接口总线上主控要周期性通过SPI读写它的内部寄存器做PDO过程数据对象映射时还要维护两套数据结构一套是外部从站控制器芯片的一套是主控自己的。EtherCAT数据进来要先从外部芯片搬到主控内存再解析、再映射到控制任务每一帧都增加了几微秒的延迟和不确定性。内部集成ESCEtherCAT从站控制器之后过程数据直接在芯片内部共享内存区控制任务可以近乎零延迟地读取接收到的命令值。以太网和CAN FD也类似外设控制器挂在芯片内部的高带宽总线上DMA直接内存访问把数据搬到内存CPU的访问路径短了延迟就低实时性把控起来容易得多。从软件角度看整个设备用同一套MCU的外设库、同一个调试入口、同一份中断优先级规划不用再写一堆SPI读写协议胶水代码去伺候外部芯片。1.3 这类MCU的典型产品定位这类MCU通常会定位在工业实时控制与通信的交叉点上。从产品形态看它们的CPU内核不一定要跑得很高但往往配备独立的通信子系统或可配置的逻辑单元。比如有的芯片会把EtherCAT从站控制器、以太网MAC媒体访问控制层和CAN FD控制器做成独立电源域和时钟域这样可以避免通信模块干扰实时控制核心。也有一些芯片采用多核架构一个核跑应用控制另一个核专职处理通信协议栈。用下来我对这类MCU的定位理解是它不是要去替代高端应用处理器而是把控制MCU能干的活和通信ASIC专用集成电路/独立控制器能干的活合并到一颗中等成本的芯片里让中低端工业设备也能用上原本高端设备才有的多接口能力。这个定位决定了选型和开发思路都不能照搬传统的一颗MCU 外扩芯片模式而是要从系统角度重新梳理资源和中断分配后面的章节我会围绕实际的配置和调试展开讲。2. EtherCAT从站落地ESC集成方式、PDO映射与SYNC抖动调试2.1 ESC的三种实现方式为什么内部集成是趋势EtherCAT从站在硬件层面必须有一个ESC负责从EtherCAT帧里提取/插入过程数据同时维护从站状态机、FMMU现场总线内存管理单元即内存映射、SM同步管理器用于管理邮箱和过程数据通道等机制。目前ESC的落地方式有三种外接独立ESC芯片比如Beckhoff的ET1100/ET1200系列通过SPI或者并行总线与主控MCU连接。在FPGA现场可编程门阵列里烧录软核ESC。MCU芯片内部硬件集成ESC模块。三种方式我都接触过。外接独立ESC方案最成熟但成本和体积摆在那里而且主控与ESC之间的通信延迟是硬伤在1ms甚至更短的控制周期里每一次SPI读写都会挤占控制任务的时间片。FPGA方案很灵活比如可以用在需要同时做很多IO逻辑的场合但开发和维护成本高不是所有团队都养得起FPGA工程师。内部集成ESC则是把上述问题的痛点直接去掉过程数据放在片上共享内存主控核直接按地址访问不再有SPI搬运这一层延迟。这类新MCU的最大卖点就在这里。选型时你要重点确认一点内部ESC是否支持DC分布式时钟同步以及DC同步的精度指标。大多数内部集成方案会复用外部晶振并通过精确时间协议实现从站之间时钟同步但不同芯片的实现细节差异很大实测才有底。2.2 从站侧的PDO映射与ESI文件很多第一次做从站的朋友都会犯一个错误认为EtherCAT从站的IO配置只要在TwinCAT主站工具里把PDO映射好就完事。实际上从站固件这边也必须做对应的映射配置两边的对象字典要能对上数据才能通。从站侧通常要完成这几件事配置CoECANopen over EtherCAT对象字典尤其是0x1600-0x17FF系列RxPDO和TxPDO映射参数。准备ESIEtherCAT从站信息文件这是给主站看的设备说明书里面包含从站的PID、厂商ID、对象字典描述、PDO默认分配等。主站靠这个文件来识别设备和配置IO。在PREOP状态下响应主站的配置请求主要就是接受PDO分配和SM通道配置。进入SAFEOP时同步开始输入输出数据刷新。实践中的建议是先用厂商提供的从站例程跑通TwinCAT扫描然后再在此基础上改PDO映射。我在调试时遇到过一个问题ESI文件里写的PDO长度和实际固件里定义的不一致主站能扫描到从站但一发送周期数据工作计数器就报错误。查了半天才发现是ESI里变量名对不上改过来就恢复正常。所以这里重点提醒改PDO映射时ESI文件、对象字典、应用固件里的结构体定义三处必须保持一致。2.3 SYNC中断抖动实测与优化EtherCAT从站的控制周期同步靠的是SYNC中断。主站通过DC机制把同步时钟分发到每个从站从站ESC在预定时间点产生SYNC脉冲MCU收到这个脉冲后启动控制任务。如果SYNC中断响应不及时或者抖动大电流环和速度环的执行时间就会不规则表现出来就是电机噪音变大甚至啸叫。我在测试某款带内部ESC的MCU时一开始直接让SYNC中断和普通外设中断用同一个优先级结果示波器上看SYNC引脚到CPU实际执行控制任务的延迟抖动超过±1.2微秒。后来我做了三件事把SYNC中断优先级提到最高不允许被打断。SYNC中断服务函数里只做两件事清标志位、把过程数据从ESC共享内存搬到控制变量区其他事情一律丢到主循环或更低优先级任务去处理。关闭中断嵌套中的不必要操作FOC磁场定向控制核心算法放到由SYNC触发的定时器中断里执行而不是直接在SYNC中断函数里算。调整后抖动降到了±0.3微秒以内跑伺服的电流环完全没问题。这块的优化思路可以复用抖动太大时先检查中断优先级再检查中断处理函数里是否有耗时操作最后看看是不是有其他外设频繁占用了总线。给一个SYNC中断处理的示意结构void ESC_SYNC_ISR(void) { // 1. 清中断标志 esc_clear_sync_flag(); // 2. 从ESC内存区读取主站下发的目标位置/速度 g_control_ref.position esc_input_sram.target_position; g_control_ref.velocity esc_input_sram.target_velocity; // 3. 置位控制任务启动标志实际计算交给控制中断/任务 g_control_trigger 1u; // 不做浮点运算不做长时间处理 }测试工具方面可以用示波器同时测量主站发出的SYNC参考信号如果是多从站看主站的第一帧以及本从站的SYNC引脚输出。两者时间差的变化范围就是你系统的同步抖动。3. Ethernet接口的工业玩法从MAC选型到协议栈调度3.1 先分清你要的是普通TCP/IP还是工业实时以太网集成Ethernet接口之后第一个要决策的问题是这个以太网口到底用来做什么。很多人笼统地说跑TCP/IP协议但工业场景下差别很大。如果只是做参数配置、诊断数据上传、网页管理那用标准的TCP/IP协议栈比如LWIP轻量级TCP/IP协议栈就够了对实时性几乎没要求。如果跑的是PROFINET RT、EtherNet/IP这种实时以太网协议那普通的TCP/IP协议栈根本不够需要用专用协议栈配合硬件的实时通道比如某些MCU内部集成的硬件加速模块来处理周期性IO数据。选型时必须确认以太网MAC对工业实时以太网协议的支持程度是否支持时间戳、是否支持VLAN优先级、是否有专用的实时收发队列。以Modbus TCP为例它本质是在TCP/IP上跑应用层协议普通MCU的以太网MAC加上一个成熟的TCP/IP协议栈就能搞定。但如果你要做EtherNet/IP的快速IO或者PROFINET厂商SDK里通常已经针对底层做了适配直接用厂商方案比自己在LWIP上硬改要稳妥得多。我的建议是在选型阶段就把以太网口跑什么协议完整写清楚这直接决定了SDK选型和开发量。3.2 PHY和变压器选型的几个关键点MCU内置的是MAC物理层收发还得靠外部PHY芯片和变压器。别觉得这是成熟的东西就可以随便选工业环境下PHY的稳定性对通信质量影响很大。实际选型时我主要看四点工作温度范围工业级至少-40℃到85℃不然现场机柜稍微热点PHY就开始丢包。MAC接口类型是MII媒体独立接口还是RMII精简媒体独立接口。RMII引脚少但需要50MHz参考时钟而且时钟来源不同会带来不同的约束比如有的PHY要求MAC提供这个时钟有的PHY自己输出接法不一样。是否支持HP Auto-MDIX自动翻转电缆线序现场维护会省很多事。MDIO管理接口的地址引脚配置电路上通常用上下拉电阻设定PHY地址量产时如果这里焊错PHY就读不到。变压器主要看内置还是外置。内置变压器的RJ45座子比如带网络变压器的连接器可以省掉单独变压器和共模电感板上面积小很多但EMI电磁干扰性能一般不如外置独立变压器方案。对成本敏感且对EMI要求不苛刻的产品直接用带变压器的RJ45坐没问题我对接过的不少工控板都这么干。如果要做高EMC电磁兼容性等级比如需要过严苛的工业现场抗干扰测试老老实实设计独立变压器加共模电感并在变压器中心抽头处理好电容。3.3 RTOS里的协议栈调度别让收发中断拖垮控制周期以太网协议栈是中断加任务配合的典型。PHY收到数据帧MAC通过DMA搬运到内存然后产生接收中断协议栈任务处理TCP/IP状态机。如果方案是把EtherCAT和Ethernet都放在同一颗MCU上就必须规划好以太网中断和控制任务的关系。我的经验是Ethernet接收中断优先级设一个中等值绝对低于EtherCAT的SYNC中断。因为TCP/IP重传丢包还能重来控制周期错过就真的错过了。协议栈任务和电机控制任务之间也要明确分工最好把协议栈任务设为低优先级控制任务以固定周期抢占运行。我实测过用一颗运行在几百MHz的MCU纯TCP传输速率可以到几十Mbps但如果控制任务每100微秒抢一次CPU协议栈吞吐会明显下降这个要提前给项目定好预算。另外一个容易忽略的点是接收描述符和缓冲区大小。TCP/IP包最大可能到1500字节左右如果你的RX DMA描述符只配了512字节那大包会被分片缓存或者直接丢弃表现为能PING通但TCP传输速率上不去。我一般会为每个RX描述符分配不小于1536字节的缓冲区宁可多占几个KB的RAM也不要出现这种奇怪的性能瓶颈。4. CAN FD迁移实战老CAN设备如何平滑升级4.1 仲裁段和数据段分段配置的玩法经典CAN的带宽上限是1Mbps每帧最多8字节数据。CAN FD的出现把两个限制都解开了数据段最高可以到5Mbps甚至更高单帧数据可以到64字节实时性和传输效率都有了质的提升。但CAN FD并不是简单地把波特率调高这么简单它把位时间分成了仲裁段和数据段两段需要分别配置。仲裁段是报文起始到BRS位数据长度码这部分用相对较低的波特率比如500k或1Mbps主要是为了和总线上其他经典CAN节点兼容保证仲裁机制稳定。BRS位之后的数据段则可以切到高速率比如2Mbps、5Mbps加快数据场和CRC循环冗余校验部分的传输。这样设计的好处是一个CAN FD网络中不同节点可以在同一个仲裁机制下竞争总线数据段各自高速传输。配置时要注意支持CAN FD的控制器能向下兼容收发经典CAN帧但经典CAN控制器收不了CAN FD帧。所以总线混用的时候如果一个经典CAN节点听到了CAN FD帧它会因为格式不认识而报错。实际迁移方案通常是分阶段先让所有节点都换成CAN FD控制器但暂时只发经典CAN帧等确认没问题了再切换成CAN FD帧发送这样可以最大程度减少对产线的影响。4.2 采样点与TDC五个参数决定总线稳定性CAN总线位时序是配置的重灾区。波特率是结果根源在于整条总线的位时间由同步段、传播段、相位缓冲段1和相位缓冲段2组成采样点就是相位缓冲段1结束的时刻在整个位时间里的占比。位时间的计算公式可以简化表达为位时间 (1 TSEG1 TSEG2) × 时间量子采样点 (1 TSEG1) / (1 TSEG1 TSEG2) × 100%这里TSEG1对应的是传播段加相位缓冲段1TSEG2对应相位缓冲段2。经典CAN通常推荐采样点在70%到80%之间CAN FD因为数据段频率更高位时间更短对采样点更敏感推荐75%到80%左右。我踩过一次把经典CAN 1Mbps下的那套TSEG参数直接套到CAN FD的5Mbps数据段上结果总线上不停出现错误帧。后来重新按采样点78%计算把数据段的位时序重新配置才恢复正常。这件事的教训是CAN FD的仲裁段和数据段位时序要分别计算不能图省事共用一套参数。另外高速率下还要关注TDC发送延迟补偿。发送节点从发送器经过收发器再到总线存在环路延迟。5Mbps时一个位时间只有200纳秒物理收发延迟已经占了相当大的比重所以CAN FD控制器一般都会提供可配置的TDC功能补偿发送路径的延迟。如果芯片支持TDC配置时根据收发器的传播延迟和总线长度估算补偿值可以显著提升高速通信的稳定性。4.3 用CAN FD做OTA升级速度能快多少CAN总线设备做OTA空中升级/在线升级是刚需尤其是分散在现场的设备。经典CAN一帧8字节假设波特率500kbps传一个256KB的固件包需要3万多帧光传输时间就非常可观。CAN FD虽然应用层还是需要分包和流控但64字节的帧长加上更高的数据段速率可以把升级时间缩短一个量级。我实测过一组对比同一颗MCU同一个固件268KB经典CAN 1Mbps下约30秒左右传完CAN FD仲裁段1Mbps、数据段5Mbps、单帧64字节大概3秒出头传完。升级过程里还涉及Flash擦写如果采用边收边写策略建议在每一帧或每几帧之后加入简单的应答机制防止Flash擦写期间缓冲区溢出丢帧。我当时用的是每收到16帧就回一个ACK发送端收到ACK后继续发下一批256KB固件整体大概5秒完成出错重传的帧数也很少。这里的一个经验是CAN FD把每帧数据量拉上来了但应用层的分包协议还得设计成一个相对通用的格式最好带帧序号和总帧数。因为实际现场升级失败最常见的场景不是传输慢而是中途断电导致固件残缺。加一个帧序号校验和以及分区备份机制比追求传输速度更重要。5. 三个外设同时跑起来的底层保障时钟树、中断与DMA5.1 时钟树分配为什么要给通信外设独立的PLL三种通信外设对时钟的需求不一样。EtherCAT从站的同步时钟通常来自ESC自身的时钟域理想情况下要能跟随主站DC调整保证所有从站同步以太网MAC的时钟来自PHY或者系统PLLMAC配置成RMII模式时还需要一路50MHz参考时钟CAN FD的位时序则完全由外设时钟决定如果你用系统主频直接分频主频一变CAN波特率就跟着飘那是灾难。这类MCU的时钟树通常会提供多个PLL锁相环可以给通信外设分配独立的时钟源。我在配置时会把EtherCAT和Ethernet分到不同的PLL域CAN FD也单独从某个外设时钟源取时钟这样互不干扰。配置时钟树时要看清楚参考手册里外设时钟的多路复用器不要图省事选了个共享时钟源结果调试EtherCAT时动了另一个模块的时钟配置把以太网频率带偏了。举一个真实情况某次我调整主频规划想把CPU从240MHz提到400MHz结果忘记同步检查EtherCAT ESC和以太网PLL的配置EtherCAT还能跑以太网PHY因为RMII参考时钟频率偏了出现间歇性link down。后来把通信外设的PLL配置单独抽出来做成独立模块配置跟主频调整脱钩这个问题就再没出现。5.2 中断优先级规划谁该打断谁心里要有谱多通信外设并存时中断优先级的规划是整个系统实时性的核心。我给一个实际项目里的优先级安排供参考中断源优先级说明EtherCAT SYNC最高控制周期起点抖动直接影响电机控制质量CAN FD接收高数据帧频率高缓冲队列短响应慢了容易丢帧定时器控制PWM(用于FOC)高电流环/速度环执行不能错过Ethernet接收中高要保证TCP吞吐和响应但可以容忍一定延迟调试串口低不影响主功能慢一点无所谓这样分配的核心逻辑是不可重来的、和实时控制强相关的优先级最高可以缓冲、可以等待的优先级降低。比如EtherCAT SYNC如果被CAN FD中断抢占即使只抢几微秒控制周期的抖动也会变大而Ethernet丢一个包TCP协议栈自己会重传根本不需要CPU中断响应得特别快。RTOS实时操作系统环境下还要注意中断优先级和任务优先级不是一回事。中断服务函数应当尽量短只做数据搬运和事件通知真正的协议处理放在任务上下文里。如果中断里直接调用像TCP发送这种长流程整个系统的实时性都会被打乱。5.3 缓存一致性和DMA缓冲区的坑通信外设大规模使用DMA之后缓存一致性成为最容易踩的坑之一。特别是带Cortex-M7这类带D-Cache的内核MCUDMA直接把数据写到内存但CPU读的时候可能从Cache里读到旧的脏数据两边数据不一致表现就是EtherCAT偶尔读到错值、以太网收到畸形包。解决缓存一致性有两个常用办法把DMA描述符和数据缓冲区分配到非缓存区域。很多MCU的链接脚本里专门有non-cacheable RAM段把通信缓冲区放进去CPU和外设直接看到同一份数据从根源上避免一致性风险。在CPU访问DMA缓冲区前后做Cache Clean和Invalidate操作。麻烦一点但适合缓冲区必须放在缓存区域的场景。我用第一种方式居多。需要留意的是链接脚本里把缓冲区放进non-cacheable区域后CPU访问这些地址的性能会比访问普通RAM慢一些但对通信外设来说关系不大。真正需要注意的是别把控制任务里频繁读写的关键变量也放进non-cacheable区域那样性能损失会比较明显。内存布局上我会把EtherCAT的ESC内存映射区、以太网DMA描述符和缓冲区、CAN FD的FIFO缓冲区分段规划好各占一块避免互相干扰方便调试时通过查看内存窗口快速定位问题。6. 从参考设计到量产上电时序、引脚默认状态与调试工具6.1 启动流程期间引脚默认状态可能给你埋雷MCU上电启动是一个循序渐进的过程复位、引导、初始化时钟、配置引脚复用、加载外设配置、执行用户程序。在复位释放到用户程序运行之间的这段时间芯片引脚处于默认状态可能是浮空、上拉或下拉具体取决于芯片设计。这个默认状态在工业总线通信场景里很危险。比如EtherCAT的PHY复位引脚如果复位释放后是浮空的PHY可能进入不确定的状态偶尔上电起不来。最常见的问题出现在RS-485/CAN这类需要关闭发送器的接口上如果TX使能引脚上电瞬间恰好为高节点就会往总线上发送垃圾信号影响同网段其他设备甚至导致主站诊断错误。我踩过PHY复位引脚的一个坑参考设计里复位引脚直接接MCU的一个GPIO我照着画板但没仔细看上电时序结果MCU的GPIO在上电配置之前输出一个短暂的高电平脉冲刚好把PHY的复位时间拉长导致PHY启动偶发失败link要等好几秒才起来。后来在复位引脚上并联了一个RC延时电路确保复位时序稳定问题就消失了。这类问题建议在硬件设计阶段就逐条核对参考设计里每个引脚的默认状态和上电时序尤其是通信相关的复位、使能、中断引脚。6.2 串口接收上拉这种小问题为什么值得单独拿出来说MCU串口接收引脚是否有上拉听起来是个特别不起眼的细节但在量产阶段它会给你颜色看。串口RX引脚在MCU不发送数据时处于接收状态如果引脚悬空电平可能漂移在阈值附近产生伪起始位导致串口收到一堆0x00或者乱码。很多MCU的引脚内部可以配置上拉但要注意配置成复用功能时的上下拉行为未必和纯GPIO一样这个要看参考手册里每个引脚的默认状态说明。我在一个项目里默认内部上拉被禁用了结果调试串口偶尔收到随机字符排查了半天才发现是RX引脚悬空导致的问题。最后在PCB上给RX加上拉电阻问题消失。量产阶段还有一个更大的坑测试夹具通过串口和板卡通信如果RX引脚悬空夹具接触瞬间的电平不确定可能导致握手失败而且这种问题在产线上复现率还不固定一会儿好一会儿坏排查起来特别浪费工时。所以我的习惯是所有串口RX引脚都在板上加一个10kΩ上拉电阻同时确认MCU内部上拉是否开启双保险。6.3 排查这类多接口板卡我常用的工具和套路设备同时跑了EtherCAT、Ethernet和CAN FD三种通信出了问题怎么快速定位这个非常考验工具组合。先说排查链路的思路从物理层往上走。第一层看物理层用示波器和逻辑分析仪检查PHY芯片、ESC和CAN收发器的信号完整性。重点测量SYNC波形、RMII/MII时钟、CAN差分信号。第二层看协议层EtherCAT用Wireshark抓包设置好过滤器看工作计数器有没有错误、状态机卡在哪个阶段以太网同样用Wireshark看TCP重传和ARP问题CAN/CAN FD用CAN分析仪工具支持CAN FD解包和错误帧统计。第三层看应用层在固件里加调试用的状态变量通过串口或以太网日志定期输出各通信模块的计数、错误码、中断触发次数。我习惯在固件里加一个通信自检功能上电后依次做三件事EtherCAT发起状态机请求并打印状态机切换结果以太网PING自己并上报往返时间CAN FD发一组自检数据并检查回环。这三项都通过后再启动正常的应用逻辑。这个自检功能在产线测试和现场排障中都特别有用能省去很多扯皮时间。调试时还有一个很实用的技巧EtherCAT主站日志和Wireshark抓包要配合看。很多情况下主站日志显示从站状态错误其实问题出在从站应用没有正确响应邮箱通信或者PDO映射和ESI文件不一致。此时Wireshark抓到的帧能告诉你应用层有没有正确回数据。现场排查时这句话基本成了我的口头禅先把物理层波形稳住再把协议层抓包看清最后才调应用层代码。按照这个顺序走绝大多数通信问题都能在比较短的时间内定位到根因。最后再分享一个小套路我在设计量产固件时会特意把三个通信模块的独立状态变量做成一个结构体并通过调试串口周期性输出哪怕平时不接也要在代码里保留这个入口。设备一旦在现场出问题接上调试串口就能看到EtherCAT工作计数器、以太网丢包数、CAN FD错误计数大部分情况下问题描述和这些计数一对照原因基本就浮出水面了。这个习惯帮我省了很多次出差。