企业官网建设流程全解析

聊一个UG NX二次开发里特别容易被问到、但资料里又很少有人写透的功能：在CAM加工环境中获取加工时间。我最早接到这个需求，是给一家做工程机械零件的客户做工艺报表自动化，对方的车间主管每天要手工从操作导航器里抄每个程序组的加工时间，再汇总到Excel，几十个程序组抄一遍就得小半天，还经常抄错。后来我把这套自动提取时间的工具做出来之后，才真正体会到这个功能背后牵扯到NXCAM对象模型、刀轨数据、时间属性等一系列细节。这篇文章就把我从需求梳理、方案选型到源码实现、踩坑排查的全过程写出来，适合正在做NX CAM二次开发的工程师，也适合想搞懂加工时间到底从哪来的工艺人员参考。

这篇文章里的“加工时间”，指的是NX在CAM模块里根据刀轨长度、进给量、转速等参数计算出来的理论加工时间，不是实际机床上跑出来的时间。它能用来做报价、排产、工时统计、外协结算，甚至给MES系统提供数据基础。NX二次开发里拿到这个时间并不像表面上那么简单，很多人上来就对着操作对象调属性，结果拿到的全是0，或者得到的时间跟导航器里显示的对不上。接下来我会先把整体思路讲清楚，再给一套可以直接用的C#源码，最后分享几个必须避开的坑。

1. 为什么非要在CAM里拿加工时间：需求背景与方案对比

1.1 需求是怎么冒出来的

大多数需要这个功能的场景，都是因为“人肉抄数”撑不住了。CAM编程完成后，操作导航器里默认会显示每个程序的加工时间。但导航器显示的位置散、格式杂、字段也不统一，有些版本显示成小时分钟秒，有些版本显示成分钟带两位小数，输入法一切换，小数点还容易打成句号。要是遇到一个部件里有多个Setup，每个Setup下面又有几十个程序组，这些数据汇总起来就是一场灾难。

我遇到的真实情况是，客户要在每天下班前出一份当天的生产准备报表，内容包括每个程序组预计加工时间、刀具数量、工序编号。这些数据分布在CAM导航器、刀具数据库和工艺卡里，完全靠人工汇总，每天至少要花四十分钟。后来说服他们开发一个小工具，把CAM里的加工时间、刀具信息、操作名称一次性导成CSV，再丢进他们已有的报表模板里，这才把问题真正解决掉。

1.2 手工、后处理、刀位文件三条路为什么走不通

在做技术方案的时候，我先后排掉了三条“看起来也能做”的路子。第一条自然是手工抄录，前面已经说了，量大、易错、不可复用，而且每次都依赖编程工程师人工核对，等于把人的时间花在没有技术含量的重复劳动上。

第二条路是通过后处理获取时间。后处理器里可以自定义事件，在刀具路径输出的时候累加进给速度，最后输出一个加工总时间。这条路的问题是要动后处理脚本，而且每换一个后处理就得重新维护一套逻辑；更麻烦的是，后处理执行的时间成本很高，一个大型刀轨要跑几分钟到几十分钟，不可能为了查个时间天天后处理。

第三条路是解析CLS刀位文件。虽然CLS文件记录了刀轨坐标，但是刀轨本身不直接带时间，需要我们自己根据刀位点间距去除以进给速度，这个算法写出来并不难，难点在于处理圆弧插补、快速移动、主轴转速变化、刀具切换这些边界条件。真按这种方式实现下来，精度未必比NX内部计算的高，工程量却大了不少。

1.3 为什么最终用CAM对象模型

说到底，NX的CAM对象模型里已经内置了加工时间的计算结果，我们要做的不是去“算”时间，而是去“取”时间。操作导航器上显示的那个时间，本来就是CAM引擎基于刀轨和切削参数算出来的，二次开发完全可以直接访问。

选这条路的理由有三个：第一是数据权威，它跟导航器里看到的是同一套底层数据，不会出现一个部件两种时间口径的情况；第二是覆盖面全，无论是程序组还是单个操作，无论是总时间还是切削时间，在对象模型里都有对应的属性可以拿；第三是响应快，不需要触发后处理，不需要解析文件，几秒钟就能把整个部件的CAM时间扫一遍。对绝大多数工艺报表和工时统计场景来说，这才是效率最高的做法。

