简介本资源是一份面向UG NX二次开发初学者的实战入门示例聚焦外部开发模式下通过C调用Open API创建基础几何体的核心流程。内容完整覆盖API环境初始化、新建公制零件、原点处生成Block、保存与关闭模型等关键环节并附带错误处理机制UF_CALL宏封装和日志输出逻辑便于理解NX Open API的标准调用范式与调试方法。资源为单文件Word文档.docx共1个文件大小仅14KB结构精炼含代码片段、逐行注释及关键函数说明适合作为开发环境搭建后的首个验证案例或教学辅助材料。目前已有622人学习下载读者可直接复现该Block创建流程掌握UF_PART_new、UF_MODL_create_block1、UF_PART_save等核心函数的参数含义与典型用法为后续复杂建模、自动化装配等高级开发任务奠定实践基础。1. 这不是插件也不是宏UG外部开发模式下创建Block是真正“绕过UI直连内核”的建模控制权你有没有试过在NX里点十次“长方体”命令只为批量生成一组尺寸固定的块有没有被“录制宏→回放失败→报错UF_MODL_create_block1参数类型不匹配”卡住一整个下午别折腾了——这个项目就是给你看的一段不到50行的C代码不启动NX界面不依赖任何菜单或对话框直接调用底层UF函数在C:\temp\plmhome.prt里从零生成一个100×100×100的Block并完整保存、关闭、释放资源。它不是教学Demo而是真实产线脚本的最小可运行单元没有MFC窗体、不走NX Open .NET封装、不碰NX Journal机制纯UF API 外部EXE模式。适合正在做PLM系统集成、自动化建模流水线、CAE前处理模板化输出的开发者也适合刚从SolidWorks API转来、还在困惑“为什么NX要分内部/外部/GRIP三种开发路径”的工程师。它解决的不是“怎么画个方块”而是“当你的调度系统需要每分钟生成37个带命名规则的基准块时哪条路不翻车”。2. 环境准备与工程结构从VS2019到NX9 SDK头文件链的硬核对齐UG外部开发不是写个main函数就能跑的“普通C程序”。它本质是链接NX运行时内核的原生客户端编译器、平台、SDK版本、甚至字符集都必须严丝合缝。下面这一步漏掉任何一个细节你将收获满屏LNK2019未解析外部符号——而且错误提示里根本不会告诉你缺的是uf_modl.lib还是uf_part.lib。2.1 开发环境三要素VS版本、NX安装路径、SDK头文件映射UG NX9官方只支持Visual Studio 2015VC14和VS2017VC15。但实测VS2019VC16在关闭SDL检查、禁用/RTC开关、手动指定平台工具集为v142后可稳定编译——这是某公司产线脚本迁移时踩出来的血泪经验。关键不是“能不能编”而是“链接时能否准确定位UF函数符号”。NX9 SDK默认安装在C:\Program Files\Siemens\NX 9.0\UGOPEN\下其中include\目录含uf.h、uf_part.h、uf_modl.h等核心头文件lib\目录含ufun.lib导入库、ufun_dll.lib动态链接库导入bin\目录含ufun.dll运行时必需必须确保PATH包含此路径。提示不要把NX SDK头文件拷到自己工程里必须用相对路径引用$(NX_ROOT)\UGOPEN\include\。否则当你切换NX10或NX12环境时头文件版本错位会导致UF_CALL宏展开异常——比如UF_MODL_create_block1在NX9中第3个参数是char* edges[]而NX12已改为double edges[3]编译不报错但运行必崩。2.2 工程配置四步锁定链接行为在VS2019新建空Win32控制台项目后必须完成以下四步缺一不可预处理器定义添加_AFXDLL;UFUN_DLL;NX90NX9对应NX90NX10对应NX100以此类推附加包含目录$(NX_ROOT)\UGOPEN\include附加库目录$(NX_ROOT)\UGOPEN\lib\win64注意必须用win64子目录即使你在x64平台编译附加依赖项ufun.lib;libugopenstubs.lib后者是NX9新增的stub库用于解决部分UF函数重定向问题# 验证环境是否就绪在命令行执行 dumpbin /exports C:\Program Files\Siemens\NX 9.0\UGOPEN\lib\win64\ufun.lib | findstr UF_MODL_create_block1 # 应返回类似 1856 74F ?UF_MODL_create_block1YAHHQANPAPADPAHZ # 若无输出说明lib路径错误或NX版本不匹配2.3 目录结构与构建产物外部EXE的部署逻辑该模式下生成的是独立.exe而非NX内部加载的DLL。其运行依赖NX内核服务进程ugraf.exe或nx.exe已启动并处于监听状态。典型部署结构如下C:\my_ug_tools\ ├── block_creator.exe # 你的编译产物Release/x64 ├── run.bat # 启动脚本start C:\Program Files\Siemens\NX 9.0\nx.exe timeout /t 3 block_creator.exe └── logs\ └── uf_syslog.txt # UF_print_syslog默认输出位置可重定向注意block_creator.exe本身不启动NX界面但它会尝试连接已运行的NX实例。若NX未启动UF_initialize()将返回错误码UF_UNABLE_TO_INITIALIZE值为101此时程序静默退出——这是设计使然不是Bug。3. 核心模块拆解一个Block从内存分配到磁盘落盘的完整链路这段代码表面只有4个UF函数调用但每个背后都牵扯NX内核的模型树管理、几何引擎调度、单位制转换和事务提交机制。我们逐行深挖不跳过任何UF_NULLSIGN或UF_PART_METRIC的语义。3.1 初始化与终止UF_initialize()不是摆设是内核握手协议if( UF_CALL(UF_initialize()) ) { return; } // ... 中间业务逻辑 ... UF_CALL(UF_terminate());UF_initialize()并非简单初始化全局变量。它实际完成三件事向NX内核注册当前进程为“合法客户端”获取唯一client_id加载ufun.dll并解析所有UF函数地址表即UF_MODL_create_block1等符号绑定分配线程本地存储TLS区用于存放当前线程的NX上下文如当前工作部件、图层状态、坐标系等。关键参数说明UF_initialize()无入参但要求调用前NX_ROOT环境变量已正确设置指向C:\Program Files\Siemens\NX 9.0\。若未设置函数返回101错误且不打印任何日志——这是新手最常踩的坑。UF_terminate()则反向执行清理TLS中所有NX上下文注销client_id卸载ufun.dll仅当无其他UF调用时。注意UF_terminate()必须在所有UF函数调用之后、且UF_PART_close()完成之后调用。若提前调用后续UF_PART_save()将因上下文丢失而失败。3.2 零件创建UF_PART_new()的路径、单位与标签生命周期UF_CALL(UF_PART_new(C:\\temp\\plmhome.prt, UF_PART_METRIC, newPart));UF_PART_new()创建的是一个空零件文档Part不是内存中的临时对象。参数详解C:\\temp\\plmhome.prt绝对路径必须存在C:\temp\目录且进程有写权限。路径中不能含中文或空格NX9对Unicode路径支持极弱UF_PART_METRIC单位制枚举值UF_PART_ENGLISH0,UF_PART_METRIC1决定后续建模操作的默认单位mm/inchnewPart输出参数接收新零件的tag_t句柄本质是unsigned longNX内核中唯一标识该Part的ID。血泪经验UF_PART_new()成功后该Part自动成为“当前工作部件”current work part。所有后续建模操作如UF_MODL_create_block1都将作用于此Part。若你同时打开多个NX窗口此操作不影响其他窗口——因为外部EXE通过client_id绑定到内核而非UI窗口。3.3 Block建模UF_MODL_create_block1()的坐标系陷阱与边缘ID玄学double coner[3] {.0, .0, .0}; char *edges[] {100, 100, 100}; UF_CALL(UF_MODL_create_block1(UF_NULLSIGN, coner, edges, blockTag));这是全篇最易误解的函数。表面看是“创建长方体”实则是“在指定坐标系原点按三边长度生成块体”。参数逐个击破UF_NULLSIGN标志位此处必须为0#define UF_NULLSIGN 0。NX9中此参数已被废弃但必须传0传其他值如1将导致函数静默失败coner[3]不是左下角坐标而是块体在当前WCS工作坐标系下的定位点。NX中Block默认以coner为“第一顶点”沿X/Y/Z轴正向延伸。因此{0,0,0}表示块体占据第一卦限edges[]字符串数组非数值数组这是UF API历史包袱——NX早期用字符串传递参数以兼容GRIP脚本。100会被内部转换为double但若传100.0或1e2同样有效。若传abc函数返回错误码UF_INVALID_INPUT1003blockTag输出块体的tag_t。该Tag可用于后续操作如UF_MODL_ask_body_type()查询类型、UF_OBJ_set_name()重命名。避坑重点UF_MODL_create_block1创建的Block默认位于绝对坐标系ACS原点不受当前WCS影响。若你先调用UF_CSYS_create_object_coordinate_system()修改了WCS此函数仍以ACS为准。这是与NX UI中“长方体”命令行为的关键差异——UI命令尊重当前WCS而UF函数不。3.4 保存与关闭UF_PART_save()与UF_PART_close()的事务边界UF_CALL(UF_PART_save()); UF_PART_close(newPart, 0, 1);UF_PART_save()看似简单实则触发NX内核的完整事务提交流程将内存中所有变更包括Block几何、特征树节点、属性序列化为UGPART二进制格式写入磁盘文件C:\temp\plmhome.prt更新文件时间戳与校验和。UF_PART_close()则负责资源回收newPart要关闭的Part Tag0是否强制保存0否1是。此处传0因前面已显式调用UF_PART_save()1是否清除内存副本0保留1清除。传1确保内存彻底释放避免后续误操作。关键区别UF_PART_save()只写磁盘不释放内存UF_PART_close()才真正卸载Part。若只调用save不close下次运行此EXE时UF_PART_new()会因同名文件被占用而失败错误码UF_FILE_ACCESS_DENIED。4. 常见问题排查那些让你怀疑人生却只需改一行代码的翻车现场UG外部开发的报错信息极其吝啬——90%的错误只返回一个整数错误码不带堆栈、不指明文件行号、不解释原因。以下是某导师带学生调试23个失败案例后总结的TOP5高频问题按“现象→原因→解决”结构给出可立即验证的方案。4.1 现象UF_initialize()返回101UF_UNABLE_TO_INITIALIZE原因NX_ROOT环境变量未设置或指向错误路径如指向NX10安装目录但链接了NX9的lib。解决:: 在VS的“调试→环境”中添加注意路径末尾无反斜杠 NX_ROOTC:\Program Files\Siemens\NX 9.0 :: 或在run.bat开头强制设置 set NX_ROOTC:\Program Files\Siemens\NX 9.04.2 现象UF_PART_new()返回1003UF_INVALID_INPUT但路径明明存在原因路径字符串含非法字符如中文、、$或使用了相对路径如.\plmhome.prt。解决// ✅ 正确绝对路径英文无空格 char full_path[] C:\\temp\\plmhome.prt; UF_CALL(UF_PART_new(full_path, UF_PART_METRIC, newPart)); // ❌ 错误相对路径、中文路径、含空格 // UF_PART_new(plmhome.prt, ...); // UF_PART_new(C:\\我的文档\\plmhome.prt, ...); // UF_PART_new(C:\\temp\\my part.prt, ...);4.3 现象UF_MODL_create_block1()返回0成功但NX中看不到Block原因coner[3]坐标值过大如{1e6,1e6,1e6}导致Block超出NX默认显示范围或edges[]字符串解析失败如传了{100.0,100,100}但NX9只接受整数字符串。解决// ✅ 强制统一为整数字符串 char *edges[] {100, 100, 100}; // 不要用100.0 // ✅ 坐标控制在[-1e4, 1e4]范围内 double coner[3] {0.0, 0.0, 0.0}; // 避免科学计数法4.4 现象UF_PART_save()返回1007UF_FILE_WRITE_ERROR原因目标目录C:\temp\不存在或当前用户无写权限尤其在Windows Server上。解决#include direct.h // 在UF_PART_new前添加 _mkdir(C:\\temp); // Windows专用创建目录 // 或用CreateDirectoryA()跨平台4.5 现象程序运行后NX界面卡死任务管理器显示nx.exeCPU 100%原因UF_terminate()未被调用导致NX内核中client_id泄漏累积到一定数量后触发内核保护机制。解决// ✅ 必须保证UF_terminate()在所有路径下都被执行 extern void main( char argc, char *argv[] ){ if( UF_CALL(UF_initialize()) ) return; tag_t newPart, blockTag; int rc 0; rc UF_CALL(UF_PART_new(C:\\temp\\plmhome.prt, UF_PART_METRIC, newPart)); if(rc) goto cleanup; // ... 其他操作 cleanup: UF_CALL(UF_terminate()); // 所有出口都经过这里 }5. 二次开发改造指南从固定Block到参数化建模流水线的五步跃迁现在你已经能稳定跑通“创建一个100×100×100块”的最小闭环。但真实产线需求永远更野比如“根据Excel表格读取100行尺寸批量生成带编号的Block”“按BOM清单在指定装配位置插入Block”“将Block导出为STEP供下游CAE使用”。下面我带你把这段代码升级为可工程化的建模脚手架每一步都附可粘贴验证的代码片段。5.1 第一步从硬编码到配置驱动——用JSON替代C字面量把尺寸、路径、单位等参数抽离为外部JSON文件避免每次修改都要重新编译。使用轻量级jsoncpp无需额外DLL头文件直链// config.json { part_path: C:\\temp\\auto_block.prt, unit: metric, blocks: [ { name: BASE_PLATE, corner: [0,0,0], size: [200,150,20] }, { name: MOUNT_BRACKET, corner: [210,0,0], size: [80,60,15] } ] }C解析代码需链接jsoncpp.lib#include json/json.h #include fstream // ... 在main开头加载 std::ifstream ifs(config.json); Json::Value root; Json::CharReaderBuilder builder; JSONCPP_STRING errs; if(!Json::parseFromStream(builder, ifs, root, errs)) { cerr JSON parse error: errs endl; return; } std::string part_path root[part_path].asString(); int unit (root[unit] metric) ? UF_PART_METRIC : UF_PART_ENGLISH;改造价值配置与代码分离运维人员可直接编辑JSON增删Block无需接触C。5.2 第二步支持多Block批量创建——循环调用UF_MODL_create_block1并命名UF API中每个几何体都有tag_t而UF_OBJ_set_name()可为其赋予人类可读名for(int i 0; i root[blocks].size(); i) { Json::Value blk root[blocks][i]; double corner[3] { blk[corner][0].asDouble(), blk[corner][1].asDouble(), blk[corner][2].asDouble() }; char *edges[] { const_castchar*(std::to_string(blk[size][0].asInt()).c_str()), const_castchar*(std::to_string(blk[size][1].asInt()).c_str()), const_castchar*(std::to_string(blk[size][2].asInt()).c_str()) }; tag_t blockTag; UF_CALL(UF_MODL_create_block1(UF_NULLSIGN, corner, edges, blockTag)); // 设置名称便于NX中查找 UF_CALL(UF_OBJ_set_name(blockTag, blk[name].asCString())); }注意UF_OBJ_set_name()要求NX 9.0.3版本旧版需用UF_MODL_ask_feature_name()配合UF_MODL_edit_feature_name()。5.3 第三步错误恢复与日志增强——让失败可追溯原始代码中UF_CALL只打印错误码。生产环境需记录具体失败的Block索引和参数#define UF_CALL_LOG(X, MSG) do { \ int irc (X); \ if(irc) { \ char err_msg[256]; \ UF_get_fail_message(irc, err_msg); \ std::ofstream log(C:\\temp\\block_log.txt, std::ios::app); \ log [ERROR] MSG failed at line __LINE__ \ with code irc : err_msg \n; \ log.close(); \ return irc; \ } \ } while(0) // 使用 UF_CALL_LOG(UF_PART_new(part_path.c_str(), unit, newPart), Create part);5.4 第四步对接PLM系统——从文件路径到Teamcenter Item ID真实场景中Block需关联TC中的Item。UF API不直接操作TC但可通过UF_PART_ask_attribute_string()读取Part属性再用TC提供的REST API更新// 创建Part后写入TC Item ID作为自定义属性 char tc_item_id[] TC-ITEM-2024-001; UF_CALL(UF_PART_set_attribute_string(newPart, TC_ITEM_ID, tc_item_id)); // 后续脚本可读取此属性调用TC REST接口建立关联5.5 第五步自动化验证——用UF_MODL_ask_block_parms()反查尺寸生成后不等于成功。必须验证Block尺寸是否符合预期这是交付前的“后悔药”double actual_size[3]; UF_CALL(UF_MODL_ask_block_parms(blockTag, NULL, NULL, actual_size)); // actual_size[0]即X方向实际长度单位mm if(fabs(actual_size[0] - 100.0) 0.001) { cerr Block X size mismatch: expected 100.0, got actual_size[0] endl; }从那以后我每次交付建模脚本都强制走一遍UF_MODL_ask_block_parms校验JSON配置比对日志归档三重检查。不是信不过自己写的代码而是信不过NX内核在不同工作站上的浮点运算一致性——去年在客户现场同一段代码在i7-8700K和Xeon Gold 6248R上生成的Block尺寸差了0.0003mm够让CAE网格生成器报错。希望帮到你。本文还有配套的精品资源点击获取
