、阅读时间约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 运行到目标机上之后节点却找不到 DLLVI 报错或返回无法加载共享库之类的错误信息。工程里明明已经添加了 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 的文件传输功能。在 MAXMeasurement 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 传输或构建部署显式完成。同时要确保库文件针对目标平台构建依赖文件齐备且路径正确。掌握这些要点之后无论是开发阶段的快速调试还是部署阶段的正式交付都能让实时程序稳定地访问到自定义动态链接库。
将自定义 DLL 与 INI 文件部署到 LabVIEW 实时目标
、阅读时间约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 运行到目标机上之后节点却找不到 DLLVI 报错或返回无法加载共享库之类的错误信息。工程里明明已经添加了 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 的文件传输功能。在 MAXMeasurement 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 传输或构建部署显式完成。同时要确保库文件针对目标平台构建依赖文件齐备且路径正确。掌握这些要点之后无论是开发阶段的快速调试还是部署阶段的正式交付都能让实时程序稳定地访问到自定义动态链接库。