阅读目录 · English

DXF专题：DXF页面与导入 → 孔位表与工艺 → DXF后处理 → G196扩孔实例

孔位表一章讲清了每个孔怎样保存自己的工艺。本章沿着这些值，依次读懂“生成G代码”、JavaScript后处理、完整程序拼接和“保存载入”。

继续使用四孔图：G81、刀号0、主轴转速1000、R平面2、进给600，停留位置选择“初始平面”。原NO.2（圆心40,10）的孔底Z为−7，其他孔为−5。选择“不排序”，把原NO.2置顶，再按“等于2”筛选，留下三个半径2的孔。程序头和程序尾在本章第3节填写。

1．“生成G代码”先把十项参数交给后处理

现在看 env/dxf/generatecode。第一层循环遍历孔，第二层循环遍历十项工艺，把每个孔的工艺存入 #6001.itemdesc[p]。

这里与导入循环的临时变量用法不同：#6002.channel 表示原始孔号，#6002 主值表示工艺项号。原赋值语句为：

#6001.itemdesc[#6002.channel]=#6001.itemdesc[#6002.channel]+#[6003+#6002].item[#6002.channel]

内层从工艺项0走到9，依次读取 #6003～#6012；每项之间加冒号，最后一项后不加。外层换到下一个原始孔，再从空字符串开始拼接。它会整理所有孔的工艺，后面的内置生成操作再根据勾选决定取哪些孔。

因此，原NO.2置顶后仍读取 #6007.item[1] 得到−7，写入 #6001.itemdesc[1] 的第5个工艺字段：

0:0:1000:0:-7:2:1:2:1:600

依次为：类型、刀号、转速、退刀方式、孔底Z、R平面、G82停留、G83啄孔深度、G83间隙、进给。数值的显示小数位可能不同，字段位置不变。G81不使用中间的G82/G83专用值，但仍保留它们的位置。

随后是生成与显示的关键三句：

#6000.description=widgetFunc["dxfDrill","","",0]
widgetFunc["PlainTextEdit","drillTextEdit","clear",""]
widgetFunc["PlainTextEdit","drillTextEdit","insertText",#6003.description+#6000.description+#6004.description]

第一句把图形和工艺转换成NC正文；第二句清空旧文本；第三句拼接完整程序。

注意同一个参数的不同字段可以承担不同任务：

看见同一个参数号，不要忽略后面是 .item 还是 .description。

2．JavaScript怎样接到圆心，又怎样返回程序文字

dxfDrill先取得选中孔的圆心和排序结果，再把几何与工艺一起交给运行目录下的：

extScripts/processComplexVerticesMap.js

它是组态能够修改的后处理文件。C++负责读取图形、整理数据和调用它；客户修改输出格式时，通常从这个JS文件入手。

后处理运行时得到两个全局名称：

用一个孔说明数据形状：

{
  "drill0:0:0:1000:0:-7:2:1:2:1:600": [
    [ { "x": 40, "y": 10, "z": 0 } ]
  ]
}

键名开头的 drill0 是生成任务编号，后面才是十项工艺。点数据是两层数组，钻孔点的 x/y 提供孔中心，钻孔深度仍取键名中的工艺Z。

在 processDrillKey 内，key.split(":")切开这些字段，G81分支生成：

vertexStr = "G" + gPrefix + "G81" +
            "X" + vertex.x.toFixed(3) + "Y" + vertex.y.toFixed(3) +
            "Z" + field5 + "R" + field6 + "F" + field10;

其中 gPrefix=98+退刀方式数值，所以0形成G98，1形成G99。G82分支另加P，并把页面上的停留值乘1000；G83分支另加Q和K。这是本文件的实际生成规则，不能用其他系统的后处理格式替代。

文件后面的总处理部分还负责按刀号排列、换刀和主轴语句：

• 非零刀号切换时生成 TnM6 和 G43Hn。
• 刀号0跳过这组换刀语句，但有转速时仍会生成 M3S...。
• 钻孔组结束时生成G80；需要结束主轴组时生成M5。
• 当前纯钻孔分支没有自动补M30，本例通过“程序尾”提供。

整个JS执行后的结果字符串返回给 dxfDrill，再回到 #6000.description。这里是生成并返回文字，不是将这些G代码立即交给NC执行。

每次生成都会重新读取这个JS文件并创建新的脚本执行环境。它不依赖上一次调用遗留的JS变量；文件位置按软件工作目录解析，和 env/dxf/ 不是同一个目录。

改后处理时，怎样保持输入和返回方式

parts[0] 是 drill0 这样的任务名，不是钻孔类型。十项工艺位于 parts[1]～parts[10]：类型在1、刀号在2、转速在3、停留位置在4、孔底Z在5、R在6、P的输入值在7、Q在8、K在9、进给在10。保持这些位置，原UI和原生成脚本才能继续配合。

原文件先定义 processDrillKey、processNonDrillKey，最后立即执行总处理并返回字符串。它的结束结构是：

    return result;
})();

