LabVIEW虚拟仪器14个实验：从数据采集到TCP/UDP通信

简介：《虚拟仪器技术》实验报告面向测控技术与仪器及相关专业本科生，也适合初学LabVIEW、希望补齐数据采集与仪器控制实践的人群。内容围绕14个实验展开，从温度计系列、面板与Tab控件、Event语句，到双通道信号显示、函数波形发生器、信号处理与帕斯瓦尔定理验证，再延伸至计数器测脉冲、串行通信、TCP/UDP波形传输及DataSocket技术，并结合PCI-6024E采集板与Demobox说明硬件配置和实验原理。报告源自上海理工大学光电信息与计算机工程学院2022级课程实践，附录还介绍多功能信号装置Demo Box的功能与用法。压缩包仅含1个PDF，约4.22MB，按实验组织要求、目的、步骤、参考面板与记录，便于按目录复现和对照调试；已有96人学习。读者可借此熟悉LabVIEW前后面板开发、子VI调用、条件循环及通信协议实现，也能获得滤波器、波形生成、温度测量等典型任务的完整实验思路与排错参照。

1. 一块采集卡撑起 14 个实验：这套虚拟仪器实验方案解决的是什么问题

虚拟仪器这门课最容易出现的尴尬是：LabVIEW 装好了，DAQ 采集卡也插上了，可到了要交实验报告那一周，前面板长什么样、框图怎么连线、华氏度和摄氏度哪个开关在上，全得凭记忆重来一遍。这份《虚拟仪器技术》实验报告从最基础的温度计控件一路排到 TCP、UDP 与 DataSocket 传输，14 个实验各自留下实验要求、目的、步骤、前面板和程序框图的完整记录，硬件侧配一块 PCI-6024E 多功能数据采集卡和一台信号演示盒。它服务的人群很明确：正在做测控类课程设计、毕业设计开题，或者第一次把图形化编程接进真实采集链路的本科生；也适合需要把这套实验重新排一遍课的授课者。照着跑一遍，控件、结构、硬件、通信四段能力会串成一条线，而不是十四个彼此孤立的截图。

2. 实验体系拆解：14 个实验如何排成一条从控件到通信的能力曲线

2.1 三层能力阶梯：控件层、结构层、通信层

把这 14 个实验按难度硬排成一条直线是行不通的，因为温度计和 DataSocket 之间隔着的不是代码量，而是三种完全不同的思维方式。我的分法是把它们切成三层：控件层解决“东西怎么摆、属性怎么改”，结构层解决“程序在什么条件下重复、在什么时机响应”，通信层解决“数据怎么从一块板卡走到另一台机器”。

控件层包含温度计系列三个实验、面板控制的密码对话框、鼠标属性、Tab 控件。这一层的共同特征是：几乎所有工作量都花在前面板的控件选型、属性节点配置和调色板上，框图里只有几条线。很多人第一次做会轻视它，觉得拖几个控件就完事，结果卡在“为什么这个开关按下去弹不回来”“为什么属性节点写进去没反应”上，一卡就是一下午。

结构层包含 Event 语句、帕斯瓦尔定理、双通道信号显示、函数波形发生器。这一层开始出现 While 循环、条件结构、移位寄存器和波形数据类型，实验的产出也从“界面能动”变成“数据能对”。帕斯瓦尔定理是最典型的例子：它要求你同时拿出时域波形和频谱，还得让两边的能量对得上，任何一个环节的采样参数写错，结论就立不住。

通信层包含信号处理、计数器数脉冲上升沿、串行通信、TCP 波形传输、UDP 信号传输、DataSocket。这一层直接接硬件和网络，出错的表现形式从“界面不动”变成“数据不动”“数据乱跳”“连接超时”，排查难度陡增。

这张表放在报告最前面，比放在最后当目录有用得多。它给出的信息是“你现在在第几层、下一层要补什么”，而不是“一共有多少个实验”。

2.2 软硬件环境清单与接线顺序

环境这一块，课程机房和个人笔记本的差异比想象中大。机房里 LabVIEW 版本通常是 2015 到 2020 之间的某一版，装的是随板卡配套的 DAQmx 驱动；个人机器上装的可能是最新版，驱动版本对不上，DAQmx 相关的 Express VI 就会显示成问号。我一般建议按实验室装机版本走，不为了一两个新特性去折腾驱动。

