简介：这份奥的斯电梯主板参数资料面向电梯维保人员、控制系统调试工程师及电梯相关专业学习者，用于快速查阅主板各输入输出端口的定义与功能。内容围绕电梯控制系统的核心逻辑展开，涵盖开门极限、开关门按钮、电子门保护、负荷称重、独立服务开关、消防与应急电源操作、轿厢上下行指示、蜂鸣器、照明控制、厅门与轿厢按钮灯、楼层选择指示及故障检测等典型信号，并标注了符号、类型与位置信息，便于对照现场接线与排查故障。资源包共1个doc文件，约511KB，以表格化参数清单形式呈现，适合打印或随工携带查阅。目前已有187人学习下载，可作为电梯主板调试、维保培训及控制系统认知的实用参考。
1. 从一份 IO 表看懂奥的斯电梯主板参数
很多人第一次拿到《奥的斯电梯主板参数.doc》，会以为它是一份“配置手册”，翻两页就发现全是DOL、DOB、EDP、CB/CTTL这类符号，后面还跟着一串像5321/0、0830/0的地址码。它其实是一份IO 点表：把主板每一个输入/输出端子的符号名、中文含义、默认状态、类型（输入/输出/双向）、物理位置（轿厢/轿底/外呼/机房）逐条列出来。电梯能不能正常开关门、响应外呼、做消防迫降、报过载，全看这张表里哪一位被点亮、哪一位被读错。
这份资料适合三类人：做电梯维保、调试的现场工程师，需要按点位排查故障；做楼宇自控、弱电集成的开发者，要把电梯状态接进自己的系统；还有做工业协议解析、想把点表转成结构化数据的程序员。它不教你怎么写程序，但它是所有上层逻辑的“字典”——没有它，你连LWO是负荷称重过载都不知道，更别提判断是称重传感器坏了还是主板输入口坏了。
2. IO 点表结构拆解：符号、类型、位置与地址码
2.1 一行点表到底包含哪些字段
把原文里任意一行拆开看，比如：
5 LWO 负荷称重过载 1330/0 输入 轿底它对应五个语义字段：
| 字段 | 示例 | 含义 |
|---|---|---|
| 序号 | 5 | 点表行号，方便口头对号 |
| 符号 | LWO | 主板内部变量名，程序里直接引用 |
| 描述 | 负荷称重过载 | 中文功能说明 |
| 地址/默认 | 1330/0 | 物理地址 + 默认电平 |
| 类型 | 输入 | 输入/输出/入出（双向） |
| 位置 | 轿底 | 该点所在物理区域 |
地址码1330/0这种写法，常见做法是把它理解成“板号+端口+位”的压缩编码：前几位定位到某块 IO 板或某个连接器，后两位定位到具体端子，斜杠后的0表示默认低电平、1表示默认高电平。不同版本的主板编码规则会有差异，但“先定位板、再定位位”这个思路是通用的。
2.2 输入、输出、双向三类的判断逻辑
点表里类型只有三种：输入、输出、入/出。判断依据很直接——信号流向。
- 输入：传感器、按钮、开关把状态送给主板。比如
DOL开门极限、DOB开门按钮、ISS独立服务开关。 - 输出：主板驱动指示灯、继电器、照明。比如
CUDL轿厢上行指示灯、BUZ蜂鸣器、FSL消防照明。 - 入/出：同一根线既读状态又驱动灯，典型就是按钮。
CB/CTTL 0轿厢按钮/按钮灯，按下时主板读到输入，同时输出点亮按钮灯。
提示：双向点排查故障时最容易误判。按钮灯不亮，可能是输出驱动坏了，也可能是输入回路断开导致主板认为按钮没接。先量线，再换板。
2.3 位置字段决定排查动线
位置字段把点分到轿厢、轿底、外呼、机房四类。现场排查时，这个字段直接决定你该去哪个位置：
- 轿厢：门机、按钮、照明、指示。
- 轿底：称重、防犯罪开关。
- 外呼：厅门按钮、厅门灯、消防开关。
- 机房：呼梯到顶层/底层、应急电源操作。
一个LWO过载误报，你不需要爬轿顶，直接去轿底查称重；一个EFK消防钥匙开关无效，去外呼面板而不是机房。位置字段就是排查地图。
2.4 用脚本把点表转成结构化数据
原文是 Word 文档，直接程序读取很痛苦。常见做法是先复制成纯文本，再用脚本按行解析。下面这段 Python 把“序号 符号 描述 地址/默认 类型 位置”拆成字典：
import re # 原始点表文本，每行形如：5 LWO 负荷称重过载 1330/0 输入 轿底 raw_lines = [ "5 LWO 负荷称重过载 1330/0 输入 轿底", "0 DOL 开门极限 5321/0 输入 轿厢", "20 CUDL 轿厢上行指示灯 051 输出 轿厢", ] # 用两个以上空格或制表符切分，避免描述里的空格被误切 pattern = re.compile(r"\s{2,}|\t+") points = [] for line in raw_lines: parts = [p.strip() for p in pattern.split(line.strip()) if p.strip()] if len(parts) < 6: continue # 跳过表头、空行、分隔线 points.append({ "no": parts[0], "symbol": parts[1], "desc": parts[2], "addr": parts[3], "type": parts[4], "location": parts[5], }) for p in points: print(p["symbol"], "->", p["location"], p["type"])逻辑说明：re.split用“两个及以上空格”作为分隔符，是因为符号和描述之间、描述和地址之间通常有多个空格对齐，而描述内部是单个空格。参数上，\s{2,}匹配连续空白，\t+兼容从 Word 复制出来的制表符。如果某行字段数不足 6，说明是表头或空行，直接跳过。跑完你就能按location或type过滤，比如筛出所有“轿底”的输入点做专项检查。
3. 按功能域读点表：门、称重、消防与应急
3.1 门系统相关点位
门系统是电梯故障率最高的部分，点表里相关符号集中在开头：
| 符号 | 描述 | 类型 | 位置 |
|---|---|---|---|
| DOL | 开门极限 | 输入 | 轿厢 |
| DOB | 开门按钮 | 输入 | 轿厢 |
| DCB | 关门按钮 | 输入 | 轿厢 |
| EDP | 电子门保护装置 | 输入 | 轿厢 |
| NDG | 碰板继电器 | 输出 | 轿厢 |
DOL是开门到位信号，主板靠它确认门已完全打开；EDP是电子门保护（光幕类），门区有人或物时它会动作，主板据此重新开门。排查“门关不上”时，先看DCB有没有被按下、EDP是否一直处于保护状态、DOL是否卡在动作位。常见误判是把EDP常亮当成光幕坏，其实可能是光幕被灰尘遮挡或供电不足。
3.2 称重与超载点位
轿底两个点最关键：
LWO负荷称重过载：称重装置判断超载时动作。LWX / ACSANS负荷称重/防犯罪开关：兼顾称重和防犯罪功能。
超载误报的排查顺序，我一般这样走：先确认轿底称重传感器供电和信号线，再看LWO在空载时是否已经动作（正常应不动作），最后才怀疑主板输入口。因为LWO是输入点，主板只是“读”，它读到动作才报超载，问题多半在传感器侧。
3.3 消防、应急与独立服务
消防和应急相关点位分散在机房和外呼：
EFK紧急/消防钥匙开关（外呼）FSL消防照明（输出，轿厢）NU应急电源操作（机房）NUSD / NUSD-1应急电源紧急操作（机房，入/出）NUG / NUG-1应急电源正常操作（机房，入/出）ISS独立服务开关（轿厢）
消防迫降逻辑通常是：EFK动作后，主板忽略内呼、响应外呼到指定层、开门停靠。如果消防开关动作但电梯不迫降，先确认EFK输入点是否真的被主板读到——用主板调试口或状态灯看该位，而不是只看开关外观。
3.4 用过滤脚本快速定位某功能域
现场没时间逐行翻，用上一节的解析结果按关键词过滤：
# 承接上文的 points 列表 keywords = ["消防", "应急", "称重", "门"] for kw in keywords: print(f"=== {kw} ===") for p in points: if kw in p["desc"]: print(f'{p["symbol"]:12} {p["desc"]:16} {p["type"]} {p["location"]}')逻辑说明：desc是中文描述字段，直接做子串匹配最省事。参数keywords可以按当天故障类型临时改，比如查“平层”就加"平层"。输出用固定宽度格式化，方便直接抄到工单上。这个脚本的价值在于：把 300 多行点表压缩成你当前关心的十几行。
4. 从点表到调试：地址码核对与常见误判
4.1 地址码与默认电平的核对方法
地址码斜杠后的默认电平，是判断“这个点空闲时应该是什么状态”的依据。比如DOL是5321/0，默认0，意味着门未开到位时该点为低；门开到位动作后变高。如果你在门完全打开时量到它还是低，要么是极限开关没触发，要么是线路断。
核对步骤：
- 从点表查出目标符号的地址码和默认电平。
- 在主板对应端子或调试界面找到该位。
- 让电梯处于该点“未动作”状态，确认读数等于默认电平。
- 手动触发该点（按按钮、挡光幕、压称重），确认读数翻转。
注意：不同批次主板的地址编码可能不同，点表里的地址码要和实物主板版本对上。拿错版本的点表去核对，会把好板判成坏板。
4.2 按钮灯不亮的三层排查
以CB/CTTL系列为例，按钮灯不亮按三层走：
- 第一层，输入：按下按钮，主板是否读到该位翻转。读不到，查按钮到主板的线。
- 第二层，输出：主板是否输出点亮信号。有输入无输出，查输出驱动或该位是否被程序屏蔽。
- 第三层，灯本身：输出正常但灯不亮，换灯板或查灯供电。
这三层顺序不能反。很多人一上来就换灯板，结果线断了，换十个灯也不亮。
4.3 外呼与厅门灯的批量点位规律
点表里UHB/UHTTL 0~31、HB/HBTTL 0~31、UHL 0~31、DHL 0~31是成组的，编号对应楼层。这种批量点位有个规律：编号连续、地址码也连续。排查某一层外呼不亮时，先看是不是只有这一层，还是连续几层都不亮。连续几层不亮，多半是那几层的公共线或某块扩展板；单层不亮，才是该层按钮或灯的问题。
4.4 把点表当回归清单用
调试完成后，我习惯把点表当回归清单：按位置分组，逐条触发并确认主板状态翻转。轿厢组、轿底组、外呼组、机房组各过一遍，比随机抽查靠谱。尤其是消防、应急、称重这几类低频动作点，平时不动作，一旦真需要时才发现坏了，代价很大。
5. 进阶：把 IO 点表接进自控系统的实践技巧
5.1 点表转 JSON 供上层系统消费
如果要把电梯状态接进楼宇自控或监控平台，第一步是把点表转成 JSON，让上层按符号名取值：
import json # 承接前文 points，转成以 symbol 为键的字典 point_map = {p["symbol"]: p for p in points} with open("otis_io_points.json", "w", encoding="utf-8") as f: json.dump(point_map, f, ensure_ascii=False, indent=2) # 上层取值示例 print(point_map["LWO"]["desc"]) # 负荷称重过载 print(point_map["DOL"]["type"]) # 输入逻辑说明：以symbol为键，是因为程序里引用符号比引用中文描述稳定。ensure_ascii=False保证中文正常写入，indent=2方便人工查看。转成 JSON 后，采集程序只需按符号名映射到实际寄存器地址，点表变更时改 JSON 即可，不用改代码。
5.2 采集时的去抖与状态确认
电梯 IO 点抖动很常见，按钮、光幕、称重都可能瞬间跳变。采集侧要做去抖：
import time def read_stable(read_func, stable_ms=200, samples=3): """连续 samples 次读到相同值才认为稳定""" last = None count = 0 while count < samples: val = read_func() if val == last: count += 1 else: last = val count = 1 time.sleep(stable_ms / 1000.0) return last逻辑说明：read_func是实际读取该点的函数，stable_ms是采样间隔，samples是连续一致次数。三个参数按现场噪声调：噪声大就加大samples，要求响应快就减小stable_ms。去抖做在采集侧，比事后在平台侧过滤更省事。
5.3 点表版本管理的一个实用习惯
点表会随主板程序升级变化，符号增删、地址调整都可能。我一般把每次拿到的点表转成 JSON 后，用 Git 管理，提交信息写清主板版本和日期。这样某天现场行为异常时，能快速 diff 出是哪个点变了。比起在 Word 里翻修订记录，diff JSON 直观得多。
5.4 一个具体技巧：用符号前缀快速分组
点表符号有明显前缀规律：CB/CTTL是轿厢按钮，UHB/UHTTL是上行外呼，HB/HBTTL是下行外呼，UHL/DHL是厅门灯，EHC/ETTL是紧急预案服务门，FPD是防火门，CPC是甲方消防反应，RCB/RCTTL是后门轿厢按钮。按前缀分组，能快速统计每类点的数量，也能在采集程序里按前缀批量映射：
from collections import defaultdict groups = defaultdict(list) for p in points: prefix = p["symbol"].split()[0].split("/")[0] groups[prefix].append(p["symbol"]) for prefix, syms in groups.items(): print(f"{prefix}: {len(syms)} 个点")逻辑说明：split()[0]取符号第一个词，split("/")[0]再去掉斜杠后的别名部分，得到纯前缀。defaultdict(list)省去判空。跑完你会看到CB、UHB、HB、UHL、DHL各 32 个点，EHC、FPD、CPC各 32 个点，RCB28 个点——这些数量本身就是核对点表完整性的依据，少一个就说明复制或解析漏了。
本文还有配套的精品资源，点击获取