软件取得的是整个文件这次执行的返回值。只添加函数定义、只打印文字、或自行写出一个文件，都不会自动把NC文字放进页面。要改钻孔行格式，通常修改 processDrillKey；要改换刀、主轴和分组结束语句，修改后面的总处理，保留最后的字符串返回。

这是软件内置的Qt JavaScript执行环境。dataMap、outputFlag 由软件提供；普通组态宏变量和 widgetFunc 没有直接作为这两个全局对象的一部分传入。需要新增工艺时，应由组态整理后随工艺字符串传递，不要把 #6007.item[1] 原样写成JS表达式，也不要直接套用Node的 require("fs")。

JS文件打不开或执行报错时，当前调用返回空字符串；已有头尾拼接仍可能留下“只有程序头和程序尾”的文字。因此，看到文本框不为空，还要确认其中确实出现了所选孔的钻孔行。

3．程序头、程序体和程序尾怎样合在一起

三个多行编辑框看起来相似，保存方式却不同：

所以程序头尾改完要让输入框失去焦点，再生成。程序体只是当前编辑器中的文字，不能靠保存默认工艺来保存它；孔位表一章介绍的整页刷新时它也会清空。

在原页面的“程序头”填写以下内容，最后一行后保留换行：

G90G17G40G49G80
G54
G0Z10

在“程序尾”填写，同样保留末尾换行：

G0Z10
M30

这些是本例明确填写的内容，页面不会自动为所有客户选G54或设Z10。数值采用机台当前单位，本例程序未发出G20/G21切换单位。

然后点生成G代码。

点击截图可查看原图。

点击截图可查看原图。

本例完整输出如下，也可下载生成的NC文本：

G90G17G40G49G80
G54
G0Z10
M3S1000 (SPINDLE ON CW)
(--- BEGIN DRILL CYCLE ---)
G98G81X40.000Y10.000Z-7.000R2.000F600.000
(--- BEGIN DRILL CYCLE ---)
G98G81X10.000Y10.000Z-5.000R2.000F600.000
(--- BEGIN DRILL CYCLE ---)
G98G81X10.000Y35.000Z-5.000R2.000F600.000
G80 (CANCEL CANNED CYCLE)
M5 (SPINDLE STOP)
G0Z10
M30

现在可以逐项对应：第一孔为40,10、Z=−7；接着为10,10和10,35、Z=−5；40,35因筛选没有生成；刀号0没有产生换刀语句，但仍然有M3S1000。

左边的连接线表示孔位处理路径，不是G81内部下钻和退刀的完整三维轨迹。需要检查实际循环效果时，应对保存后的NC程序使用软件的程序预览和仿真功能。

拼接操作没有自动补换行。若程序头最后没有换行，最后一条指令可能与生成段开头接在同一行。另一个常见误操作是在“程序体”里手工修改后又点“生成G代码”：原脚本会清空并重建文本，手工修改会被覆盖。

4．“保存载入”怎样接回原来的加工流程

确认程序体内容后点保存载入，输入文件名，例如 dxf-drilling.nc。

loadgcode先读取编辑器当前内容：

#6002.description=widgetFunc["PlainTextEdit","drillTextEdit","plainText",0]

选择路径后，它调用 savefile保存这段文字，再设置程序页面要用的数据。主要关系是：

点击截图可查看原图。

图3　已经载入生成的NC文本；左侧保留的图形来自DXF阶段。载入文件与重新仿真加工程序是不同操作。

