简介：面向数控车床初学者、在线操机员及维修人员的一份信号采集参考文档，聚焦广数980TD系列在机床控制中的信号线定义、线号识别与基础接线逻辑，适合用于日常查阅、上机核对和故障排查。包内为1个docx文件，约814KB，内容围绕980TDi与980TDc两种型号展开，说明两者在机床信号输出配置上的共同点，并重点整理62A输出接插件的IO输出对应关系：Y2.5运行对应34号、Y2.6计数对应35号、Y2.7报警对应36号，同时注明IO采集盒COM端接+24V电源接口。文档把运行、计数与报警信号的用途、常见触发场景及排查关注点放在同一份资料中，便于读者快速对照机床状态、核对线号并定位异常，对报警触发后的原因判断也有参考价值。已有3166人学习，适合需要随手查阅信号定义、缩短故障判断时间的技术人员使用。

1. 反直觉结论：COM 端接 +24V 而不是 0V，决定了整条信号链的极性

在数控车床的信号采集现场，最容易出问题的一步发生在通电那一刻：IO 采集盒的 COM 端该接哪里。按照弱电柜里的习惯思路，公共端接 0V、信号线接正，这几乎是肌肉记忆；但 980TD 系列的信号线定义里写得很清楚，COM 端要接 +24V 电源接口。接错的后果不是采不到数，而是三个点全部读到相反的值，运行灯常亮、报警灯常灭，操作工看着屏幕上“一切正常”的机床发呆。这件事之所以值得详细分析，是因为它反映的是一整套电气约定：机床那侧的输出电路只会把信号线接到 0V，从来不会主动给出 +24V，采集盒必须自己提供这个电势。理解了这一点，Y2.5 运行、Y2.6 计数、Y2.7 报警这三个点位才算是真正通了，而不只是抄了三条信号线定义。

2. 电流回路：从 Y2.5 到采集盒，信号到底怎么“流”过去

2.1 62A 接插件与 Y2.x 的地址映射

980TDi 和 980TDc 两个型号的机床信号输出，都落在同一个 62A 输出接插件上，点位分别是 Y2.5 对应 34 号针、Y2.6 对应 35 号针、Y2.7 对应 36 号针。这组数字不是随便排的：位号连着的三个点，针脚号也是连着的，位号每加一，针脚号也加一。按这个规律往前推，Y2.0 应该落在 29 号针上，Y2.0 到 Y2.7 这一个字节整体占用了 29 到 36 这八个连续的针位。

这个规律背后是一套软硬件对齐的设计。PLC 内部按位元件寻址，八个输出点打包成一个字节；硬件侧对应的是一片八路驱动阵列，或者一组排布整齐的光耦。软件说“第 2 组第 5 位”，电路上说“第 3 片驱动器的第 6 路”，两者用的是同一套坐标。好处很直接：查线时看 PLC 梯形图里的 Y2.6，直接数到 35 号针就行，不需要中间再做一次换算表。代价是这套坐标一经确定就很难改，后来的型号只能沿用，这也是 980TDi 和 980TDc 定义完全一致的原因。

另外，62A 同时承载输入 X 和输出 Y，方向是相反的。常见的实现思路是输入侧光耦的阳极已经内部上拉，外部只需要给一个 0V 就能触发。如果误把 +24V 接到输入针脚上，光耦会反偏，或者直接超过耐压而击穿，这一点在改线时比接错输出严重得多。

提示：上表里 29 号针是根据位号连续性反推出来的，实际接线前仍要以原厂接口图为准，别拿推断当图纸用。

2.2 漏型输出与源型输入：COM 为什么必须落在 +24V

把 COM 接 +24V 这件事说透，关键是搞清楚电流从哪来、往哪去。机床侧的 Y 输出如果是漏型，也就是常说的 NPN 输出，它内部的开关器件一端接在输出端子上，另一端接在板内的 0V 上。这个开关导通时，它做的事情是把输出端子拉到 0V，而不是送出 +24V。它本质上是一个能接负载到地的开关，本身不产生电势。

既然机床不给电势，电势就必须由采集侧提供。COM 接 +24V 之后，完整的回路是这样的：+24V 从电源正极出来，进采集盒的 COM 端，穿过盒内的限流电阻和光耦发光二极管，从某个输入端子出来，沿电缆走到 62A 的 34 号针，进入机床 I/O 板，穿过板上已经导通的三极管或达林顿管，最后落到板内的 0V，回到电源负极。整条链路上没有任何一处需要机床“输出电压”，它只负责把回路闭合。