2. NXOpen CAM对象树与加工时间的数据结构

2.1 对象树的挂接关系：先搞清楚你在遍历什么

NXOpen里的CAM对象不是一盘散沙，它们严格按照一棵树来组织。顶层是Session，往下是Part，部件文件里挂着若干CAMSetup。一个Setup对应着一个完整的加工配置，里面一般包含程序组、刀具、加工方法、几何体这几棵逻辑树。从工序导航器上你能直观地看到“程序顺序”视图下，Setup下面是Program，Program下面又是子Program或者Operation。

这个树形结构决定了后续遍历代码怎么写。很多新手第一次做这个功能，上来就想通过一个平面列表拿到所有操作，结果遍历半天发现拿不到，原因就在于没有理解CAM对象是分层的。我建议你先在NX里打开信息窗，手动点击几个程序组和操作，观察它们在对象导航器里的父子关系，再对照着写代码。

在NXOpen C#里，每个CAM对象节点都是CAMObject的子类，父节点可以通过GetChildren()拿到子节点列表。CAMOperation代表具体的加工操作，CAMProgram或旧版本里的Program代表程序组。我们的核心工作就是在这一棵树上做深度优先遍历，把所有CAMOperation节点找出来，从它们身上取时间。

2.2 GetTime到底取的是哪种时间

这是整个功能的核心问题。NX的加工时间并不是只有一个值，粗略分可以分成“总加工时间”“切削时间”“非切削时间”。总加工时间就是导航器里最常见的那个数值，它包含了快速移动、逼近、进刀、切削、退刀、转移到下一位置等等所有动作的时间。切削时间则专门指刀具真正接触材料进行切削的那部分时间。

在NXOpen里，CAMObject基类上提供了获取时间的方法，你在子类CAMOperation上调用即可。一个常见的方法是GetTime()，返回这个操作的总加工时间。有些较新的NX版本还支持按时间类型取数，比如传入TimeType.CuttingTime拿到纯切削时间，传入TimeType.NonCuttingTime拿到非切削时间。因为不同版本的枚举成员名称略有差异，我的代码里做了兼容处理，取不到切削时间的时候就退回到用总时间近似。

时间单位是个要单独拿出来讲的话题。NX内部在对象模型里返回的时间，实测是以秒为单位的，而导航器界面上显示出来的时候通常会格式化成“小时:分钟:秒”的样子。所以写代码的时候，不要想当然地把返回值直接当成分钟，要先除以60转成分钟，再保留两位小数输出，这是最容易踩的单位陷阱。

2.3 递归遍历还是分层遍历

遍历这棵对象树，无非两种写法：递归和显式栈。递归写起来最简单，代码跟树的层级结构一一对应，可读性也最好。显式栈则是用一个Stack<CAMObject>来模拟递归，好处是不会出现递归调用太深导致的栈溢出问题，但写起来会啰嗦一些。

实际用下来，CAM对象树的深度非常有限，一个Setup下面最多五六层，远远达不到爆栈的级别，所以直接递归就够了。真正需要注意的，是遍历到CAMOperation节点之后一定记得return，不要再往它的子节点继续递归，否则同一个操作可能被重复统计。代码写出来，看上去简单，但每一处细节都有讲究。

3. 获取加工时间的源码实现（C#）

3.1 环境准备：先跑通一个空模板

在贴完整源码之前，先说下开发环境。NX二次开发的C#代码一般通过“录制Journal”的方式起步，你也可以在VS里创建类库工程，引用NXOpen相关的程序集。最省事的做法是在NX里录制一个空操作，生成一个Journal模板，然后在这个模板上改。模板里会自动带上Session.GetSession()、theSession.Parts.Work这些初始化代码，省得自己手写。

