阅读目录 · English

学组态时，经常会遇到这样的情况：已经写出一条公式或几行条件判断，想先看看结果，再把它放进按钮脚本。程序页面原有的三个入口就可以完成这件事：开发者模式主脚本、开发者模式第二脚本和MDI。

本篇使用原有功能键、输入窗口和便签帮助。先顺着原UI和脚本看清输入怎样保存、执行入口怎样选择、便签树怎样由参数字段组成；最后在原分类中追加一条便签，学习如何沿现有结构扩充内容，并保持页面和共用处理脚本不变。

1．先把入口放到程序功能键区

进入程序页面。按前面功能键配置的方法登录开发者权限，在要配置的功能键上右击，从菜单选择相应功能。

点击截图可查看原图。

图1　原菜单局部。本例的MDI已经分配到F7。

本例把F4设为开发者模式主脚本，F5设为开发者模式第二脚本，使用原F7位置的MDI。F4、F5只是本例选择的位置；配置前记下原功能，学习结束后可从同一菜单选回。某项已经分配到其他位置时，应先检查已有按钮。

开发者登录与功能是否显示是两个条件。标准组态还用“开启开发者权限”对应的 #929.item[6] 控制这两个开发者菜单项是否出现。已经登录却看不到时，应检查这项配置和当前功能分配；不要通过改登录身份参数来代替正常登录。

先记住三者的用途：

三个窗口都能输入文字，但执行入口不同。后面把代码接到正式按钮时，要沿用与其用途相符的入口。

2．在主脚本窗口计算12×8

点击刚配置好的开发者模式主脚本。先保留窗口里原有的内容，再输入下面三行；本例会使用 #100、#101 和显示结果用的 #9999。

#100=12
#101=8
#9999=#100*#101

点击右下角执行。下方显示 调试信息：96。

点击截图可查看原图。

逐行看就很容易理解：第一行准备12，第二行准备8，第三行计算乘积，并把它写到本窗口用来显示结果的参数。

结果栏不会自动列出所有变量。 本例能看到96，是因为最后一行主动给 #9999 赋值。若只计算另一个参数，想在这里查看它，就要把要看的值写入 #9999。

现在只把第二行的8改成12：

#100=12
#101=12
#9999=#100*#101

再次点击执行，结果变成 调试信息：144。

点击截图可查看原图。

每次点击都会重新运行输入文件中的整段代码。这里的前两行每次都会重新赋值，因此不是在上次结果上继续乘。

3．关闭再打开，代码为什么还在

关闭这个窗口，再从同一个功能键打开。刚才的三行代码仍在，结果栏却会先清空；再次点击执行，才重新得到144。

原因是两件事分别处理：

• 输入区对应一份文件。离开输入区时，控件把文字写回文件；点击“执行”会先让输入区失去焦点，再执行刚保存的内容。
• 打开窗口的脚本会清空 #9999。它清的是显示结果，没有清掉输入文件。

主脚本的输入文件是 env/mdi/mainParser。它没有扩展名，仍是一份脚本文本。窗口上方会显示类似 MDI:env/mdi/mainParser 的路径；实际路径前缀由当前环境目录决定。

这里的“MDI:”是几个窗口共用的文件提示文字，不能据此判断当前是否在执行NC程序。 应结合打开的功能、窗口标题和后面介绍的“执行”按钮设置来区分。

输入文件是可反复编辑的工作文件。要保留一段已经写好的功能，应另存为有明确用途的脚本；不要把这里的草稿当作唯一备份。运行目录也需要有写入权限，否则输入内容无法正常保存。

4．第二脚本怎样使用

打开开发者模式第二脚本，同样输入第一组12×8的三行代码，点击执行，得到96。

点击截图可查看原图。

这个窗口保存到 env/mdi/auxParser，不会把主脚本文件中的12×12覆盖掉。两个文件分别保留各自的输入内容。

主脚本和第二脚本都使用组态脚本的语法。对于按名称查找控件的操作，例如 widgetFunc 的 PlainTextEdit 操作，它们的一个重要区别在于从哪个窗口查找控件：

例如，同样写 plainTextEdit，必须先弄清是哪一个窗口里的输入框。某个控件在当前辅助窗口中存在，不表示主界面也有同名控件。

部分宏函数还允许用参数另选目标窗口，使用时应按该函数的说明处理，不能仅靠“主脚本／第二脚本”的名称判断全部行为。