保存的是编辑器此刻的内容，因此保存前在程序体内作出的手工修改也会写进文件。原脚本还检查 #929.item[4]，当前配置名称为开启逆向加工。值为1时，这条保存载入路径会请求仿真并生成逆向路径；值为0时，只完成保存和载入。本例使用关闭状态。

原脚本在加工或暂停状态下会直接退出保存载入操作。生成后的加工启动、暂停、恢复仍然使用启动、暂停、恢复和停止介绍的原有调度流程。

5．今后定制DXF功能，从哪一层改起

本例的组态方法可以概括为一条具体的数据路线：

DXF文件 → 内置读图 → 孔位编号和圆心
                         ↓
默认工艺 → 每孔参数 ← 原生表格和输入框
                         ↓
                    筛选、排列
                         ↓
              JS把几何与工艺写成NC文字
                         ↓
             程序头 + 生成段 + 程序尾
                         ↓
                保存文件 → 标准程序页

内置读图和几何处理提供基础能力，组态决定用户填写什么、怎样组织每孔数据，JS决定输出怎样的程序文字。理解这几个交接位置，就能判断新需求需要修改哪些文件。

沿一个实际值走完设计过程

回到本例原NO.2的孔底Z=−7，从页面到输出逐步对应：

这也给出了定制时的检查顺序：先看输入写到了哪里，再看工艺字符串，最后看JS取的是哪个位置。不要在输出不正确时，同时修改表格、排序和后处理，失去对应关系。

增加工艺字段时，要把每一个交接位置接上

当前原脚本使用 #6002.itemnum 作为工艺项数，又按 6003+项号 查找每孔参数。直接给 #6002 加一个子项，导入和保存循环就会访问下一个参数号；这不是只在默认表末尾多显示一行。 扩展前先确认该参数号在实际工程中没有其他用途，不能根据本章就认定 #6013 可以随意占用。

一次完整扩展应依次处理：定义新项的默认值、输入类型和中英文名称；导入时为每个孔建立相应子项；在正确的工艺区放入按原始孔号绑定的输入；决定“保存参数”是否复制该值；在生成工艺中固定字段位置；最后让JS读取并使用它。若新项不适合继续使用连续参数号，就要同时改导入、保存和生成三处的取值方式。

可以先用本页已有G82练习这条路线：找到停留输入 lineEdit_17，沿 #6009.item[p] 找到工艺的第7项，再找到JS的 parts[7] 和乘1000的处理。这样无需增加新控件，就能理解一个完整工艺项是怎样接入的。

交付时只打包实际修改的UI、组态脚本、语言词条及后处理文件；新增参数要提供只补所需字段的安装步骤。原目录中的 dxf-install 导入整份参数定义文件，可帮助追溯参数来源，不应在已有客户配置上当作普通“刷新”脚本反复执行。包的组织方式见组件部署。

6．轮廓法线跟随，可以接着怎样扩展

现有 processComplexVerticesMap.js 的 processNonDrillKey 已有轮廓跟随处理：轮廓点的 z在这条数据通道中表示预先计算的切向角，生成代码再以 C=z-90 等处理形成旋转轴角度；实际切深来自另一项工艺参数。

这和钻孔点的z含义不同，也不是本章钻孔十项参数的另一种填法。扩展页面时，需要选择成对的轮廓初始化与生成操作，定义安全高度、切深、进给和延伸量等输入，再把正确的轮廓数据送给已有JS分支。不需要先重写一套法线算法，也不能只打开DXF开关就认为标准钻孔页已经具备轮廓输入。

具体交接位置可以这样对照。右列是后续扩展要接入的设计，当前标准页面仍使用左列：

两类初始化都使用 #6001 保存对象清单。设计模式切换时，应重新建立对应清单，不能拿上一模式的孔编号和工艺去解释轮廓。这是另一条完整的页面接入流程，不能只替换“生成G代码”中的一个函数名。

详细接入关系见已有法线跟随设计。需要AI协助修改后处理时，可参考针对实际数据格式的提示词，同时保留本章已讲清的输入字段和输出规则。

7．遇到问题，先检查这些位置

掌握这条“页面输入 → 每孔参数 → JS → NC文字”的路线后，下一章在现有页面增加G196扩孔，把一次完整的工艺扩展做出来。

上一课：孔位表与工艺 · 阅读目录 · 下一课：G196扩孔实例