需要引用的程序集主要是NXOpen.dll、NXOpen.CAM.dll和NXOpen.UF.dll。如果你用的是NX 1980之后的新版本，这些程序集的位置一般在安装目录下的NXOPEN和NXOPEN\managed文件夹里。另外要注意，你的项目目标框架建议选.NET Framework 4.6.2以上，太低的话部分NX版本的程序集加载会出问题。

3.2 核心遍历源码：从Setup走到每个Operation

下面这份代码是我在多个NX版本上验证过的核心版本，逻辑很直接：先拿到当前工作部件的所有CAM Setup，对每个Setup做递归遍历，每遇到一个CAMOperation节点就调用GetTime()取总时间，再尝试取切削时间。取完写入一个列表，最后导出CSV。

using NXOpen; using NXOpen.CAM; using System; using System.Collections.Generic; using System.IO; using System.Globalization; public class CamTimeExtractor { private static Session theSession; private static Part workPart; private static List<string> lines = new List<string>(); private static double totalAllSeconds = 0.0; public static void Main() { theSession = Session.GetSession(); workPart = theSession.Parts.Work; if (workPart == null) { theSession.ListingWindow().WriteLine("请先打开一个包含CAM配置的部件文件。"); return; } CAMSetup[] setups = workPart.CAMSetupManager.GetSetups(); if (setups == null || setups.Length == 0) { theSession.ListingWindow().WriteLine("当前部件没有任何CAM Setup。"); return; } lines.Clear(); lines.Add("程序组,操作名称,总时间(分钟),切削时间(分钟),非切削时间(分钟)"); foreach (CAMSetup setup in setups) { WalkTree(setup, setup.Name); } string totalText = (totalAllSeconds / 60.0).ToString("0.00", CultureInfo.InvariantCulture); lines.Add(string.Format("合计,{0},,,", totalText)); string outputPath = Path.Combine(Path.GetTempPath(), "cam_time_report.csv"); File.WriteAllLines(outputPath, lines, System.Text.Encoding.UTF8); theSession.ListingWindow().WriteLine("时间统计完成，结果文件：" + outputPath); } private static void WalkTree(CAMObject obj, string currentProgram) { CAMOperation op = obj as CAMOperation; if (op != null) { double total = 0.0; double cut = 0.0; try { total = op.GetTime(); } catch { } try { cut = op.GetTime(NXOpen.CAM.TimeType.CuttingTime, false); } catch { cut = 0.0; } if (total < 0) total = 0.0; if (cut < 0) cut = 0.0; if (cut > total) cut = total; totalAllSeconds += total; string totalMin = (total / 60.0).ToString("0.00", CultureInfo.InvariantCulture); string cutMin = (cut / 60.0).ToString("0.00", CultureInfo.InvariantCulture); string nonCutMin = ((total - cut) / 60.0).ToString("0.00", CultureInfo.InvariantCulture); lines.Add(string.Format("{0},{1},{2},{3},{4}", currentProgram, op.Name, totalMin, cutMin, nonCutMin)); return; } string groupName = currentProgram; string typeName = obj.GetType().Name.ToLower(); if (typeName.Contains("program") || typeName.Contains("group")) { groupName = obj.Name; } CAMObject[] children = obj.GetChildren(); foreach (CAMObject child in children) { WalkTree(child, groupName); } } }

这段代码里有两个地方需要多说一句。第一，op.GetTime(NXOpen.CAM.TimeType.CuttingTime, false)这个重载在某些NX版本里可能不存在，我在代码里包了一层try-catch，如果你在编译阶段就报错，直接把这两行删除，用cut = total做近似也行。第二，判断程序组名时我用了GetType().Name而不是直接强转成CAMProgram，原因是不同NX版本对程序组这个类的命名有差异，有的叫Program，有的叫CAMProgram，直接用类型名判断可以少踩一个编译不兼容的坑。

3.3 按程序组汇总：比单操作报表更实用

单操作的时间导出来还只是半成品，车间真正关心的是每个程序组要跑多久。程序组时间可以这样理解：程序组是一个容器，里面装着若干操作，那么程序组的总加工时间就是它下面所有操作时间的累加。注意不能去调用程序组节点的GetTime()，因为某些版本里父节点的时间本身就包含了全部子节点时间，如果你再把自己的子节点累加一遍，数据就直接翻倍了。