硬件清单按“必须有”和“有了更顺”分开列，避免一开始就被采购清单劝退。

接线顺序有一条血泪经验：先把板卡在 MAX（Measurement & Automation Explorer）里认出来，再做自检，再去接端子板，最后才打开 LabVIEW 建 VI。反过来做，LabVIEW 里一个“设备未找到”的报错能耗掉半天，而真正的问题可能只是驱动没装完。

自检这一步具体看三个地方：设备树里能不能看到板卡型号、自检（Self-Test）是否通过、测试面板里给一个直流通道输入已知电压能不能读到相近的值。第三项最关键，读到 0 或者读到满量程，基本就是通道配置或接线的问题，跟程序无关。

2.3 每个实验的交付物模板

十四个实验如果每个都按不同格式写，最后装订出来会像拼凑的。比较稳妥的做法是固定成四段式：实验要求与目的原文照抄（这部分老师最看重，别改写）、关键步骤与参数、前面板与框图截图、试验记录与三行结论。

试验记录这一栏最容易写空。合格的记录至少要有可核对的数据，比如温度控制实验里记下报警触发时的阈值设定值和实际读数、串口实验里记下波特率和实际收发的字节数、TCP 实验里记下传输点数与耗时。三行结论不要写“我学会了使用 While 循环”这种话，改成“While 循环加 50 ms 延时后 CPU 占用从满核降到 10% 以内”这种带观测结果的句子，答辩时经得起追问。

截图也有讲究。前面板截图要能看清控件标签，框图截图要能看清连线走向，必要时用整理程序框图（Clean Up Diagram）先把线捋直。一张糊成一片的框图，评阅人第一反应就是“这是抄的”。

3. 前四个实验的落地实现：控件、属性节点与事件结构怎么连

3.1 温度计系列：随机数模拟输入与子VI封装

温度计系列是整个报告的地基。第一个实验看上去简单——放一个温度计指示件、一个竖直开关，把开关状态接到选择结构上决定显示摄氏还是华氏——但它同时训练了三件事：控件选型、单位换算、子VI封装。

输入源在机房里通常用 Demo Read Voltage 这个教学用 VI 给，自己练的时候用随机数乘 100 更省事，含义是 0 到 100 摄氏度的模拟温度。换算关系只有两条：摄氏到华氏是乘 1.8 加 32，华氏到摄氏是减 32 再除以 1.8。框图里的节点顺序是随机数、乘法、选择结构，两个分支各放一套运算，输出接同一个温度计指示件。

# 对应框图：Random Number × 100 -> Select -> 温度计指示件 raw = 36.5 # 随机数 × 100，代表 0~100 摄氏度 unit_is_fahrenheit = True # 前面板竖直开关：True 显示华氏，False 显示摄氏 if unit_is_fahrenheit: display = raw * 1.8 + 32 # 摄氏转华氏 else: display = raw # 直接显示摄氏 print(round(display, 1)) # 36.5 -> 97.7

这段逻辑搬进 LabVIEW 就是三个节点加一个选择结构。参数上要注意两点：随机数乘的系数决定量程，改成 1000 就是模拟 0 到 1000 度，温度计的刻度范围要同步改，否则指针一直顶在满量程；选择结构的布尔接线端要接开关的“值”而不是“值变化”，接错了会出现松手就跳回去的现象。

真正拉开差距的是封装那一步。图标编辑这一步很多人敷衍，随手写个字母了事，后面实验二调用它的时候，框图上出现三个一模一样的字母图标，自己都分不清哪个是温度计。我的习惯是图标里画一个温度计轮廓加单位字母，接线端口按 LabVIEW 的固定惯例分配：左边放输入（单位选择开关），右边放输出（温度值）。接反了不会报错，但调用时线连不上，新手会以为是自己连线技术不行。

接线端口分配的具体做法是右键右上角图标框，选 Show Connector，LabVIEW 会按控件数量自动选一种模式。两个端口就用最简单的左右两格，先点左边格再点开关控件，格子里变黑说明绑定成功；再点右边格再点温度计指示件。绑定完成后点空白处，格子变暗，表示已经定死。

保存这一步建议直接存进课程指定的 LLB 程序库，文件名就叫 Thermometer.vi。后面实验二要用 Select a VI 的方式把它当子VI调出来，路径换个地方就找不到，这是最冤的一种翻车。

