Address
宁波研发园A区2栋12B17
聚贤街道,鄞州区,宁波市,浙江中国
Work Hours
周一 to 周五: 8:30AM - 10:30PM
周六 to 周日: 9:30AM - 10:30PM

在西门子数控机床上装测头,采购和技术沟通里最常听到的一句话是“828D 是简版,840D sl 是高级版,差的就是系统大小”。这句话在选型阶段大致能用,一旦进入工程落地阶段就会显得过于粗糙。真正决定一台机床能不能顺畅装测头、装完之后程序好不好维护的,并不是“系统定位高低”这个标签,而是一批具体的功能落地条件:这台系统上原生的测量循环能不能用、用哪几个;测头信号从 PLC 到 NC 之间走的是哪条通路、由谁来传递;程序里的变量、数据块、子程序怎么组织、谁来初始化;出问题时报警文本能不能读、能不能定位到具体环节;以及把已经调好的项目从一台搬到另一台上时,哪些东西是可以搬的、哪些必须在目标系统上重建。
这些条件在 828D 与 840D sl 之间的分布并不一致。同一个测量循环号,在一台上是随系统自带的,在另一台上可能受选项或版本约束;同一段 PLC 与 NC 之间的数据交换逻辑,在一台上靠某个固定接口就能走通,在另一台上却要多绕一层;同一份 SPF 子程序加全局用户数据,在一台上放进去就能跑,搬到另一台上可能因为数据块没有对应定义而直接报警。这些差别不会在选型表里写出来,只会在现场调试和后续移植时集中暴露。
本文从工程落地角度把两平台的差异逐项拆开,覆盖测量循环与功能范围、PLC 与 NC 数据交换方式、变量与数据块管理要求、报警与诊断可读性、以及程序移植时必须重建的内容,并给出一份移植核对表。文中涉及的西门子系统侧语法均来自已核实的官方资料;基线未收录的具体 I/O 地址、数据块号、端子号、报警号与画面编号,一律以该机床的 PLC 程序与西门子官方手册为准,不做推算。
装测头这件事在第一层遇到的门槛,就是“这台系统上原生测量循环到底有没有、是哪几个”。西门子的原生测量循环按已核实的资料是一组以 CYCLE971 开头的循环,官方目录收录的号段涵盖 CYCLE961 至 CYCLE998 等多个编号,其中 CYCLE971、CYCLE972、CYCLE973 是现场常被引用的几个:CYCLE971 用于在机床上对刀具或工件做接触式测量并处理测量结果,CYCLE972 与 CYCLE973 则分别对应不同测量对象的同类动作。需要说明的是,这些循环各有独立的参数入口与适用对象,不能相互替代:例如 CYCLE971 用于校准与测量,CYCLE972 用于校准对刀仪与测量车削刀具(官方已注明其由 CYCLE982 取代),CYCLE998 用于 3D 对齐平面与边距对齐。
即便是同一组原生循环,“在这一台上可用”与“在那一台上可用”也不能默认等价。828D 与 840D sl 在测量功能与选项上的分布不同,这是已核实的口径。工程上要落地的判断不是“系统支不支持测量”,而是三件更具体的事:目标系统当前的选项状态里,测量循环相关功能是否被许可;这套系统的软件版本里,目标循环号是否随版本提供;这台机床的制造商在出厂时有没有把循环文件实际装载进系统。三者里任意一条不成立,程序里出现循环调用就会在启动或执行时报错,表现为“循环未定义”一类的问题,而不是精度问题。
再往下走一层,测量循环的调用接口本身也要按系统核。西门子的原生循环在被调用时有一套约定俗成的参数传递方式,参数按位置或按名传入,测量结果的回传位置也有约定。828D 与 840D sl 在参数个数、可选项、结果变量位置上的差异,会直接影响同一段调用代码能不能原样通过。工程上更稳妥的做法,是在目标系统上先用最简调用试跑,确认“循环能被识别、参数能被收下、结果能被读出”三件事,再把完整程序铺开。跳过这一步,往往是在完整程序跑到一半时才暴露调用不兼容。
与原生循环并存的还有第二套体系。按已核实资料,西门子上存在雷尼绍 L98xx 宏与西门子原生循环两套体系并存的情况。这意味着同一台机床上,工件测量可能走原生循环,而对刀或特定动作走厂商提供的宏子程序,两套体系共用同一批测量输入与系统变量。移植时如果把两套体系的边界搞混,把宏体系里的调用号当原生循环号用,或者把原生循环的调用约定套到宏上,都会出现“号看着对、跑起来不对”的现象。用哪一套、怎么分工,按对应厂商官方手册与该机床的实际配置确定。
对刀仪与工件测头在功能范围上还有一处需要分开考虑。两者虽然共用测量输入通路与坐标读取方式,但触发部件、安装位置和测量目的不同,对应的循环或宏也可能落在不同的号段上。有些机床上对刀那套是靠厂商宏子程序完成的,工件测量那套才用原生循环;有些则两套都走宏。核对时要按设备类型分别列清单,不能因为测头那套跑通了就默认对刀仪也已经就位。
把这一层整理成两平台的对照,能更清楚地看到哪些是“系统级”的差异、哪些是“项目级”的差异。系统级差异指由系统型号与版本决定的功能边界,凭现场调整难以绕过;项目级差异指由机床制造商配置、选项开通状态、循环文件装载情况决定的差异,可以通过配置或选项确认来解决。分清这两类,后续核对表里每一项该找谁确认也就清楚了:系统级的问系统手册与版本说明,项目级的回到这台机床的 PLC 程序与制造商交付资料。
| 对照项目 | 828D | 840D sl | 说明 |
|---|---|---|---|
| 原生测量循环号段 | CYCLE961~998 等多个编号 | CYCLE961~998 等多个编号 | 号段一致,可用性受选项与版本约束 |
| CYCLE971/972/973 | 需确认选项与循环文件 | 需确认选项与循环文件 | 不得默认任一台已开通 |
| CYCLE998 | 存在(3D 对齐平面/边距对齐) | 存在(3D 对齐平面/边距对齐) | 属原生测量循环 |
| 测量指令 | MEAS(=±1 测头 1、=±2 测头 2) | MEAS(=±1 测头 1、=±2 测头 2) | 语法一致 |
| 触发坐标读取 | $AA_IW[轴名] | $AA_IW[轴名] | 语法一致 |
| 公制编程 | G71 | G71 | G21 为发那科写法 |
| 第二套体系 | L98xx 宏 + 原生循环 | L98xx 宏 + 原生循环 | 分工按厂商官方手册 |
| 功能边界决定因素 | 型号+选项+循环装载 | 型号+选项+循环装载 | 系统级与项目级需分开确认 |
这张表要读两层:语法层多数项目是一致的,所以“语法不一样”并不是两平台差异的主战场;真正的差异集中在可用性、选项与配置这一层,而这一层是选型表通常不写的。下一章要讲的 PLC 与 NC 数据交换方式,差异同样集中在这个层面。
测头要能工作,测量输入信号必须从机床侧进到运动控制侧能被识别的通路里。这一步在西门子机上由 PLC 与 NC 之间的数据交换完成。两平台在这一段的差别,主要不在“能不能传”,而在“按什么方式传、由谁定义、传的时候要不要多绕一层”。
先明确这一步的物理含义。测头或接收器输出接到 PLC 输入点之后,PLC 在扫描周期里读到该输入位的状态变化,再通过 PLC 与 NC 之间的交换通道把状态递送到 NC 侧的测量输入,供含 MEAS 的运动段在合适时机取用。MEAS=±1 表示使用测头 1(测量输入 1),MEAS=±2 表示使用测头 2(测量输入 2);+1/+2 为上升沿触发,−1/−2 为下降沿触发;MEAS 删除剩余距离,MEAW 保留剩余距离。测量结果通过 $AA_IW[轴名] 这类轴位置系统变量读出。也就是说,PLC 侧负责“把信号送到位”,NC 侧负责“在正确时机把信号用起来”,两者之间的通道是整条链路里必须核对的一段。
两平台在这一段的第一处差别,是交换接口的组织方式。西门子的 PLC 与 NC 之间通过定义好的交换区传递信号,具体哪些字节位对应测量输入、哪些对应使能与状态回读,由系统侧的接口定义与机床制造商的 PLC 程序共同决定。828D 与 840D sl 在交换区的规模、可用接口资源、以及部分通用接口位的默认安排上并不完全相同,这意味着同一段梯形图里写死的交换地址,搬到另一台上未必指向同一个含义。这一点在移植章节里还会再展开:交换地址属于必须重新核对、不能沿用的一项。
第二处差别与 PLC 程序的规模与结构有关。PLC 按扫描周期工作,信号经 PLC 传递到 NC 存在一个与扫描周期同量级的延迟。程序的规模、调用的功能块数量、以及信号在梯形图里经过的处理级数,都会影响这个延迟的实际大小。同一段测头信号处理逻辑,如果在一台上只经过一两级映射,在另一台上因为程序结构不同而多绕了几级,响应时间就会变化。这不是“哪台快”的问题,而是“同一段移植代码在目标系统上的响应行为可能不同于原系统”,必须用实测确认,而不是按原系统的经验推定。
第三处差别在于测量输入通路的选择余地。测头信号是短促的电平跳变,触发沿的持续时间有限,通路上的滤波与去抖设置会直接影响它能不能被完整捕获。若输入模块或 PLC 侧设置了滤波,一个极短的触发沿可能在滤波环节被吞掉,表现为偶发漏触发;反之,滤波设置过松则可能把干扰当触发。两平台上可用的输入通路类型、可设置的滤波参数并不是同一套,工程上应当在目标系统上确认可用的测量输入通路以及其滤波设置的实际取值,而不是把原系统的参数值直接照抄。由于这些参数随输入模块与该机床配置而异,具体数值须对照该机床的 PLC 程序与西门子官方手册查取。
第四处差别在使能与状态回读的设计。测头通常不是一个“接上就一直有效”的设备:测量前后往往需要开、关测头,测量过程中需要知道测头是否就绪、是否已触发、是否出现异常。这些使能与状态位也要经过 PLC 与 NC 之间的交换区传递。两平台在可用位资源与状态位的组织上并不相同,某些机床上还会把测头使能与其他机床逻辑共用同一段交换资源,需要考虑互斥关系。核对时要把“开测头、等就绪、触发、读结果、关测头”这条动作序列上每一个信号落在哪个交换位、由谁写、由谁读,逐项列出来,再在目标系统上重建。漏掉其中一个状态位,往往不表现为报警,而表现为“偶尔等了很久才动”或“偶尔不动”,属于较难定位的一类。
还需要说明,信号在 PLC 侧处理时涉及的常开常闭方向、公共端类型与输入模块类型,两平台上的处理习惯也可能不同。同一只测头,在原系统上按常开逻辑接线并正常工作,在目标系统上如果梯形图的逻辑起点不同,就可能表现为恒常触发或从不触发。这类问题与交换方式本身无关,却常在移植时与交换地址问题混在一起,导致排查方向跑偏。工程上建议把“接线层”与“交换层”的核对分开做,先确认输入位本身能被读到并正确翻转,再看交换区有没有把它递送到位。
| 核对层面 | 需要确认的内容 | 两平台是否可沿用 | 判定方式 |
|---|---|---|---|
| 物理输入位 | 输入位能被读取、翻转方向正确 | 需按目标机床接线重核 | 按下测头看输入位是否翻转 |
| 交换区地址 | 测量输入、使能位、状态位落在哪个位 | 不可沿用 | 对照目标机床 PLC 程序 |
| 交换资源 | 使能位与状态位是否与其他逻辑共用 | 不可沿用 | 检查梯形图占用关系 |
| 传递级数 | 信号经几级处理到达 NC 侧 | 需按目标程序结构重核 | 读梯形图并实测响应 |
| 滤波设置 | 输入通路滤波与去抖取值 | 不可照抄 | 按目标输入模块与手册确认 |
| 常开常闭 | 逻辑起点方向与输入类型匹配 | 需按目标梯形图重核 | 对比静止与触发状态 |
上述六项里只有第一项偏物理、可直接观察,其余五项都属于“必须落到目标系统的程序里去读”的内容。这也是两平台差异在工程上真正的重量所在:语法层一致的项目搬起来轻,交换层与配置层的项目搬起来重,且重的那部分不看程序就核不出来。下一章讲的变量与数据块管理,是同一性质的问题在程序组织层面的表现。
测量程序不是一段孤立的代码,它依赖于一批变量、数据块和子程序文件。西门子上,测量相关的程序通常组织为 SPF 子程序文件,配合 GUD9 全局用户数据使用。这一组织方式在 828D 与 840D sl 上都成立,但两平台在“这些文件由谁装载、数据块由谁定义、初值由谁给、作用范围如何界定”这几件事上的要求不同,而这些不同正是项目移植时最容易踩空的地方。
先看 SPF 子程序这一层。SPF 是西门子的子程序文件形式,测量相关的初始化、标定、预设、接口等动作通常被拆成若干 SPF 文件分别承担。以已核实的资料为例,马波斯 MIDA 的西门子版就使用 MPS_INI、MPS_CAL、MPS_PRES、MPS_INTL 这类 SPF 文件,配合 GUD9 全局用户数据一起工作。这种拆分方式的工程含义是:程序的可用性不只取决于“主程序里调用对不对”,还取决于这几个 SPF 文件有没有全部装载到目标系统、文件名与调用名是否一致、装载路径是否在系统能找到的位置。任何一个环节缺失,表现为子程序找不到或初始化未执行,而不是测量精度偏差。
再看数据块与全局用户数据这一层。GUD9 属于全局用户数据区,它的特点是需要在系统侧做定义并装载,程序运行时按定义的结构读写。两平台在这方面的差别体现在两点:一是可定义的数据结构规模与可用号段在不同系统上的资源分配不同;二是装载与生效的机制不同,某些系统上需要显式装载或重新上电才生效,某些系统上在特定操作后即生效。工程上的正确处理不是记住某个固定号,而是把本项目实际用到的全局用户数据逐项列出清单:名称、结构、用途、初值来源、由谁写入、由谁读取,然后在目标系统上逐项重建定义并确认生效。基线未收录的具体数据块号与结构定义,应回到该机床的 PLC 程序与西门子官方手册确认。
第三层是变量作用范围与生命周期。测量程序里的变量有局部与全局之分,局部变量随子程序调用建立与释放,全局用户数据则在整个系统范围内持续存在。这个区别在同一个项目里往往不成问题,搬到另一台系统上却可能出错:原系统上某个值依赖全局数据在多次测量之间保持,若目标系统上该数据被放在局部范围或未被执行初始化,会出现“第一次测对、第二次测错”或“上电第一次不对”这类间歇性现象。核对时应逐个变量确认其作用范围,并对需要跨调用保持的量明确指定其承载位置与初始化时机。
第四层是初始化与复位的一致性。测量程序通常有两个必须明确的时刻:上电或复位后的初始状态,以及每次测量前的准备状态。前者决定数据块里的初值从哪里来,后者决定哪些量需要在每次测量前被重新置定。原系统上如果依赖某段文件在启动时自动执行初始化,搬到目标系统上若该文件的执行时机不同或没有被触发,数据块里可能残留上一循环的值。这类问题在现场表现为“参数被改过之后一直不对”,直到重新上电才恢复,定位成本较高。稳妥做法是在核对清单中明确列出:哪些量在上电时初始化、哪些在每次测量前初始化、各自由哪个文件或哪段代码承担。
第五层是字符串与信息输出。测量程序常需要在画面上给出提示或报警文本,西门子上使用 MSG() 输出,但不能把变量直接拼进 MSG 参数里,需要先用 DEF STRING[32] 一类定义字符串再拼接再输出。这一点在两平台上语法一致,但同一段文本输出在两侧对应的显示方式与可用字符长度可能受画面配置影响,移植时需要实测确认输出内容是否完整显示,尤其在多语言界面的机床上。此处的字符串定义长度、可用字符集以系统手册与实际画面配置为准。
| 管理层 | 需要处理的对象 | 常见疏漏 | 后果表现 |
|---|---|---|---|
| SPF 子程序 | 初始化、标定、预设、接口等文件 | 文件未全部装载或调用名不符 | 子程序找不到、初始化未执行 |
| 全局用户数据 | GUD9 等全局数据区定义 | 定义未重建或未生效 | 读写异常、值不更新 |
| 作用范围 | 局部变量与全局数据的界定 | 需保持的量放入局部 | 间歇性测错、上电首次异常 |
| 初始化时机 | 上电复位与每次测量前 | 依赖文件未被触发 | 残留旧值、改参后不生效 |
| 字符串输出 | MSG 与 DEF STRING 拼接 | 直接拼接变量 | 报警或提示输出异常 |
| 数据清单 | 名称、结构、初值、读写方 | 无清单,靠记忆核对 | 移植时漏项且难定位 |
这张表的用法不是逐项打钩,而是要求在移植前先把本项目实际用到的对象整理成一份数据清单。清单一旦成形,目标系统上需要重建什么、需要向机床制造商确认什么,就成了可分配的任务;没有清单,整件事只能靠现场比对,而现场比对的漏项往往在量产后才暴露。下一章讲的报警与诊断可读性,正是用来在漏项暴露时缩短定位时间的手段。
程序移植过去之后,出问题时的第一手信息来源是报警与诊断画面。828D 与 840D sl 在这一层的差异,直接影响现场判断的效率,也影响移植核对能发现多少隐藏问题。这一章从报警来源、报警文本、诊断画面与运行监控四个方面说明差异所在。
报警来源方面,测量相关的报警通常来自三处:系统对测量指令本身的状态判定,测量循环内部的判定,以及 PLC 侧对测头使能与状态的判定。三处报警的呈现方式和可读性并不相同。系统级报警通常有明确的号段与文本,能直接指出是参数不合理、循环未定义还是测量动作超时;循环内部报警的文本可能依赖循环文件的版本与语言包,同一段程序在不同系统上给出的提示可能详略不同;PLC 侧报警则取决于机床制造商在梯形图里有没有针对测头相关状态设计报警位与文本,若没有设计,测头异常就只能表现为“不动”而没有任何提示。
报警文本方面,西门子的报警文本通常通过文本文件或系统内的文本表提供,支持多语言。两平台在文本资源的组织方式、可自定义报警号段的可用范围、以及文本装载生效的机制上要求不同。工程上应当确认的是三件事:测量相关报警号落在哪个可用号段、对应文本由哪个文件提供、改了文本之后如何生效。基线未收录的具体报警号与文本文件路径,以该机床的系统手册与 PLC 程序为准。需要注意的是,自定义报警若使用了系统保留的号段,可能与系统自身报警冲突,核对时应先确认可用范围再分配。
诊断画面方面,两平台提供的诊断工具类型不同,画面布局与可监视对象也不同。工程上真正需要的诊断能力是三项:能看到 PLC 输入位与交换位的实时状态,能看到 NC 侧测量相关变量的当前值,能看到测量循环执行时的中间状态。若目标系统上的诊断画面缺少其中某一项,定位手段就要靠其他方式补足,例如在程序中临时增加状态输出或使用调试工具在线监视。核对时应把这三项能力逐项确认,并记录各自的查看路径。画面编号与菜单路径因系统型号与版本而异,具体以该机床的系统手册为准。
运行监控方面,还有一个容易被忽略的差异:测量程序的执行过程在两侧的可观测程度不同。有些系统上可以逐段观察测量程序的执行与变量变化,有些系统上只能看到最终结果。这个差异决定了“间歇性问题”在两平台上的定位难度不一样。工程上较为可行的做法是在程序里保留必要的中间状态输出点,使关键中间量在任一侧都能被读到;同时为测量动作设定明确的时间判据,一旦超时即输出可读提示,避免程序长时间无信息地等待。
把这一层组织成一张“诊断能力核对表”,可以在移植前把工具面先摸清,而不是等出了故障再找路径。表中逐项确认的是能力是否存在与路径在哪里,不涉及具体编号与画面名,具体以实现该机床的实际配置为准。
| 诊断能力 | 需要确认的内容 | 缺失时的影响 | 补足方式 |
|---|---|---|---|
| 输入位监视 | 能实时看 PLC 输入位状态 | 无法判断物理层是否通 | 状态表或在线监视 |
| 交换位监视 | 能看 PLC 与 NC 交换位状态 | 无法判断信号是否递送 | 增加在线监视点 |
| 测量变量监视 | 能看 $AA_IW[轴名] 当前值 | 无法判断触发是否发生 | 程序中输出中间量 |
| 循环执行状态 | 能看到测量循环执行进度 | 无法判断卡在哪一步 | 增加分段提示输出 |
| 报警号与文本 | 确认可用号段与文本来源 | 报警无文本、难定位 | 按手册分配号段 |
| 超时判据 | 测量动作是否有时间判据 | 无信息长时间等待 | 程序中加入超时提示 |
这六项覆盖了“信号是否到位”“触发是否发生”“动作是否完成”“出错是否有提示”四个判断层次。两平台的差异主要在前四项的工具与路径上,后两项则更多取决于程序本身有没有做设计。也就是说,报警与诊断的可读性并不完全由系统型号决定,程序侧的设计同样占很大比重;把这一点与前四章的结论放在一起看,可以得出一个对工程有价值的判断:两平台差异中真正难补的是系统与选项层面的功能边界,而程序组织、诊断设计、初始化安排这些是可以靠工程手段补齐的。下一章把所有需要核对的项目汇成一张表。
把前四章的内容收敛成一张可执行的核对表,是移植工作的实际交付物。这里要先把移植的两个方向区分开:从 828D 项目搬到 840D sl,与从 840D sl 项目搬到 828D,需要核对的项目名称相同,但风险分布不同。向功能范围更宽的平台上搬,容易出的问题是“原系统上没用到、新系统上有但被忽略的资源没有利用,同时新系统上默认的配置与原系统不同导致行为变化”;向功能范围更窄的平台上搬,容易出的问题是“原程序用了目标系统上不可用或未开通的功能,直到运行到该指令才暴露”。两个方向的共同点是:都不能靠“把程序拷过去再试跑”来完成,必须逐项核对。
核对表按五个类别组织,对应前四章的五条主线。每一项都要求落到目标系统的实际程序或手册上确认,确认不了的项目应明确标注为待确认,而不是按原系统经验推定。
| 类别 | 核对项 | 核对方式 | 不核对的典型后果 |
|---|---|---|---|
| 循环与功能 | 目标系统是否提供并许可所用测量循环(官方目录涵盖 CYCLE961~998 等多个编号) | 查目标系统版本说明与选项状态 | 循环调用报错、程序无法启动 |
| 循环与功能 | CYCLE971/972/973 是否已随系统装载 | 在目标系统上试跑最简调用 | 运行时提示循环未定义 |
| 循环与功能 | 调用参数个数与结果回传位置是否一致 | 对照两侧循环调用说明逐项比 | 参数错位、结果读到错误变量 |
| 循环与功能 | 宏体系与原生循环的分工是否重排 | 列两套体系各自承担的测量动作 | 调用号混用、动作落到错误体系 |
| 信号与交换 | 测头信号在目标系统的输入位地址 | 对照目标机床 PLC 程序与电气图 | 信号未被读取、输入位不翻转 |
| 信号与交换 | 测量输入、使能位、状态位的交换位 | 读梯形图找映射关系 | 信号递送不到 NC、状态读不到 |
| 信号与交换 | 交换资源是否与其他逻辑共用 | 检查梯形图中占用关系 | 使能冲突、动作偶发不执行 |
| 信号与交换 | 滤波与去抖设置的实际取值 | 按目标输入模块与手册确认 | 短触发沿被滤掉、偶发漏触发 |
| 信号与交换 | 常开常闭方向与输入类型匹配 | 对比静止与触发两种状态 | 恒常触发或从不触发 |
| 变量与数据 | SPF 文件是否全部装载、调用名是否一致 | 逐个文件确认装载与命名 | 子程序找不到、初始化未执行 |
| 变量与数据 | GUD9 等全局用户数据是否重建定义 | 列出清单后在目标系统逐项建 | 读写异常、数据不更新 |
| 变量与数据 | 各变量的作用范围是否重新界定 | 逐个确认局部与全局归属 | 间歇性测错、上电首次异常 |
| 变量与数据 | 初始化时机是否覆盖上电与每次测量 | 明确承担初始化的文件或段落 | 残留旧值、改参后不生效 |
| 变量与数据 | 字符串定义与 MSG 输出是否实测通过 | 在目标系统上实测显示内容 | 提示或报警文本异常 |
| 诊断与报警 | 测量相关报警可用号段与文本来源 | 查手册确认号段与文本文件 | 报警无文本、定位困难 |
| 诊断与报警 | 三项监视能力(输入位、交换位、变量) | 逐项在目标系统上试查看 | 故障时无第一手信息 |
| 诊断与报警 | 测量动作的超时判据是否存在 | 检查程序中是否有时间判据 | 无信息长时间等待、停位不清 |
| 移植收尾 | 数据清单与实际程序是否一致 | 用清单逐项对照目标系统 | 漏项在量产后才暴露 |
| 移植收尾 | 待确认项是否全部闭环 | 把标注待确认项逐条跟踪关闭 | 风险带入量产、返工成本上升 |
这张表的十九项里,前四项与循环功能相关,中间五项与信号交换相关,接下来五项与变量数据相关,后三项与诊断报警相关,最后两项是移植收尾。实际使用时建议按类别分批推进,而不是混在一起做:循环功能那一批在程序跑通之前就能确认,信号交换那一批必须在现场加电状态下确认,变量数据那一批可以离线比对清单完成大半,诊断报警那一批要等到动作实际执行时才能真正确认。
不核对的典型问题可以归纳成四类表现。第一类是启动即失败:循环未定义、子程序找不到、数据块未定义,这类问题暴露得早,成本相对可控。第二类是能启动但结果不对:参数错位、结果读到错误变量、坐标读取的轴名对应错,这类问题需要在标定件上复测才能发现,容易被误判为测头本身的问题。第三类是间歇性问题:滤波吞掉短触发沿、使能位与状态位未重建、需保持的量被放到局部范围,这类问题在现场表现为“偶尔不对”,定位成本较高,也最容易在排查中把方向带偏。第四类是维护性问题:报警无文本、诊断路径缺失、数据清单不全,这类问题不影响当前运行,却让后续任何一次修改都变得困难。四类问题里,前两类靠核对表可以拦掉大多数,后两类更多取决于有没有把清单与诊断设计当成交付物的一部分来做。
还有一处需要单独提醒:即便上述核对全部通过,也应当保留一份针对本次移植的现场记录,写明目标系统的型号、软件版本、选项状态、各项目的确认结果与待确认项。这份记录的价值在于,下一次在同一台机床上改动或新增设备时,不必重新从头核一遍;同时,若后续出现间歇性问题,这份记录能快速缩小范围。记录格式不需要统一模板,内容以能支持复核为准。
问一:828D 和 840D sl 装测头,差别是不是就是系统定位高低?
不只是。按已核实资料,两者在测量功能与选项上存在差异,但工程落地时真正影响结果的是可选循环范围、PLC 与 NC 的交换方式、数据块管理要求、报警与诊断可读性这几层。系统定位只是这些差异的由来,不是差异本身,移植前应当逐项核对而不是按定位推定。
问二:CYCLE971、CYCLE972、CYCLE973 在两平台上都能用吗?
官方目录收录的原生测量循环号段涵盖 CYCLE961~998,两平台同属这一体系。但“号段存在”不等于“这台机床上可用”,还要确认目标系统的选项状态、软件版本以及循环文件是否已装载。这些循环各有独立用途,例如 CYCLE998 用于 3D 对齐平面与边距对齐,与 CYCLE971~973 并不通用。
问三:西门子上能用 G31 做跳步测量吗?
不能。西门子没有 G31 这条语法,发那科与三菱的 G31 在西门子上不存在。西门子用 MEAS 测量指令:MEAS=±1 表示使用测头 1(测量输入 1),MEAS=±2 表示使用测头 2(测量输入 2),+1/+2 为上升沿触发,−1/−2 为下降沿触发,结果通过 $AA_IW[轴名] 这类轴位置系统变量读出。
问四:移植时能不能把原系统的 PLC 交换地址直接照抄?
不建议。测量输入、使能位、状态位落在哪个交换位,由系统侧接口定义与该机床制造商的 PLC 程序共同决定,两台机床不一定一致,交换资源的占用关系也要重新核。具体地址依据该机床的 PLC 程序与西门子官方手册核定。
问五:SPF 子程序和 GUD9 全局用户数据,移植时要重建什么?
要确认三件事:SPF 文件是否全部装载到目标系统、调用名与文件名是否一致、初始化是否被正确触发;GUD9 这类全局用户数据需要逐项列出名称、结构、初值与读写方,在目标系统上重建定义并确认生效。基线未收录的具体数据块号与结构定义,其界定以该机床的 PLC 程序与西门子官方手册为出处。
问六:移植后出现“偶尔不对”,最可能和哪些项目相关?
按工程经验,这类现象多与滤波设置吞掉短触发沿、使能位或状态位未重建、需要跨调用保持的量被放在局部范围、初始化时机与原系统不同这几项相关。它们都不表现为明确报警,建议用第5章核对表中“信号与交换”“变量与数据”两个类别逐项复查,并在标定件上复测。
问七:报警和诊断这一层,程序侧能做什么弥补?
可以在程序里保留关键中间量的输出点,使 PLC 输入位、交换位与 NC 侧测量变量在任一侧都能被读到;为测量动作设定明确的时间判据,超时即输出可读提示;并为测量相关报警选定未被系统保留的可用号段。具体号段与文本文件以该机床的系统手册与 PLC 程序为准。
问八:不做核对会出现哪些典型问题?
可分为四类:启动即失败(循环未定义、子程序找不到、数据块未定义);能启动但结果不对(参数错位、结果变量对应错、轴名对应错);间歇性问题(滤波吞沿、状态位缺失、作用范围错);维护性问题(报警无文本、诊断路径缺失、数据清单不全)。前两类多数可被核对表拦下,后两类取决于有没有把清单与诊断设计当成交付物。
本文关于西门子系统侧语法的内容,包括西门子没有 G31、测量指令 MEAS(MEAS=±1 表示使用测头 1(测量输入 1)、MEAS=±2 表示使用测头 2(测量输入 2),+1/+2 为上升沿触发、−1/−2 为下降沿触发,MEAS 删除剩余距离、MEAW 保留剩余距离)、触发位置读取 $AA_IW[轴名]、刀具补偿数据 $TC_DP6(半径几何)与 $TC_DP12(长度磨损)、原生测量循环号段涵盖 CYCLE961 至 CYCLE998 等多个编号、SPF 子程序文件与 GUD9 全局用户数据、公制为 G71(G21 为发那科写法)、字符串输出 MSG() 需先 DEF STRING 拼接、以及雷尼绍 L98xx 宏体系与西门子原生循环两套体系并存等,均来自已核实的官方资料,按官方口径写入。828D 与 840D sl 在测量功能与选项上存在差异这一口径同样来自已核实资料。本文未收录的、以及各机型与各配置间存在差异的具体 I/O 地址、数据块号、端子号、交换位地址、诊断画面编号、报警号与文本文件路径、测量循环调用参数与结果回传号段,一律以该机床的 PLC 程序与西门子官方手册为准,本文不做推算或编造。涉及测头与接收器的供电、屏蔽接法、公共端类型等接口事项,以对应设备的官方数据表与接线说明为准。
每台机床的配置、工况和预算都不一样,本文给出的只是参考框架。您可以:
宁波匠测科技——15 年专注精密测量,服务雷尼绍、马波斯、波龙全系测头与对刀仪的选型、安装、校准、维修与维保。
| 联系方式 | 信息 |
|---|---|
| 官方预约 | jcetech.cn/contact |
| 咨询热线 | 157-5780-7400 / 132-2194-1413 |
| 寄修地址 | 宁波鄞州研发园 A2-12B17 |
| 服务范围 | 全国上门 · 加急维修 48 小时响应 |
把问题发给我们,让专业工程师帮您算清楚这笔账。
打开微信扫一扫,关注「宁波匠测」
获取维修进度查询与技术支持
打开企业微信或微信扫一扫
添加专属顾问,随时沟通