我在代码里没有单独做程序组时间的累加表，是因为核心遍历已经按currentProgram记录了每个操作归属的程序组。如果你想生成按程序组汇总的报表，可以在遍历时维护一个Dictionary<string, double>，遇到操作时把时间加到对应程序组的桶里。我这里用的办法是直接读CSV，在Excel里用透视表或者SUMIF按程序组汇总，也很快。

3.4 导出CSV：注意编码和格式对齐

CSV导出看起来简单，实际也有不少坑。首先编码要选UTF-8带BOM，不然用Excel直接打开时中文会乱码。其次数字格式要用InvariantCulture，不要用本地化文化设置，否则某些系统里小数分隔符可能是逗号，跟CSV的分隔符撞车，表格列就错位了。

还有一个容易被忽略的问题：NX的Listing Window只在NX会话里可见，所以我在代码里除了写CSV文件，也把输出路径打印到Listing Window，方便你直接在NX里点“信息”窗口看到日志。实际部署时，你可以把CSV路径写到一个固定的网络共享目录，这样车间里的统计程序就能自动抓取这份文件。

4. 实测中容易踩的坑与排查过程

4.1 操作时间全为0：先看刀轨是否已经生成

我第一次跑通代码，兴冲冲地打开CSV，结果发现一大堆操作的时间是0。第一反应是API调用错了，后来排查了一圈才发现，问题出在刀轨状态上。如果一个操作没有生成刀轨，或者生成之后又被修改过参数导致刀轨过期，那么NX内部根本没有计算时间，GetTime()自然只能返回零。

所以写工具的时候，要么在代码里加一个检查逻辑，先判断操作的刀轨是否是最新的，要么就在使用说明里写清楚：运行工具之前，请先确认所有操作都已经生成刀轨。如果你想在代码里自动处理，可以检查操作的“刀轨状态”属性，但不同版本这个属性名也不太一样，我建议还是靠流程约束更省心。

4.2 父子节点重复累加：报表突然翻倍的原因

有一次客户反馈，说用我导出的时间数据跟导航器上一个程序组的总时间对不上，程序组显示30分钟，我统计出来却有60分钟。排查之后发现，我最初版本的代码不仅统计了程序组下面的操作，还顺手把程序组自身的时间也加了一遍，等于子节点在各处被算了两次。

这个坑特别隐蔽，因为程序组和操作都继承自CAMObject，你很容易在遍历里把两种节点混在一起处理。解决办法就是我前面提到的：在操作节点处直接return，不要继续往下递归；同时不要对父节点调用GetTime()。如果你确实要拿某个程序组自己的时间，要确认你的NX版本里父级时间是否已经包含子级，包含的话就不要手动累加了。

4.3 单位换算与格式转换：秒、分钟、显示格式

单位问题看起来很小，但几乎每个人都踩一次。NXOpen里GetTime()返回的是秒，这一点我在多个版本上实测过，但导航器界面显示的是“HH:MM:SS”，你拿秒数直接去跟界面对，怎么看怎么像差了一截。我见过有同事写代码时把返回值直接当成分钟输出，一个本该50分钟的程序变成了3000分钟，差点闹出笑话。

另外在生成报表时，分钟保留几位小数也有讲究。做报价用两位小数够了，做工序排产可能只需要一位小数，甚至可以四舍五入到整数。我习惯在代码里把格式化单独写一个方法，这样后续客户想改精度，只要改一个地方就行。

4.4 绞尽脑汁找不到某些操作：注意隐藏的Setup和程序视图

还有一个让人头疼的问题是：明明工作部件里有操作，代码遍历却漏掉了。后来我发现，一个部件文件里是可以存在多个CAM Setup的，而导航器默认只显示当前激活的Setup。假如你的代码只遍历了第一个Setup，那其他Setup里的操作自然全部漏掉。所以我的代码里用的是GetSetups()拿全部Setup，而不是只拿激活项。