3.2 温度分析与温度控制：While 循环里的最大最小平均值与报警

第二个实验开始出现循环。要求是用 While 循环持续采集，用两个波形图表分别显示原始温度和分析后的温度，同时算出最大值、最小值、平均值，显示在三个字符串指示件上。第三个实验再加一层：温度超过设定值时触发报警。

框图结构可以拆成三段。采集段放在循环里，每次迭代取一个温度值送进图表；统计段把最近一批数据组成数组，接 Array Max & Min 和 Mean 两个节点；报警段用一个比较节点把当前值和阈值比，输出布尔量去驱动声音输出和指示灯。

import numpy as np threshold = 60.0 # 报警阈值，摄氏度 buffer = [] # 对应框图里的移位寄存器或数组缓存 for t in [55.2, 58.9, 61.4, 63.0, 59.1]: buffer.append(t) if t > threshold: # 比较节点 -> 声音输出 + 报警灯 print(f"ALARM at {t}") print(f"max={max(buffer):.1f} min={min(buffer):.1f} mean={np.mean(buffer):.1f}")

参数上有两个坑。一个是循环延时，While 循环不加 Wait（ms）节点会以 CPU 全速空转，风扇声比报警声还响，延时给 50 到 100 ms 比较合适，既不影响观察也不占满核。另一个是图表和图形的区别：波形图表（Chart）是逐点追加、有历史缓冲；波形图（Graph）是一次性接收整个数组、每次刷新重画。温度分析要“实时滚动”的观感就用图表，实验七的双通道对比用图形更合适。

那个状态转换开关负责在“显示原始温度”和“显示分析结果”之间切换，本质是选择结构接一个布尔量。步骤里有一条容易被忽略的细节：把开关设为 ON 之后，要在弹出菜单里选 Data Operations → Make Current Value Default，把 ON 设成缺省状态。不做这一步，每次打开 VI 都是 OFF，演示时第一眼看到的是空图表，评阅人很容易记成“程序没跑起来”。

报警阈值的设定我一般做成前面板可调的数值控件，而不是写死在框图里。写死之后答辩现场想改个数就得关掉重连，改一次错一次。做成控件，评委临时说“把阈值调到 50 看看”，你当场就能演示，这比任何解释都管用。

3.3 面板控制：密码对话框子VI 与 Case/While 组合

面板控制实验的产出是两个东西：一个密码输入对话框子VI，一个调用它的主程序。对话框本身很简单——一个字符串控件、两个布尔按钮、一次比较——难的是窗口属性和按钮机械属性这两块，因为它们决定了“像不像一个真正的对话框”。

字符串控件要设成密码显示，输入时回显星号。这个设置在控件的属性对话框里，把显示模式改成 Password。布尔按钮的机械属性要选 Latch When Released 一类，按下去自动弹回，否则用户点完“确定”，按钮会一直保持按下状态，第二次点就没反应。三种常见机械属性的差别值得记一下：

子VI 的窗口属性在 VI Properties 里配：窗口类型选 Dialog，勾上运行时居中，去掉标题栏的关闭按钮或者至少在关闭时做一次确认。主程序调用它的时候，把密码比较的结果作为布尔输出接出来，正确就走 Case 结构的“真”分支，发出一定频率的声音并点亮指示灯，错误分支什么都不做。主面板上还要放日期和时间显示，用时间函数节点输出格式化字符串，格式串写%Y-%m-%d %H:%M:%S这类即可。

这里有处玄学：声音节点在某些机器上不出声。原因往往不是程序错，而是系统采样率或输出设备被占用。排查顺序是先单独建一个 VI 只放 Beep 节点测，出声了再回到主程序查分支连接，别一上来就怀疑 Case 结构。

3.4 鼠标属性、Tab 控件与 Event 结构：属性节点、簇与表格更新

这三个实验放在一起讲，因为它们的共同点是把“界面”当成可编程对象。鼠标属性实验要求鼠标移到窗口上方时颜色改变，点击时弹出消息框；Tab 控件实验要求对 Tab 的尺寸、颜色、明暗和使能状态做设置；Event 语句实验要求用事件结构响应 Table 控件的数据更新并调用子VI。

