简介：本资源是一套专为LabVIEW开发者设计的安捷伦34970A数据采集器驱动程序套件，面向自动化测试、高校实验及工业数据采集领域的工程师与科研人员，解决LabVIEW环境下快速接入、配置、扫描控制与多通道测量等核心交互问题。压缩包共72个文件，含60个功能完备的VI（覆盖初始化、通道配置、高级扫描、矩阵开关、RF复用等典型操作）、7个菜单文件（mnu）用于集成至LabVIEW工具栏、1个lvlib库文件实现模块化管理，以及lvproj工程、aliases别名配置、HTML说明文档和bin3二进制资源，整体仅1.29MB，轻量易部署。已有2410人学习下载，资源结构清晰，按Public/Private/Examples分层组织，内置EZ Scan与Advanced Scan等典型应用范例，附带Default Instrument Setup等实用工具VI，可直接调用或二次开发，显著降低硬件通信开发门槛，助力用户高效构建高可靠性数据采集系统。
1. Agilent 34970A 数据采集开关单元的 LabVIEW 驱动程序：不是“即插即用”的封装包，而是需要你亲手拧紧每颗螺丝的底层通信胶水
你手头有一台 Agilent 34970A（现为 Keysight 34970A），它是一台带扫描功能的精密数据采集/开关控制单元，常用于温度、电压、电阻等多通道自动测试场景。但当你在 LabVIEW 中拖出一个 VISA Write VI，发一条*IDN?命令却收不到回显，或者用 Switch Executive 配置完通道后发现继电器根本不动作——这时候你才意识到：LabVIEW 自带的仪器驱动库（IVI、NI-DAQmx）根本没把它当“自己人”。这个名为 “agilent_34970LabVIEW驱动程序” 的资源，不是官方发布的成熟 IVI 驱动，而是一套由某高校测控实验室开发者整理、验证并开源的VISA 层级原始驱动集合。它不提供图形化配置面板，也不自动映射通道名到物理端子；它只做三件事：把 SCPI 命令可靠地发出去、把响应字符串干净地读回来、把常见操作（如扫描启动/停止、通道闭合/断开、读数获取）封装成可复用的子 VI。适合正在搭建自动化产线校准系统、实验室温循监控平台或嵌入式传感器标定流程的工程师——你得懂 SCPI 协议结构、会查 34970A 编程手册第 5 章的命令语法、能看懂 VISA 资源名称格式（如ASRL1::INSTR或TCPIP0::192.168.1.100::inst0::INSTR），否则它不会替你兜底。
2. 驱动程序结构解析与核心 VI 功能拆解：从顶层调用到底层 VISA 通信的完整链路
这套驱动程序并非单个.lvlib文件，而是一个典型的 LabVIEW 项目级组织结构，包含明确分层的 VI 模块。它没有采用 IVI-COM 或 .NET 封装，全部基于原生 VISA 和字符串处理构建，因此兼容性极强（LabVIEW 2013 SP1 及以上均可运行），但也意味着所有错误处理逻辑都暴露在你眼前。下面按调用层级逐层展开，重点说明每个模块的不可替代性与参数设计意图。
2.1 主控 VI：Agilent34970A_Init.vi—— 连接建立与硬件握手的唯一入口
这是整个驱动链路的起点，也是最容易翻车的第一关。它不接受 IP 地址字符串，而是要求你传入一个完整的 VISA 资源名称（Resource Name）。该 VI 内部执行三步原子操作：打开 VISA 会话、设置超时（默认 5000 ms）、发送初始化命令*RST; *CLS; :SYST:COMM:SER:BAUD 9600（重置设备、清空错误队列、强制串口波特率）。注意：它不自动探测设备，也不会帮你从 NI MAX 里读取已识别的资源列表——你必须先确认设备已在 NI MAX 中显示为在线状态，并复制其准确的资源名。
# 实际调用示例（在 LabVIEW 前面板上手动输入）： # 串口连接：ASRL4::INSTR # COM4 对应的 ASRL 资源名 # TCP/IP 连接：TCPIP0::192.168.1.100::inst0::INSTR # 注意 inst0 是 34970A 默认的 LAN 接口别名提示：若使用 TCP/IP 连接，请确保 34970A 前面板 Network 设置中启用了 “LAN Interface”，且“VXI-11” 或 “Socket” 服务已开启（推荐 Socket，更轻量）。
inst0是设备固件预设的接口名，不可修改；若改用 VXI-11，则资源名应为VXI11::192.168.1.100::INSTR，此时需额外安装 NI-VISA 的 VXI-11 支持组件。
该 VI 输出两个关键句柄：VISA Refnum（供后续所有 VI 复用）和Error Out。切勿跳过此步直接调用其他功能 VI——所有后续 VI 都依赖此句柄进行通信，未初始化即调用会导致 VISA 错误 -1073807339（“Invalid session reference”）。
2.2 通道控制 VI：Agilent34970A_CloseChannel.vi与Agilent34970A_OpenChannel.vi—— 继电器动作的精确开关
34970A 的核心价值在于其内置的多路复用开关矩阵（如 34901A 模块为 20 通道单刀单掷）。这两个 VI 就是控制物理继电器通断的“扳手”。它们接收的不是“CH1”、“TEMP1”这类语义化名称，而是标准 SCPI 通道地址字符串，例如"101"（模块1通道1）、"116"（模块1通道16）、"205"（模块2通道5）。这种设计看似反直觉，实则精准对应手册中定义的(@101)语法，避免了抽象层引入的歧义。
# 关闭通道 101（即让继电器断开） # 输入参数： # VISA Refnum: 来自 Init.vi 的输出 # Channel String: "101" （字符串，非数字！） # Timeout (ms): 可选，默认 1000 # 执行 SCPI 命令：":ROUTe:OPEN (@101)"# 打开通道 101（即让继电器闭合） # 执行 SCPI 命令：":ROUTe:CLOSe (@101)"关键细节在于：该 VI 不检查通道当前状态。如果你对已闭合的通道再次执行CloseChannel，设备无反应，VI 也返回成功（因为 SCPI 协议本身允许重复执行）；同理，对已断开的通道执行OpenChannel亦然。这意味着状态同步完全由上层逻辑维护——比如你在主循环中用一个布尔数组记录各通道当前通断状态，每次操作前先比对，再决定调用 Open 还是 Close。
2.3 数据采集 VI：Agilent34970A_ReadScan.vi—— 扫描模式下的批量读数引擎
这是驱动中最复杂的 VI，负责启动一次完整的扫描序列并返回所有通道的测量值。它不支持“单次读取某一个通道”，而是严格遵循 34970A 的扫描机制：先用:ROUTe:SCAN命令定义扫描列表（如(@101,102,103)），再用:INITiate启动扫描，最后用:FETCh?获取结果。该 VI 将这三步封装为一个原子操作，并自动处理逗号分隔的 CSV 格式响应（如"25.123,25.124,25.122"）。
# 输入参数详解： # VISA Refnum: 同上 # Scan List String: "@101,102,103" （注意开头的 @ 符号和逗号分隔，无空格） # Measurement Type: 字符串，如 "TEMP", "VOLT:DC", "RES" （必须与模块能力匹配） # NPLC: 数字，积分时间倍数（1=0.02s, 10=0.2s, 100=2s） # Range: 字符串，如 "100"（100°C）, "10"（10V）, "1000"（1000Ω） # 输出： # Readings Array: DBL 数组，长度等于 Scan List 中通道数 # Timestamps Array: U64 数组，单位为纳秒（自 LabVIEW 启动起），可用于计算实际采样间隔注意：
Measurement Type必须与所插模块的实际功能一致。例如 34901A 是通用多路复用器，不支持直接测温，若你强行设为"TEMP"，设备将返回错误-222（“Setting not allowed”）。正确做法是：用 34902A（热电偶模块）或 34903A（RTD 模块），并在Scan List中指定对应通道（如"201"表示模块2通道1）。
3. SCPI 命令映射与底层 VISA 交互原理：为什么不能绕过驱动直接发字符串
很多工程师初学时会想：“既然 34970A 认 SCPI，我直接用 VISA Write/Read 不就行了？何必用这套驱动？” 这是个血泪经验换来的误区。这套驱动的价值，恰恰藏在它对 SCPI 协议细节的“过度处理”中。下面以最常被忽略的:READ?命令为例，拆解驱动如何把黑匣子变成可控白盒。
3.1:READ?命令的隐式状态依赖：一次读数背后有四个隐藏步骤
当你在终端里敲:READ?并收到一个数值，LabVIEW 驱动其实默默完成了以下四步：
- 查询当前配置：先发
:CONF?获取当前测量类型（如VOLT:DC 10,0.000001），确认量程与分辨率； - 触发单次测量：发
:TRIGger:SOURce IMM切换为即时触发模式（避免受扫描队列干扰）； - 执行读数：发
:READ?，等待设备返回字符串（如"2.501234E+00"）； - 清理触发源：发
:TRIGger:SOURce BUS恢复总线触发（防止影响后续扫描）。
如果跳过驱动，仅用VISA Write(":READ?") + VISA Read()，你大概率会得到错误-222或超时。原因在于：设备可能仍处于扫描模式（TRIG:SOUR SCAN），此时:READ?被忽略；或量程设置不当导致读数溢出。驱动 VIAgilent34970A_ReadSingle.vi就是把这些状态切换逻辑固化下来，确保每次:READ?都在干净、确定的上下文中执行。
3.2 字符串解析的容错设计：应对设备返回的“脏数据”
34970A 的 SCPI 响应并非总是干净的数字。在高噪声环境或长电缆下，你可能收到：
- 开头带空格：
" 2.501234E+00" - 结尾带换行符：
"2.501234E+00\r\n" - 多余的引号：
'"2.501234E+00"' - 错误码混入：
"+2.501234E+00;+0.000000E+00"（双读数模式）
驱动中的String To Number子 VI 并非简单调用 LabVIEW 原生函数，而是前置了Trim Whitespace、Search and Replace（移除引号）、Scan From String（用%g格式解析科学计数法）。更重要的是，它会对解析失败做降级处理：若Scan From String返回NaN，则尝试用正则(-?\d+\.\d+E[+-]\d+)提取有效数字段——这是某开发者在产线现场连续抓包 72 小时后加上的后悔药。
3.3 VISA 层级的超时与重试策略：为什么你的读数偶尔“卡住”
VISA 的默认超时（1000 ms）对 34970A 的慢速测量（如 NPLC=100 时需 2 秒）是致命的。驱动在每个VISA Read前，都会根据NPLC参数动态计算超时值：Timeout = max(1000, NPLC * 200)ms。同时，它实现了有限重试（默认 2 次）：若首次VISA Read返回空字符串或错误-1073807339（Timeout），则自动重发:READ?命令。这不是“网络不稳定”的补救，而是对 34970A 固件中一个已知行为的适配——当设备刚从待机唤醒，首次读数可能因内部时钟未稳而丢弃。
4. 常见问题排查与五大典型踩坑记录：那些让你调试到凌晨三点的“玄学”故障
这套驱动程序最大的特点是“诚实”：它不掩盖硬件缺陷，也不美化协议漏洞。下面列出我在三个不同项目中反复遇到、且文档里绝不会写的五条真实踩坑记录，每条都附带可立即验证的定位方法。
4.1 现象：Agilent34970A_Init.vi返回错误 -1073807346（“Unable to open VISA resource”）
原因：NI MAX 中设备状态显示“Online”，但实际 VISA 资源名已被其他 LabVIEW 应用独占。34970A 的 VISA 会话不支持多客户端共享，同一资源名只能被一个进程打开。
解决：在 NI MAX 中右键设备 → “Close Session”；或在任务管理器中结束所有labview.exe进程；终极方案是重启 NI Visa 服务（Windows 服务列表中找到 “NI Visa Server”，重启）。
4.2 现象：Agilent34970A_ReadScan.vi返回全零数组，但设备面板显示正常读数
原因：Scan List String输入了错误的语法。常见错误包括：漏掉@符号（输成"101,102"而非"@101,102"）、通道间用了中文逗号、末尾多了一个逗号（"@101,102,"）。34970A 对语法极其敏感，此类错误不会报错，而是静默忽略整个扫描列表。
解决：用VISA Test Panel手动发送:ROUTe:SCAN?，查看返回值是否为预期列表；若返回空，则证明Scan List未生效。
4.3 现象：TCP/IP 连接下，Agilent34970A_ReadScan.vi首次调用成功，后续调用超时
原因：34970A 的 Socket 接口存在一个固件级 Bug：当连续快速发送命令（间隔 < 50 ms），设备可能进入“假死”状态，不再响应新请求，但 VISA 会话仍显示正常。
解决：在每次VISA Write后强制添加Wait (ms)，最小间隔设为 100 ms；或改用 VXI-11 协议（需在设备端启用），其底层重传机制对此类问题更鲁棒。
4.4 现象：串口连接时，Agilent34970A_CloseChannel.vi执行后继电器无动作，但VISA Write测试命令*IDN?能收到响应
原因：串口线缆的 RTS/CTS 流控信号未正确连接。34970A 在串口模式下默认启用硬件流控，若线缆只接了 TX/RX/GND 三根线（常见于廉价 USB 转串口线），设备会拒绝执行任何:ROUTe:命令，但基础*IDN?仍可工作。
解决：更换为全信号线缆（含 RTS/CTS），或在设备前面板进入Setup > Communication > Serial，将 “Flow Control” 设为 “None”。
4.5 现象：使用 34902A 热电偶模块时，Agilent34970A_ReadScan.vi返回+9.9E+37（溢出值）
原因：未为热电偶模块设置冷端补偿（CJC）参考温度。34902A 必须知道接线端子的物理温度才能换算热电势，若未配置，固件默认 CJC=0°C，当实际端子温度远高于此（如夏天实验室 30°C），计算结果必然溢出。
解决：在调用ReadScan前，先用VISA Write发送:UNIT:TEMP C（设温度单位为摄氏度）和:SENSe:TEMPerature:TCouple:CJunction:RANGe:AUTO ON（启用自动 CJC 范围），或手动设置:SENSe:TEMPerature:TCouple:CJunction:RANGe 30（设 CJC=30°C）。
5. 进阶技巧：构建可验证的自动化校准流程——用驱动程序实现“闭环自检”
真正体现这套驱动价值的，不是单次读数，而是构建一个能自我验证、自动报警的长期运行系统。下面以某公司温箱校准项目为例，展示如何用这套驱动实现“无人值守 + 故障自诊断”的闭环流程。整个方案不依赖外部数据库或云服务，全部在 LabVIEW 内存中完成。
5.1 校准点序列的动态生成与执行
校准不是固定测几个点，而是按预设温度梯度（如 25°C→50°C→75°C→50°C→25°C）循环升降温，每个温度点稳定后读取 10 次数据。驱动本身不提供“温度控制”，但它的ReadScanVI 输出的时间戳数组（Timestamps Array）是关键——你可以计算相邻读数的时间差，若某次差值 > 2000 ms，说明设备响应延迟，触发告警。
# 伪代码逻辑（在 While 循环内）： # 1. 设置温箱目标温度（通过另一套 PID 控制 VI） # 2. 等待温箱反馈温度进入 ±0.5°C 稳态窗口（持续 60 秒） # 3. 调用 Agilent34970A_ReadScan.vi，Scan List="@201,@202"（201=标准铂电阻，202=被校传感器） # 4. 计算 Timestamps Array 相邻差值：DeltaT[i] = Timestamps[i] - Timestamps[i-1] # 5. 若任意 DeltaT[i] > 2000000000（2秒），则记录 "Device Latency Alert" 并暂停流程5.2 数据一致性校验：用驱动的“原始性”反向验证设备健康
由于驱动直接操作 SCPI，我们可以利用其“不加修饰”的特性做深度校验。例如，对同一通道连续读两次，理论上应高度接近。但若两次读数差值 > 0.1°C（对热电偶模块），则可能是接触不良或模块老化。
# 具体实现（在 ReadScan 后）： # readings = [25.123, 25.124] # 两次读数 # diff = abs(readings[0] - readings[1]) # if diff > 0.1 then # Log_Error("Channel 201 instability detected: diff=" + FormatToString(diff, "%.3f")) # // 触发继电器自检：先 Open 再 Close 通道 201，观察设备面板 LED 是否同步闪烁 # Call Agilent34970A_OpenChannel("201") # Wait(100) # Call Agilent34970A_CloseChannel("201") # end if5.3 故障日志的结构化存储：用驱动输出的原始字符串还原现场
当发生严重错误（如 VISA 超时、SCPI 语法错误），驱动的Error Out会包含详细信息，但更关键的是捕获设备返回的原始响应字符串。我们在每个核心 VI 后增加一个VISA Read Raw节点（不带终止符），将原始字节流存入日志文件。这样，当客户报告“某天下午 3 点读数异常”，我们能直接打开日志，看到那一时刻设备返回的是"9.91E+37"还是"+0.000000E+00"，从而区分是传感器失效还是 CJC 配置错误。
| 日志字段 | 示例值 | 诊断价值 |
|---|---|---|
Timestamp | 2023-10-05 15:02:33.456 | 定位故障发生时间点 |
Command Sent | :READ? | 确认发出的指令无误 |
Raw Response | "+9.91E+37\r\n" | 直接判断是溢出（9.91E+37）还是无效值（+0.000000E+00） |
VISA Error | -1073807339 | 区分是通信超时还是协议错误 |
从那以后我每次部署新产线，都会在 LabVIEW 项目中新建一个Calibration_Log文件夹，里面放一个LogWriter.vi，它监听所有驱动 VI 的Error Out和Raw Response输出，并按上述表格格式写入 CSV。这套日志机制帮我们快速定位了三次重大客诉——其中两次是客户自己拔掉了 34902A 模块的 CJC 温度探头，一次是温箱厂商固件升级后改变了温度反馈协议。希望帮到你。
本文还有配套的精品资源，点击获取
