UG NX与PLC-1500在环虚拟测试：机电联调全流程指南

1. 为什么我会把UG NX和PLC-1500放在一起做在环测试

干这行久了你会发现一个挺尴尬的现象：机械设计那边用UG NX把三维模型画得漂漂亮亮，电气那边用TIA Portal把PLC程序写得逻辑严密，但两边真正坐在一起讨论问题，往往要等到设备已经在车间里立起来、气路电路都接好了才发生。这时候如果程序有个低级错误，或者机械动作顺序和电气逻辑对不上，改起来就是拆了装、装了拆，时间和钱都是真金白银。

我这两年越来越习惯在一开始就做一件事：在电脑里把机械模型和PLC程序先"联调"一遍，也就是标题里说的UG NX与PLC-1500的在环虚拟测试。这里说的PLC-1500，就是西门子的S7-1500系列PLC，只是大家口语里经常这么叫。所谓在环，就是把PLC的程序逻辑和NX里的机电模型跑在一个闭环环境里，PLC输出的信号去驱动模型运动，模型里的传感器反馈再回到PLC程序里，形成完整的控制回路。

这项技术适合谁？说实话覆盖面挺广。做非标自动化设备、装配线、物流分拣线的机械工程师，写伺服电机和气缸控制逻辑的电气工程师，做数字化工厂规划的人，甚至高校里带学生做机电一体化课程设计的老师，都能从这里省出大量时间。这套方法的核心价值一句话就能说清：把原本在现实设备上才能发现的逻辑错误、干涉问题和时序冲突，提前到图纸还没出厂的阶段解决掉。

1.2 在环测试的层级，别搞混了

圈子里常说的在环测试其实分好几档，很多人一上来就混为一谈，导致方案的预期和结果对不上。

• MIL（Model in the Loop，模型在环）：控制逻辑是纯数学模型，机械部分也是数学模型，比如用Simulink做仿真。它的优点是跑得快、改起来方便，但和实际代码、实际硬件的差距很大。
• SIL（Software in the Loop，软件在环）：PLC程序编译出来的机器码跑在PC上，机械部分仍由仿真模型承担。这个层级的好处是，电气工程师在电脑上就能验证逻辑本身是通还是断。
• HIL（Hardware in the Loop，硬件在环）：使用真实的PLC硬件，接上仿真环境模拟的传感器和负载。这种级别最接近实际工况，但需要一台真实PLC，而且接线、配置都更费工夫。

UG NX与PLC-1500的在环虚拟测试，严格来讲是介于SIL和HIL之间的方案。PLC程序跑在PLCSIM Advanced这个虚拟PLC环境里，不占用真实硬件；而机械部分则完全由NX MCD（Mechatronics Concept Designer，机电概念设计模块）提供。它既有SIL的轻量，又比纯软件仿真的可置信度高——因为NX MCD的动力学解算和碰撞检测是非常接近真实物理情况的。

1.3 这个组合的实际价值：一次真实案例的启示

去年我帮朋友调试一条小型装配线的程序。按照传统流程，机械装配完成后电气进场，光是在现场来回改传感器位置和程序逻辑就用了一周多。后来第二个项目我们提前在NX里搭了整线的简化模型，包括几个滑台、气缸和传送带，PLC程序直接通过PLCSIM Advanced连上模型跑。结果有个气动顶升的顺序逻辑问题，在虚拟测试里就暴露出"气缸还没缩回就启动平移"的冲突，当场在办公室里就改了程序。后来设备进场，电气调试只用了大半天，基本是一次通过。

这就是在环虚拟测试最实在的价值：**把调试时间从车间搬回办公室，把试错成本从物理世界搬到数字世界。**下面我把整个链路拆开讲，从环境搭建到联调踩坑，把我这几年的经验一次说透。

2. 环境搭建与版本匹配：第一道真正的门槛

很多人在这一步就被卡住了，不是因为难度大，而是因为**西门子和西门子自家的软件，版本兼容性有时候也相当拧巴。**先把你需要的东西列全，再讲我在版本匹配上踩过的坑。

2.1 软件清单

做这套在环虚拟测试，你至少需要以下三套软件：

