UG二次开发实战：NXOpen C++环境配置与自动化建模指南

简介：面向UG二次开发学习者与工程师的完整资料包，定位为从UG_OPEN API入门、GRIP脚本到工程落地的系统化合集，既有概念讲解，也有可运行的示例工程，适用于UG用户、C++程序员及机械、航空航天领域需要定制CAD/CAM/CAE功能的人员。包内共620个文件，压缩后141.03MB；以C++工程为主线，包含.h头文件、.c/.cpp源文件、.obj编译中间文件、.dll动态库、.lib静态库，辅以.prt部件、.men/.tbr菜单定义、.dlg/.bmp界面资源，以及PDF课件、Word说明文档，构成从源码、构建配置到界面素材的完整链路。已有3858人学习下载。这套合集还提供可直接打开的项目工程（如.dsw/.dsp）和pdb/pch等调试文件，便于读者对照学习UG对象结构、界面定制和自动化任务开发；同时涵盖从环境搭建、插件生成到打包部署的实战技巧，并配有螺栓、弹簧、压块等机械零件示例，可有效规避常见问题、缩短开发上手周期。

1. UG二次开发资料合集：先别急着收藏，它能帮你把重复建模变成C++函数

做结构件和非标设计的人，大概率经历过这种场面：同样的打孔、同样的出图、同样的格式转换，一周重复几十次。去网上搜UG二次开发，搜出来的多是零散教程，要么是NXOpen Python脚本，要么是GRIP老古董，很多代码一贴进Visual Studio就编译不过。这份资料合集的定位是C++方向的UG二次开发资源集，既有环境配置，也有从入门到进阶的实例，适合已经会用NX建模、但想把重复操作自动化、想写自己的工具菜单的工程师。打开它之前，先想清楚一件事：你要的是“能跑的代码”，不是“能看的教程”——下文就是教你怎么从里面筛出前者。

2. 资料合集底盘：从文件目录到开发环境的三层筛选

拿到这种合集，第一步不是解压去浏览每个PDF，而是按照“版本匹配、环境配置、代码可用性”三层筛选。这里所谓的合集，往往包含几百个文件，但真正有价值的通常不超过三成。剩下三成里，真正能直接编译的又不到一半。所以先花半小时摸底，比后面省三天强。

2.1 拿到压缩包先做三件事：查版本、查入口、查示例

第一，确认合集对应的NX版本。UG二次开发的API和版本强相关，NX12的NXOpen代码到NX2007下编译可能直接报错，因为部分函数被废弃或拆到新头文件。打开合集的说明或者README，看有没有标明版本号；没标的话就看示例工程文件，用文本编辑器打开.sln或.vcxproj，里面的PlatformToolset和WindowsTargetPlatformVersion能反推编译器，但NX版本只能靠代码里的头文件引用猜测。更可靠的方法：找示例里用了什么API，比如UF_MODL_create_cyl1还是NXOpen::Features::Cylinder，后者通常出现在NX11之后的版本。

第二，找有没有现成的解决方案文件。如果合集里直接有.sln，双击能打开，那是最省事的。但如果这个sln是用Visual Studio 2015建的，而你本机是Visual Studio 2022，打开时会出现“平台工具集不匹配”的提示。不要盲目升级或转换，先看源码里的includes。有时候升级工具集后，一堆CMake或MFC相关的宏会变得古怪，反而更难查。老练一点的做法：自己新建一个空项目，把示例的源文件加进去，按自己当前的编译器重新编译。这样虽然慢，但每一步都清楚。

第三，找最小示例。所谓最小示例，就是那种只有一个ufusr或一个外部能够运行的函数，创建最基础的方块或圆柱体。这类代码是判断合集质量的试金石：能编译，说明环境没问题；编译不过，按下一节去查环境。我也习惯把最小示例单独复制出来，保持它不被其他代码依赖，必要时还可以把它改成自己的“冒烟测试”程序——每次改动环境配置后，先编译它验证。