反过来，如果按习惯把 COM 接到 0V，光耦的发光二极管就处于反偏或者两端等电势的状态，无论机床那侧开关导通还是断开，盒内都不会有电流，采集结果恒为 0。更棘手的情况是 COM 接 0V、机床侧又恰好是源型输出，两边都往同一条线上加电势，那就变成对着电源短路，损坏往往发生在一瞬间。

定义文件里明确写了 COM 接 +24V，等于直接告诉你机床这侧是漏型输出。这条信息比三个点位的名字更有价值，因为它决定了整条链路能不能通。

2.3 光耦、限流电阻与“什么算高电平”

采集盒判断一个点位是否有效，靠的是光耦里的发光二极管是否导通，判断依据是电流，而电压阈值并不是判断标准。24V 加在 2kΩ 的限流电阻上，稳态电流大约 11mA；换成 3.3kΩ 大约 7mA。多数工业光耦的可靠导通区间在 5 到 15mA，两个值都在范围内，但电流越大，光耦的开关速度越快，边沿越陡，抗干扰的余量也越大。这也是为什么有些采集盒在长线场景下会建议把限流电阻调小一档。

这里有一个很能说明问题的现象：拿万用表直流档量 34 号针对 0V 的电压，在机床运行时会读到接近 24V，但采集盒读到的却是 0。原因并不在采集盒坏了；问题在于万用表的内阻极高，它测的是“电势存在与否”，而光耦要的是“电流能不能流过去”。如果 COM 端没有接上 +24V，这条回路根本没闭合，电势悬在那里，表上看得见，光耦里却一点电流都没有。这就解释了为什么“用表量着有电、系统就是采不到”是这类接线事故里最常见的描述。

还有一层容易被忽略的细节：输出断开时，输入端是悬空的，光耦不导通，逻辑上读 0，看起来没问题。但几十米长的电缆在变频器、伺服驱动器旁边走线，悬空端会感应出足以让光耦微微导通的能量，表现就是计数点在机床停机时还在零星跳字。常见的做法是在采集盒输入端和 0V 之间并一个放电电阻，把悬空端钳住，或者在软件侧靠去抖掩盖，前者治本，后者治标。

3. 三个点位的语义差异：运行、计数、报警不是一个读法

3.1 Y2.5 运行：电平型状态量，怕的是抖动不怕慢

运行信号的物理形态是一个长时间保持的电平。机床开始加工时它变为有效，加工结束或者停机时它恢复无效，保持时间从几秒到几十分钟不等，和一个加工循环的长度同量级。这种信号对采样速度几乎没有要求，100ms 甚至 500ms 轮询一次都不会漏掉任何有效信息。

它的风险在另一头，也就是抖动。上电瞬间电源建立过程中，24V 会有一个几十毫秒的斜坡，光耦在阈值附近可能反复导通和截止；急停按下时，接触器断开引起的反电动势同样会让输出端出现毛刺。如果采集侧不做处理，一次正常的上电就会在数据库里写下三五条“启动—停机—启动”的事件记录，班次统计里凭空多出好几次开机。稳妥的做法是给电平型信号配一个 100 到 300ms 的确认窗口：新状态必须连续保持这么久才被接受，短于窗口的跳变一律当作噪声丢弃。

3.2 Y2.6 计数：脉冲型事件量，怕的是漏不怕慢

计数信号完全是另一种东西。它对应的是“发生了一件事”，比如完成一个工件、换了一次刀、走完一个循环。这类信号的物理形态是一个窄脉冲，宽度取决于 PLC 程序里那个输出线圈被保持了几个扫描周期。980TD 这类系统的扫描周期通常在 8 到 20ms 之间，如果程序里是一置位就复位，脉冲宽度就等于一个扫描周期，十来毫秒。

十来毫秒的脉冲，用 100ms 的轮询去抓，命中率全看运气。现场最典型的抱怨是“产量统计比实际少了百分之几”，差得不多，所以很长时间没人怀疑，直到月底盘库对不上才发现。这个问题在软件层面几乎无解：轮询周期必须小于脉冲宽度才可能不漏，而当脉冲宽度本身就是一个扫描周期时，轮询周期得压到毫秒级，那又会让通讯和 CPU 开销变得不可接受。

真正的解法在信号源头。一是让采集盒用硬件计数器，输入侧一旦检测到边沿就在硬件里加一，软件只负责定期读走计数值，脉冲再窄也跑不掉。二是干脆不采这个点，改去读 PLC 内部计数器的当前值寄存器，那是一个单调递增的绝对值，两次读数的差值就是这段时间的产量，天然免疫漏脉冲。后者的前提是机床侧确实配了计数器并且地址开放，这需要在做方案时就确认清楚。

3.3 Y2.7 报警：可能要按失效安全来理解