另外建议装一个Excel或WPS，后面批量配置信号映射时，用来整理IO表特别方便。

2.2 版本匹配关系（重点）

这步很容易踩坑。NX MCD、TIA版本、PLCSIM Advanced三者之间不是随便配的。我整理了一个大致参考表，具体安装前务必查阅各软件安装包自带的Release Notes确认：

我印象最深的一次，是用了NX 1980配TIA V15.1，结果在MCD里做外部信号映射时，始终找不到PLCSIM Advanced的实例。查了半天才发现，是PLCSIM Advanced V3.0对NX 1980的适配做得不够好，后来升级到TIA V16和PLCSIM Advanced V4.0才解决。所以这套组合里，PLCSIM Advanced的版本往往是最关键的卡点，优先保证它和TIA的版本兼容，再考虑NX的版本。

2.3 网络与虚拟网卡准备

PLCSIM Advanced运行时会创建一个虚拟的以太网适配器，你可以把它理解成给PC装了一个"虚拟出来的网口"，S7-1500的IP协议栈就跑在这个虚拟网卡上。TIA编译完成后，程序会通过这个虚拟网卡下载到虚拟PLC中。

需要注意两点：

• 建议提前在Windows的"设备管理器"里确认一下是否生成了名为PLCSIM Virtual Ethernet Adapter的网卡。如果没有，说明PLCSIM Advanced安装有问题，需要修复安装。
• 虚拟网卡的IP地址要规划好。大部分场景下，我会手动分配一个独立网段，比如192.168.10.1，子网掩码255.255.255.0，避免和公司办公网、WiFi网段冲突。别小看这一步，很多MCD连不上PLCSIM的案例，罪魁祸首就是IP段冲突或者虚拟网卡被系统禁用了。

2.4 安装顺序和授权注意事项

我一般推荐这个顺序：先装NX，再装TIA Portal，最后装PLCSIM Advanced。原因倒不是因为有什么严格的依赖关系，而是PLCSIM Advanced的安装配置有时会重置网络环境，放在最后装最省心。

另外一个容易忽略的点：**PLCSIM Advanced的许可证类型。**它支持按时间计量的试用授权和正式授权，授权过期后虚拟PLC实例会无法启动，错误提示有时候还特别隐晦。所以开工前先检查一下授权工具的许可状态，别做到一半发现工具罢工了。

3. NX MCD机电模型搭建：让机械结构变成"可执行对象"

在UG NX里做机电模型，不是把三维图装进去就完事。**NX MCD要的是"能动的对象"，不是"能看的模型"。**这里有几条核心原则和操作细节，我分开讲。

3.1 几何体简化：先跑通，再精细

建模的第一原则是：能简化就简化，不要试图把每一个螺丝、每一个倒角都带进虚拟测试。

倒角、圆角、螺纹这些细节，对动力学解算没有任何帮助，反而会大幅增加计算量。我的习惯是，直接用NX里的"简化体"命令，把模型的形状精简成方块、圆柱、平板等基本体。保留必要的轮廓尺寸和重心位置就够了，因为MCD里的刚体质量、惯性矩都可以后期手动指定或自动计算。

比如一个带导轨的滑台，实际结构可能很复杂，但在MCD里，我一般用一个长方体代表滑台的运动部分，一个固定底座代表静止部分，中间加一个滑动副就可以了。如果你非要保留丝杠、导轨滑块的所有零件，仿真速度会明显下降，而且运动学约束有时候反而会出现奇怪的问题。

3.2 刚体与运动副

创建运动副之前，必须先把参与运动的几何体定义为刚体（Rigid Body）。在NX MCD的命令里，选中几何体，指定质量和惯性矩，它就从一个普通三维体变成了具备物理属性的刚体对象。

运动副的选择直接决定机构的运动方式：

• 旋转副（Hinge Joint）：绕一个固定轴旋转，适合转台、折叠臂、门开合等场景。
• 滑动副（Slider Joint）：沿固定方向平移，适合滑台、气缸活塞、升降台。
• 圆柱副（Cylindrical Joint）：允许绕轴旋转同时沿轴滑动，适合气缸活塞杆这类既要伸出又要微转的机构。
• 球铰副（Spherical Joint）：允许三个方向旋转，适合机械臂腕部等场景。