“第二脚本”也不是主脚本执行完后自动接着执行的第二步。它有自己的入口；选择它，不会自动建立两段脚本之间的先后关系。不要把它当作让长循环自动转到后台运行的开关。

5．在MDI中运行一小段NC循环

下面改用MDI入口，计算1＋2＋3。先使系统空闲并解除复位，保留原输入内容后，输入：

#100=0
#101=0
WHILE#100<3DO1
#100=#100+1
#101=#101+#100
END1
#9999=#101

点击执行，完成后下方显示 调试信息：6。

点击截图可查看原图。

当 #100 等于3时，#100<3 不再成立，程序离开循环，把最终和写入 #9999。

这份输入保存在 env/mdi/macroMDI1.nc，由NC解释器执行。本例只含赋值和循环。MDI也能执行实际NC动作；以后加入G代码或M代码时，要按对应指令确认坐标、速度和机台条件。

点击执行是提交NC运行请求。 NC调度接到请求后才处理程序，按钮动作结束不能作为NC已经完成的依据。系统复位会阻止NC继续执行；有其他NC任务占用时，也不能按空闲状态连续提交。

因此，MDI没有得到结果时，应先看复位、忙碌和错误提示，再查输入内容。不能靠重复点击或随意加延时来解决运行条件问题。

6．右侧便签怎样用参数和共用脚本组成

便签值得学习的地方，是把“每一条内容”放在参数里，把“所有条目共同的动作”写成脚本。增加内容时，沿用原来的树控件和处理脚本即可，不必为每条便签另建一个按钮。

整个设计分三部分：

下面用原有的 B类宏程序语句 → IF GOTO 顺着这三部分看一遍。

点击截图可查看原图。

6.1 一个分类是一个参数，一条便签是它的一个子项

原“B类宏程序语句”使用 #9003。当前标准配置有4个子项，分别存放GOTO、IF GOTO、IF THEN和WHILE片段。以第1项IF GOTO为例：

itemtitle不是本例第一列的文字，itemdesc也不是双击时插入的代码。 这些字段的具体用途由UI和脚本约定。例如这里把 itemunit 用作图片路径，就不是把它作为毫米、度等单位显示。

中文文字来自 env/i18n/translatPack-0 中的 #9003 定义，英文文字来自 translatPack-1。子项类型、分类等结构还来自已有配置数据，不能只看语言包就把整个分类的定义过程理解完。

6.2 树控件怎样读取这些参数

在 env/mdi/mdi-main.ui 的 treeWidget 上，原 accessibleDescription 是下面两段。mdi-aux.ui 采用相同的便签规则。