为了快速定位，我一般会先把压缩包里的顶层目录列出来。如果看到有doc、src、sample、video这样的名字，心里就有数了。表格如下：

2.2 环境变量与NX安装目录：C++编译不通过的大半原因在这

UG二次开发C++环境，本质上是让Visual Studio能找到NX的头文件和库。核心环境变量是UGII_BASE_DIR，指向NX安装根目录，比如D:\NX\NX12。另外要在PATH里加上%UGII_BASE_DIR%\NXBIN和%UGII_BASE_DIR%\UGII，否则运行时加载NXOpenCpp.dll会失败。命令窗口里可以这样写：

setx UGII_BASE_DIR "D:\NX\NX12" /M setx PATH "%PATH%;%UGII_BASE_DIR%\NXBIN;%UGII_BASE_DIR%\UGII" /M

注意，setx /M需要管理员权限，而且会截断PATH到1024字符，我一般不推荐用它改PATH。而是在系统环境变量里手动加到现有PATH的后面。更关键的是Visual Studio项目设置：项目属性 -> C/C++ -> 附加包含目录 添加 $(UGII_BASE_DIR)\UGOPEN; $(UGII_BASE_DIR)\NXOpen; 链接器 -> 附加库目录 添加 $(UGII_BASE_DIR)\UGOPEN; 附加依赖项里加 libnxopencpp.lib; libnxopenufpp.lib; libufun.lib; libnxopen_cpp.lib 这些。不同NX版本，这些.lib的名字有细微变化。

很多“编译报错找不到头文件”的问题，实际是项目的搜索路径没有包含UGOPEN目录。资料合集里通常会有一篇环境配置文档，但容易过时。我习惯的做法：从NX安装目录里找最新的头文件，而不是全信合集里的设置。比如展开UGOPEN目录，看里面有哪些.h，再对照代码里的#include，缺哪个就补哪个。

另一个高频坑是字符集。Visual Studio默认可能选了Unicode，而NXOpen的老接口和UFUN函数很多要求char*。所以项目属性 -> 常规 -> 字符集 建议设置为“使用多字节字符集”。如果你坚持用Unicode，那就要用NXString的转换函数去适配，麻烦得多。我在第一次编译资料里的示例时，报了几十个错误，一半是头文件路径，一半是char和wchar_t不匹配。改成多字节字符集后，错误消失了大半。

另外，如果你用Visual Studio 2019或更高版本，还要注意Windows SDK版本。NX自带的lib是用较老SDK编译的，新SDK一般没问题，但如果遇到“std::filesystem”相关的链接错误，试试把C++语言标准调成C++17。这个属于玄学，但确实出现过。

2.3 用grip和journal定位这个合集的能力边界

GRIP是NX老玩家很熟的批处理语言，但在NX11以后基本被边缘化，官方都在推NXOpen。如果一个合集里GRIP占了大半，要么是年代久远，要么是作者习惯偏老。你当然可以学GRIP，但它解决不了现代NX的很多问题，比如和Teamcenter集成、做Block UI Styler复杂界面。我个人建议：GRIP只做查阅和迁移参考，主力精力放在NXOpen C++或NXOpen Python。

判断合集是否“新”，可以看有没有Journal相关的代码。NX菜单里“工具 -> Journal -> 录制”能生成VB/C#/C++的代码，这个功能对二次开发入门极友好。你可以自己录制一个创建一个块的操作，生成NXOpen C++代码，然后拿到合集里对比：如果合集的代码风格和生成的代码接近，说明它跟得上当前版本；如果还在用UFUN老接口，就要小心。

比如下面这段是从NX Journal生成的NXOpen C++代码（简化过）：