在定义运动副时，还要注意设置碰撞体（Collision Body）。碰撞体不是必须的，但它决定了物体之间会不会互相阻挡。比如滑台走到导轨尽头要停住，你就必须在挡块位置设置碰撞体，否则滑台会直接穿过去。

3.3 信号适配器：模型和PLC之间的翻译官

这是整个NX MCD里最核心的概念。**信号（Signal）是PLC和模型之间的沟通语言。**MCD通过定义输入信号和输出信号，在外面暴露出一组可供PLC读写的接口。

以气缸为例：

• MCD输出（给PLC的信号）：气缸是否伸出到位、是否缩回到位、活塞当前位置。
• MCD输入（PLC给模型的信号）：控制气缸伸出、控制气缸缩回。

在NX MCD里，创建信号的路径是"运行时行为"相关的命令面板，找到"信号"并添加输入/输出信号。我强烈建议从一开始就建立一套命名规范，比如：

命名规范这个事儿，一开始嫌麻烦，等你处理上百个IO点的时候，就知道有多省事了。名字乱的话，信号映射时手动找都要找老半天。

3.4 外部信号映射：把MCD信号绑定到PLC变量

模型里的信号建好之后，需要把它们映射到PLC程序里的变量。操作路径在NX MCD里的"外部信号映射"功能，可以选择PLCSIM Advanced作为目标。

映射的关键是建立信号名与PLC变量地址/名称的对应关系。如果两边都用了一致的命名，映射时可以自动匹配；如果名字对不上，就要手动一个一个拖。

在映射时，特别要注意信号的数据类型和长度。MCD里的Bool型信号对应PLC的Bool变量，Real型对应Real变量，Integer对应Int或DInt。类型不匹配轻则数值截断，重则映射失败直接断线。另外，字节序（大端/小端）在PLC中默认是大端传输，这在MCD连接大多数S7设备时是天然兼容的，但如果中间有第三方转换层，就需要额外关注。

3.5 建模时另一个容易被忽略的"仿真步长"

NX MCD里的仿真默认是按时间步长推进的。步长越短，结果越精细，但计算量越大。我一般先按默认值跑通整个逻辑，再去调整步长观察细节动作。如果需要做高速运动机构（比如凸轮、飞剪）的时序分析，再专门把步长缩短，同时配合MCD的数据记录工具抓取运动曲线。

4. PLC-1500虚拟PLC侧配置：从TIA到PLCSIM Advanced

模型这边准备好了，接下来是PLC侧。这一步的关键词是：让编译后的PLC程序真正跑在一个"虚拟CPU"上。

4.1 创建PLC项目和程序

在TIA Portal里新建项目，组态一台S7-1500 PLC。注意，这里的关键在于硬件的固件版本（Firmware Version）要和PLCSIM Advanced支持的版本匹配，否则后面下载程序时会报错。

比如PLCSIM Advanced V4.0对S7-1500固件版本有限制，你在TIA里组态时如果选择了过新的固件，虚拟PLC可能无法识别。解决办法是查一下PLCSIM Advanced版本对应的固件支持范围，在组态时选择兼容的固件版本。

程序逻辑按正常方式编写，不需要特殊处理。以我上一个项目为例，我写了一个最简单的电机正反转控制程序：

• I0.0：正转启动按钮
• I0.1：反转启动按钮
• Q0.0：电机正转接触器
• Q0.1：电机反转接触器
• I0.2：正转限位开关
• I0.3：反转限位开关

这个程序本身没什么特别，重点是这些IO地址要和NX MCD里映射的信号对应上。你在TIA里分配了多少IO点，MCD的模型就要准备好相应数量的信号接口。

4.2 PLCSIM Advanced实例创建

启动PLCSIM Advanced，你会看到一个管理虚拟PLC实例的界面。操作的要点是：

1. 创建一个新实例，选择的PLC类型必须和TIA里组态的一致（比如CPU 1511-1 PN）。
2. 为实例分配IP地址，例如192.168.10.10。
3. 启动实例。成功后，它会显示为一个绿色状态，你可以把它理解成一台"已经通电待命"的虚拟PLC。