{
-标题：(#1009_itemtitle7),500,5
-标题：(#1009_itemtitle8),200,5
-属性：-D
-T(0<<#1<<#2)
-事件: (treeDoubleClicked:/env/mdi/inserttip[1])
-事件: (treeClicked:/env/mdi/tiphelp[1])
}

{
-nodenum:#%0_itemnum
-nodeserial:0
-nodeinterval:1
-nodetitle:#%0_title

-rows:30
-serial:9000

-过滤器(#%0classify==4)
-结点过滤器(#[%%].itemtype%0==14)

-列：[-T1(#[%%].item%0) -D]
-列：[-T1(#[%%].itemtitle%0) -D]
}

第一段定义列标题、选择结果和事件。两列的标题分别从 #1009.itemtitle[7]、#1009.itemtitle[8] 取得，中文显示为“便签集”“描述”。500和200是原设定的列宽；窗口较窄时，第二列可能在右侧，需要横向滚动或拖动表头调整列宽。

第二段定义树的内容，按下面的顺序理解：

这里的 -T1 指定按字符串显示，不是“第1列”。虽然数据的 itemtype 是14，便签树中的两列仍按字符串标签显示；类型筛选与显示方式是两件事。

MDI窗口 mdi.ui 的顶层过滤条件改为 classify==3，所以会列出G指令集、M指令集等NC便签。两个脚本窗口共用分类4的资料，MDI读取分类3的资料。 如果一条资料只在MDI出现，先检查所属分类，不要急着改显示脚本。

6.3 %0和%%在这里怎样对应到具体字段

这些写法让同一组列规则可以用于很多分类和很多条目，不需要把 #9003、下标1逐个写死在UI中。

在上层建立分类时，#%0按当前分类参数解释。例如正在处理9003时，#%0_title读取 #9003.title。

进入该分类的条目后，本例把分类参数号作为 %%，把子项号作为 %0的基准。因此，在IF GOTO这一行：

这是这份树定义中的对应关系，不能把 %0在其他表格、其他层次中的含义也一律解释成便签下标。过滤掉一些条目以后，剩余条目仍对应原参数下标，不会按屏幕上可见的第几行重新编号。

6.4 单击时，先确定是哪一项，再调用帮助脚本

第一段中的这行是两个共用脚本能够工作的关键：

-T(0<<#1<<#2)

开头的0表示：从被点击条目的第0列控件绑定的数据项识别其来源。随后把参数号写入 #1，把子项号写入 #2。这里不是把第一列的“IF GOTO”文字交给脚本，也不是读某个叫 #0 的选择结果。

选中IF GOTO后，相当于为后续脚本准备：

然后原事件调用 env/mdi/tiphelp。它的完整内容是：

widgetFunc["PlainTextEdit","plainTextEdit_2","clear",0]
widgetFunc["PlainTextEdit","plainTextEdit_2","insertText",^1.itemdesc[#2]]

widgetFunc["Label","label_5","setMovie",^1.itemunit[#2]]
debug ^1.itemunit[#2]
widgetFunc["Label","label_5","playMovie",0]

^1表示间接取参数：先读 #1中的9003，再去访问参数9003。于是 ^1.itemdesc[#2]在本次选择中就是 #9003.itemdesc[1]。共用脚本不需要知道你选的是IF、WHILE还是另一类资料。

前两行清空帮助框，再填入本条详细说明。后面几行把 itemunit中的路径交给 label_5，设置并播放动画；其中 debug还会把路径写到调试信息。路径为空时，不应把底部清空误认为计算失败。

原 label_5还有自己的显示条件：

-C(^1.itemversion[#2]==1) -V0

这里的 -V0表示用第0个条件决定控件是否显示；0是条件编号。前面的条件是 ^1.itemversion[#2]==1，因此，本例借用所选条目的 itemversion字段作为图片显示标志：值为1时满足显示条件。增加图片说明时，应同时核对资源路径、资源文件和显示标志。

6.5 用MDI中的G41看清文字、图片和代码怎样配套

IF GOTO便签没有图片。换到原MDI窗口，展开右侧的G指令集，找到第一列的 G41D；对应描述为左偏刀具半径补偿。先保留原输入内容，再单击这一项。

下方“帮助”区会显示G41说明，图片区开始播放原有的刀具补偿演示动画。帮助内容较长，可以在文字框内滚动查看；图片在同一帮助区的下方。

点击截图可查看原图。

图7　原窗口右侧局部。可拖动分隔条，给文字和图片留出足够空间；图中保留原字体和原图片，截图记录动画播放中的一个画面。

这个实例用的是 #9007的第41项。沿着前面已经学过的选择传参规则，单击后 #1=9007、#2=41，共用脚本就能找到这一组内容：

原语言脚本已经把图片路径和待插入片段分别定义好：

#9007.itemunit[41]="images/g41.gif"
#9007.item[41]="G41D"

这两行是原设计的摘录，阅读时无需重新执行。说明文字来自 translatPack-0或 translatPack-1，而分类、条目类型及显示标志还要结合现有参数配置理解。

单击后的处理顺序是：

1. 树控件把9007和41交给 #1、#2。
2. tiphelp用 ^1.itemdesc[#2]取得G41的说明，填入 plainTextEdit_2。
3. setMovie用 ^1.itemunit[#2]取得 images/g41.gif，把这份资源设置到 label_5。
4. playMovie让这个标签开始播放已经设置的动画。

图片路径按软件进程的工作目录查找。标准启动方式下，本例资源位于运行目录中的 images/g41.gif；它与 env是同级目录。交付图文便签时，必须把资源文件按路径一起打包，单独拷贝参数或脚本不会自动带上图片。

这里播放的是随便签提供的GIF说明动画。 修改左侧输入内容或D号，不会重新计算这段动画。选择便签也不会发出NC执行请求，不能用这幅演示图判断自己编写的程序是否正确。

接着保留原草稿、清空输入区并点好插入位置，双击 G41D。左侧只插入 G41D，帮助里的长篇说明和示例程序不会一起插入。

点击截图可查看原图。

图8　原MDI窗口。底部“调试信息：images/g41.gif”来自帮助脚本的 debug行；它是资源路径提示。

本例到插入片段为止。G41D还没有填写D号和建立补偿所需的程序内容，不能直接点击“执行”把它当作完整加工程序。查看完可恢复原草稿。

从这个例子可以归纳出给便签配图的方法：在选定条目中分别准备代码、说明和图片路径，把该条目的图片显示标志设为1，再把资源文件放到相应位置。沿用原 tiphelp和 label_5就能显示，不需要为每条资料增加图片控件。中英文说明分别维护在对应语言内容中；本例两种语言共用同一份只有图形和NC代码的GIF。若自己的图片含有语言文字，也应提供对应语言的资源路径。

6.6 双击为什么能在光标处插入片段

双击事件同样先写入 #1、#2，再调用 env/mdi/inserttip。这个脚本只有一行：

widgetFunc["PlainTextEdit","plainTextEdit","insertText",^1.item[#2]]

它把本条 item的文字插入左侧 plainTextEdit，没有清空输入框，也没有发出执行程序的请求。详细帮助与待插入片段分别保存，两段脚本各读自己需要的字段。

原树控件的 focusPolicy设为 Qt::NoFocus。设计意图是让操作者先在输入区放好光标，再点击或双击右侧便签时，保持输入区的编辑位置。

按这个顺序操作：先点击左侧输入区确定插入位置 → 双击便签 → 补全片段 → 点击执行。 点击执行时，输入区失去焦点，原保存规则把新增文字写回文件，然后才运行文件。如果此前焦点在别的按钮上，先点回输入区；不能把“文字已插入”当成“文件已经保存”。

例如插入原IF GOTO只会得到 IF GOTO片段，还需要填写条件和标号。便签不是一组直接执行的功能按钮。

6.7 沿现有分类增加一条计算便签

下面只往原 #9003分类追加一条资料，保留原UI和两个共用脚本。先在独立的开发配置副本中操作。以下代码使用 #100暂存新下标，在开发者模式主脚本中运行一次：

#100=#9003.itemnum
#9003.itemnum=#100+1
#9003.itemtype[#100]=14
#9003.item[#100]="#9999=12*8"
#9003.itemtitle[#100]="12*8=96"
#9003.itemdesc[#100]=#1009.itemtitle[5]+"96"
#9003.itemunit[#100]=""

原分类有4项，因此本次追加在下标4，不会改写0～3的原便签。这段代码的作用依次是：记录新下标、扩展子项数、满足条目过滤条件、填写待插入代码、填写第二列说明、填写帮助、留空动画路径。

#9003.item[#100]右侧的代码放在引号内，定义便签时只保存这段文字；真正的12×8要等插入后点击执行才计算。详细帮助复用当前语言的“调试信息：”标题，在中文版显示“调试信息：96”，英文版显示“Debugging information:96”。

运行定义后，关闭输入窗口，再打开开发者模式第二脚本。展开原“B类宏程序语句”，会看到新增的 #9999=12*8。单击显示本条帮助；保留原输入后清空编辑区，点击编辑区，再双击新条目，输入区出现 #9999=12*8。点击执行，结果为96。

点击截图可查看原图。

图9　只新增一条参数数据。为了同时看清“便签集”和“描述”，原表头列宽已作拖动调整；页面和处理脚本沿用标准设计。

完整定义文件见追加计算便签示例。这是一次追加操作，每运行一次都会再追加一项，不能放到周期脚本中反复运行。

6.8 从这个例子推广到自己的资料库

修改已有条目时，按原参数号和子项号更新相应字段。增加条目时，保留原内容，在末尾扩展子项数；增加分类时，还要定义分类名称、分类值和子项集合，并确保参数号落在当前UI扫描的9000～9029范围内。选择新参数号前，应按项目的参数登记检查占用，不能看到空项就认定它永远可用。

-D用于刷新已建立控件的内容，不等于在 itemnum变化后自动增加树节点。修改分类、子项数量或过滤条件后，最直接的做法是关闭再打开该窗口，让树重新按定义建立。

正式交付时，把参数定义纳入组件部署流程，记录分配的分类号和条目号。安装完成后的日常启动不应再次无条件追加；后续更新应维护已经分配的项。中文和英文的标题、详细帮助应纳入相应语言设置，避免只改当前内存值、切换语言后又被原语言包覆盖。本例使用现有语言标题拼接帮助；若以后要随语言切换即时更新这段新帮助，也应在语言处理时重新赋值。

排查新增便签时，沿同一条链检查即可：

这套方法同样可以组织常用公式、按钮脚本片段、工艺说明和标准NC片段。新增便签只是提供文字与帮助，不会给解释器增加一种新指令；片段仍须采用目标解释器已经支持的语法。

7．沿着原文件看完整过程

下表中的路径以软件运行目录为起点。

7.1 功能名称怎样找到入口

前面已经认识 #913 和 #914。在程序功能区，功能8是MDI，功能9是主脚本，功能10是第二脚本。菜单标题在 #913 中；按钮分配和对应事件在 #914 中。

以主脚本的鼠标松开事件为例，原功能定义包含：

-A: (MouseButtonRelease:/env/mdi/mdi3[1])

这一步的 [1] 负责运行打开窗口的组态脚本。它还没有运行输入区的 mainParser。不能因为入口这里写了 [1]，就说主脚本窗口中的代码也交给辅助解释器执行。

7.2 打开脚本怎样选择输入文件

mdi3 在准备好参数后执行下面这一段：

#1009=2
#1009.title=#1009.itemtitle[2]
#1009.item[0]=#405+"mdi/macroMDI1.nc"
#1009.item[1]=#405+"mdi/macroMDI2.nc"
#1009.item[2]=#405+"mdi/mainParser"
#1009.item[3]=#405+"mdi/auxParser"
#9999=""
MarcoDialog "/env/mdi/mdi-main.ui"

#1009 的值2选中第2项，因此不写下标的 #1009.item 在这里取到 mainParser 的路径。#405 提供环境目录前缀。第二脚本选第3项，原MDI入口选第0项。

第1项的 macroMDI2.nc 是另一份MDI输入文件，与“开发者模式第二脚本”不是同一项。不要把文件名中的2与菜单名称中的“第二”混在一起。

原脚本前面还有参数初始化部分；标准环境已经为 #1009 配置了标题等字段。阅读时应保留完整文件及现有参数定义，不要只复制初始化片段去覆盖当前配置。

7.3 输入框为什么能直接读写文件

原 QPlainTextEdit 输入框的设置是：

-T(#1009.item) -D

#1009 的对应子项被定义为文件名类型。于是输入框读取选中的文件，并显示文件内容；离开输入框时，再把编辑后的文字保存回去。-D 让控件按绑定内容刷新。

这里不是把整段代码存进 #1009.item：参数存文件路径，文件存输入文字。 这是理解这几个窗口最有用的一点。也不要把这里的自动保存行为套用到所有多行输入框，它还取决于字段类型和控件设置。

7.4 执行按钮才决定使用哪个解释器

主脚本窗口的原按钮设置：

-T(#1009_itemtitle6)
-事件: (clickedEvent:/env/mdi/mainParser[0])

第二脚本窗口的原按钮设置：

-T(#1009_itemtitle6)
-事件: (clickedEvent:/env/mdi/auxParser[1])

MDI窗口的原按钮设置：

-T(#1009_itemtitle6)
-事件: (clickedEvent[2]("mdi/"+#1009.item/"/"))
-C(#319.item3==1) -E0

前两个明确指定组态脚本文件和编号。MDI从选中的路径取出文件名，组成NC调用路径，使用 [2] 提交执行；下面的条件在NC启动状态为1时禁用按钮。实际执行仍要满足NC调度的运行条件。

因此，开发时要分清两次调用：功能键先打开窗口，窗口里的“执行”按钮再运行输入文件。

7.5 结果栏怎样显示

底部标签的原设置是：

-T(#1009_itemtitle5+#9999) -D

前半部分是随语言切换的“调试信息：”，后半部分是当前结果。它是一个显示参数的标签，没有另外建立一份逐行运行记录。不同脚本或帮助功能写入 #9999 时，这里的文字也会改变。

8．把这里试好的代码用到正式功能中

开发一个按钮功能，可以按下面的顺序进行：

1. 先算对。 在相应入口写最小一段代码，给定输入，把需要观察的值写入 #9999。
2. 换几组数。 检查正常值、边界值以及分支条件；循环应有明确结束条件。
3. 另存功能文件。 给文件起能说明用途的名称，放到该功能所属目录。
4. 接到已有按钮。 组态脚本按需要选主脚本或辅助脚本入口；NC程序使用NC入口。操作控件时重新核对所在窗口。
5. 从正式入口再做一遍。 原来为了观察结果而写的 #9999，不一定就是最终页面的显示参数；按最终页面的设计接好输入和显示。

遇到问题时，可按下表排查：

接下来回到主界面的轴配置，继续看菜单选择如何写进共用参数，并让坐标行显示或隐藏。需要观察其中的计算和参数值时，就可以使用本篇介绍的入口。

上一课：右键菜单和多级菜单 · 下一课：轴配置 · 阅读目录