如果将一次处于连接状态的 TNC 会话剥离至底层网络线缆，留下的数据结构精简得令人吃惊：一个 4 字节的长度字段、一个 4 字符的 ASCII 指令代码，以及紧随其后的有效载荷。这里没有冗长的 JSON 对象树，没有繁复的 XML 架构定义，也没有常见的 HTTP 请求报头。当工程师深入海德汉（HEIDENHAIN）数控机床的工业网络通信底层时，所面对的这套紧凑而高效的二进制报文规范，正是 LSV2 协议。
这种表面上的极简极具欺骗性。LSV2 是海德汉专为 TNC 系列数控系统定制的基于 TCP 的专有报文协议，承担着加工程序双向传输、机床运行状态监控、坐标轴实时数据采集以及内部 PLC 寄存器寻址等核心任务。海德汉官方从未公开发布过面向公众的完整规范文本。工业界对该协议的掌握，几乎完全依赖于对真实机床通信报文的抓包分析、状态码逆向推演，以及对 TNCremo 等官方配套通信工具的长期跟踪。本文旨在以客观的工程技术视角，系统解析这一工业专用语言的运行脉络。[1][2]
LSV2 核心技术参数速览
| 开发厂商 | DR. JOHANNES HEIDENHAIN GmbH（德国海德汉公司） [1] |
|---|---|
| 协议类型 | 专有二进制 TCP 报文协议；面向长连接且维护会话状态 [1][2] |
| 传输媒介与端口 | TCP 19000（经典默认端口）；新型控制器支持 SSH（22 端口）加密通道 [4][5] |
| 数据帧封装 | [len:u32 BE][cmd:4 ASCII][payload]；长度计算不包含 4 字符命令头 [2] |
| 会话登录指令 | A_LG（用户名方式登录），P_LG（密码鉴权登录）；响应 T_OK 或 T_ER [1][2] |
| 数据覆盖范围 | 运行模式、执行程序名称、进给倍率、PLC 点位寄存器、内部存储文件目录 [1][2] |
| 交互方向 | 双向读写与文件数据流传输；受会话角色与机床软硬件授权选项管控 [3][6] |
| 文档开放程度 | 封闭专有；依赖 pyLSV2 等开源社区项目通过逆向测试进行梳理 [1][2] |
| 实测兼容型号 | TNC 320、TNC 620、TNC 640、iTNC 530、TNC7、CNCpilot 640、MANUALplus 620、MillPlus IT [1] |
| DNC 选件依赖 | 高阶状态指令依赖 DNC Option 18；未开通选件的机床可通过读取 PLC 符号地址替代 [6] |
概念界定：LSV2 的定位与技术边界
LSV2 处于海德汉数控系统网络互联的最底层通信链路。当 PC 端工具（例如 TNCremo）执行程序上传、读取目录列表或轮询系统运行工况时，均是在 TCP 连接之上分发 LSV2 二进制报文。在车间现场，许多工程师经常将 LSV2 与“海德汉 DNC”混为一谈；二者在架构上存在明确分工：DNC 是面向车间制造执行的上层应用套件与集成方案，而 LSV2 则是承载这些业务交互的基础传输协议。[1][6]
同样，将 LSV2 与 MTConnect 划等号也是常见的方案误判。MTConnect 是一套完全开放、纯只读、基于 XML/JSON 与标准 HTTP REST 构建的跨品牌语义标准；而 LSV2 则是海德汉机床专有的、有状态的、采用紧凑二进制格式的通信协议，不仅支持只读采集，还涵盖加工程序下发与内存写入。前者用于全厂多品牌设备的横向统一管理，后者则直接与海德汉数控系统的深层数据打交道。[1]
8 字节报文头与 4 字符助记指令
LSV2 的报文结构设计展现了工业通信的极高紧凑性。每条报文均以 8 字节固定头部起始：前 4 字节为大端序（Big-Endian）的 32 位无符号整型，表示有效载荷的实际字节数；紧随其后的 4 字节为固定长度的 ASCII 指令代码。需要特别强调的是：长度数值仅计算指令后面的数据载荷，并不包含这 4 字节的指令本身。所有指令均严格由 4 个英文字符构成，例如 A_LG、R_RI、S_RI、T_OK 和 T_ER 等。[2]
登录请求： [len:u32 BE] [A_LG] [用户名字符串 + 0x00]
系统响应： [len:u32 BE] [T_OK] [可选返回数据]
状态请求： [len:u32 BE] [R_RI] [子功能编号:u16 BE]
数据响应： [len:u32 BE] [S_RI] [运行数据载荷]建立通信会话支持两种方式：A_LG 仅发送用户名字符串即可尝试登录，而 P_LG 则要求验证登录口令。在配置 TNCremoNT 模拟器开展测试时，经常可以观察到 PASSWORD 或 REMOTE 等缺省口令；但这些标识仅适用于测试环境，绝不可直接当做生产级安全机制使用。会话认证成功后，数控系统将回送 T_OK，失败则返回 T_ER 并附带具体的错误代码。[1][2]
在文件传输层面，LSV2 支持 ASCII 与二进制两种工作模式。如果在请求的文件名后追加单字节 0x01，即表示启用二进制传输模式。这一技术细节至关重要：若以 ASCII 文本规则去传输二进制程序文件，会导致字符转义错乱破坏控制器存储。此外，路径格式必须严格适配 TNC 系统内部规范（例如 TNC:\nc_prog\），直接传递宿主机操作系统的绝对路径将导致系统直接抛出路径无效异常。[2]
在故障诊断方面，系统返回的错误代码划分了明确的数值区间。根据开源逆向项目 pyLSV2 的记录，0 至 19 代表底层网络与传输级故障，20 至 99 代表报文格式及语法错误，100 至 200 则代表数据块文件传输级异常。采集客户端在收到 T_ER 响应时，不能仅仅提示“通信超时”，必须记录具体的状态码并解析载荷，以准确定位故障究竟出自网络闪断、文件冲突还是权限未开通。[3]
R_RI 指令：精准提取数控系统运行快照
与一次性倾倒海量数据的方式不同，LSV2 在运行状态采集时采用 R_RI（Read Running Info）指令开展按需轮询。客户端向 R_RI 指令追加 2 字节的大端序子功能编号（Sub-ID），控制器则回送携带目标数据的 S_RI 报文。生产车间数据采集应用中最核心的 4 个子功能编号如下：[1][2]
| 子功能编号 | 采集参数含义 | 响应数据结构与解析规则 |
|---|---|---|
| 23 | 运行工作模式（Execution State） | 4 = 自动连续运行，1 = MDI 手动数据输入，0 = 手动操作 |
| 24 | 当前选中的加工程序路径 | 从第 4 字节起始，以空字符（null）分隔的路径字符串 |
| 25 | 机床倍率旋钮数值（Override） | 连续 3 个 u32 整数：进给倍率、主轴倍率、快移倍率 |
| 26 | 加工程序执行状态 | 0 = 运行中，1 = 暂停停止，2 = 正常结束，3 = 取消中止，7 = 空闲 |
针对子功能 25，有一个不容忽视的工程换算关系：报文返回的原始数值中，10000 代表 100%。控制器以万分之一的基准反馈倍率旋钮刻度。如果直接将原始整型当做百分比显示，看板上的数据将偏离两个数量级。不同驱动库的实现也不尽相同：部分组件会将原始数据除以 10000 转换为浮点比例（1.0），而另一些组件则除以 100 输出显示百分比（100.0）。在系统架构设计阶段，必须提前明确该指标的数据格式规范。[2]
子功能 24 在解析时同样存在工程细节：程序文件名从返回数据的第 4 字节开始，多个嵌套子程序之间以空字符 0x00 进行分隔。虽然首个路径通常对应主程序，但各系统固件返回的子程序排布序列并不完全相同。数据解析程序必须具备健壮的分隔符容错逻辑，防止因遇到末尾空白字符而发生解析中断。[2]
会话角色体系：细粒度的权限边界
LSV2 协议的权限体系远非“建立连接即拥有一切”那般简单。在登录初始化握手时，客户端必须显式申明本次会话所需扮演的操作角色。根据 pyLSV2 项目的解析，系统内置的角色包括 INSPECT、FILE、DNC、MONITOR、DIAGNOSTICS、PLCDEBUG、SCOPE 以及 DATA。其中，INSPECT 用于读取轴坐标与静态状态；FILE 专用于管理工件文件；DNC 用于跟踪程序执行生命周期；而 PLCDEBUG 则允许直接深入底层 PLC 内存区间。[3]
这些会话角色构成了工业网络的安全隔离带。用于车间状态采集的监控程序，应当严格限定在 INSPECT 或 MONITOR 角色之内。若向自动化数据采集器赋予 PLCDEBUG 权限，无疑人为放大了控制区被误写入的安全风险。严格限定接入角色，是工业安全管理的基本原则。[3]
工程认知转折之一：简明的数据封装与封闭的技术生态
LSV2 紧凑的 8 字节报文结构很容易让初涉该领域的工程师产生“协议非常简单”的错觉。然而真正的工程瓶颈往往不在于解析数据包头，而在于缺乏透明的技术文档：如何获知每个 Sub-ID 返回的具体寄存器排布、特定版本控制器支持哪些指令集，以及遭遇异常代码时如何处理。海德汉官方并未向普通用户公开发布完整的通信规范，开源社区正是通过持续的抓包测试，逐步拼凑出这套体系的轮廓。[1][2]
在工业级生产线上应用此类工具时，必须清晰区分协议机制研究与实体生产机床部署。开源项目 pyLSV2 采用 MIT 协议开源，但其文档首页明确作出了“禁止直接用于生产实体机床”的技术免责声明。这种谨慎源于专有协议的本质特征：不同世代控制器在固件更新后，可能会微调底层时序或拒绝特定指令组合。[1]
工程认知转折之二：双重权限授权壁垒
在海德汉系统中，数据访问受制于两道彼此独立的权限屏障。第一道是握手阶段协商的会话角色；第二道则源于机床物理硬件中开通的授权选项。具体而言，如果要通过高阶指令完整提取程序执行信息与详细工况，机床必须在硬件 SIK（系统识别密钥）中激活 DNC Option 18 选件。如果该选件未开通，控制器虽然接受网络握手建立，但在收到核心状态查询时将直接返回权限拒绝错误。[6]
缺少 Option 18 并不意味着完全无法获取生产数据。在没有该高阶选件的旧机床上，行业通行方案是通过读取 PLC 内部标志位与符号地址来获取基础开停机状态。尽管该方案需要提前熟悉各机床厂商自定义的 PLC 点位映射表，且数据粒度相对受限，但它为老旧设备的数字化改造提供了一条可行的过渡技术路径。明确“成功连上端口”与“具备读取业务数据权限”之间的本质差异，是海德汉数据采集项目必须掌握的核心技术逻辑。[6]
工程认知转折之三：控制系统代际演进与端口多元化
将 LSV2 视为一成不变的通信标准，容易掩盖其伴随机床换代产生的演进细节。在 iTNC 530、TNC 640、TNC7、CNCpilot 640 以及 MillPlus IT 等不同系列之间，支持的命令集、超时机制以及底层传输链路均存在明显差异。新一代控制器为了满足工业安全要求，开始支持将 LSV2 数据流封装进 SSH 安全隧道（22 端口）传输；而传统旧式机床则直接在明文的 TCP 19000 端口上进行监听。[1][5]
此外，海德汉官方 DNC 软件组件在不同配置下也会分配不同的网络服务端口。例如在某些 TNC640 DNC 方案中，上位机配置连接至 19003 端口，而底层的原生 LSV2 依然运行在 19000 端口。19003 是海德汉 DNC COM 软件层的封装接口，并非 LSV2 的通用替代端口。工程技术人员切忌在方案规划中对网络端口进行盲目假设。
在文件传输机制上同样存在差异：部分机床允许直接无阻碍流式写入，而另一些系统则会校验特定安全密码或对目标目录设置严格的属性锁定。单纯宣称“支持 LSV2 通信”，脱离了明确的数控型号与固件版本，在工程上是不完整的表述。
技术路线选型对比：LSV2、DNC COM 与 MTConnect
| 评估维度 | 原生 LSV2 协议 | 海德汉 DNC COM 组件 | MTConnect 开放标准 |
|---|---|---|---|
| 深层 CNC 及 PLC 数据采集 | 完全支持 | 完全支持 | 受限于标准定义范围 |
| 加工程序文件双向传输 | 完全支持 | 完全支持 | 不支持（只读标准） |
| 宿主机操作系统依赖性 | 极低（纯 Socket 通信） | 较高（依赖 Windows COM 运行库） | 极低（标准 HTTP/REST 服务） |
| 跨品牌通用兼容能力 | 不支持（仅限海德汉） | 不支持（仅限海德汉） | 完全支持（多品牌通用模型） |
| 推荐生产应用场景 | 轻量级边缘网关、嵌入式采集节点 | 厂商认证级 MES/CAM 系统集成 | 全厂跨品牌 OEE 看板与生产统计 |
技术选型应当立足于明确的业务需求。如果系统必须下发加工文件，MTConnect 显然无法满足要求；反之，若业务目标仅是实时呈现全厂设备的开机利用率，直接开启 LSV2 的双向通道反而会带来不必要的控制风险。
车间工程落地实施的七项准则
- 在控制器端开通外部访问： 必须在 TNC 系统设置中启用外部通信权限并设置对应密码，否则任何连接请求都将被直接阻断。
- 核验网络端口与传输通道： 先行测试 TCP 19000 端口连通性；若为新型 TNC640 或 TNC7 机型，需提前规划 22 端口的 SSH 隧道配置。
- 遵循最小权限角色原则： 状态监控应严格指定
INSPECT或MONITOR角色；文件传输使用FILE；严禁随意使用PLCDEBUG角色。 - 核验 Option 18 授权状态： 检查机床 SIK 硬件密钥中 DNC 选项状态；若未购买该选件，应尽早确立基于 PLC 点位读取的替代方案。
- 确立单一会话采集策略： 多个采集端并发高频轮询容易造成老款系统连接异常；建议通过边缘网关进行集中数据采集分发。
- 明确数据比例换算规范： 严格遵循 10000 = 100% 的原始数据换算协议，防止看板数据产生两个数量级的显示偏差。
- 建立异常代码记录与报警： 全量捕获并记录所有的
T_ER响应及其附带的状态码，精准区分网络物理中断与权限不足问题。
结语：报文的简明掩盖不了工程的严谨
LSV2 协议的基础报文头仅由 8 个字节构成，但要让其在车间稳定工作，必须全面驾驭会话角色、硬件授权、代际差异以及状态码分类。单纯根据精炼的数据包头就轻言“完全吃透了协议”，无异于只观察到了门锁的锁舌，却忽略了整座大厦复杂的防御结构。
您的车间在采集海德汉机床时，目前使用的是何种会话角色？而在尚未开通 DNC Option 18 选件的设备上，基于 PLC 的数据读取方案是一套规范受控的正式架构，还是一项临时应变方案？
本文为数控系统控制协议系列的第三篇深度解析。如需了解物理层串行通信，请阅读我们的 RS-232 深度解析；嵌入式信号底层机理可参考 I2C、SPI 与 UART 协议物理分析。
权威来源与工程参考
- pyLSV2 • 开源项目仓库：测试机型清单、SSH 隧道配置与生产免责声明 • github.com/drunsinn/pyLSV2
- pyLSV2 • “Findings on LSV2″：协议数据帧布局、二进制工作模式与 R_RI 子功能编号 • pylsv2.readthedocs.io
- pyLSV2 •
const.py：会话角色定义、指令列表与错误代码分类 • const.py - pyLSV2 •
low_level_com.py：默认 19000 端口 Socket 通信底层逻辑 • low_level_com.py - inventcom • 海德汉 PLC 数据采集实战：TCP 19000 与 SSH 22 端口配置 • inventcom.net
- inventcom • DNC Option 18：硬件 SIK 选件及基于 PLC 标志位的替代方案 • inventcom.net