搞了大半天最后发现让机床报警的居然是一行中文注释——准确说是注释文件的编码格式不对。当时客户那台西门子828D操作工从U盘拷贝了一个加工程序进去结果一选中运行系统第一段就报“字符错误”。可怪就怪在机床操作界面全是中文程序管理页里也能看到文件名偏偏就是读不了。后来把文件拉到电脑上用十六进制一看好家伙文件是UTF-8带BOM系统把BOM头当成程序字节来解析了不出错才怪。这种问题在828D和840Dsl上都遇到过不少次所以今天不聊什么深奥的数控原理就专门梳理一下数控程序和PLC中文注释那些最容易被忽视、又最能坑人的细节。1. 先分清两件事NC程序注释和PLC程序注释是完全不同的链路1.1 很多人把“数控程序”和“PLC程序”的中文注释混为一谈在车间现场一说“程序里的中文注释”大家容易默认是一回事。其实这里面的坑差着十万八千里。数控加工程序也就是我们平时说的NC程序、零件程序是由数控系统里的NCK解析执行的它的注释是直接写在加工程序里的跟着程序一起走。而PLC程序是另一套逻辑负责处理机床外围动作——换刀、冷却、润滑、报警这些它的中文注释通常存在于编程软件的工程文件里。两者下载、存储、显示经过的环节完全不一样。我见过有工程师在828D上想把PLC程序的中文注释直接显示在操作屏上以为把注释写在程序段后面就能在诊断界面看到这算是对“注释”和“报警文本”这两个概念理解岔了。程序注释主要是给人看的PLC下载到控制器运行之后注释一般不参与在线监控显示除非你用在线监视功能去看某个程序块看到的是代码和在线状态不是中文说明。所以先建立这个认知NC程序注释、PLC程序注释、PLC报警文本是三套不同的链路后面讲到每个链路时才知道该往哪个环节去改。1.2 828D与840Dsl的底层架构差异直接决定中文注释的兼容性西门子828D属于紧凑型数控系统PLC是集成在系统里的不是外面挂一个独立的S7-300CPU。它的PLC程序是基于S7-200指令体系发展而来的编程时使用西门子为828D提供的Toolbox工具包里面的PLC基本程序版本还必须和828D系统的软件版本严格匹配。版本不对程序根本打不开更别提看注释了。840Dsl则是高端全功能数控系统它的PLC部分基于S7-300平台调试软件用的是Step7或TIA Portal。在这种体系里FC、FB、DB这些概念和标准S7-300是一脉相承的符号表和程序注释的存储方式也和828D有区别。很多人从828D转840Dsl项目时第一感觉是NC编程差不多可一旦去碰PLC程序就发现结构差很远。再加上840Dsl的NCU型号不同、PLC基本程序版本不同连注释导出都有版本兼容性问题。所以千万不要拿着处理828D注释的经验直接套到840Dsl上。我遇到过客户在其他品牌机器上习惯用中文写变量注释到了840Dsl的Step7项目里某些自带西门子标准功能块的内部变量是不能乱改注释的一改的话程序块属性出现乱码反而不如原版英文清楚。2. NC加工程序里的中文注释条件、写法、编码三大门槛2.1 一个好用的注释也有前提系统语言不解决文件编码问题我之前有个误区觉得只要把数控系统界面调成中文那么U盘里带中文注释的加工程序就能随便读。后来被现实教育了系统界面语言显示中文只代表HMI把操作按钮和系统报警文字都换成了中文包它和NCK去解析一个零件程序文件中的字符完全是两回事。要往828D或840Dsl里读取带中文注释的NC程序系统区域语言最好设置为中文这是前提但更关键的是文件本身的编码必须和系统期望的一致。大多数情况下西门子系统对从外部传入的TXT程序文件按ISO 8859-1或系统区域内码去解析。你如果直接在Windows记事本里输入中文保存时选的是UTF-8那文件里的中文字节已经变成了UTF-8编码系统按单字节字符集去解析看到的自然是一堆乱码而且这串乱码里一旦出现单字节0x0A、0x0D之外的特殊字节很容易扰乱程序行解析直接引发报警。我自己是强烈建议现场涉及机床生产的加工程序如果不是特别有必要程序内部不要放长中文注释。想放的话优先放在程序头那几行固定注释区别放在运动指令中间。程序头注释即使有问题排查时打开文件一眼就能发现如果每个程序段后面都跟一段中文注释一旦编码出问题整个文件的行尾解析都会乱套。2.2 半角括号全角括号一个看着不起眼却能要命的细节在西门子数控编程体系里注释最常用的办法是用括号包起来。也就是说系统看到一对圆括号就会把里面的内容忽略掉不参与执行。很多初学者容易踩的一个坑就是切换成中文输入法之后直接打了全角括号中文括号比如N10 G01 X100 Y100 F1000这是走直线这种情况下系统不认识全角括号它会把内容当成非法字符报错。这里要注意注释格式必须使用半角英文括号吗其实在西门子系统里比较推荐的注释方式更多是用分号和特定的文本格式但实际车间里用半角括号包注释是流传最广的写法尤其在FANUC里也一样。到了西门子系统括号注释通常也是被兼容的。为了安全程序里任何括号都尽量用半角括号不要用全角。更讲究一点的做法是把中文注释放在独立一行不要跟在运动指令后面。比如程序开头放几行 (零件号ABC-20240115) (版本V1.2 编辑人张三) (说明粗铣上表面D12平底刀)这种独立注释行在程序传输时会稳定很多。因为整行注释被括号包起来就算里面有几个中文字符在传输过程中编码异常顶多就是这一行显示乱码不太会影响下面N行运动指令的解析。要是把注释紧紧贴在运动指令后面编码出错后系统可能把整段截断或者状态异常。2.3 DNC边传边加工时中文注释乱码会连带产生断刀风险很多工厂做了DNC联网电脑直接给机床传程序。传输时有两个模式文本模式和二进制模式。如果DNC软件设置成文本模式它会对文件内容做代码页转换中文注释就很危险。比如你把程序文件里的注释用GBK编码保存DNC软件在文本模式下按当前电脑系统代码页去解释再以它自己的传输协议发给机床中间任何一次字符集转换不完整到了机床端中文就变成问号或者乱码。乱码本身不一定报警但如果注释行乱码之后把换行符吞了或者0x00之类的字符混进去了DNC在线加工时会出现程序段突然中断、机床进给停止等莫名其妙的故障严重时甚至因为刀具还在切削而断刀。我自己用DNC传程序时习惯先把文件另存为“纯ANSI文本”并且用专门的DNC传输程序设置成二进制模式。对于几百行的小程序这没问题但大程序涉及在线加工时你还得考虑文件里中文注释对系统预读缓冲区的影响。具体操作上的建议不管哪种方式先在小零件上空跑验证一下。比如在程序开头加一行特殊注释然后在系统侧打开程序看能不能正常识别这一行。通过这种办法任何DNC软件的编码问题都能提前露馅。3. PLC程序里的中文注释从电脑到控制器再到HMI的完整链路3.1 828D内置PLC的注释和项目管理828D的内置PLC程序通过西门子Toolbox中的PLC编程工具来编辑。这个工具的操作界面和Step7比较接近但与标准S7-200/S7-300又有差别。你在程序块里写的网络注释、程序段说明存在你电脑上的项目里真正编译下载到828D控制器之后HMI操作界面并不会把这些注释显示出来。有些同行以为把程序段里中文注释写全之后操作工在机床屏幕上就能像看说明书一样看到解释这是错误预期。在828D项目过程中反而是项目管理上要求高。Toolbox程序版本必须和实际828D软件版本一致否则即使你打开一个已经编好的PLC程序文件系统也会提示版本不兼容打不开程序自然看不到注释。所以用828D做设备维护时千万保留好和机床软件版本对应的Toolbox安装包以及机床当前PLC程序的备份。3.2 840Dsl里的S7-300平台中文注释840Dsl的PLC程序因为是基于S7-300的所以大多数情况下你会用Step7或者TIA Portal打开。标准S7-300程序的中文注释是通过符号表、块注释和网络注释来体现的。我的经验是变量名或符号名最好永远使用英文或“字母下划线数字”不要用中文变量名。虽然西门子某些版本支持中文字符作为符号名但一旦后续做跨系统通信、OPC-UA地址映射、HMI变量连接中文符号名会产生兼容性麻烦。注释部分则完全可以中文比如FB块的标题、网络的标题、每条指令后的说明。这样既满足了中文可读性又不影响系统底层寻址。另一个容易被忽略的问题就是跨电脑打开项目的区域语言一致性。比如你在学校或家里用中文版Windows编辑一个Step7项目到了客户现场用一台英文版Windows的电脑打开归档文件最常见的结果是中文注释变成一片乱码。这种乱码并不是文件损坏了而是代码页在读取时不对应。遇到这种情况不要反复修改程序先把电脑区域语言改成中文重启后再打开项目。有人问我TIA Portal是不是对中文注释支持更好了后面我实际用下来支持的确实好很多但不同版本TIA对Unicode的默认处理还是有差异。尤其当你同时用TIA V15和TIA V18来回打开同一个项目时要小心注释的字符集转换。归档文件在版本间迁移时最好做一次全项目搜索专门看网络注释部分有没有显示异常。3.3 报警文本和中文注释不要混淆PLC程序里的注释和报警文本是两码事。PLC程序注释只是给工控工程师看的写在程序段里不参与运行显示。而操作工在机床屏幕上看到的中文报警信息比如“液压压力低”“急停被按下”“刀库门未关”来自PLC报警文本。这个报警文本通过SDK或Toolbox里的报警文本文件配置每个报警编号对应一条中文描述下载到系统后由HMI读取显示。调试时最标准的做法是先在PLC程序里用一个FC块调用报警功能。比如在某些西门子数控系统中通过调用Alarm块并给一个报警号参数然后到报警文本配置文件里维护这个报警号对应的中文文本。这和你在FC的Network注释里写一行“这里是一号刀套伸出报警”完全不是一回事。很多新工程师搞不清结果PLC程序注释写得满满的可机床报警还是显示英文或者只是一个号码就是因为漏了报警文本文件这一环。4. 三个乱码与报错场景的完整排查链路4.1 场景一U盘程序带中文注释第一行就报字符错误我前面提到的客户现场案例就是一个典型。当时在828D上操作工用U盘拷贝了一个加工程序文件名是英文看到文件能显示在程序管理列表里但一运行就报错。我第一反应不是看注释内容而是把文件从U盘原样拷回电脑用十六进制编辑器打开文件头。一看文件开头是EF BB BF这个正是UTF-8编码的BOM头。Windows记事本如果保存成UTF-8格式会在文件最前面加上BOM标记。数控系统在读取程序文件时并不会像Windows文本编辑器那样友好地跳过BOM它会把这三个字节当作程序内容来解析自然第一行就出错。排查链路先看报警行是不是第一段再看文件是不是从Windows记事本保存过再查十六进制文件头确认BOM最后用Notepad转成UTF-8无BOM格式或ANSI格式重新保存传到机床运行正常。这个问题在840Dsl上同样有和系统新旧关系不大就是编码问题。4.2 场景二机床上显示正常的中文注释传到电脑打开却乱码这个过程比前一个更隐蔽。有次客户反馈机床上的程序编辑器里看中文注释完全正常但程序通过网线传到电脑上用Windows记事本打开注释全是乱码。客户怀疑是传输过程把注释损坏了。实际上机床上编辑并保存的程序内部使用的是系统自身的编码方式通常和Windows默认的ANSI编码不同。系统显示正常是因为系统内部解码规则一致传到Windows电脑上记事本默认按本地代码页去显示结果自然乱。排查时不要盲目转换文件先在电脑上用Notepad打开然后在“编码”菜单里尝试切换为“ANSI”或“UTF-8”或者“GB2312”总有一种能让中文正常显示。找到正确的编码后再另存为需要的格式。这里也给大家一个习惯如果电脑里只是查看备份不乱动编码如果要从电脑端修改再回传就一定先确认源文件在哪种编码下显示正常再修改保存为无BOM格式否则回传到机床后反而会制造乱码。4.3 场景三PLC程序上传后打开中文注释乱码甚至编译不过某840Dsl项目现场工程师用新配的英文版Windows笔记本电脑把机床上PLC程序上传后用Step7打开发现所有中文注释都变成了类似“ä¸æ–‡”这样的乱码。更麻烦的是程序里有一部分原来写的临时中文备注导致编译器报错程序下载的时候用户程序报不一致。当时排查下来问题根源是这台电脑的操作系统区域语言设置与项目创建时的中文环境不一致。英文Windows的默认非Unicode程序语言代码页是1252而中文项目使用的是936GBK代码页不一样Step7读注释时就映射错了。处理办法第一步不要急着去改程序里的注释否则越改越乱第二步把Windows区域语言改成中文简体中国重启电脑第三步重新打开项目注释基本恢复第四步如果某些块内注释已经无法恢复那就从西门子原厂备份归档文件里恢复对应代码块再重新下载到PLC。从那以后我就特别强调凡是多语言环境下做西门子PLC项目先确认电脑区域语言统一再谈程序注释和中文变量。5. 让中文注释真正可用的几条经验5.1 中文注释不是为了“显示中文”而是为了减少故障时间我把话放在这里中文注释有个很大的价值就是在设备发生故障交底时能让下一个接手的工程师快速读懂程序意图。很多设备厂家在售后阶段最头疼的就是上一任工程师留下的PLC程序没有注释变量全是英文缩写或者干脆是A1、B2这种。但是注释本身也会带来风险尤其当它经手编码转换、跨系统传输、多人修改后更容易出现乱码。我这些年下来比较实用的一套原则是NC程序文件名一律用英文或者数字程序内部注释用中文可以但集中在文件头部。PLC程序的块名、变量名、符号名用英文块标题和网络注释用中文。中文注释的行长度控制在40个汉字以内避免因为自动换行或者字符转换出现意外。涉及DNC传输的在线加工文件首选无中文注释版本如果需要查看工艺流程用独立的工艺说明文档管理。5.2 固定注释模板比临时发挥可靠得多吃过乱码的亏后我现在给客户做程序标准模板时会在程序头部集中放固定格式的说明类似如下格式这个模板的好处是信息完整关键路径方便检索和追踪(项目量产物料A45-02T粗加工) (程序号O1010机床M03) (刀具D12平底刀主轴转速S800进给F350) (日期2024-05-20作者ZhangSan)如果你把作者、版本、日期都放在每个运动的中间注释里一旦要改版全程序都是注释非常冗长还不利于传输。放在头部后续维护时可以直接在系统侧查看也方便DNC传输后做版本比对。PLC程序也一样每个功能块开头注释最好固定写“功能说明、输入输出变量说明、修改记录”三块。这样的话即使你设计得不算精巧后来人也不至于看半天看不懂。5.3 编码转换和备份一定要作为维护流程的一部分数控系统的程序备份千万不要只在U盘里留一份。828D的系统备份和PLC备份840Dsl的NC程序归档、PLC项目归档、报警文本文件应该分门别类存放。归档格式最好能保留两套一是原厂的归档压缩包二是导出的文本/PDF版本。文本版本会出现编码问题但作为灾备信息哪怕乱码也还能人工看出一部分内容。同时每台机床旁边建议留一张“程序编码备忘卡”上面写明这台机床程序使用的字符编码、文件传输方式、DNC软件的传输模式。这个卡片是我在一个汽车零部件厂推广的效果出奇好后来再没出现过因为编码问题被叫去现场解决的状况。说到底中文注释本身没有原罪很多人是栽在注释之外那些看不见的编码环节上。把注释规范好了、传输链路固定了中文注释就能踏踏实实成为设备调试和排查故障的好帮手而不是定时炸弹。