顺便说一句，PLCSIM Advanced支持同时运行多个实例，这在做多PLC联动仿真时非常有用。我可以同时启动一台S7-1500和一台S7-300仿真，让它们通过真实的S7通信指令互相交互，效果和现场两台PLC通过以太网通信几乎一样。

4.3 程序下载到虚拟PLC

在TIA Portal里点击下载，选择目标类型为PLCSIM，接口选择PLCSIM Advanced提供的虚拟网卡对应的访问点，就能把程序下载到虚拟PLC里。

下载过程可能遇到的坑是访问点名称不对。TIA的PG/PC接口设置里，必须选择"PLCSIM Advanced"或"Siemens PLCSIM Virtual Ethernet Adapter"作为访问点。如果你电脑上装过真实网卡驱动，TIA有时候会倾向于选择真实网卡，导致下载失败。解决办法是在TIA的下载对话框里手动强制指定访问点。

下载完成后，虚拟PLC会进入运行或停止状态，你可以手动把它切到RUN。到这里，一台"跑着真实PLC程序"的虚拟控制器就算备妥了。

4.4 PLC侧的在线监控

一个有价值的技巧是：虚拟PLC同样支持TIA的在线监控和梯形图调试功能。你可以在TIA里打开梯形图，一边看着PLC程序的输入输出状态，一边看着NX MCD里模型的运动情况。这种"程序状态+机械动作"同屏对照的体验，现场调试时反而不容易实现。

我调试时经常把TIA的编程窗口和NX的MCD窗口并排放，PLC程序里某个位变成1，NX模型里相应的气缸马上动作，非常直观。这也是在环虚拟测试相比纯软件仿真最爽的地方。

5. 从启动仿真到联动调试：一次完整的流程

环境有了，模型有了，程序有了，接下来就是让它们跑起来。这一步是整套链路中成就感最强、也是各种问题集中爆发的阶段。

5.1 正确的启动顺序（重要）

我不止一次看到有人在论坛上问"为什么MCD连不上PLCSIM"，结果一问，顺序反了。稳妥的启动顺序是：

1. 启动PLCSIM Advanced，创建并启动虚拟PLC实例。
2. 确认虚拟PLC状态为RUN。
3. 在TIA Portal里把程序下载到虚拟PLC，并触发RUN。
4. 打开NX MCD文件，进入"外部信号映射"界面，确认映射状态为已连接。
5. 在MCD里启动仿真模式，观察模型状态。

为什么这个顺序很关键？因为NX MCD在启动仿真时，会去主动连接PLCSIM Advanced的实例。如果PLCSIM侧还没就绪，MCD的连接请求就会失败，之后即使PLCSIM启动正常了，MCD也不会自动重连，必须你手动刷新或重新映射一次。

5.2 判定联调成功的标准

如何确认整个链路确实通了？我的判断标准是：

• 信号方向正确：PLC里给一个输出置位，MCD模型里相应的机构开始运动，不是反向的。
• 反馈准确：模型里某个传感器信号被触发，PLC程序里对应的输入位变化为1。
• 时序正确：比如气缸先完全伸出，触发到位信号，PLC才允许下一步动作，这个先后顺序不能乱。
• 异常处理生效：按下模型的急停信号，PLC程序能够立刻进入安全停车分支。

前三条都好理解，第四条往往在真实设备调试时才会重视，但在虚拟测试里，你有最好的机会去验证急停、超时报警、互锁逻辑等安全功能。别偷懒，这些功能必须在虚拟阶段就完整验证一遍。

5.3 一个直线滑台案例走查

拿我上面提到的直线滑台举例，整个过程是这样的：

• 我按下TIA里的仿真按钮（或者在模型上做一个虚拟按钮），PLC程序置位Q0.0，正转输出为1。
• 这个状态通过PLCSIM Advanced的通信层传到NX MCD的外部信号映射里，MCD识别到"Move_Slide_Forward"输入信号为真。
• 滑台的运动副收到一个正向驱动力，开始在滑动副上向右移动。
• 当滑台到达右端时，碰撞体在一个限位传感器的位置触发，MCD把"Slide_At_Right"输出信号置为1。
• PLC程序收到I0.2为1，把Q0.0复位，同时如果后续逻辑有下一步指令，就继续执行。