鼠标位置的读取靠属性节点：在前面板控件上右键建 Property Node，选 Mouse → Mouse Position，拿到一个簇，再用 Unbundle 拆出 X、Y 两个数值，接比较节点判断是否落在窗口区域内。颜色改变靠 Color 属性写入 RGB 值。这些操作在框图里就是一根线接一个属性节点，难点在于属性节点只能挂在具体控件上，挂在错误控件上不报错但没效果。我一般把三个属性节点并排放，按“位置判断 → 颜色写入 → 弹窗”的顺序排列，排错了顺序会出现弹窗盖住颜色变化的观感问题。

Tab 控件的关键是页的选择。程序里不能直接对某一页操作，要先写 Tab 的 Value 属性切到目标页，再对页内的控件操作。属性节点里对应的是“页”这一项，值从 0 开始按顺序编号。很多人在这一步翻车，是因为没有先在前面板把四个 Digital Control 放进 Tab 的页面里，而是放在了 Tab 外面，视觉上看着像在里面，实际不属于任何一页，切页时控件不跟着动，很容易被误判成属性节点写错了。

Event 结构实验的任务是做一个 showgraph.vi 显示多道数据，再用主程序的事件结构完成对它的调用和 Table 数据更新。事件结构的分支配置有两种写法：一种是按控件值变化（Value Change）触发，另一种是加超时分支（Timeout）兜底做周期刷新，超时时间给 100 ms 左右。只配值变化不配超时，程序在没有用户操作时完全不响应，界面会像卡死一样。

# 对应 Event 结构的分支划分：Value Change 分支 + Timeout 分支 events = {"table_update": False, "timeout_ms": 100} def on_timeout(): return "刷新显示、检查子VI是否有新数据" def on_value_change(ctrl): if ctrl == "run_button": return "调用 showgraph.vi" if ctrl == "table_ctrl": return "写回 Table 的单元格数据" return "未配置的控件 -> 保持默认分支"

这份骨架的意思很直白：事件结构只处理“发生了什么”，不负责“一直做什么”，周期性的事情要交给超时分支。Table 控件的数据写入用属性节点里的“单元格值”，行列索引从 0 开始，写越界会静默失败，这个坑在实验五的记录里几乎人人踩过一次。

4. 后八个实验的落地实现：信号处理与三条通信链路

4.1 帕斯瓦尔定理验证：时域能量与频域能量的对账

帕斯瓦尔定理这个实验的意义在于它是整份报告里唯一一个“结果可以被数学严格判定对错”的实验。要求也不算复杂：采一段信号，做 FFT，把时域能量和频域能量各算一遍，看两者是否相等。

做法是先由函数波形发生器或信号演示盒给一个单频正弦，采样率设 1000 Hz，采样点数取 1024，频率 50 Hz，幅值 1 V。时域能量是各点平方和，频域能量是各频点幅值平方和除以点数 N。两个数理论上相等，实际因为泄漏和窗函数会有偏差，正常情况下相对误差能压到百分之一以内。

import numpy as np fs, n = 1000.0, 1024 # 采样率 1 kHz，1024 点 t = np.arange(n) / fs x = np.sin(2 * np.pi * 50 * t) # 50 Hz 单频，幅值 1 V X = np.fft.fft(x) e_time = np.sum(x ** 2) # 时域能量 e_freq = np.sum(np.abs(X) ** 2) / n # 频域能量，注意除以 N print(e_time, e_freq, abs(e_time - e_freq) / e_time) # 误差应在 1% 内

三个参数改一个就会翻车：点数不是 2 的整数次幂，FFT 会走慢速路径且泄漏变大；采样率与信号频率不成整数倍关系，频谱上会出现明显的旁瓣；忘了除以 N，两边能差出三个数量级，这时候先别怀疑定理，先检查归一化。

在 LabVIEW 里对应的是 FFT Power Spectrum 节点加两个数组运算。实验记录里建议放一张对照表：设定频率、理论能量、实测时域能量、实测频域能量、相对误差，五行数据一看就知道是程序不对还是信号源不稳。

4.2 双通道显示与函数波形发生器：采样率、缓冲与图表刷新

双通道显示实验要在一张图上同时看到两路信号，函数波形发生器实验要能产生正弦、方波、三角、锯齿四类波形并调幅值、频率、相位。这两个实验的公共难点是采样参数，而采样参数里最容易被忽略的是“每通道采样数”。

