diesel_generator.c

源文件路径：midware/meter/diesel_generator.c 所属模块：midware/meter（电表/油机中间件） 代码行数：337

1. 文件职责

本文件实现油机（柴油发电机组）控制器的 Modbus RTU 数据轮询。油机控制器（Genset Controller，从站地址 99）挂在与电表同一条 RS485 总线上（由 usart1 承载），EMS 通过标准 Modbus 功能码 0x03（读保持寄存器）周期性读取四段寄存器：Page 4 基础仪表、Page 5 扩展仪表、Page 7 累积仪表、Page 154 告警状态。

数据流向：genset_comm_handle() 被 midware/meter/meter.c:5876 的 task_meter() 循环每轮调用一次，函数内部按 500ms 节拍轮流发起一次查询，把响应解析进全局表 g_t_diesel_gen；net/ems.c 的 STATUS_SEND_GENSET_DATA 报文（net/ems.c:1585-1617）再把这些字段上报云端。

本文件只有采集和"通讯丢失清零"两类职责，不参与任何能量调度决策——全工程检索表明 g_t_diesel_gen 只被 net/ems.c 读取用于上报，logic/ 层不引用其数据。油机的启停/带载由硬件或人工控制，EMS 侧只做监视。

2. 关键数据结构与宏

GENSET_RUN_TABLE_T 字段（diesel_generator.h:50）

3. 函数清单

本文件另在 :25-30 有 6 行前置声明（4 个页查询 + send_query_genset_command + genset_run_data_clear）。

4. 核心逻辑解析

4.1 调度与状态机（genset_comm_handle()，:296）

每轮 task_meter() 调用一次
      │
      ├─ genset_enable_flag == FALSE ──► u32_get_data_last_time = now
      │                                  （若此前在通讯中，调 genset_run_data_clear()）
      │
      └─ TRUE
           ├─ (now - u32_dg_query_tick) >= 500ms ──► tick = now; send_query_genset_command(); s_genset_comm = TRUE
           │   （若 tick > now，说明 u32 节拍回绕 → tick = now）
           │
           └─ (now - u32_get_data_last_time) >= 15000ms ──► last_time = now
                                                            若 s_genset_comm == TRUE → 清数据并置 FALSE

要点：

• 轮询节拍：u32_dg_query_tick 记录上次"决定查询"的时刻，abs(OSTimeGet() - tick) >= 500 才发起下一次查询。由于 4 个页依次轮询，一个完整循环（4 个页）周期约 2 秒（500ms × 4，再加各页阻塞收发耗时）。因此油机数据的最坏刷新延迟约 2 秒。
• 节拍回绕保护：if (u32_dg_query_tick > OSTimeGet()) → tick = now。OSTimeGet() 是 uCOS-II 的 32 位 ms 节拍，约 49.7 天回绕一次；这个分支专门处理回绕，避免长时间停止轮询。
• 通讯丢失判定：u32_get_data_last_time 只在任一页查询收到长度与字节数都匹配的响应时被刷新（四个页查询函数里都有 g_t_diesel_gen.t_dg_ctrl_cmd.u32_get_data_last_time = OSTimeGet();）。15 秒内没有任何一页成功，且本机确实发起过查询（s_u8_genset_comm == TRUE），才调用 genset_run_data_clear() 把数据清零。s_u8_genset_comm 的作用是避免"从未通讯过"时就清零（清一次即可，不用反复清）。
• 失能处理：u8_genset_enable_flag == FALSE 时每轮都把 u32_get_data_last_time 刷成当前时刻（防止重新使能瞬间触发丢失判定），若之前处于通讯中则清一次数据。
• 无重试机制：单页查询失败不做重发，只是该页数据保持旧值；下一轮调度会跳到下一页，等 4 帧后（约 2 秒）才再次轮到它。

4.2 帧格式（Modbus RTU，四个查询函数结构相同）

请求帧（8 字节）