这条链路看一眼就能明白，和真实设备的逻辑是完全一致的，唯一的区别就是电机换成了虚拟驱动力、传感器换成了碰撞体触发、导线换成了TCP/IP信号。

5.4 数据记录与回归测试

虚拟测试一个特别大的优势是结果可记录、可对比、可回归。NX MCD支持把仿真过程中的运动曲线、速度曲线导出，PLCSIM Advanced也支持变量记录的导出。我一般会把每个测试用例的运行结果保存下来，等程序改了一版之后再用同一组测试用例跑一遍，看看有没有哪里逻辑退化了。

这种"回归测试"能力在现场调试中属于奢侈品，一台设备动起来之后很难再回到初始状态重新跑一遍，但在虚拟测试里，只要按一下复位，模型回到初始位置，PLC程序重新执行，几分钟就能跑完一轮完整测试。这也是后面第七节要讲的自动化的基础。

6. 联调翻车现场：我把容易踩的坑都列出来

做虚拟调试这两年，我总结了几类高频问题。这些问题单独看都不难，但排查起来往往特别费时间，我按实际排查链路写出来，希望能帮你少走弯路。

6.1 现象一：信号映射一直是红色断线

这是最常见的问题。在NX MCD的外部信号映射界面里，状态列一直显示红色，或者干脆找不到PLCSIM Advanced实例。

我的排查顺序是：

1. PLCSIM Advanced实例是否真正运行。有些人把实例创建了但没启动，看起来有，其实连不上。
2. 虚拟网卡是否被禁用。Windows更新有时候会重置网络适配器，把PLCSIM Virtual Ethernet Adapter给禁掉，去设备管理器里检查一下。
3. IP是否相通。用命令行ping一下PLCSIM虚拟网卡的IP地址（比如192.168.10.10），不通就检查虚拟网卡的IP设置。
4. 防火墙拦截。Windows Defender防火墙有时候会拦截PLCSIM Advanced的通信端口，暂时关闭防火墙测试，如果能连上，就添加相应的放行规则。
5. NX MCD内部连接管理器是否刷新。有些情况下手动刷新一次外部信号映射连接即可。

6.2 现象二：PLC输出置位了，模型纹丝不动

PLC程序里看状态，Q0.0已经置1了，但NX模型里的电机就是不转。

这个问题十有八九是信号映射配置出了问题。排查步骤：

1. 检查MCD输入信号是否真的收到了PLC的置位值。可以在MCD的信号监控面板里看这个信号的值，如果还是False，说明链路在中间断了。
2. 检查映射关系是否搞反了方向。输入输出方向反了，PLC输出信号进了MCD的输出端口，模型当然不会反应。
3. 检查运动副的驱动方式。如果MCD运动副定义的"驱动源"是"速度"，但PLC发送的是位置指令，模型可能会忽略这个输入。要确保PLC发送的数据类型和运动副接受的驱动参数类型一致。

6.3 现象三：仿真一开始CPU就跑满，模型一顿一顿

这是性能问题，常见于模型复杂度过高或通讯步长设置不合理。

我的处理办法：

• 把MCD模型的碰撞体数量降下来。碰撞检测是最消耗计算资源的部分，能删就把不必要的碰撞体删掉。
• 缩短仿真步长不一定能解决问题，反而会增加计算量。先把步长调大，跑通逻辑再说。
• 检查数据记录功能。MCD里如果开了大量信号的数据记录，每个仿真步都要写盘，会很拖速度。测试阶段就把数据记录关掉，等需要分析时再开。

6.4 现象四：换了一台电脑就各种连不上

虚拟测试项目经常要在台式机和笔记本之间移动，换环境后最容易出问题的是授权问题和版本不匹配。PLCSIM Advanced的授权是绑定电脑的，换机器后要重新激活；另外，目标机器上的TIA版本、PLCSIM Advanced版本必须和原机器一致，否则项目文件能打开，但虚拟PLC可能拒绝运行。

所以我建议在项目启动前，就把所有参与虚拟测试的机器统一"软件基线"，包括NX、TIA、PLCSIM Advanced的版本、服务包、甚至操作系统版本，全部记录在项目文档里。别小看这件事，比任何调试经验都省时间。

