做工业数据采集绕不开Modbus。做边缘网关选型ESP32又几乎成了性价比的默认选项。这两个词拼在一起很多人第一反应是“用ESP32当Modbus TCP服务器把传感器数据喂给上位机”可我这次想聊的恰恰反过来的场景让ESP32当Modbus TCP客户端主动去轮询一批从站设备把数据收回来之后统一处理。听起来不难真正做起来才发现最折腾人的不是TCP握手也不是从站地址表而是“一次读不完”和“读完了放哪”这两个看似基础的问题。把这两个问题揉在一起就有了“分片缓存”这套设计。我先说结论如果你做的项目里单台从站的寄存器超过125个或者现场挂着好几台从站而你希望所有数据都有一份“本地镜像”那这篇内容对你应该有用。我尽量不写教科书全部按实际调试的视角来讲。1. 为什么要做分片缓存先搞懂瓶颈在哪1.1 Modbus TCP一帧到底能装多少数据Modbus TCP的数据单元PDU最长只有253字节。去掉功能码和字节计数这些固定开销真正留给寄存器数据的空间就跟不多了。以最常用的功能码0x03读保持寄存器为例响应帧的结构是功能码占用1字节后面的字节计数字段占1字节再往后才是寄存器数据每个寄存器占2字节。算下来253 - 1 - 1/ 2 125.5所以一帧最多只能读回125个寄存器。读线圈会宽裕一些功能码0x01最多能读2000个线圈因为线圈是bit位压缩的。但实际项目里最普遍的还是寄存器读写尤其是保存模拟量、累计值、状态字这些数据。要么一个寄存器放一个整型要么两个寄存器拼一个32位数值要么四个寄存器拼一个浮点。一旦点位多起来比如某个从站有400个寄存器就意味着至少要发4次Modbus请求才能读完它的全部数据。还有个容易被忽略的点写操作的限制比读更严。写多个寄存器功能码0x10时请求PDU里除了功能码、起始地址、数量还要带上字节计数和待写入的数据本体所以一次最多写123个寄存器。要是你的控制逻辑里有“批量下发参数表”这种需求分片这件事就不仅是读了写的时候同样逃不掉。1.2 “分片”和“缓存”其实是两个要分开解决的问题很多刚上手的人会把“分片缓存”当成一个词来理解觉得无非就是“把大块数据切碎再存起来”。我在实际开发中的体会是这是两件独立的事只是它们经常同时出现。分片解决的是“一次性读不完”的问题。它的本质是把设备的寄存器空间映射成一张分片规划表把一个大地址区间拆成若干个小请求。每个分片就是一条具体的Modbus报文对应着起始地址、寄存器数量、所属设备这些信息。缓存解决的是“读完的数据怎么为上层服务”的问题。它的本质是在ESP32的内存里划出一块镜像区把轮询回来的数据填进去让上层的显示、上报、控制逻辑不直接依赖网络的实时响应。上位机或者本地逻辑要数据时直接从缓存区拿只有缓存失效时才去触发重新轮询。分片做好了才能保证“全量数据在可控周期内刷新一遍”缓存做好了才能保证“数据在刷新间隙仍然是可用的、一致的”。两者是承上启下的关系少了任何一环另一环都会暴露问题。1.3 我在项目里实际踩过的坑最早做这个采集网关的时候我偷懒没用缓存直接按需读取界面上要显示某个值立刻发一条Modbus请求等响应回来了再刷新UI。看起来逻辑很直接但一跑起来就露馅了。第一个坑是点位多了以后整个页面的数据像抽风一样跳动。因为每次读取都是独立请求寄存器A和寄存器B返回的时间差可能有几十毫秒如果这两个寄存器本来应该组成一个完整的物理量那中间这段时间拿到的数据就是“撕裂”的。第二个坑是遇到慢从站。有些从站是串口服务器转Modbus TCP的底层走的是RS485串口波特率才9600。这种情况下读125个寄存器响应时间可能要到几十甚至上百毫秒。这时候如果客户端又发了一条新请求很多从站根本不理会直接导致超时。我后来抓包发现现场大量超时不是网络问题纯粹是客户端请求发得太急把从站“问懵”了。第三个坑是单个寄存器逐个读。一开始我的分片粒度很细每个分片只读一个寄存器想着这样最灵活结果一个400寄存器的设备要轮询400次一个刷新周期跑完要几十秒完全没法用。后来才明白125这个上限不是让你每次读125个但也不能只读1个。要在“请求数量”和“刷新周期”之间找平衡。2. 整体设计ESP32上的分片缓存架构2.1 数据流向与角色划分在这套设计里ESP32的角色是Modbus TCP客户端。它向下通过以太网或WiFi连接若干从站设备向上面对的是本地业务逻辑比如按键显示、控制逻辑和远程服务器MQTT上报、HTTP API。缓存区放在中间像是一个“数据池塘”。数据流动大体是这样的分片调度器按规划表依次向各从站发起请求响应回来后经过校验、字节序处理写入缓存区并更新对应分片的刷新时间戳上层业务只与缓存区打交道。当缓存区的某个分片超过设定的老化时间上层可以触发一次“主动刷新”或者干脆等调度器下一轮自然轮询到它。这种设计最大的好处是把“网络通信”和“业务消费”彻底解耦。网络抖动、从站无响应、TCP断线重连这些脏活累活都被挡在缓存区外面上层逻辑看到的数据始终是内存里那份稳定的镜像。2.2 分片规划表的设计缓存区不是凭空建起来的它必须有一张“地图”来告诉调度器哪些地址要读、分几片、隔多久读一次。我习惯把这套配置做成一张静态表放在常量区改设备点位时直接改表就行。下面是一个典型的规划表示意从站编号起始寄存器寄存器数量分片大小分片数刷新周期优先级1040010042s高11000505015s低2026010032s高2200161611s紧急为什么分片大小是100而不是125这是我故意留的余量。有些从站虽然号称支持Modbus TCP但内部实现其实是单片机限制单次最多读60或100个寄存器超了就返回异常码。125是协议上限不是所有设备的实现上限。根据现场设备手册调分片大小这是必须养成的习惯。分片规划的背后还有一个原则同一个“业务变量”涉及的所有寄存器必须尽量落在同一个分片里。比如一个累计流量的64位浮点数占4个寄存器如果这4个寄存器分别落在两块分片上两次请求之间有时间差那拼出来的数值可能是“前一半是第1秒读的后一半是第2秒读的”这在计量场景里是不能接受的。2.3 缓存区的内存布局ESP32的RAM是有限资源。经典ESP32虽然有520KB左右的SRAM但WiFi协议栈、TCP/IP协议栈、任务栈都会吃掉不少实际留给应用堆的通常只有一两百KB。所以缓存区不能按“寄存器数量 × 2字节”这么简单地铺开要有规划。我的做法是用一个uint16_t数组模拟整个寄存器空间每个元素对应一个寄存器编号。为了节省内存不保存整个Modbus地址空间的副本只保存规划表里实际用到的寄存器区域。每片缓存额外配一个状态结构体记录这块数据分片的上次成功刷新时间、失败次数和有效标志。typedef struct { uint16_t start_addr; uint16_t count; uint32_t last_ok_tick; uint16_t fail_cnt; uint8_t valid; } cache_slice_t; #define MAX_SLICE_NUM 16 #define MAX_REG_NUM 1024 uint16_t reg_cache[MAX_REG_NUM]; // 缓存主数组 cache_slice_t slice_info[MAX_SLICE_NUM]; // 分片状态表这里有个权衡寄存器地址并不是连续的缓存主数组的下标和实际的Modbus地址之间需要一个映射函数。如果现场设备不多直接用线性映射最简单。设备多了、地址碎片化了可以引入哈希或分段映射但代价是代码复杂度上来了。对这个场景来说线性映射完全够用。3. 分片策略和缓存一致性的几个关键决定3.1 分片大小不是越大越好既然协议允许读125个寄存器那是不是所有分片都直接按125来切我试过发现并非如此。从报文时长估算就能看出来。一个读125寄存器的响应帧TCP层总长度大概是259字节MBAP头7字节 功能码1 字节数1 数据250。在局域网里这个长度的报文传输耗时几乎可以忽略真正的大头是设备内部的处理时间。有些PLC或采集器的Modbus处理周期是固定的比如10ms扫一次你发再大的请求它也是按这个周期处理有些设备则是收到请求后临时组包125个寄存器需要拼接250字节处理时间反而比读32个寄存器更长。实际经验是分片大小设为100左右比较折中。一是避开某些设备125寄存器处理的性能瓶颈二是响应帧控制在200字节左右调试抓包时一屏能看全问题也容易定位。当然如果现场设备手册明确写了单次读多少个那就以手册为准这永远是第一优先级。3.2 数据一致性和跨分片变量怎么处理缓存一致性是这套设计里最容易被轻视、也最容易出问题的地方。这个问题在小型监控屏项目里几乎不存在因为显示要求没那么高但一旦涉及计量类、累计类数据就绕不过去了。我的处理套路是这样先梳理业务层的“逻辑变量表”把每个变量对应的物理寄存器列出来。一个逻辑变量可能占用1个、2个或者4个寄存器。然后做分片规划时不允许任何逻辑变量的寄存器被拆分到两个分片里。如果某几个寄存器在地址上是连续的但被设备手册定义为“高位字”和“低位字”只要它们属于同一个逻辑变量就必须放在同一个分片请求里读。如果确实有变量跨分片了比如必须从地址0读到63再从地址64读到127而变量A正好占用地址63和64那就只能接受它“偶尔不一致”。要缓解这个问题可以在应用层看到缓存更新后对跨分片变量增加一个“效验”机制比如连续读两次值完全一致才给上层用。代价是实时性降低所以尽量别走到这一步。另外缓存区里一定要有“时间戳”的概念。分片刷新时间超过设定阈值后那一片数据就不能再被认为是新鲜的。我一般用系统节拍数tick作为时间戳而不是用WiFi的NTP时间因为NTP本身可能在现场环境下不可用而且tick是单调递增的判断“多久没更新”特别直观。3.3 缓存刷新策略时间片轮询还是按需刷新分片调度器的刷新策略有两种极端一种是纯时间片轮询所有分片轮流读简单可靠但低优先级的点位和高速点位享受的待遇完全一样另一种是纯事件驱动哪个点被访问了才去读实时性最好但极端情况下会出现“缓存区大部分数据都过期了上层还不知道”。我目前用的是“基础轮询 按需插队”的混合策略。调度器维护一个分片队列按优先级排序每轮按时间片依次发起请求。当上层逻辑访问某个分片发现它已经老化超过刷新周期还没更新就向调度器发一个“插队请求”调度器暂停当前队列优先处理这个紧急分片处理完再回到原来的位置继续。这个策略的工程实现也不复杂就是给缓存区加一个“访问老化检查”的入口函数uint16_t read_cache_reg(uint16_t addr) { cache_slice_t *sl find_slice(addr); if (is_slice_stale(sl)) { request_slice_refresh(sl); // 向调度器发插队请求 } return reg_cache[addr]; }这里有个细节stale的判定阈值不能设得太小否则一旦轮询稍微抖动上层就会反复触发插队插队多了又会挤压正常轮询形成恶性循环。我一般把阈值设为正常刷新周期的1.5倍到2倍。3.4 写操作与缓存的配合缓存区的存在给“读”带来了不少便利但它和“写”天然有冲突。如果上层通过Modbus把某个寄存器写成了新值而缓存区里还是旧值下一次读取就可能把刚写进去的值覆盖掉从而造成“写失败”的假象。解决思路很朴实写操作完成后立刻同步更新缓存区里对应的寄存器并重新打上时间戳。同时调度器在规划轮询时跳过高优先级的这组分片等下一个正常周期再读回来校准。这里要考虑“读回校准”的先后问题一般写入后等待100ms左右再读比较稳妥给设备的内部处理留出时间。如果同一时间有多个逻辑在写同一个分片的不同寄存器我建议给每个分片加一个忙标志。写操作持有标志期间调度器不对该分片发起新的读请求读请求也要等待标志释放。这个锁的粒度不需要到寄存器级别到分片级别就够了不然并发控制太琐碎反而容易出乱。4. 直接能用的实现思路调度器和缓存更新4.1 核心模块怎么拆模块划分不需要太复杂三个东西就够了分片规划表、调度器、缓存区。分片规划表的职责是回答“读什么”它定义了每个分片的起始地址、长度、从站IP、Unit ID、刷新周期。调度器的职责是回答“什么时候读”它维护当前请求序列按时间片或者插队信号决定下一条发什么。缓存区的职责是回答“读回来放哪”它提供按寄存器号读写的接口并维护分片状态。如果项目再大一点还可以加一个“上报模块”定期把缓存区的数据打包成JSON或者二进制帧推送给MQTT或HTTP服务端。但上报模块不应该绕过缓存区直接去读从站那会让整个架构立刻退化回“点对点调用”的老路。4.2 调度器的实现骨架调度器本质上是一个状态机。每次状态切换发出一个Modbus请求请求的发送是异步的发出去之后不阻塞等待而是注册一个超时定时器然后在接收回调里检查响应是否匹配当前事务ID。这里我直接给一个简化但能跑起来的框架。核心是把“发请求”和“处理响应”分开用状态变量记录当前正在等待响应的事务号typedef enum { SM_IDLE, SM_WAIT_RESP } sch_state_t; typedef struct { uint8_t unit_id; uint16_t start_addr; uint16_t count; uint32_t period_ticks; uint32_t last_ticks; } slice_req_t;void scheduler_poll(void) { if (sch_state SM_IDLE) { slice_req_t *req pick_next_slice(); // 按优先级和周期选一个分片 if (req) { build_mbtcp_req(req); // 组包 send_req(req); // 发TCP报文 start_resp_timer(200); // 200ms超时 sch_state SM_WAIT_RESP; } } }接收处理则在TCP回调里做。判断响应的事务ID是不是自己刚刚发出的那一个是的话就进入缓存更新。这里有个容易踩的坑Modbus TCP允许在同一个TCP连接上多发请求而不等响应也就是“流水线模式”协议本身是支持的。但很多相对简陋的从站实现并不能正确处理这种并发它们往往在硬件层面只保留一个请求缓冲区新请求一来就把之前的响应覆盖了。所以我在代码里特意保持了“一请求一等待”的串行模式宁肯效率低一点也要保证稳妥。4.3 缓存更新的关键操作响应报文进入缓存前一定要做校验。CRC是不需要的TCP本身有校验但需要检查功能码是否带错误位第7位。Modbus的错误响应帧功能码会置上最高位比如0x83就表示读保持寄存器请求失败这时候数据区带的是异常码千万不要当成正常数据往缓存里写。正常的更新流程是这样找到响应对应的分片信息根据该分片的起始地址把数据逐个写入缓存主数组对应位置最后更新时间戳。这里要考虑字节序对齐的问题——Modbus寄存器传输是大端字节序而ESP32的CPU是小端字节序。如果直接按uint16_t指针强转你会发现高字节和低字节反了。void update_cache(slice_req_t *req, uint8_t *raw_data, uint16_t raw_len) { uint16_t cnt raw_len / 2; for (uint16_t i 0; i cnt; i) { uint16_t val (raw_data[2*i] 8) | raw_data[2*i 1]; reg_cache[req-start_addr i] val; } slice_mark_ok(req, get_ticks_now()); }4.4 缓存区向上层开放的接口上层读取数据时不应该直接操作reg_cache数组。一是因为数组下标和Modbus地址的映射逻辑不该散落到各处二是直接操作容易踩到“读的时候正好有分片在写入”的竞态条件。我给上层提供的是这样的接口读一个寄存器返回uint16_t读一个32位值返回uint32_t读一个浮点返回float。内部统一完成地址映射、一致性组合和老化检查。uint16_t reg_get16(uint16_t addr); uint32_t reg_get32(uint16_t addr); float reg_getfloat(uint16_t addr);并发保护用互斥锁但这个锁的粒度要控制好。频繁加锁会影响上层读取性能而实际现场的上层读取频率并不高所以一个全局互斥锁其实开销很小。如果你有高频率采集的场景比如每毫秒都要取值那要么改用无锁环形缓冲要么把缓存区拆成双缓冲。对绝大多数网关类应用来说全局锁就够了别把架构搞复杂。5. 调试实录和问题排查5.1 现象有些分片一直刷新不成功如果缓存区里某几个分片的valid标志一直不置位先别急着怀疑缓存逻辑而是直接抓包看请求有没有发出去、有没有响应。我遇到过一次很典型的情况代码里配置的从站IP和Unit ID都对但就是有一个分片死活读不到数据。抓包后发现每次这个分片发出请求后从站返回的是异常码0x02意思是“非法的数据地址”。查了设备手册才发现那个地址区间只有一半是有意义的另一半是保留区根本不该读。这就不是缓存或调度的问题而是分片规划表里有“空洞”。解决办法也简单把分片规划表按设备的有效地址区间重新划分不要一股脑地从一个基础地址连续读到结束。5.2 现象缓存里的数值莫名其妙跳变跳变一般分两种。一种是单个寄存器跳变比如从9000突然变成0过会儿又恢复。这通常是字节序处理错误或者从站本身在这个地址上放的数据就是两种格式混用。另一种是整个业务变量的跳变比如一个32位累计值偶尔出现大跳变这大概率是跨分片一致性出了问题。排查思路很简单先在抓包里找到这个变量对应的两条读请求的时间差。如果时间差明显大于同一个分片内部的寄存器读取时间那就说明它被拆分了。解决办法就是文章前面说的把同一个逻辑变量的寄存器合并到一个分片或者在应用层做二次校验。5.3 现象断线重连后长时间不恢复Modbus TCP的客户端重连逻辑看起来简单但有几个细节几乎每次都坑到我。第一个是TCP连接的接收超时不复位Socket已经断开了但本地Recv函数还长时间阻塞在那边导致重连逻辑根本走不到。第二个是重连后没有重新发送MBAP头里的事务ID导致从站分不清新旧连接。我的习惯是给每个从站维护一个独立的连接状态机状态包括IDLE、CONNECTING、CONNECTED、WAITING_MBAP。接收超时用软件定时器轮询检测而不是依赖Socket自身的超时时间这样可以把超时控制在几十毫秒级重连响应会敏捷很多。另外断线期间调度器不应该继续往死连接上发请求否则会产生一堆无效报文。我会在连接状态不为CONNECTED时直接跳过对应从站的所有分片连日志都只记一条避免刷屏。5.4 几个偏门但实用的调优经验超时时间的设置要分场景。局域网内正常的Modbus TCP响应2到5毫秒就回来了。但从站是串口转发器带多个RS485设备时串口调度可能会拖到50毫秒以上。所以超时时间不要拍脑袋最好现场实测一般取正常响应时间的3到5倍。比如串口转发场景我往往把超时设到200毫秒直连PLC的话100毫秒就够。ESP32的任务栈也要留足。如果用了FreeRTOS来跑调度器和TCP回调那涉及网络收发和JSON组包的任务栈大小至少给4096字节最好偏大一点。栈溢出在联网程序里表现很隐蔽可能跑几十个小时才随机复位一次查起来特别费劲。还有一个经验是不要在调度器任务里做阻塞式打印。日志打印走串口是有I/O延时的一旦打印量大了会影响整个轮询周期。我有段时间现场设备偶发性卡顿最后定位到就是调试日志打得太频繁把调度节奏拖乱了。5.5 现场偶发超时的排查流程如果你遇到“偶尔有几帧没响应”的情况我的排查顺序是这样的先看是否所有从站都超时如果是问题大概率在交换机和网关自身再看是否只有特定从站超时那就需要确认这个从站的Modbus实现有多少个并发处理能力最后看超时发生的时间特点如果固定每隔一段时间就超时一次多半是有外部干扰或WiFi信号周期性问题。我这里说的都是自己摸过的坑不一定适合所有现场但思路是通用的先把“缓存机制”和“网络问题”分开。缓存可能掩盖网络抖动但掩盖不代表解决。真正常态化运行的采集网关还是要靠日志记录每帧的耗时分布对规律性的延迟异常有预判能力。6. 一点个人体会整套方案做下来我最深的感受是ESP32作为采集网关硬件性能不是瓶颈真正的瓶颈在设计思路和软件的稳健性。分片缓存这种东西单独看都不是新概念但它放在资源有限的ESP32上要考虑内存占用、轮询周期、片上一致性每个环节都是一分钱一分货的取舍。如果后续要扩展我第一个想加的方向是“变化上报”。目前的缓存区是所有数据周期刷新但很多点位其实长期不变重复上报完全是浪费带宽。在缓存写入时做一层变化检测只有变化超过阈值才触发上报能大幅降低云平台流量。另一个方向是缓存区支持“秒级快照”便于设备重启后的状态恢复这也是很多项目里常见的需求。先把分片和缓存的地基打牢这些扩展就都只是在上面加业务逻辑的事。