DAQmx 读取节点上有两个关键设置：采样模式和每通道采样数。有限点采样（Finite）是读满设定点数就停，适合一次性分析；连续采样（Continuous）是一直读，适合做实时显示。每通道采样数给小了波形毛刺明显，给大了界面刷新变卡，1000 点是个比较稳的起点。通道接成差分还是单端也要统一，两路信号一个差分一个单端，波形上会出现明显的共模干扰差异。

函数波形发生器这边，频率和采样率的关系要满足工程惯例上的 2.56 倍：想输出 200 Hz 的波形，采样率至少要 512 Hz 以上，实际一般取 5 到 10 倍留余量。幅值、偏置、相位三个参数通过簇打包送给波形生成节点，改参数时用属性节点比重新连线省事。

import numpy as np fs = 5000.0 # 采样率，取信号最高频率的 25 倍 n = 2000 # 每通道采样数 t = np.arange(n) / fs sine = 1.0 * np.sin(2 * np.pi * 200 * t) # 幅值 1 V，200 Hz square = 1.0 * np.sign(np.sin(2 * np.pi * 200 * t)) # 方波，注意吉布斯现象 print(sine[:3], square[:3])

方波用 sign 函数生成会在跳变沿出现振铃，这是采样离散化的正常现象，不是程序错。记录里把它写清楚，比硬说是“噪声干扰”可信得多。双通道显示时图例和曲线颜色要手动区分，两路都用默认色，截图打印出来是一片黑，答辩时讲不清哪条是哪条。

4.3 计数器与串行通信：上升沿计数与 VISA 参数

计数器实验用板卡上的 CTR0 数脉冲上升沿个数，信号源用演示盒的方波输出。配置路径是 DAQmx 创建通道选 Counter Input → Count Edges，边沿类型选 Rising，计数方向选 Count Up，采样模式用有限点，读一次拿总数。这里最容易翻车的是信号质量：方波幅度不够或者边沿太缓，计数器会多数或者少数。缓解办法是先把信号接到示波器上看边沿，实在不行降低信号频率再数。

串行通信实验用 VISA 系列节点，配置参数固定成一张表贴在报告里，比文字描述清楚得多。

回环测试是排查串口问题的第一手段：把 TX 和 RX 短接，发什么应该收到什么。收不到，问题在配置或线序；收得到但乱码，问题在波特率；收得到但少字节，问题在终止符或读超时。这个顺序能省掉大量猜测，我一般把它写进实验记录的“调试过程”一栏，比只贴一张成功截图有说服力。

4.4 TCP、UDP 与 DataSocket：三条链路的选型与配置

这三个实验是整份报告里最像“真实项目”的部分。TCP 实验做波形传输，服务端监听、客户端连接、双方按字节流收发；UDP 实验做信号传输，不建连接直接发；DataSocket 实验用统一资源定位的方式发布和订阅数据。三者的差别不在语法，而在适用场景。

TCP 的具体做法：服务端用 TCP Listen 指定端口（示例里用 6340，实际取 1024 以上任意空闲端口），客户端用 TCP Open Connection 连 IP 加端口，双方用 TCP Read 和 TCP Write 收发。波形数据要先转成字符串或字节数组，直接发波形数据类型会因为字节序问题变成乱码。读超时建议设 5000 ms，太小会在网络抖动时误报超时，太大出问题时又等得人心慌。

UDP 用 UDP Open、UDP Write、UDP Read、UDP Close 四个节点，两端端口要对上，本机测试用 127.0.0.1 就行。UDP 没有重传，发送频率过高时接收端会丢包，这不是程序 bug，选型时就该知道。实验记录里如实写“发送 1000 包，接收 987 包”，比伪造一个 100% 的接收率更有价值。

DataSocket 的地址格式是dstp://localhost/waveform这类，服务端用 DataSocket Write 往这个地址写，客户端用 DataSocket Read 订阅。它的好处是不用管 TCP 细节，前面板上的波形控件可以直接绑定地址做远程显示，做演示效果最好。缺点是出了问题时排查层次更少，除了地址拼错几乎没别的可能性，反而不适合用来训练调试能力。

5. 避坑清单：LabVIEW 实验里最容易翻车的五件事