报警点在语义上最需要小心，因为它涉及一个方向性问题：有效电平到底代表“有报警”还是“没报警”。定义文件只写了 Y2.7 是报警、落在 36 号针，没有写常开还是常闭，这一项必须现场核对。

工业设备的常见做法是失效安全：正常状态下输出保持导通，回路里有电流；一旦出现报警、急停、断线或者整机断电，回路断开。这样设计的好处是“无电流”这个状态天然覆盖了所有异常，包括采集盒自己掉电、电缆被拉断、接插件松动这些机床根本不知道的情况。如果反着设计，正常时无电流、报警时有电流，那么一根断掉的信号线在系统看来就是“永远正常”，这等于把最需要被发现的故障藏了起来。

采集侧的配置必须跟着这个约定走。如果确认是失效安全接法，那么点位定义里的有效电平就要标成低有效（无电流即有效），并且要明确写清楚这是“反逻辑”配置，而不是配置错了。这一条如果漏掉，后面接手的人会以为是 bug，改回去之后报警就再也不响了。

4. 采集侧实现：把三个位变成可信数据

4.1 点位表：用一个数据结构描述整块 I/O

现场代码最容易退化的地方，是把点位信息散落在十几处 if 判断里，改一个点要翻五个文件。稳妥的做法是先建一张点位表，把针脚号、字节地址、位号、有效电平、信号类型这几个属性固定下来，后面所有逻辑都从这张表里取。这样定义文件更新时，只改表，不改逻辑。

# 点位表：把"针脚—地址—语义—极性"四者固化在一处 # pin 只用于查线和文档，运行时不参与运算 POINTS = [ # name, pin, byte_addr, bit, active_low, kind ("running", 34, 2, 5, True, "level"), ("counter", 35, 2, 6, True, "edge"), ("alarm", 36, 2, 7, True, "level"), ] def decode(raw_byte: int) -> dict: """一次性解出整个字节，避免多次通讯造成的状态撕裂""" out = {} for name, _pin, _addr, bit, active_low, _kind in POINTS: v = (raw_byte >> bit) & 0x01 if active_low: # 漏型输出：回路导通 = 读到 0 v ^= 1 out[name] = bool(v) return out

这段代码有两个刻意的选择。第一，三个点从同一个字节里解出来，而不是分三次去读位地址。分三次读的话，两次读之间机床状态可能已经变了，你会得到一个“运行中但报警”的中间态，这种状态在某些统计逻辑里会被当成真实事件记下来，属于典型的读撕裂。一次读整字节是原子的，解出来的三个位一定属于同一个时刻。第二，active_low是数据而不是硬编码的取反，因为极性取决于机床侧是漏型还是源型，写死在函数里，换一台机床就得改代码。

4.2 去抖与边沿计数：代码怎么写

去抖和边沿检测看起来简单，但把两者混在一起写是常见的错误来源。正确的层次是先对每个点位做时间维度的稳定化，再在稳定值上做状态变化检测。顺序反了，毛刺会被当成边沿，计数器就会多吃脉冲。

class Debounce: """连续 need 次采样一致才认，返回稳定值变化，否则返回 None""" def __init__(self, need=3): self.need = need self.cnt = 0 self.stable = False def feed(self, raw: bool): if raw == self.stable: self.cnt = 0 return None self.cnt += 1 if self.cnt >= self.need: # 达到确认窗，接受新状态 self.stable = raw self.cnt = 0 return self.stable return None class EdgeCounter: """只在去抖后的值上跑，统计上升沿个数""" def __init__(self): self.prev = False self.count = 0 def feed(self, state: bool): if state and not self.prev: self.count += 1 self.prev = state

need的取值直接换算成时间窗：采样周期 50ms、need=4，就是 200ms 的确认窗，适合运行和报警；计数点如果非得用软件采，need 只能设成 1 甚至 0，而这恰恰说明它不该走这条路。这个类还有一个隐藏约定，就是初始状态必须确定。如果第一次feed之前stable的默认值碰巧和真实状态相反，第一个采样周期就会凭空产生一个边沿，计数器从 1 开始，全天产量永远多一件。上线前先强制读一次真实值做初始化，这个坑就能绕过去。

4.3 时序对齐：为什么轮询周期和 PLC 扫描周期会打架

采集端的采样周期和机床 PLC 的扫描周期是两个独立的时钟，谁也不知道对方走到哪一步。这种异步关系会带来两个具体问题。

一是采样混叠。假设脉冲宽度 12ms、轮询周期 50ms，那么一个脉冲落在两次采样之间的概率相当高，而且落法取决于两者的相位差。相位差会随着温漂和设备运行缓慢变化，于是表现出来就是“有时候准、有时候少几个”，非常难复现，属于典型的数据不一致问题。