7. 用NX二次开发把虚拟测试自动化

做到这一步，说明你已经能手工跑通整个在环虚拟测试流程了。但对于真正的项目交付，手动流程还是太慢。一个大型设备可能有几百个IO信号、几十个运动副，手动建模型、手动映射、手动测试，效率和出错率都会成为瓶颈。

7.1 为什么必须走向自动化

我做过一个项目，设备不算大，但IO点有三百多个。如果全部手动在NX MCD里创建信号再手动映射，没有半天搞不定。而用脚本批量生成，整个过程压缩到十几分钟。

NX二次开发（NX Open）支持C#、C++和Python。对于虚拟测试自动化，我强烈推荐用Python，原因是上手快、代码量少，而且和MCD的API配合得不错。你可以在NX的"执行"菜单里直接运行脚本。

7.2 批量创建刚体和信号

举一个最简单的例子。假设你的装配体里所有需要变成刚体的零件名都以"RB_"开头，你可以用一段Python脚本批量处理：

import NXOpen import NXOpen.Mechatronics session = NXOpen.Session.GetSession() work_part = session.Parts.Work mcd = work_part.MechatronicsManager for body in work_part.Bodies: if body.Name and body.Name.startswith("RB_"): rb = mcd.RigidBodyCollection.Create(body) rb.Name = body.Name

这只是最基础的一步。你可以继续扩展，从Excel表格里读取信号清单，自动创建MCD输入输出信号：

import csv with open("signal_list.csv", "r") as f: reader = csv.DictReader(f) for row in reader: name = row["signal_name"] direction = row["direction"] # "Input" or "Output" data_type = row["data_type"] # "Bool", "Real", "Int" if direction == "Input": signal = mcd.SignalCollection.CreateInputSignal(data_type) signal.Name = name else: signal = mcd.SignalCollection.CreateOutputSignal(data_type) signal.Name = name

信号模板批量创建之后，你可以在MCD里手动把它们和几何体、运动副关联起来。虽然这一步目前还需要一定的人工介入，但已经把最耗时的重复劳动大幅压缩了。

7.3 自动映射与回归测试

再进一步，你可以用脚本直接操作外部信号映射，把MCD信号和PLCSIM Advanced变量一一绑定。这需要用到NX Open里和外部信号映射相关的API，核心思路是遍历信号列表，逐个指定目标PLC变量名和地址。

前阵子圈子里在讨论NX与MCP这类更开放的控制接口方案，本质上是想让NX的模型信息和外部控制/调度系统更自由地融合。我没有把这条路完全走通，但方向是明确的：**通过二次开发把NX MCD的IO通道抽象成标准接口，让不同的控制器（虚拟PLC、真实PLC、甚至外部调度系统）都能用一致的方式接入。**就算暂时不做那么深的集成，只把脚本做成一键建立映射、一键启动仿真、一键恢复初始状态，就已经能为回归测试省下大量时间了。

7.4 自动化回归测试的执行方式

一个简单的自动化回归测试流程，我的做法是：

1. 提前准备多组输入信号表，每组对应一个测试场景（比如"正常流程"、"急停"、"堵料"）。
2. 写一个Python脚本，按顺序加载每组信号，驱动PLCSIM Advanced里对应的PLC变量置位。
3. 在NX MCD里启动仿真，运行固定时长后，记录模型的最终状态和PLC的输出状态。
4. 把记录结果和期望结果比对，输出测试报告。

整个过程不需要人盯着屏幕，跑完一批测试用例直接看报告。对于需要出正式项目文档的交付场景，这比手动截屏记录要专业得多。

回到最开始的问题：为什么费这么大劲把UG NX和PLC-1500拉在一起做在环虚拟测试？我个人的体会是，它不只是一个软件操作技巧，更是一种把调试环节前置的思维方式。机械和电气不再各自闷头干活，而是通过这套数字链路，在设计阶段就互相咬合、互相验证。第一次跑通整套流程的时候可能觉得繁琐，但一旦形成模板，后续每个项目都会越用越顺手——尤其在那些改了一遍又一遍的程序版本之间，虚拟测试给了我们从容试错的底气。