#include <NXOpen/NXObjectManager.hxx> #include <NXOpen/PartCollection.hxx> #include <NXOpen/Features/FeatureCollection.hxx> void create_block() { NXOpen::Session *session = NXOpen::Session::GetSession(); NXOpen::Part *workPart = session->Parts()->Work(); NXOpen::Features::FeatureCollection *features = workPart->Features(); NXOpen::Features::BlockBuilder *blockBuilder = features->CreateBlockBuilder(nullptr); blockBuilder->SetOrigin(Point3d(0.0, 0.0, 0.0)); blockBuilder->SetLength(100.0); blockBuilder->SetHeight(50.0); blockBuilder->SetWidth(20.0); blockBuilder->Commit(); blockBuilder->Destroy(); }

这段代码在NX12和NX2007之间大部分能通用，但要注意头文件引用路径。如果你的资料合集里匹配不上，就用这个思路去倒推版本。同时注意，Journal生成的代码经常会有很多多余的UI操作，比如选择视图、刷新等，这些在批处理时反而会拖慢速度。所以从Journal转成正式工具时，要一层层剥掉外观操作，只保留特征操作和数据访问。

还要留意合集里是否有.prt示例文件。有些代码需要特定的零件环境才能跑，比如“曲面缝合”示例如果拿一个空的prt执行，会先报找不到体。所以我把合集自带的prt按用途分目录存好，免得每次临时找模型。

3. NXOpen C++第一个程序：从dll到菜单按钮的完整链路

环境配好后，第一个目标是让NX跑起来你写的代码。这条路径是：入口函数 -> 创建一个特征 -> 挂到菜单。走通这条链路，你就算真正入了门。资料合集里大多数示例都是围绕这条链路展开的，但不会把这些细节串成一条线，所以我来帮你串。

3.1 创建NXOpen C++入口：手动搭工程 vs 向导模板

NXOpen C++的dll程序有两种入口：ufusr和ufsta。ufusr是临时执行入口，适合调试；ufsta是启动加载入口，适合做正式工具。大多数合集示例用ufusr，因为它不需要考虑菜单注册就能运行。下面是一个最小框架：

#include <uf.h> #include <NXOpen/NXOpen.hxx> #include <NXOpen/Session.hxx> extern "C" DllExport void ufusr(char *param, int *retcod, int param_len) { NXOpen::Session *session = NXOpen::Session::GetSession(); NXOpen::Part *workPart = session->Parts()->Work(); if (workPart == nullptr) return; // 把自己的功能逻辑放在这里 }

说明：ufusr是NX调用dll的入口点，param和retcod是历史遗留，通常忽略。Session是整个NX进程的单例，通过它才能拿到当前的工作部件。return前不需要额外清理，NX会管理资源。但如果你在函数里创建了Builder或对象，记得用Destroy释放。

手动搭工程的时候，有几个参数容易错。运行时库选多线程DLL（/MD），Debug对应/MDd，Release对应/MD，否则可能和NX内部运行时库冲突，导致莫名崩溃。还要把项目的输出类型设为DLL，导出符号在源文件里用DllExport声明。Visual Studio的向导模板里并不直接提供NXOpen工程类型，所以很多人都是复制一个现有dll工程再改。资料合集里如果有完整的工程模板，直接改头文件引用和链接库就行，省事很多。

关于DllExport，不同的NX版本写法略有不同。旧版本可能在头文件里已经帮你定义好了，你只需要包含Windows.h。新版则建议直接声明：

#define DllExport __declspec( dllexport )

放在项目预处理器或公共头文件里，这样各源码文件都能用。有些示例代码用extern "C" __declspec(dllexport)，注意不能把extern "C"和DllExport的顺序写反，否则编译器会当作不同的类型。

如果不想从零搭，可以用NX自带的录制Journal功能，把生成的代码丢进一个空白C++ DLL工程里，然后按上面的设置补环境。这是最快的起步方式。Journal代码里自带了很多头文件引用，你只需要把它们整理成当前工程的引用路径。

3.2 一个最小实现：创建圆柱体的UFUN和NXOpen写法

先看UFUN写法。UFUN是老接口，函数名带前缀UF_，风格是C语言式，适合快速验证环境和处理简单对象。代码很短：

