1. 先说清楚球标到底是个什么东西为什么值得单独拿出来写1.1 一张装配工程图里球标是那个绕不开的圆做CREO二次开发久了你会发现图纸上能让出图工程师最烦躁的往往不是尺寸标注而是那一圈一圈的球标。球标就是装配图里带圆圈的数字序号它和BOM表一一对应告诉你图上这个圈里的件在明细表里是哪一行。零件一多比如上百个零件的装配体光靠手一个个点球标、调引线、对位置一天的时间就耗进去了。我最早接触球标函数是在给一家做非标设备的客户做图纸自动化工具的时候。他们的总装图每次改版都要重新核对BOM、重新补球标手工操作两三个小时是常态改一版错一版。后来我把球标这块用CREO Toolkit的API做了批处理两分钟就能跑完全部图纸从那以后我才真正意识到球标这个看起来不起眼的“小圆圈”在二次开发里的价值被严重低估了。这篇内容就是围绕CREO二次开发里和球标相关的函数展开讲清楚球标是怎么创建的、位置怎么控制、文本怎么改、批量操作怎么排布以及我实际开发中踩过哪些坑。适合正在做图纸自动化、BOM自动标注、或者想把Creo出图流程提速的工程师参考。1.2 开发前先理清图纸对象的关系链在动代码之前得先理解CREO工程图里的对象层次。一张工程图Drawing下面有若干视图View视图里可以显示模型模型可以是装配体Assembly也可以是零件Part。球标并不是单独悬浮在图纸上的它本质上是一种带引线的注释挂在某一个视图上并且通常和装配里的某个元件或者BOM表条目关联。这个关系链决定了你调用API的路径。比如你用ProBomBalloon系列函数背后的逻辑就是从装配BOM表折返回视图再生成球标。如果你用ProDwgBalloon这类函数重点则在“图纸注释”这个维度上。早期我写代码时没分清这两条路结果一个球标创建接口折腾了好几天后来才明白需要看你到底是想从BOM侧生成还是从视图侧生成。搞开发的人容易犯一个毛病上来就翻函数库。我的建议是先花十分钟理清楚你手里的数据入口是装配模型、BOM表还是图纸视图你要生成的球标是挂在哪个视图上这三个问题定了API函数怎么选自然就清楚了。2. 球标相关的核心API与数据模型拆解2.1 Pro/TOOLKIT里球标函数怎么分组CREO二次开发最常用的环境是Pro/TOOLKIT也就是C语言接口。球标相关的函数分布不算散我按用途给你分个组这样查起来有方向。第一类是创建与删除。创建球标的核心函数围绕ProBomBalloon展开比如ProBomBalloonCreate删除用ProBomBalloonDelete批量收集图纸里所有球标用ProBomBalloonCollect。这三个函数是高频使用的其他大部分操作都是在拿到球标对象句柄之后做的。第二类是查询与修改属性。拿到一个球标对象后你经常需要知道它挂在哪个视图、引线指向哪个元件、球标文本内容是什么。相关的有ProBomBalloonReferenceGet、ProBomBalloonTextGet、ProBomBalloonTypeGet等。反过来修改文本内容和球标类型就用TextSet、TypeSet这一类。第三类是位置控制。球标在图纸上的位置包括坐标点位置和引线折点对应的是ProBomBalloonLocationGet和ProBomBalloonLocationSet。这一组函数值得重点研究因为批量排布球标能不能做好看全靠它。第四类是参数相关。有些公司会给球标挂自定义参数比如“是否外购件”“是否必标件”然后用参数值控制哪些零件要显示球标。这部分会用到ProBomBalloonParameterGet和ProBomBalloonParameterSet。我整理个简表方便你对照查文档用途典型函数说明创建球标ProBomBalloonCreate在图纸上创建BOM球标收集球标ProBomBalloonCollect取当前图纸所有球标数组删除球标ProBomBalloonDelete删除指定球标获取位置ProBomBalloonLocationGet拿球标坐标和引线折点设置位置ProBomBalloonLocationSet移动球标到指定坐标获取引用ProBomBalloonReferenceGet拿球标关联的元件或视图文本读写ProBomBalloonTextGet/Set改球标里的数字或文字类型读写ProBomBalloonTypeGet/Set切换球标样式注意一点具体函数签名和常量定义以你安装的Creo版本头文件为准不同版本之间会有细微差异但整体思路没变过。2.2 球标的“三要素”位置、引线、文本缺一个都不行球标在界面上一看就是个圆加数字但在API的对象模型里它是由三个核心要素组成的。位置要素。球标圆心的位置是图纸空间坐标不是模型空间坐标。这就意味着一旦你把球标放到某个位置它不会跟着模型转动而自动改变模型视图变了位置可能就飘了。理解这一点很重要很多初学者以为球标挂在某个零件上零件移动球标就跟着走实际不是这样的。球标的位置是独立存储在图纸上的。引线要素。球标和零件之间靠引线连接。引线可能有一条折线也可能有多个折点。API里拿到的方向点就是折线经过的关键点。批量创建球标时引线折点如果不处理默认会生成一条从球标到视图中心的直引线多个球标重叠在一起时极其难看。文本要素。球标里的内容不一定是纯数字也可能是“3-1”这种带后缀的格式甚至是多行文本。文本和BOM表的行号关联逻辑需要在创建时确定有的公司习惯按BOM顺序编号有的公司习惯按零件在视图中的位置编号这些都是通过文本处理和BOM排序来控制的。我见过很多二次开发工程师把精力全花在创建球标本身忽略了引线和位置的处理结果球标是生成出来了但全部挤成一团还不如手工点。实话说球标创建的一半工作量在位置排布上。3. 实操从零开始写一个批量球标工具3.1 开发环境怎么搭注册文件怎么配CREO二次开发的常规组合是Visual Studio加Pro/TOOLKIT。我用的是VS 2019搭配Creo 8.0安装时选上Toolkit模块然后新建一个DLL工程包含目录指向Toolkit的include文件夹库文件链接对应版本的库。这里有个容易踩的坑Creo的Toolkit DLL注册方式有两种一种是随Creo启动自动加载的异步模式一种是用户点菜单触发的同步模式。球标操作一般放在异步模式下做因为要一次性处理多张图纸异步模式不会阻塞Creo主界面处理完还能弹个结果框。在protk.dat注册文件里最少要包含这些信息name BalloonAutoTool exec_file $ORIGIN/balloon_tool.dll text_dir $ORIGIN startup dll allow_stop true delay_start false revision creo_8把这个文件放到Creo的启动目录下或者在配置选项里指定toolkit_registry_file路径。配置完以后启动Creo时如果日志里能看到你的DLL被加载那环境就通了。3.2 第一步遍历图纸和装配收集需要打球标的零件批量球标工具的第一步是把“要处理哪些图纸、每张图纸对应哪个装配”这两个信息拿到手。我的做法是先定义一个结构体保存图纸名、模型名、视图名然后从外部配置文件读入这个列表。也可以直接遍历当前进程打开的图纸窗口但那样太受限于用户当前会话自动化程度不够。装配里的零件收集用ProBomTable或者ProAsmMdlCollect这类函数可以拿到装配下的元件列表。注意这里要处理一个问题子装配要不要展开如果装配里套了子装配而BOM表是展开到零件级别的那你收集元件时也要递归到最底层零件。反之如果BOM表只到子装配级别就不需要递归。这一步还牵扯到过滤。实际项目中并不是所有零件都要打球标标准件、共享件经常被排除。我的做法是序列化收集到的每个元件再逐个检查它的自定义参数用一个“是否出球标”的参数控制。3.3 第二步创建球标并指定视图和引线搭好零件列表之后核心环节是创建球标。代码逻辑大致长这样ProError CreateBalloonsForAssembly(ProDrawing drawing, ProAsmcomppath comp_path, ProView view, ProBomBalloon* balloon_array, int* count) { ProError err; ProBomBalloon balloon; ProPoint3d location; ProLine3d leader_line; /* 位置初始化为视图中心偏移 */ location[0] view_center_x; location[1] view_center_y; location[2] 0.0; /* 创建球标 */ err ProBomBalloonCreate(drawing, view, comp_path, location, balloon); if (err PRO_TK_NO_ERROR) { /* 设置引线折点 */ leader_line.point1[0] location[0] - 5.0; leader_line.point1[1] location[1] - 5.0; leader_line.point2[0] comp_x; leader_line.point2[1] comp_y; err ProBomBalloonLeaderLineSet(balloon, leader_line); balloon_array[*count] balloon; (*count); } return err; }这段代码我不能保证在你的版本里原样编译通过毕竟每个项目的头文件和约束不同但整体调用流程是一致的先准备球标位置点再创建球标对象再设置引线。位置点如果不想传某些接口也有默认生成逻辑但默认生成的位置经常不好看我建议还是自己计算。视图的选择也要注意一张图纸可能有多个视图同一个零件也可能出现在多个视图里。通常球标只标在主视图或者明细视图上不能每个视图都打。我用一个视图过滤规则优先选图纸里比例最大的那个视图或者选带BOM表注释的那个视图。3.4 第三步批量位置排布和避让球标创建完后最花功夫的是排布。所有球标初始位置都在视图中心附近不处理的话就是一团乱麻。我的排布思路分成三步走。先统计球标数量确定大致布局形状。数量少时按单列排数量多时按多列蛇形排。比如50个球标我会算出来用两列每列25个列间距大概是球标直径的三倍。再计算每个球标的目标坐标。按照BOM顺序从左上角开始往下排每个球标间隔相等。这里有一个关键点球标位置必须相对于视图位置计算不能相对于图纸原点计算否则视图平移后球标位置就会错乱。我当初因为忽略这个问题被现场工程师截图骂了一顿。最后做引线交叉避让。这一步最费时间我用的是一种比较笨但稳定的贪心算法先排完所有球标再对每条引线做交叉检测如果发现交叉就把其中一个球标往旁边偏移反复迭代几次。这个算法虽然不是最优解但工程上够用而且跑得快。位置写回用ProBomBalloonLocationSet传入新的坐标数组一次性把所有球标的位置更新掉这样Creo界面上的刷新操作也只发生一次效率高很多。4. 常见问题与排查技巧实录4.1 球标位置乱跳或者干脆跑到视图外头这个问题出现频率最高而且多在“图纸打开后被脚本修改”的场景下发生。球标位置的坐标是图纸空间坐标如果你用ProBomBalloonLocationGet拿到位置后直接拿这个值去写另一个视图的球标位置大概率是错的。我的排查经验是先把视图的变换矩阵取出来把图纸坐标转成视图坐标系再做偏移。Creo的API里视图坐标转换相关的函数有好几个我最常用的是按视图原点偏移换算处理简单场景足够了。球标跑到视图外面还有一个原因是创建时没有传有效的引线参考。某些版本里如果你创建球标时引线指向的零件不在当前视图中球标会被默认丢到图纸左上角。解决方法是创建之前先判断零件在当前视图中是否可见不可见的直接跳过。4.2 BOM表一改球标序号就对不上了这个坑我也踩过不是球标的错是BOM排序和球标文本没有同步。球标里的数字通常对应BOM表的行号但BOM表的行号会随着你添加、删除零件而变化。如果你只批量生成了球标后期BOM变动了球标不会自动重新编号。我的办法是写一个“重新编号”功能每次图纸变更后调用。先把所有球标收集起来按引线指向的元件在BOM表中的实际位置排序然后把从1开始的序号重新写进球标文本。这样即使BOM变了只要球标关联关系还在一键就能刷新编号。刷新编号还要注意一个细节BOM表可能存在多级折叠行号是显示出来的行号不是内部序号。我用的做法是拿到BOM表每一行的实际索引然后跳过折叠隐藏的行按显示顺序编号。4.3 大批量创建球标运行速度像蜗牛几百个零件的装配体逐个创建球标和设置位置如果每次调用API都触发界面刷新时间会非常可怕。我第一次写这个工具时没做任何优化400个球标跑了将近十分钟现场差点摔鼠标。优化方向有两个。一是尽量批量操作。Creo的Toolkit里很多函数支持数组参数比如一次传入多个球标对象统一设置位置比一个一个设置快很多。二是延迟重绘。在脚本处理期间利用某种后台方式将UI刷新暂时挂起等所有球标处理完再统一刷新。具体做法不同版本不一样但思路都是“最后集中重绘一次”。实测下来优化后同样是400个球标处理时间从十分钟降到了三十秒以内体感差距巨大。4.4 C的API搞不定的场景换J-Link或者Python试试虽然Pro/TOOLKIT功能最全但有些操作在C接口里做起来很别扭比如复杂的字符串处理、正则匹配、和外部系统对接。这时候我习惯把球标工具拆成两层核心的创建和位置操作用C DLL完成业务逻辑和流程控制在J-Link或者Python里做。J-Link对球标的封装思路和C类似但对象模型更面向对象一些代码维护起来清爽。Python的话可以用Creo的二次开发库间接调用Toolkit接口适合快速验证想法。我的习惯是正式工具用C写做实验和调试用Python两边互补。5. 把球标工具做成稳定可交付的成品5.1 封装成独立DLL配合菜单和配置文件使用写一次性的脚本容易做成给同事和客户稳定使用的工具难。我的做法是把球标功能封装成独立DLL暴露一个入口函数然后用菜单注册文件挂到Creo的“工具”菜单里。这样用户不用碰代码点一下菜单选好图纸工具自动跑完。配置方面我习惯用一个ini文件存参数比如球标直径、列间距、起始编号、过滤参数名。配置文件的好处是现场调整不用改代码重编译改一行ini就能适配不同公司的出图习惯。这看起来是个小细节但在实际交付时非常加分。5.2 积累了这么久几个特别想提醒你的习惯球标相关的函数细碎参数非常多头文件和文档经常不够直观。我个人的经验是每接触一个新函数先写一个最小测试用例单独验证这个函数的行为确认没问题再往主工具里集成。千万不要一上来就写大流程出了问题很难定位。另一个习惯是把典型的报错信息收集起来做成日志。球标创建失败的原因千奇百怪有的是因为视图比例不对有的是因为元件被隐藏有的是因为BOM表为空。有了日志现场反馈问题的时候你能快速知道是哪一类不用远程猜半天。最后给球标工具留一个“撤销式”的清理功能。批量创建之后用户大概率还想微调几个球标如果工具没有提供一键删除所有自动生成球标的能力用户只能手动一个个删那体验就非常糟糕了。我后来都会在工具里加一个“清除本视图自动球标”的按钮看似功能小但实际使用率非常高。这些经验都是我在真实项目里一点点攒出来的。球标函数本身不难难的是把生成、排布、同步、交付这一整条链路捋顺。现在每当我看到几百个球标在几秒钟内自动整齐排好还是会觉得当初在这上面死磕的时间和精力是值得的。