、
**阅读时间：**约6分钟
**适用人群：**使用 LabVIEW 实时（Real-Time）开发环境的工程师，尤其是刚刚接触 PXI 实时控制器或 CompactRIO、需要通过"调用库函数节点"（Call Library Function Node）调用自定义动态链接库，并希望在开发阶段或正式部署阶段把 DLL、INI 配置文件等支持文件正确传送到目标机的用户。
一、背景与问题现象
在使用 NI PXIe-8133 等实时控制器配合 LabVIEW Real-Time 开发环境时，一个常见的需求是通过"调用库函数节点"调用自定义 DLL。这类 DLL 通常承担硬件访问职责，例如先读取一个 INI 配置文件，再根据其中记录的路径调用另一个 DLL，从而完成对采集卡的初始化与读写操作。此时工程中往往同时存在多个文件：主 VI、被包装的 DLL、INI 配置文件，以及 DLL 间接依赖的另一个 DLL。
在开发初期，许多用户会把这些文件全部拖入 LabVIEW 工程窗口，以为文件一旦出现在工程中，运行 VI 时就会自动被下载到实时目标机上。然而实际操作时往往会发现，把包含"调用库函数节点"的 VI 运行到目标机上之后，节点却找不到 DLL，VI 报错或返回"无法加载共享库"之类的错误信息。工程里明明已经添加了 DLL，目标机上的程序却访问不到，这正是这一类问题的典型现象。对于后续需要加载 NI DSC 等软件模块的场景，还可能看到 "Failed to load shared library" 的提示，说明目标机文件系统中缺少对应的库文件。
二、原理或机制分析
要理解这一现象，需要厘清 LabVIEW 工程与实时目标机之间文件关系的本质。工程窗口中的文件条目只是对源文件位置的登记，并不等同于文件已经部署到目标机。当在开发环境中执行一个面向实时目标的 VI 时，LabVIEW 会把 VI 的代码及其框图上的静态依赖（被调用的 VI）下载到目标机；但对于程序运行期才动态引用的外部资源，情况则完全不同。
"调用库函数节点"是在运行时才加载 DLL 的。该节点本身只把 DLL 的名称或路径信息交给目标机的加载器，由目标机操作系统在其文件系统中查找这个 DLL。与运行 Windows 的主机不同，实时控制器运行的是实时操作系统，其目录结构和加载器搜索路径都比较有限，普通 Windows 平台编译的 DLL 也无法直接使用，必须由合适的工具链针对目标机的操作系统与处理器架构重新构建。DLL 的加载还涉及依赖链：第一个 DLL 要读取 INI 文件，INI 文件又记录了第二个 DLL 的存放路径，只要其中一个文件缺失或路径不符，整条调用链就会中断。
此外，工程构建规范（Build Specification）才是控制文件打包去向的地方。把文件标记为"始终包含"（Always Included）之后，构建并部署可执行程序时，支持文件才会随程序一起传送到目标机，通常存放于可执行程序所在的 data 子目录中。开发阶段如果不构建可执行程序，这套机制就不会生效，文件自然不会被传送。
三、实现方法或解决方案
针对开发阶段与正式部署阶段，有以下几种可靠做法。
方法一：使用 MAX 的文件传输功能。在 MAX（Measurement & Automation Explorer）中右键点击实时目标，选择"文件传输"（File Transfer）选项，即可打开一个基本的 FTP 客户端界面，浏览目标机的目录结构并上传文件。也可以改用功能更完整的 FTP 客户端，例如 FileZilla，通过 FTP 协议把 DLL、INI 等文件直接复制到目标机。对于"调用库函数节点"所需的主 DLL，将其放置到目标机的系统目录中，节点运行时即可找到；INI 文件应与该 DLL 位于同一目录；第三个被间接调用的 DLL 可以放在任意位置，只需把它的完整路径写入 INI 文件。
图1 通过 MAX 的文件传输功能浏览并上传文件到实时目标机的界面示意
方法二：构建并部署一个最小的实时可执行程序。在工程中为实时目标建立 RTEXE 构建规范，把 DLL、INI 等所有支持文件加入构建规范并标记为"始终包含"，然后执行部署。部署完成后，所有文件都已存在于目标机上，之后就可以在开发环境中直接运行 VI，目标机能够找到所需的全部文件。这种方法尤其适合长期以演示 VI 调用库接口的场景，它能一次性把文件安置到稳定的位置。
方法三：通过 MAX 安装 NI 软件组件。如果错误涉及 NI 自带的模块库，例如 DSC 模块的 nialarms.dll，则应优先使用 MAX 在目标机上安装对应的 NI 软件包，再结合 FTP 上传自定义库文件，两者配合才能解决依赖缺失问题。
四、关键设计要点与易错点
第一，把文件加入工程不等于部署。工程窗口中的 DLL 条目仅表示文件被工程登记，实时目标机并不会因此获得该文件，必须借助 FTP 传输或构建部署机制才能实现传送。
第二，不要混淆目标机平台与主机平台。标准 Windows DLL 无法在实时目标机上运行，DLL 必须针对目标机的操作系统与处理器架构构建，否则即使文件已经到位，加载依旧会失败。
第三，注意 DLL 的依赖链。仅上传主 DLL 往往不够，它依赖的其他 DLL 与配置文件必须一并上传，并保证相对路径或绝对路径正确。INI 文件通常必须与主 DLL 位于同一目录，间接 DLL 的路径则记录在 INI 之中。
第四，留意可执行程序部署后的目录布局。通过 RTEXE 部署时，支持文件通常被放入 data 子目录，"调用库函数节点"中的路径设置必须与之匹配，必要时在程序中使用属性节点或配置文件动态拼接绝对路径。
第五，复制文件后应通过 MAX 的文件传输界面核对目标机上的文件是否可见、大小是否正确，避免因传输中断导致文件损坏或残留旧版本。
五、实践建议与小结
对于刚刚接触 LabVIEW 实时开发的工程师，建议先从 MAX 的文件传输功能入手。它步骤直观，无需构建程序就能把文件送达到目标机，便于快速验证"调用库函数节点"能否正确加载库；之后再逐步过渡到构建 RTEXE 并标记"始终包含"的正式做法，为后续交付做准备。无论处于哪个阶段，都应当把 DLL、INI 及其全部依赖视为一个整体来规划存放目录与路径约定，并把"目标机平台是否匹配、文件是否真实送达"作为排查问题的首要检查项。
总而言之，向实时目标下载 DLL 的核心在于理解"工程登记"与"物理部署"的区别：文件不会因为出现在工程窗口中就被传送到目标机，必须通过 FTP 传输或构建部署显式完成。同时要确保库文件针对目标平台构建，依赖文件齐备且路径正确。掌握这些要点之后，无论是开发阶段的快速调试，还是部署阶段的正式交付，都能让实时程序稳定地访问到自定义动态链接库。