简介：罗德与施瓦茨R&S®CMW100的WLAN发射测量指令手册，面向通信测试工程师、射频调试人员及实验室技术人员，系统讲解CMW100上各WLAN测量选件的功能、参数配置与操作流程。内容覆盖IEEE 802.11a/b/g、802.11n、802.11ac及802.11ax标准，并对选件KM650至KM657及多评价列表模式KM012逐一说明，涵盖SISO、复合MIMO、开关MIMO、真MIMO以及面向车联网V2X的802.11p测量，便于使用者根据测试对象匹配相应模式。资源包为单个PDF文件，大小约4.95MB，可直接下载后查阅或打印。目前已有1389人学习下载，多用于产线射频测试与实验室研发准备。除各选项操作步骤外，手册还包含功能特性、安全指南、故障排除、维护校准及数据表等内容，能够帮助读者理解仪器能力边界、规避误操作风险并提升WLAN发射测量效率，是一份值得常备的仪器参考手册。
1. CMW100-WLAN指令手册：产线WLAN射频测试怎么靠SCPI指令跑起来
做产线射频测试的工程师，手里大概率见过 CMW100 这台机器。罗德与施瓦茨的这台宽带无线电测试仪，在 WLAN 产测里是绝对主力，但真正让它高效跑起来的，不是前面板那几颗按键，而是一套能远程控制的指令系统。说是“CMW100-WLAN指令手册”，本质上就是一套 SCPI（可编程仪器标准指令）语法，配合 WLAN 测试的专用命令集，让你用网线或 GPIB 把仪器连到电脑上，用脚本完成频率设置、功率测量、调制质量分析、吞吐量测试等一系列动作。今天这篇就顺着这条线，把它讲透。
这篇文章主要为两类人写：一类是刚接手产线测试项目、对着 CMW100 前面板翻菜单翻到头晕的新手；另一类是已经在用 CMW100 但依赖厂商提供的 EXE 或 DLL 封装的熟手，想绕过黑匣子直接用指令层把测试节奏压到极限。无论哪类，读完你都能自己动手写第一版 WLAN 测试脚本，知道参数怎么设、结果怎么读、问题怎么排。
2. 从面板操作到指令控制：为什么产线测试必须走 SCPI
2.1 CMW100 的指令体系构成：SCPI 与 WLAN 专用命令
CMW100 的远程控制遵循 IEEE 488.2 标准，指令走 SCPI 语法。仪器内部维护一棵命令树，从根节点往下分：CONFigure、MEASure、READ、FETCh、CALCulate、SENSe这些是通用分支，而 WLAN 相关的测试模块挂在CONFigure:WLAN和SENSe:WLAN下面。这种设计让指令读起来像在拼路径——你把命令从根走到叶子，就是一次完整的设置。
仪器对每条指令的响应也固定：设置类指令（以:开头）执行成功会返回OK或者不返回，查询类指令（结尾带?）返回测量结果或当前参数值。产线脚本里最常见的错误就是把设置指令当查询用，或者查询指令漏了问号，导致仪器一直不回应。这属于所有 SCPI 设备共通的脾气，但 CMW100 的报错机制相对温和，出错时你可以在控制器里发SYSTem:ERRor?读回错误码和描述，排查起来不算难。
我一般建议新项目先用厂商自带的 CMWRun 或 R&S 的 VSE 软件跑通一遍手动测试，打开软件的指令日志窗口，看它背后发了哪些 SCPI 命令。这样做有两个好处：一是拿到仪器厂商自己在用的标准指令序列，照着改比从头猜指令快得多；二是能确认你的 CMW100 固件版本支持到哪个 WLAN 测试选项，不同选件对应的命令分支不完全一样。
2.2 连接方式与前置准备：IP、VISA、驱动三件事
CMW100 支持 LAN、GPIB 和 USB 三种远程接口，产线主流是 LAN。接上网线后，先在仪器前面板按SETUP键进入网络配置页，手动设一个固定 IP，比如192.168.1.10，子网掩码255.255.255.0——产线环境不建议用 DHCP，仪器重启后 IP 漂移会让脚本直接连不上。电脑那边用网线直连或经交换机都行，只要双方能 ping 通就算第一步完成。
第二步是装驱动。CMW100 在 Windows 下走 VISA 库，推荐装 R&S 自家的 VISA 或者 NI-VISA，两者都行。装好后在电脑上打开 NI MAX 或 R&S VisaTester，输入TCPIP0::192.168.1.10::inst0::INSTR这个地址，能打开会话就说明连接正常。注意inst0这个后缀不是随便写的，它对应 CMW100 的 VXI-11 服务，如果你改用 SCPI-Raw 方式连接，地址会变成TCPIP0::192.168.1.10::5025::SOCKET，端口号 5025 是 CMW100 的 SCPI 直连端口。
第三步是验证指令通路。打开你熟悉的编程环境，用pyvisa先发一条最基础指令：
import pyvisa rm = pyvisa.ResourceManager() inst = rm.open_resource('TCPIP0::192.168.1.10::inst0::INSTR') inst.timeout = 5000 # 毫秒，产线建议设 3000-5000，太短容易误报超时 print(inst.query('*IDN?'))*IDN?是 IEEE 488.2 标准里必须支持的识别指令，仪器会返回厂商、型号、序列号和固件版本。能读到这串信息，说明 VISA 库、IP 配置、仪器服务三个层面全部打通。这里有个判断经验：如果*IDN?都超时，问题八成在 IP 层；如果*IDN?正常但 WLAN 专用指令报错，问题在选件或模式设置。
2.3 三种控制方式选型：VISA 直写、CMWRun 脚本、DLL 封装
实际项目里控制 CMW100 有三条路：直接用 VISA 写 SCPI 指令、用 CMWRun 软件跑脚本、用厂商的 DLL 封装接口。
VISA 直写的好处是灵活和快。你能完全掌控时序——先切换频率、再启动测量、然后轮询状态、最后读结果，每一步之间隔多少毫秒都由你定。缺点是你要对指令和状态机足够熟，而且调试阶段比较痛苦，发错一条指令只能靠SYSTem:ERRor?一条条排查。
CMWRun 是 CMW100 配套的测试序列软件，它把常用功能做成了图形化配置，底层还是生成 SCPI 指令。适合验证测试方案的可行性：先把测量项、限值、信号参数在 CMWRun 里配好跑一遍，确认标准没问题，再转成 VISA 脚本。这个转换不是白做的，因为 CMWRun 生成的指令序列往往有大量冗余设置，直接搬进产线脚本会拖慢节拍。
DLL 封装是厂商提供给 C# 或 C++ 项目的接口库，比如RsCmWlan这类。它的好处是上手快，函数名直观，不用背 SCPI 语法；坏处是灵活性受限，有些底层时序控制暴露不出来，而且调试问题时你还是要去看它背后发的指令。我的建议是：脚本开发期用 VISA 直写加*IDN?和SYSTem:ERRor?做验证，稳定后可以不动；如果是给设备厂商做二次开发，DLL 封装更省事。长期维护的产线脚本，我倾向 VISA 直写，因为指令透明，以后换仪器型号或改测试项时改起来可控。
3. 用 SCPI 指令跑通 WLAN TX 测试：从信号配置到结果读取
3.1 测试模式切换：非信令模式的核心指令
WLAN 产测几乎都在非信令模式（DUT 不上网、不关联 AP）下完成，仪表充当信号源和分析仪，DUT 在电脑控制下直接发包。CMW100 上要做的第一件事，就是把 WLAN 测量模块激活并切到正确的信号分析路径。这组动作对应两条关键指令：
CONFigure:WLAN:MEAS<instance>:SIGNaling:OFF CONFigure:WLAN:MEAS<instance>:RESTartMEAS<instance>是测量实例名，CMW100 支持多个并行测量实例，通常从MEAS1开始。第一条指令关闭信令模式，进入非信令；第二条重启测量实例，让配置生效。如果你的固件版本较老，可能不认SIGNaling:OFF这条指令，那就直接用CONFigure:WLAN:MEAS1:STATe ON激活，再检查面板上是否显示非信令图标。
很多新手在这里翻车：发完配置指令就直接启动测量，结果测量一直停在“等待同步”状态。这是因为 CMW100 的 WLAN 测量链路需要先切换到正确的信号源路径——当 DUT 是源时，仪表要配置成分析仪；当仪表当信号源给 DUT 灌包时，要配置成信号发生器。这两种角色对应不同的子系统，不是一条指令能同时完成的。判断角色配置是否正确的办法，是查CONFigure:WLAN:MEAS1:ROLE?，它会返回当前配置的角色，TX表示仪表在测 DUT 发射，RX表示仪表给 DUT 灌信号测接收。
3.2 频率和带宽设置：决定测试是否踩在信道上
WLAN 测试的第一组参数是信道频率和带宽。2.4GHz 频段常见的是 2412MHz 到 2484MHz，5GHz 频段按信道号对应不同中心频率。CMW100 里设置方式是这样的：
CONFigure:WLAN:MEAS1:RADIo:STANdard:CHANnel:FRANge:CHANnel 1 CONFigure:WLAN:MEAS1:RADIo:STANdard:BAND B5G CONFigure:WLAN:MEAS1:RADIo:STANdard:CHANnel:BW20这三条分别设置信道号、频段和带宽。注意CHANnel 1在不同频段下对应的频率不一样——在 2.4GHz 下是 2412MHz，在 5GHz 下可能对应 5180MHz。所以设置频段必须在设置信道之前，顺序反了容易踩到不存在的信道组合，仪表会报错。另一个容易忽视的点是带宽和信道的约束关系：80MHz 带宽下有些信道索引不能用，你设置完最好回查一下：
CONFigure:WLAN:MEAS1:RADIo:STANdard:CHANnel:FRANge:FREQuency?这个查询会返回当前实际生效的中心频率。如果返回 0 或报错，说明你刚才的组合非法。产线项目里通常把信道表写死在工位配置文件里，而不是每次算频率，因为不同国家版本的 DUT 支持的信道表不一样，比如日本地区多了 channel 14，美国多了部分 5G 信道。调试阶段养成“设完就查”的习惯，能省掉大半的测量不启动问题。
3.3 测量项配置：发射功率、EVM、频谱模板的指令写法
WLAN TX 测试的核心测量项有三个：发射功率、EVM（误差矢量幅度）、频谱模板（SEM）。CMW100 里这些测量项不是独立指令，而是挂在同一个测量实例下的“统计”和“结果”分支。配置方式如下：
CONFigure:WLAN:MEAS1:TX:STATistic:ALL ON CONFigure:WLAN:MEAS1:TX:STATistic:AVERage:COUNt 20 CONFigure:WLAN:MEAS1:TX:RESult:POWer ON CONFigure:WLAN:MEAS1:TX:RESult:EVM ON CONFigure:WLAN:MEAS1:TX:RESult:SEMask ON第一行把该 TX 实例的所有统计项打开，第二行设置统计平均次数为 20。平均次数这个参数要重点说：产线节拍要求测试快，平均次数设 10 就够；研发调试阶段想拿到稳定的 EVM 数值，设到 50 甚至 100 更合理。平均次数直接影响测试时长——每次平均对应一帧或一段测量周期，20 次平均比 10 次平均的时间不是两倍，因为还要算上仪器内部的状态切换开销。
RESult分支下的三个开关决定哪些结果会被计算和存储。这里有个性能层面的经验：不要把所有结果项全打开。比如你的产测项目只关心功率和 EVM，那 SEMask 就别开，因为频谱模板计算涉及大量 FFT 运算，会显著拉长单次测量时间。CMW100 的并行测量能力再强，也不能让计算资源被用不到的测量项白占着。
3.4 触发与同步：为什么你的测量一直卡在“等待信号”
WLAN 信号是突发式的，DUT 不是持续发射，仪表必须在正确的时刻抓取信号。CMW100 的触发机制在 WLAN 测试里是翻车重灾区。触发源一般有两种配置：一种是仪表自己检测到 RF 功率就触发（IF Power），另一种是外部硬件触发（EXT），后者在产线里配合夹具上的传感信号更常见。
TRIGger:WLAN:MEAS1:SEQuence:SOURce IFPower TRIGger:WLAN:MEAS1:SEQuence:LEVel -20dBm第一行设置触发源为 IF 功率触发，第二行触发电平设为 -20dBm。这个触发电平怎么定？测灵敏度（低功率场景）时，触发电平要比被测信号低 5-10dB，否则信号太弱触发不了；测高功率发射时，电平设太高会被底噪误触发，设太低会漏掉信号前端。一般 DUT 发射功率在 10dBm 附近时，触发电平设在 -20dBm 到 -30dBm 之间比较安全。还有一个参数值得注意：触发电平单位是 dBm，指的是仪表输入端口的绝对功率，不是相对 DUT 发射功率的偏移量，很多人在 DUT 加外部衰减器后忘记把这个值按衰减量修正，导致触发失效。
触发配置完成后，启动测量的指令是INITiate:WLAN:MEAS1，然后轮询STATus:OPERation:WLAN:MEAS1:CONDition?，返回的 bit 值表示测量是否完成。轮询间隔建议 100ms，不要写死 sleep，因为不同频段和带宽下测量时长差异很大。
4. WLAN RX 测试与灵敏度测量：灌包指令和结果判定
4.1 仪表作为信号源：DUT 接收测试的指令路径
TX 测试测的是 DUT 发射能力，RX 测试反过来——仪表发射已知信号，DUT 接收并解调，通过比较发送和接收的数据判断链路质量。CMW100 的 WLAN RX 测量实例需要切换到信号源角色，配置方法和 TX 侧是对称的：
CONFigure:WLAN:MEAS1:ROLE RX CONFigure:WLAN:MEAS1:RADIo:STANdard:CHANnel 6 CONFigure:WLAN:MEAS1:RADIo:STANdard:BW20 CONFigure:WLAN:MEAS1:RX:STATistic:ALL ON角色切换指令放第一行，因为后续所有配置都依赖角色定位。信道和带宽的设置沿用 TX 侧指令——同一个测量实例里切角色不会重置射频参数，所以先配信道再切角色也行，但顺序固定下来更好排查。RX:STATistic:ALL ON把接收统计全打开，包括误包率（PER）、吞吐量、RSSI 等结果项。
RX 测试有个特殊的“节点”概念：CMW100 在 RX 模式下会模拟一个 AP（接入点），DUT 作为 STA 接收。DUT 侧需要配置成接收模式并持续监听信道。产线常用的做法是：电脑先通过 AT 指令或厂商私有命令把 DUT 切到 RX 模式，再启动仪表发射。这里要处理好两条链路——控制链路（电脑到 DUT）和测试链路（仪表到 DUT），两条链路不能共用天线，否则信号自激会把测量结果带到沟里。
4.2 灌包参数设置：帧格式、数据速率、包长
RX 测试的准确性很大程度上取决于灌包参数。CMW100 里配置帧格式和数据速率的指令如下：
CONFigure:WLAN:MEAS1:RX:FRAMe:FORMat:STANdard IEEE80211ax CONFigure:WLAN:MEAS1:RX:FRAMe:FORMat:MODulation:ALL QAM256 CONFigure:WLAN:MEAS1:RX:FRAMe:LENGth 1500 CONFigure:WLAN:MEAS1:RX:FRAMe:PSDU:VALue 1500 CONFigure:WLAN:MEAS1:RX:FRAMe:RATE:LEVel MCS7第一行设置帧标准——802.11ax（WiFi 6）和 802.11ac（WiFi 5）的帧格式差异很大，混用会导致 PER 虚高。第二行调制方式，QAM256对应 802.11ac 的 VHT 模式，如果用 802.11ax 的 OFDMA 测试，调制配置可能不在这个分支下。第三、四行设置包长，单位是字节，典型值是 1500 字节（以太网 MTU），测最大吞吐量时用 1500，测弱信号健壮性时建议降到 500 以下，让误码集中在某些固定的数据段。
这里要特别强调 MCS（调制编码方案）索引的选择。MCS7 在高信噪比下能跑到很高的速率，但在灵敏度测试里，你必须逐步降低 MCS 等级或增加衰减，才能找到误包率从合格到不合格的边界。CMW100 里 MCS 索引和速率等级的对应关系因标准而异：802.11n 的 MCS0-MCS7 是 1 流，MCS8-MCS15 是 2 流，802.11ac 又引入了更多组合。设置错了 DUT 完全不认，就会出现“仪表一直发、DUT 一直丢、PER 卡在 100%”的假故障。
4.3 误包率（PER）的读取与判断标准
RX 测试的结果读取沿用的是 SCPI 查询套路：
FETCh:WLAN:MEAS1:RX:PER? FETCh:WLAN:MEAS1:RX:RSSI? FETCh:WLAN:MEAS1:RX:THRoughput?三条指令分别返回误包率、接收信号强度和吞吐量。PER 的返回值通常是一个百分比数值，比如1.250000E+00表示 1.25%。判断标准要看产品规格：一般消费级 WiFi 模块要求 PER 不高于 10%，车规级模块对灵敏度边界的要求会更严，有些定义在 PER=8% 甚至更低。RSSI 返回值是 dBm，幅度一般为负数，从 -30dBm（强信号）到 -90dBm（极弱信号）。
PER 测量有个统计量的问题：只发 100 包测出的 1% 误包率（1 个错包）和发 10000 包测出的 1% 误包率（100 个错包），置信度完全不同。产线为了节拍通常只发 100-500 包，研发阶段做灵敏度曲线必须发到 1000 包以上。CMW100 里可以设置单次发射的包数量：
CONFigure:WLAN:MEAS1:RX:FRAMe:COUNt 1000包数设 1000 后，单次测量时间会拉长，但 PER 的重复性会好很多。做产线直通率改善的人都有经验：PER 从 2% 波动到 8%，往往不是 DUT 的问题，而是包数太少导致统计噪声。把包数翻一倍，数据就稳了。
5. 避坑与排查：CMW100 WLAN 指令调试的 5 条血泪经验
5.1 超时误报：不是仪器没测完，是你轮询得太死板
现象：脚本里query一条结果指令，动不动就超时，但手动在仪器面板上操作是正常的。
原因：CMW100 在测量未完成时，对结果查询指令不会返回完整数据，而是等待测量结束才响应。你把 VISA 超时设成 3 秒，但一次 WLAN 测量平均 20 帧、每帧需要几毫秒到几十毫秒，加上统计计算时间，总耗时可能超过你的超时阈值。
解决：不要用query直接读结果，先用*OPC?或状态寄存器轮询测量完成，再读数据。我常用的写法是：
inst.write('INITiate:WLAN:MEAS1') while True: status = inst.query('STATus:OPERation:WLAN:MEAS1:CONDition?') if int(status) & (1 << 3): # bit3 表示测量完成 break time.sleep(0.1) result = inst.query('FETCh:WLAN:MEAS1:TX:POWer?')VISA 超时设 5000ms 以上只用于保险，不要把它当正常的测量等待机制用。还有一个隐藏坑：STATus:OPERation:CONDition?返回的是十进制数，你要先转成二进制再判断 bit 位，不要直接拿十进制和某个阈值比较，位数对不上会让你误判状态。
5.2 功率读数偏低但面板显示正常：衰减补偿没进指令
现象：脚本读回的 TX 功率比面板显示低 10-15dB，而且差值刚好等于外部衰减器的值。
原因：产线为了不烧仪表输入端，DUT 和 CMW100 之间通常串了固定衰减器或耦合器。衰减器把信号幅度压低了，仪表测到的是衰减后的功率，需要把衰减值补偿入读数。面板上有设置衰减补偿的入口，但远程指令必须显式发送，面板设置不会自动同步到 SCPI 会话。
解决：在配置阶段设置输入衰减补偿：
SENSe:WLAN:MEAS1:POWer:COMPensate:TX:LEVel:DB 10.0这条指令把功率测量结果整体补偿 10.0dB。数值取正号表示“实际信号比测量值大”，对应外部衰减器；如果你用了放大器（DUT 输出端接 PA），补偿值为负。注意补偿只影响功率相关读数（发射功率、RSSI），不影响 EVM——EVM 是相对值，不受线性衰减影响。如果项目里既有衰减器又有放大器，补偿值是两者之差，而不是各自代数相加。
5.3 EVM 异常偏大但功率正常：触发位置偏移了
现象：发射功率合格，但 EVM 数值不稳定，时好时坏，坏的时候明显偏大。
原因：功率触发是检测 RF 能量上升沿，但 WLAN 信号的前导（Preamble）和帧头信息在能量上升沿之后才出现。仪表从触发点开始抓取信号，如果触发点偏晚，会丢掉一部分前导，导致解调参考失真，EVM 计算不准确。
解决：确认触发电平不要高于信号峰值功率太多。触发电平在 -20dBm、信号峰值在 10dBm 时，触发点在信号边沿很靠前的位置，一般没问题。但如果你把触发电平调到 0dBm 附近，信号上升沿的缓慢段可能够不到触发限制，触发点就会滑到帧中段。另外，CMW100 有触发点偏移（TRIGger:SEQuence:HOLDoff）参数，误用时会让解调窗口整体偏移。我一般保持 HOLDoff 为默认值 0，除非做特定信号切片分析，否则不动它。
5.4 WLAN 指令在固件版本间不兼容：升级前先跑一遍回归
现象：同一套脚本在样机上跑得好好的，换成量产批次的仪器就报指令错误。
原因：CMW100 的固件版本更新会调整 WLAN 测量指令的命令树。常见的是老指令被标记为 deprecated（弃用），或者指令参数的可选值发生了变化。比如有些老固件里CONFigure:WLAN:MEAS1:TX:STATistic:AVERage:COUNt最大值允许 1000，新固件限制到 100，超限就报错。
解决：升级固件前用仪器的“指令兼容性测试”功能跑一遍现有脚本，或者至少把每一个用到的指令发一遍?查询确认参数范围。项目中途不建议频繁升级固件。如果你必须在多台不同固件版本的仪器上运行同一套脚本，在脚本开头加一个版本检测：
SYSTem:VERSion?返回结果里包含固件版本，你根据版本走不同的指令分支。这件事看着小，但在一线吃过亏的人都知道：产线 20 台仪器固件版本不统一，是测试数据对不齐的主要原因之一。
5.5 并行测量实例的资源冲突：开了两个测量实例反而更慢
现象：想用 CMW100 的并行测量能力同时测 2.4G 和 5G 两个信号，结果每个测量实例的耗时都翻倍了，总节拍没变快。
原因：CMW100 的硬件资源不是无限的。多个测量实例共享射频前端和 DSP 资源，当信号带宽加起来超过一定阈值，仪器内部就开始串行处理。你把仪器当成万能并行机用，实际上它只是在任务间频繁切换。
解决：并行测量实例适用于“不同频段、错峰使用”的场景，比如 2.4G 测完开始测 5G，中间切换时间被并行实例覆盖。如果两个信号同时到达，需要确认仪表型号和选件是否支持真正的多通道并行采集。CMW100 和更高端的 CMW500 在并行能力上差异明显，产线方案设计时就要摸清这个边界。我一般建议单台 CMW100 只承担一条产线的 WLAN 测试任务，不要一台拖两条线，算下来节省的硬件成本不够抵维护和排障的人工成本。
6. 把指令手册变成产线脚本：批处理、限值判断与日志记录技巧
6.1 用 Python 封装仪器的核心操作：从裸指令到可维护脚本
前几章的指令都是裸的 SCPI，真正上产线必须封装成函数。以 Python 为例，我会把操作 CMW100 的代码拆成三层：底层是一个CMW100类，封装连接、断开、读写和错误查询；中间层是 WLAN 测试相关的业务函数，比如config_tx_channel(freq)、start_tx_measure()、get_power_result()；最上层才是测试流程逻辑，按项目需求调用中间层。这样写的好处是DUT 的差异不影响底层代码，测试流程改动也不用翻底层函数。
class CMW100: def __init__(self, ip): self._inst = rm.open_resource(f'TCPIP0::{ip}::inst0::INSTR') self._inst.timeout = 5000 def query(self, cmd): val = self._inst.query(cmd) err = self._inst.query('SYSTem:ERRor?') if 'No error' not in err: raise RuntimeError(f'SCPI error after {cmd}: {err}') return val def close(self): self._inst.close() cmw = CMW100('192.168.1.10') print(cmw.query('*IDN?'))这个封装里有个关键决定：每条查询指令后都带一次SYSTem:ERRor?。这样做的代价是每条指令的响应时间多几毫秒，但收益是任何错误立刻浮出水面，不会让错误指令静默执行下去、最后给出一个离谱的测试结果。产线测试宁可慢几毫秒，也不能让坏数据蒙混过去。
6.2 限值判断放在脚本端还是仪器端：两条路各有取舍
测试结果的判定，CMW100 有两种方式：一是你读回原始值，在脚本里和标准限值比较；二是在仪器内部设置限值，让仪器直接返回 PASS/FAIL。
CALCulate:WLAN:MEAS1:TX:LIMit:POWer:MAX 18.0 CALCulate:WLAN:MEAS1:TX:LIMit:POWer:MIN 10.0仪器端设限值的优势是节省传输时间，而且产线日志里直接记录 PASS/FAIL，不需要二次换算。缺点是限值的修改要写进 SCPI 指令，改一次要重新下发；限值逻辑复杂时（比如频率不同限值不同）在仪器端维护比较麻烦。
脚本端判断的优势是灵活，限值写在一个 CSV 文件里，按产品型号划分；缺点是每次测试都要把结果值传回报文，多一到两毫秒的传输时间。我的建议是：单条产线的方案，限值写脚本端就够了，读写文件和配置更直观；多产品共线生产、频繁切换型号时，可以结合仪器端限值保存多套配置，用一条指令切换方案。后者初期配置复杂，长线运维省心。
6.3 日志记录的三个维度：原始值、判定结果、错误码缺一不可
产线脚本最容易犯的错是只记录最终 PASS/FAIL，不记录原始测量值和 SCPI 错误码。等出了问题追溯时，只有判定结果没有测量数据，根本没法定位是 DUT 的问题还是仪器的问题。我记录日志的习惯是：每条测试记录包含三部分——测量原始值（功率、EVM、PER）、判定结果（PASS/FAIL）、这条测试相关的 SCPI 错误码（没有错误就记 None）。另外，时间戳要带毫秒，因为产线节拍分析要用。
日志的存储位置我放在本地 CSV 文件加网络共享盘双写。本地写是为了不因网络问题丢数据，网络写是为了汇总分析。CSV 文件名带上日期和线别，比如wlan_test_line1_20250218.csv，每天的记录按小时滚动分文件，避免单文件过大影响打开速度。调试阶段我还会加一个开关，把所有 SCPI 指令和响应原样写入调试日志——这个问题定位时最有价值，因为它让你看到仪器实际执行的每一步。
6.4 产线脚本上线前的验证清单：先打仪器再打 DUT
脚本写完后不要直接上产线，按照下面的顺序先在实验室验证：第一，用信号源或已知好的 DUT 跑一遍完整流程，确认测量值和 CMWRun 软件手动测得的结果误差在合理范围内（功率误差 0.5dB 以内、EVM 误差 1% 以内）。第二，故意设置一个超限条件（比如把 DUT 天线拔了），确认脚本能准确判 FAIL 并正确记录错误信息，这是验证异常处理路径。第三，连续跑 50 次完整测试，统计节拍稳定性——如果 50 次里有几次测量超时或结果跳变，当场排查，不要带上产线。
这三步做完再挂产线试跑。我见过太多人省掉第二步，上线后 DUT 天线接触不良时，脚本把 FAIL 当成 PASS，或者直接卡死在那里等人工介入。产线脚本不是“能测就行”，是“测了要可靠”，这一字之差，体验完全不同。做射频测试仪器控制这些年，我最大的习惯就是所有测量值都先问一句“这个数合不合理”，而不是直接拿去判断。希望这篇 CMW100 WLAN 指令笔记能帮你在调试和上线时少走几段弯路。
本文还有配套的精品资源，点击获取