二是事件顺序失真。上位机读到“报警有效”时，机床可能已经在报警前完成了计数动作，但因为计数脉冲太窄被漏掉，事件流里就出现了“先报警、后计数”这种物理上不可能的顺序。做故障回溯时，这种顺序错乱会把排查方向带偏。

能落地的缓解手段有三个。把一次批量读做到一个报文里，保证同一时刻的状态是自洽的；在数据里带上采集侧的时间戳，并且时间戳取在通讯发起之前而不是返回之后，否则网络延迟会被算进机床的时序里；对已知的窄脉冲信号放弃轮询，改用硬件计数或者寄存器差值，从根上消除混叠。

5. 避坑与排查：现场最容易翻车的五个点

5.1 电气侧：极性、地与电源

第一，COM 端接成 0V。现象是三个点全部读 0，或者完全不按机床状态变化，但用万用表量针脚电压又一切正常。原因是漏型输出的机床只把线拉到 0V，采集盒没提供 +24V 电势，光耦回路根本不闭合。解决办法是把 COM 改接到 +24V，改完先量一下 COM 与输入端子之间的压差，正常运行时应接近 24V，输出有效时降到接近 0V。

第二，采集盒与机床不共地，屏蔽层两端都接了。现象是计数点在停机时零星跳字，报警点偶尔误触发，且频率跟附近变频器启停相关。原因是两边参考地不同，存在共模电压，长电缆又把这部分干扰耦合进来。解决办法是 24V 电源与机床控制电源同源，或者至少单点共地；屏蔽层只在一端接地，通常接在采集盒这侧，另一端悬空。

第三，24V 取自机床同一路且上面挂着感性负载。现象是接触器吸合的瞬间采集盒重启，或者通讯中断几秒。原因是感性负载断开时的反电动势把 24V 母线拉低，超出了采集盒的欠压门限。解决办法是给采集盒单独一路 24V，或者在接触器线圈上并续流二极管、在采集盒电源入口加 TVS 和足够容量的滤波电容。

5.2 逻辑侧：漏计数与常开常闭搞反

第四，产量统计长期偏少几个百分点。现象是对账时数字对不上，但差得不多，长期被当成正常损耗。原因是计数脉冲宽度只有一个 PLC 扫描周期，软件轮询必然漏采。解决办法是改用采集盒的硬件计数器通道，或者直接读 PLC 内部计数器的当前值寄存器再做差分，不要试图靠缩短轮询周期硬追。

第五，无人值守时报警反复触发。现象是夜班没有加工，系统里却记录了十几次报警，每次只持续几十毫秒。原因有两个可能：一是报警点的常开常闭判断反了，把“正常导通”读成了报警；二是去抖窗口太短，电源纹波被当成了报警。解决办法是先核对原厂接口图确认有效电平，再把报警点的确认窗拉到 200ms 以上，并且把通讯超时和数据无效单独标记，不要让通讯中断伪装成状态变化。

6. 设计取舍：这套“三根线”的接口为什么能活这么久

用三个硬件点位来表达一台数控车床的运行状态，放在今天看是很节省的做法，甚至有点原始。任何一条现场总线都能一次性传上来几百个变量，为什么还要保留这种一位一位接线的接口？把取舍摊开看就明白了。

收益在于不依赖协议，因此有很强的通用性。Y2.5、Y2.6、Y2.7 加一根 COM，任何采集盒、任何 PLC、任何一块单片机都能读，不需要协议栈、不需要驱动、不需要知道对方是什么系统。对于设备种类杂、年份跨度大的车间，这一点比信息量重要得多。而且断线是可诊断的：线断了就是没电流，和“输出断开”在电气上可以区分开，配合失效安全接法，故障自己就会暴露出来。

代价也很明确，就是信息密度低。三个位只能回答三个问题：在不在干活、干了多少、有没有出事。想再加一个“当前刀具号”就得再拉线，加到八个以上，布线成本和故障点数量就上来了。所以这套接口的定位从来不是“完整状态采集”，而是“最小可用的运维信号集”，正好覆盖了稼动率统计、产量对账、故障响应这三件最刚需的事。980TDi 与 980TDc 两个型号定义完全一致，也说明这套接口被当成了系列级的契约而不是型号特性，稳定压倒扩展。

我自己在这上面犯过的错误很具体：第一次接手这类改造，看到 COM 端写着 +24V，第一反应是“图纸标错了吧”，按经验接了 0V，然后花了一整个下午在怀疑采集盒固件有问题。从那以后我每次接这类信号，都强制走一遍同样的动作：先确认机床输出是漏型还是源型，再确认 COM 该落在哪个电位，最后用万用表量 COM 与输入端子的压差来验证回路真的闭合了，三步做完才通电。希望帮到你。

本文还有配套的精品资源，点击获取