#include <uf.h> #include <uf_modl.h> static void create_cylinder() { double origin[3] = {0.0, 0.0, 0.0}; char *height = "50.0"; char *diameter = "30.0"; tag_t cylinder_tag = NULL_TAG; UF_MODL_create_cyl1(origin, height, diameter, height, &cylinder_tag); }

这里要特别说明：UF_MODL_create_cyl1的第三个参数是直径，第四个是高度（其实是圆柱的另一个端点坐标值），第五个返回特征tag。传字符串是它的特点，NX内部会解析。在NX12之后这个函数的头文件还在，但已经不推荐使用，官方文档把它列在Legacy里。我在新项目里已经不怎么用UFUN创建特征了，但读老代码必须懂它。

NXOpen版本更面向对象，逻辑更清晰：

NXOpen::Features::CylinderBuilder *cylBuilder = workPart->Features()->CreateCylinderBuilder(nullptr); cylBuilder->SetDiameter(30.0); cylBuilder->SetHeight(50.0); cylBuilder->Origin()->SetValue(0.0, 0.0, 0.0); cylBuilder->Commit(); cylBuilder->Destroy();

注意，这里的origin是圆柱底面的中心位置，方向和当前坐标系的ZC轴一致。想让它沿XC轴就麻烦了，需要先创建一个方向对象，比如NXOpen::Direction，或者先旋转工作坐标系。新手最容易在这里翻车：明明设置了直径和高度，圆柱却出现在奇怪的地方，一查是方向或原点没设。

关于Builder的生命周期，NXOpen里几乎所有CreateXxxBuilder函数返回的builder对象，用完都要调用Commit或Dispose（按不同版本），然后Destroy。漏掉Commit，特征不会出现在模型树；漏掉Destroy，内存泄漏，长时间运行或批处理时内存暴涨。这是类合集里很难通过阅读代码发现的坑，只有调试多了才有感觉。

3.3 菜单和回调：把dll挂到工具栏上

ufusr写好了，每次都要通过“文件 -> 执行 -> NX Open”运行，不够专业。正式工具应该做成菜单按钮。关键步骤有两步：写菜单脚本，注册ACTIONS。

菜单文件放在你用户目录的startup文件夹下，常见路径是 %UGII_CUSTOMER_DIR%\startup，文件名custom.men。内容如下：

VERSION 120 EDIT UG_GATEWAY_MAIN_MENUBAR MENU BUTTON UG_HELLO LABEL 创建圆柱 ACTIONS create_cylinder_dll END_OF_MENU

这里ACTIONS后面写的名字是回调标识。然后在dll里注册这个动作。标准做法是：

#include <uf_ugmgr.h> static UF_UG_open_action_p_t actions[] = { create_cylinder_dll, nullptr }; extern "C" DllExport int ufusr_ask_unload(void) { return UF_UNLOAD_IMMEDIATELY; }

回调处理函数需要形如：

