Prechádzať zdrojové kódy

oem_scan 侧反推: 分母已齐(理论表+速比) / 分子缺(峰值拾取口径) + 一处文档与实现的差异(速比 119.75≠119.752)

这一族(约 23 件测量形态件)有标准答案, 所以能反推:
· 比值语义确认: bearing_freq_scan 的 FTF/BSF/BPFO/BPFI/边带 与 gear_freq_scan 的 GMF_*/IMS_1x/
  rotor_1x/ring2_2R/sun1_1S/carrier2 都是"观测频率 ÷ 理论特征频率" —— 按 component 聚合中位数
  1.00~1.07(HS 轴承边带 1.19/1.20 偏得最多, 正是诊断信息); 同一行里 IMS_1x/rotor_1x/ring2_2R/
  sun1_1S/carrier2 取值相同(同一根轴的 1×), 反证了比值语义。
· 分母齐备: reference/rudong/oem_bearing_freqs.json(29 个轴承条目, 键名 BPFI_Hz/BPFO_Hz/BSF_Hz/
  ORF_Hz/shaft_Hz) + gear_mesh_map_measured.json(shafts_Hz / gear_mesh_Hz / stage_ratios 乘积
  119.752 = 铭牌)。
· 运动学口径 + 一处文档与实现的差异: blade_1p_records 的 f1P = 发电机转速 ÷ 速比 ÷ 60, 而由 662 行
  样件反解出的等效速比精确等于 119.75(均值 119.750000 / 标准差 4.6e-15 / 逐台恒定), 不是机型常量
  119.752。照文档写会整体偏 1.7e-5 相对量 —— 这正是第一次对拍看到 3.7e-6 绝对偏差的来源。
  只有反解样件才看得出来, 文档里读不到。
· 仍缺: 分子 = "在谱里怎么取观测峰"(带宽/按什么量取最大/是否插值/是否阶次跟踪/多记录怎么合并) ——
  即缺的 rudong_tcm_oem_scan.py 的核心。测试台已备好: bearing_freq_scan 880 行 · gear_freq_scan
  880 行 · cage_slip_scan 3681 行(带 bin 与 n_rec, ftf_amp 是幅值)。
· 据此收窄取料单第 1 项: 源码仍是首选, 但只问一句话也行 —— 理论频率附近怎么取观测峰?
docs/振动六层链_接口规格与缺口_v0.1.md 增 §7(分母/分子/速比差异/收窄后的问法)。
zhouyang.xie 3 týždňov pred
rodič
commit
da2aeb9a40

+ 1 - 1
docs/向振动线取料单_v0.1.md

@@ -14,7 +14,7 @@
 
 | # | 要的东西 | 现状 | 拿到后解锁 |
 |---|---|---|---|
-| 1 | `scripts/rudong_tcm_oem_scan.py` | 缺 | 轴承/齿轮/保持架/叶片 1P 的**特征频率扫描**(约 23 件扫描件可从"✗ 无生成端"转成"✓ 已在重算链上") |
+| 1 | `scripts/rudong_tcm_oem_scan.py` | 缺 | 轴承/齿轮/保持架/叶片 1P 的**特征频率扫描**(约 23 件扫描件可从"✗ 无生成端"转成"✓ 已在重算链上")。★ **只要一句话也能推进**:在理论特征频率附近**怎么取观测峰**(带宽 ±?% / 按幅值还是能量取最大 / 是否插值 / 是否按 rpm 阶次跟踪 / 多记录怎么合并)—— 分母(理论频率表 + 转速换算)包内已齐、比值语义已确认,缺的只有这一步(见规格书 §7) |
 | 2 | `scripts/rudong_line_energy_share.py` | 缺 | 线能量占比(对应产物名待你确认,包内未见同名件) |
 | 3 | `scripts/rudong_model_run.py` | 缺 | `model_run_l6.parquet` + `model_run_summary.json`(六层模型的第六层出件) |
 | 4 | `scripts/rudong_fusion_run.py` | 缺(**本包已逆向实现了一件**,见下) | `fusion_38.csv` + `fleet_scalar_z.parquet` 等融合面产物 |

+ 50 - 1
docs/振动六层链_接口规格与缺口_v0.1.md

@@ -73,7 +73,51 @@ python.exe: can't open file '…\scripts\rudong_model_run.py': [Errno 2] No such
 3. 在那之前,系统按现口径如实呈现:这 36 件(`vib_handoff_and_scans` 里非人工的那部分)标 **✗ 无生成端**,
    页面缺件时给结构化说明(不静默、不造数、不从交付包补)。
 