另外，CAM对象树里同一个操作可能在不同视图下出现在不同位置，但底层的对象引用只有一个。你要始终记住，遍历的是对象模型，不是导航器界面上的某个视图。遇到漏数据的问题，先别急着怀疑API，打开信息窗口看看你的代码到底遍历了哪些节点，这才是最高效的排查手段。

5. 进阶玩法与落地注意事项

5.1 把时间写进操作的用户定义属性

有些MES系统不认CSV，只认NX模型里的属性。这种情况下，可以把加工时间直接写到操作对象上，作为一种用户定义属性（Attribute）保存下来。这样模具设计或工艺部门打开NX就能看到每个操作的时间属性，下游系统也能通过属性同步接口直接读取。

op.SetAttribute("CAM_TotalTime", total, NXObject.AttributeType.Double); op.SetAttribute("CAM_CuttingTime", cut, NXObject.AttributeType.Double);

这里要注意的是，属性写入之后必须保存部件才会固化成文件数据，而且属性名要保持唯一，避免和CAM内部已有的属性冲突。我习惯在所有自定义属性前面加一个统一前缀，比如CAM_，这样后面做批量清理或同步时能一眼识别。

5.2 集成到菜单里：让编程工程师一键运行

脚本写好了，总不能每次都在NX里通过“执行Journal”去手动找文件。我在实际项目里习惯把这类工具集成到NX的菜单或Ribbon工具栏上。最简单的做法是在NX的“用户化”配置里挂一个菜单项，回调指向一个编译好的DLL函数。或者用NXOpen的菜单编辑机制，在startup目录下放好菜单脚本，让NX启动时自动加载。

菜单集成属于锦上添花，但落地效果好得多。之前让工程师手动执行Journal，一个月之后就没人在用了；后来我把按钮加到CAM工具栏上，配合一个“跑完自动弹报告”的反馈，使用率几乎百分之百。做开发的人很容易忽略“入口够不够方便”这件事，其实这直接决定工具能不能真正用起来。

5.3 时间为什么和后处理对不上：理论时间与机床时间

很多客户会拿这个工具导出的时间和实际机床上跑的循环时间比，发现对不上，然后跑来质问工具是不是算错了。这里我必须说清楚：NX里GetTime()返回的是理论加工时间，它依据刀轨长度和进给速度计算，不会考虑机床加减速特性、主轴响应时间、换刀时间和冷却等待。后处理输出的实际时间同样也是理论到实际之间的一个过渡值，因为不同后处理对快速移动的处理方式不同。

所以我的建议是，用这套工具做横向对比没问题，比如比较不同加工方案的效率，估算报价也基本够用；但如果你要作为真正的机床计费依据，最好还是结合机床数据采集系统或后处理时间做二次修正。在我的项目里，通常会按部件类型乘一个经验系数，比如0.85到1.1之间，用来把理论时间修正到接近实际生产时间。

5.4 大型部件与多Setup场景的落地建议

如果是大型模具或复杂结构件，CAM对象树里的节点动辄几百上千，递归遍历本身没有问题，但每一次GetChildren()调用都有一定开销。实测下来，两千多个节点的部件，完整遍历加导出一份CSV大概需要几秒钟，完全可以接受。如果发现性能瓶颈，建议优先优化输出部分的代码，比如用StringBuilder拼接文本而不要频繁操作List<string>，以及在遍历完成后再一次性写文件。

多Setup场景前面已经提过，这里再补充一点：如果不同Setup代表不同的加工区域，建议在CSV里增加一列Setup名称，这样后续按Setup分表统计会很方便。另一个小技巧是，在代码开头判断当前工作部件是否为装配，如果CAM配置在装配子件里，你可能需要递归遍历从属部件，或者让使用者先切换到包含CAM配置的显示部件，否则一样会什么都拿不到。

最后再分享一点个人体会。这类CAM时间提取工具，最容易被低估的其实是需求沟通，而不是技术本身。你以为用户要的是一堆数字，实际上他们想要的是“能直接放进今天报表里的格式”。所以我后来在做类似开发时，都会先问清楚三个问题：时间口径用哪种，输出格式是什么，谁来使用这个工具。把这几个问题搞定了，代码怎么写反而清爽得多。