5.1 前面板与框图类的坑

第一个坑：程序点运行没反应，前面板一动不动。现象是运行按钮变黑但界面无变化，也不报错。原因多半是 While 循环里没放延时，或者循环条件接线端接了一个恒为真的常量，程序在后台空转，界面刷新被饿死。解决是把 Wait（ms）节点加进循环，延时给 50 ms 左右，顺手检查循环条件是不是接到了停止按钮的值上而不是“值变化”上。

第二个坑：子VI调用后输出恒为零。现象是主程序跑起来没报错，但调用温度计子VI传来的数据一直是 0。原因通常是接线端口没绑定或者绑反了，输入端接了指示件、输出端接了控制件，LabVIEW 不会拦你。解决是打开子VI，右键图标框重新走一遍 Show Connector，按“左输入右输出”逐个点选绑定，绑完点空白处确认变暗。

第三个坑：事件结构里改了控件值，界面不更新。现象是事件分支执行了，数据也写进去了，但前面板显示的还是旧值。原因是事件结构在执行分支时会锁住前面板，直到分支结束才刷新，如果分支里还有循环或者等待，界面就卡住。解决是把耗时操作挪出事件分支，用队列或者局部变量把数据传出去，事件分支只做“接收动作”，不在里面干活。

5.2 硬件与通信类的坑

第四个坑：DAQ 采集到的数据全是噪声或者一直是零。现象是程序结构看着没问题，波形图上是满屏毛刺或者一条平线。原因分两类：接线侧是通道配置与端子板实际接线不一致，差分通道接成了单端；配置侧是采样率设置过高、每通道采样数过小，或者输入量程设成了 ±10 V 而信号只有几十毫伏。解决的顺序是先断开程序，用 MAX 的测试面板读一次已知电压，读得准说明硬件没问题，问题在 VI；读不准就先查线，再查量程。

第五个坑：网络通信两端连不上。现象是客户端一直卡在 Open Connection 或者报错误 63。原因通常是端口被占用、防火墙拦截、两端 IP 不在同一网段这三类之一。解决顺序是先用 127.0.0.1 在本机跑通，本机能通再换真实 IP；本机不通就先看端口有没有被别的进程占着，再检查服务端是不是在 Listen 之前就被停止按钮打断了。

这五条覆盖了十四个实验里绝大多数“卡住超过半小时”的情况。它们有个共同特征：报错信息几乎帮不上忙，只能靠现象反推。所以我在报告里专门留了一页“故障速查”，答辩时翻到这一页，评阅人问“你遇到过什么问题”，答案现成。

6. 验收与答辩：怎么让一份实验记录自己会说话

实验报告交上去之后，真正决定分数的是评阅人翻看那三分钟里能不能确认“这个人自己动过手”。三个动作最有效：每章开头放一句“这个实验解决了什么具体问题”、关键参数写在正文里而不是藏在截图里、失败记录和修复过程与成功结果并排放。

验收自查可以按下面这张表走一遍，任何一项填不出来，就说明那个实验还停留在“跑过”而不是“掌握”。

答辩环节的提问往往集中在两个方向：参数为什么这么设、出问题怎么定位。第一个问题提前准备一句话答案，比如“采样率取信号频率的 25 倍，是为了让方波边沿有足够采样点，同时不超过板卡上限”；第二个问题就把故障速查表翻出来讲，讲一次自己踩过的坑，比讲十次顺利的流程可信。

还有一个容易被低估的细节：报告里的每一张截图都要能被单独看懂。评阅人不会按顺序读，翻到哪页算哪页。前面板截图旁边标一句“开关置 ON 时显示华氏度”，框图截图旁边标一句“左侧为输入端口，右侧为输出端口”，这类一句话说明能省掉大量误解。

我自己的教训是第一次交这份报告时，十四个实验的框图全是默认配色、线全部交叉，评阅人翻了两页就问了句“这些图是同一个程序吧”。后来我给自己定了个死规矩：每个实验交之前，先按整理程序框图把线捋直，再按功能把框图分段，最后把参数标注补全，全部走完才截图。从那以后每次实验报告的分数都稳定在同一档，也不再出现“程序对但分不高”的情况。希望这套结构和这份避坑清单，能帮你少走几趟我当年走过的弯路。

本文还有配套的精品资源，点击获取