-> 台账现状(2026-09-17):✓ 呼应成立 1742 件 · ✗ 无生成端 285 件 · ◆ 人工件 209 件 · 无法验证 0 · 未归类 0。
+## 7. `oem_scan` 侧:**分母已齐、分子缺**(2026-09-17 反推)
+
+用户令之后的继续推进。这一族(约 23 件测量形态件)**有标准答案**(随包件在盘上),所以可以反推;
+本轮把"哪些部分已经确定、还缺哪一步"钉成了结论。
+
+### 7.1 已确定:扫描列是"观测 / 理论"的比值,**理论侧(分母)包内齐备**
+
+- `bearing_freq_scan.parquet` 的列 `FTF/BSF/BPFO/BPFI/BSF_2x/BPFI_sb/BPFO_sb`,按 `component`
+  聚合后的中位数 ≈ **1.00–1.07**(`GEN_bearing` 1.0018–1.0382;`HS_bearing` 的边带/2×BSF 达 1.19–1.20)
+  ⇒ 明确是"观测频率 ÷ 理论特征频率"。偏离 1 的部分正是诊断信息(HS 轴承边带偏得最多)。
+- `gear_freq_scan.parquet` 同理;同一行里 `IMS_1x / rotor_1x / ring2_2R / sun1_1S / carrier2` **取值相同**
+  —— 因为它们都是**同一根轴的 1×**,比值自然一致(这也反过来印证了"比值"语义)。
+- 分母(理论频率)在包内且是"实机/OEM 参数表"级别:
+  `reference/rudong/oem_bearing_freqs.json`(29 个轴承条目,键名 `BPFI_Hz/BPFO_Hz/BSF_Hz/ORF_Hz/shaft_Hz`,
+  例:`2nd Stage Planetary Section#0 → BPFI 23.8 / BPFO 17.0 / BSF 7.5 Hz`,型号码 `NSK LV220-2/…`);
+  `reference/rudong/gear_mesh_map_measured.json`(`shafts_Hz` HSS 25.0 / IMS 7.08 / C2 1.67 / LSS 0.20876;
+  `gear_mesh_Hz` GMF1 19.219 / GMF2 151.56 / GMF3 750.0;`stage_ratios` 乘积 **119.752 = 铭牌**)。
+
+### 7.2 已确定的运动学口径(含一处**文档与实现的差异**)
+
+`blade_1p_records.parquet` 的 `f1P`(转子 1P 频率)= **发电机转速 ÷ 速比 ÷ 60**,而由 662 行样件反解出的
+**等效速比精确等于 `119.75`**(均值 119.750000、标准差 4.6e-15、逐台恒定),**不是**机型常量/铭牌上的
+`119.752`。
+
+⇒ 实现时必须用 **119.75**(若照文档写 119.752,`f1P` 会整体偏 1.7e-5 相对量 —— 这正是我第一次对拍看到
+3.7e-6 绝对偏差的来源)。这条差异只有靠"反解样件"才看得出来,文档里读不到。
+
+### 7.3 仍然缺的:**分子** —— "在谱里怎么取观测峰"
+
+要复现这些列,必须在每个理论频率附近从 FFT 谱里取出"观测频率"。这一步的口径(**带宽多大、取什么量最大、
+要不要抛物线插值、是否按转速做阶次跟踪、多窗/多记录怎么合并**)就是缺的
+`scripts/rudong_tcm_oem_scan.py` 的核心,也是**唯一还没确定的部分**。
+
+已备好的测试台:880 行 `bearing_freq_scan` / 880 行 `gear_freq_scan` / 3681 行 `cage_slip_scan`
+(后者还带 `bin` 功率分箱与 `n_rec` 记录数,`ftf_amp` 是幅值)—— 口径一旦给出,逐值对拍可以立刻做。
+
+### 7.4 对取料单的**收窄**(这条很实用)
+
+原本向振动线要"整个 `rudong_tcm_oem_scan.py`";现在可以**只问一句话**:
+
+> **在理论特征频率附近怎么取观测峰?**(带宽 ±?%、按幅值还是按能量取最大、是否插值校正、是否按 rpm 阶次跟踪、多记录如何合并)
+
+拿到这句话,配上包内已有的理论表与转速,这一族就能照 `temp_monthly` / `fleet_scalar_z` 的老办法
+(反推 → 逐值对拍 → 一致才敢用)转成"✓ 已在重算链上"。**源码仍是首选**(省一轮试错),但不再是唯一路径。
+
 
 ---
 
@@ -161,3 +205,8 @@ MAD=0.80209 → z=−0.3116 · IQR/1.349=1.46899 → z=−0.1701 ·
   ③ `fusion_38.csv` 无标准答案,需振动线给一份历史产出(或那四个脚本的源码)。
 
 
+
+---
+
+> 台账现状(2026-09-17):✓ 呼应成立 1742 件 · ✗ 无生成端 285 件 · ◆ 人工件 209 件 · 无法验证 0 · 未归类 0。
+> 缺料自查:`python scripts/chain_gap_check.py --check`;取料单:`docs/向振动线取料单_v0.1.md`。