组帧实现：先在 6 字节的 query_genset_cmd[6] 里拼载荷，memcpy 到 l_u8_tx_buf[8]，再 GetCrcCode_Modbus(l_u8_tx_buf, 6) 追加 CRC。

响应帧（标准 Modbus 0x03 响应）

响应有效性判定（四个函数一致，以 Page 4 为例，:59）：

if ((l_u16_recv_num > 0) && (g_u8_recv_buf[2] == DG_PAGE_4_A0_33_REG_NUM*2))

即仅校验"收到了数据"且"字节数字段等于期望值"，不校验从站地址、功能码，也不校验帧总长。CRC 校验在 meter_recv_data()（meter.c:66）内部完成。

四个页的请求参数与解析偏移：

所有 32bit 量的拼接方式统一为 (b0<<24)|(b1<<16)|(b2<<8)|b3（大端），存进 u32；有功功率额外做 (s32) 强转保留符号。

4.3 页轮询（send_query_genset_command()，:228）

static u8 g_u8_query_dg_cmd = PAGE_N_MAX_E;   // 静态游标，初值 5
if (g_u8_query_dg_cmd >= PAGE_N_MAX_E)  g_u8_query_dg_cmd = PAGE_4_BASIC_E;  // 回到第 1 页
else                                    g_u8_query_dg_cmd++;
switch (g_u8_query_dg_cmd) { case 1..4: 调对应页查询; default: 游标复位; }

• 游标用"先自增/复位、再 switch"的方式实现环形轮询，顺序固定为 Page 4 → 5 → 7 → 154 → 4…。
• default 分支把游标置回 PAGE_N_MAX_E（5），下一轮即从 Page 4 重新开始，属于防御性兜底。
• 该函数是阻塞的：每个页查询内部完成一次完整的 Modbus 事务（写 + 读），因此在 task_meter() 的单次调用里最多消耗一次总线事务时间。

4.4 数据清零（genset_run_data_clear()，:267）

逐字段赋值 0，最后把 8 个告警字都置为 4369：

for (u8 i = 0; i < 8; i++) g_t_diesel_gen.t_dg_run_data.u16_alarm[i] = 4369;

4369 = 0x1111，是"告警数据无效"的魔数标记（云端借此区分"确实无告警（0）"与"通讯丢失（0x1111）"）。函数不清 t_dg_ctrl_cmd（节拍字段由调用方维护）。

4.5 与 uCOS-II 的配合

• 本文件不使用信号量、互斥量或消息邮箱，所有时序靠 OSTimeGet() 读取的 32 位毫秒节拍做非阻塞比较。
• 唯一的阻塞点是底层 usart1_send_data()（超时 1000ms，见 meter.c:57）与 meter_recv_data()。meter_recv_data() 是非阻塞轮询：只有 usart1_is_recv_async_data() 为真时才读取并把 *len 写成实际长度，否则立刻把 *len = 0（meter.c:110）。因此油机查询不会长时间挂在接收等待上，这依赖上一轮的响应已经完整落到 USART1 接收缓冲——也就是说油机查询实际上依赖"500ms 轮询周期 > Modbus 事务往返时间"这一隐含时序假设。
• 任务上下文：唯一的调用方是 task_meter()（由 user/main.c 静态创建的电表任务），其循环体尾部有 OSTimeDlyHMSM(0,0,0,300) 延时（meter.c:5881）与 IWDG_Feed()。

4.6 关键全局变量的读写

5. 对外接口

导出（供外部调用）

调用（依赖的外部函数/变量）

6. 依赖关系