extern "C" DllExport void create_cylinder_dll(int *response) { // 实际调用 create_cylinder(); *response = UF_UI_CB_CONTINUE; }

这里response是回调返回值，告诉NX执行后继续还是退出菜单。如果菜单文件里的ACTIONS名字和这个函数名不一致，NX会在用户菜单初始化时报告“函数未找到”，但很多时候这个错误不弹出，而是日志记录在syslog里，所以你会发现点了按钮没反应，而且没有任何提示。遇到这种情况，先看%TEMP%\NX.\syslog，搜索“not found”或“dll”能快速定位。

合集里如果提供了Block UI Styler制作的对话框，那么回调函数里还会涉及对话框的构建和显示。Block UI Styler可以可视化生成对话框代码，但它生成的代码是C++或VB.NET，需要你把它嵌入到ufusr或回调里。很多新手把生成的代码直接复制到一个新文件里就跑，结果报一堆未定义变量——因为Block UI Styler生成的类需要和入口文件无缝拼接，不是随时随地都能用的。

调试这类dll有一个笨方法但很好用：在Visual Studio里按F5启动，附加到NX进程，然后在ufusr入口处打断点。这样可以看到变量值和调用栈，比写日志快。缺点是每次都要重新编译和拷贝dll到加载目录。另一个技巧是入口处写一个日志函数，把关键参数输出到文本文件，比如：

void log(const std::string &msg) { FILE *fp = fopen("D:/ug_dev_log.txt", "a"); fprintf(fp, "%s\n", msg.c_str()); fclose(fp); }

这个日志函数在排查菜单不响应、坐标不对时非常管用。一般在ufusr第一行就调用log("enter")，最后一行的调用能确认函数是否完整执行。资料合集里的示例很少教你加这些，但实际开发中这是生存技能。

4. 避坑与排查：版本错位、dll加载失败、中文乱码的五个现场

环境搭建和第一个程序走通之后，接下来会遇到各种玄学。我整理五个高频现场，每条按现象、原因、解决的思路写，都是我在实际开发里踩过的坑。

4.1 现象：运行时提示NXOPEN.dll找不到

现象：程序编译通过，但从NX里执行时弹出“无法加载NXOPEN.dll”或“系统找不到指定的模块”。

原因：NXOpen的C++运行库不在当前PATH里。NX打开的dll需要加载libnxopencpp.dll、libnxopenufpp.dll这些动态库，它们位于NX安装目录的NXBIN下。如果PATH里没有%UGII_BASE_DIR%\NXBIN，就会找不到。另一个原因是VS项目里链接了错误的lib版本，比如32位/64位混用。NX12之后基本都是64位，如果你编译成Win32，加载64位NX必然失败。

解决：首先确认项目平台是x64，然后用管理员身份在系统环境变量PATH里追加%UGII_BASE_DIR%\NXBIN和%UGII_BASE_DIR%\UGII。最后打开命令提示符，输入echo %PATH%，确认两个目录都在。如果还报错，用Dependency Walker查看dll依赖关系，或者直接用Process Monitor看加载了哪个绝对路径，以此反查环境变量。

4.2 现象：编译通过但一点菜单NX就崩

现象：程序运行到某个函数时，NX直接闪退，但单独调用同样的UFUN函数没崩。

原因：最典型的是UF_initialize和UF_terminate不配对。UFUN系列函数必须在UF_initialize之后调用，并且在函数结束前调用UF_terminate。如果你在ufusr里先UF_initialize，然后调用了NXOpen API或者C++标准库抛异常，就会在清理阶段崩掉。另一个原因是Builder对象没有正确释放，尤其是没有先Commit就直接Destroy，可能导致内部对象状态错乱。

解决：在入口函数上做好异常保护，用try/catch包住全部逻辑，catch里调用UF_terminate并返回。满天飞的返回值检查虽然难看，但对NX这种C++和C混存的环境非常必要。我的习惯是写一个辅助宏，在函数入口构造时自动UF_initialize，析构时自动UF_terminate，这样防止漏掉配对。示意如下：

extern "C" DllExport void ufusr(char *param, int *retcod, int param_len) { try { UF_initialize(); // 主逻辑 UF_terminate(); } catch (...) { UF_terminate(); } }

catch里再次调UF_terminate可能重复，但总比崩掉好。更严谨的做法是用一个智能指针管理初始化状态。

4.3 现象：中文注释或字符串乱码

现象：在C++源码里写了中文注释或中文字符串，编译没问题，但运行时日志或对话框标题显示乱码。

原因：NX内部使用UTF-8还是本地代码页，跟NX的启动区域设置有关。国内大部分NX默认区域可能是中文，但C++工程字符集如果设置了Unicode，字符串会变成宽的wchar_t，NXOpen接口很多用的是NXString，它内部能够转换，但如果你直接拿char*传给UFUN函数，就可能乱码。另一个原因是源文件编码不是UTF-8，VS编译时会按照本地代码页解析，文件保存编码不一致就会出问题。

解决：源文件统一用UTF-8 with BOM保存，Visual Studio里多字节字符集下能正常显示和传递。调用NXOpen API时，尽量用NXString或者std::string传入，需要char*时用split函数显式转换。如果对话框标题乱码，检查Block UI Styler里的属性是否设置了正确字符集。我遇到过最邪门的情况是：同一个字符串在Debug下正常，Release下乱码，后来发现是代码页宏不一致，在工程属性预处理器里强制加了_CRT_SECURE_NO_WARNINGS后才稳定。

4.4 现象：UFUN函数返回错误码401或500

现象：调用UF_MODL_create_cyl1返回401，或者UF_initialize返回500，程序继续执行但模型没有特征。

原因：401是“无效对象或对象类型不对”，500是“未初始化或初始化失败”。401常见于传入的坐标系或起点不是工作坐标系的合法表达；500常见于UF_initialize重复调用或没有在NX的进程中运行。如果你把dll用外部进程加载，没有通过NX召唤，UFUN初始化就不会成功。

解决：确认dll确实通过NX执行菜单或ufusr加载。起步阶段用ufusr直接执行，避免菜单干扰。检查传入参数是否都属于当前工作部件，尤其是tag_t不能为NULL_TAG。对于500，把UF_initialize放在所有UFUN调用之前，且只调用一次，或者用try/catch确保没有被异常中断。

4.5 现象：Journal生成的代码一模一样，但编译不过

现象：录制的Journal里有一段创建特征代码，和资料合集里的代码几乎一样，但照抄到Visual Studio后编译报错“未定义的标识符”或“C2065”。

原因：Journal生成的是C++报告文件，它默认包含的某些头文件在当前VS工程里没有加入。Journal报告顶部那一堆#include看着全，其实很多是NX内部才有的路径。另一种可能是Journal里引用了NXOpenCpp和NXOpenCPP两个不同库的方法，而你的链接器附加依赖项没有导入对应的lib。

解决：对照Journal生成的代码，把include路径里的.h从NX安装目录逐个找到，确认存在。不要全搬所有include，只需搬当前函数用到的那几个。链接器的依赖项按需添加，不要为了省事加libnxopencpp.lib就完了。用到的FeatureBuilder类，很多在libnxopencpp.lib里已经覆盖，但UFUN相关的在libnxopenufpp.lib。检查是否两个都加了。如果编译错误指向NXOpen名称空间下的某个类，先在安装目录的头文件里搜索类名，确认它是哪个库的内容。

以上五个坑，随便一个都能卡住大半天。资料合集里的PDF一般不会讲这些，因为它们大多属于“作者自己也没遇到”的边界情况。但你只要敢上手改代码，这些坑早晚会踩一遍。

5. 让资料合集变成自己的开发骨架：一个可复用的代码组织套路

资料合集看得再多，不落地都是纸面功夫。我的习惯是：从合集里提炼出那些与业务无关的通用能力，封装成自己的一套静态库。比如创建圆柱、读取表达式、遍历实体、导出图片，这些功能每个工具都可能用到，却没必要每次重写。

具体做法：建一个CommonLib项目，输出静态库。头文件里只暴露简单接口：

// common_cylinder.h #pragma once #ifdef __cplusplus extern "C" { #endif int CreateCylinder(double x, double y, double z, double d, double h); #ifdef __cplusplus } #endif

实现文件里再去调NXOpen或UFUN，外部调用方不需要知道NXOpen细节。这么做还有一个好处：团队其他人用你的函数时，不会因为误用Builder导致崩溃。接口简单，出问题的概率也低。

我曾经有一次直接在一个大工具里混用UFUN和NXOpen创建特征，结果因为坐标系的单位搞混，批量运行时生成了几百个体，全部偏了0.0254（一英寸）。后来查了一下午才发现是UFUN函数内部用英寸，而我输入的是毫米。从那以后，我每次拿到新资料包，都会先看它的长度单位是英寸还是毫米，在代码入口统一转成毫米，封装进CommonLib。希望这个习惯能帮到你。

本文还有配套的精品资源，点击获取