• 依赖：diesel_generator.h、includes.h、midware/meter/meter.h（电表总线读写与配置结构）、common/crc.h（Modbus CRC16）。
• 被依赖：
  • midware/meter/meter.c:5876（唯一调用 genset_comm_handle() 的地方）。
  • net/ems.c:1585-1617（读 g_t_diesel_gen 组 CMD_SEND_GENSET_DATA 报文）、net/ems.c:5021（用 u8_genset_enable_flag 决定上报时机，间隔 300 个 RTC 节拍）。
  • net/server.c、hmi/key.c、midware/interface/modbus/modbus.c 通过 u8_genset_enable_flag 间接参与（不含 g_t_diesel_gen 数据）。

7. 备注与风险点

1. 响应长度未校验，存在越界读风险——四个查询函数只检查 g_u8_recv_buf[2] 等于期望字节数，然后直接索引到 g_u8_recv_buf[70]（Page 4）。虽然 g_u8_recv_buf 有 256 字节（meter.h:92）不会越界读内存，但会把上一帧的残留数据当成本帧数据解析：meter_recv_data() 只在 CRC 正确时把 *len 设为实际长度，而查询函数传入的 l_u16_recv_num 被置为非 0 后就完全不使用它做长度比对。正确做法是同时校验 l_u16_recv_num >= 3 + 期望字节数 + 2。
2. 不校验从站地址与功能码——:59 的条件里没有 g_u8_recv_buf[0] == GENSET_ADDR 和 g_u8_recv_buf[1] == 0x03。异常响应帧（addr + 0x83 + 异常码 + CRC）的 buf[2] 是异常码，恰好等于 68/4/8/18 的概率极低，所以实际风险有限，但这是协议实现上的薄弱点。
3. 拷贝全局接收缓冲导致耦合——四个页查询都直接使用 g_u8_recv_buf（电表模块的全局缓冲）而不做深拷贝。任何在油机查询之后、解析之前插入的其他总线事务都会污染数据（当前调用序列中不存在这种情况，属潜在脆弱点）。
4. p4 页首寄存器被跳过——Page 154（9 个寄存器）的 8 个告警字取自 buf[5..20]，即跳过第 0 个寄存器（A0）。从命名与实现看 A0 可能是"运行状态字"而非告警位，但代码中没有任何注释说明，属寄存器映射未文档化的隐患。
5. u8_genset_enable_flag 从 HMI/Modbus 写入时无互斥——该字段由其他任务写入（hmi/key.c、modbus.c），本文件在 task_meter() 中读取；理论上存在读到中间态的可能（u8 单字节读写在本平台是原子的，实际安全）。
6. 失能不清 u32_dg_query_tick——重新使能后，若 u32_dg_query_tick 停留在很久以前，第一次调用会立即发起查询（这是期望行为），但如果停留在"未来"（节拍回绕后残留），会走 tick > now 分支重设，行为正确。
7. 响应延迟假设——meter_recv_data() 是非阻塞的，因此油机查询在"响应尚未到达"时会静默失败并把该页数据保留旧值。500ms 的 DG_QUERY_SPEED_VALUE 是唯一保证，代码里没有任何显式的"等待响应"或"失败重发"逻辑。若总线负载加重（电表查询与油机查询共用 usart1），这一假设可能不成立。
8. 魔数——:286 的告警填值 4369(0x1111) 无宏定义、无注释；:154/:175 的寄存器地址用 page*256+n 的算术写法，隐含"页号高字节编码"这一非标准 Modbus 约定，需对照油机控制器手册才能确认。
9. 代码重复严重——四个页查询函数结构几乎完全相同（组帧 → 发送 → 校验 → 逐字段挑字节），只有寄存器地址/个数/解析偏移不同；单帧接收解析逻辑可用表驱动，现实现使得新增一页必须复制约 50 行代码。
10. l_u8_tx_buf[8] + query_genset_cmd[6] 冗余——先填 6 字节数组再 memcpy 到 8 字节数组，多一次拷贝，没有实际必要。
11. printf 调试分支保留但关闭——GENSET_DEBUG_INFO 为 0，printf 会被预处理器剔除，不影响运行；但四个函数各有 12 行的 printf 块，占源码篇幅较大。