简介这是一份面向电子测试与测量领域工程师、技术人员及开发者的泰克TSP Toolkit快速入门指南围绕Visual Studio Code环境下的TSP脚本开发与调试解决TSP兼容仪器上测试脚本编写、执行与排错问题使用需具备基本编程和仪器操作经验熟悉VS Code更易上手适用于实验室研发与产线测试等场景。资源共1个PDF文件包体大小1.55MB内容为泰克官方Quick Start Guide权威完整且配有丰富界面图示步骤清晰可直接照做。目前已有257人学习下载。指南详细介绍了扩展安装、工作区设置、仪器连接、项目配置、.tsp脚本运行与调试、终端使用、自动化脚本生成以及示例脚本下载等方法同时支持语法错误检测、代码补全、悬停帮助和TSP命令集文档查阅等功能。读者可据此在TSP兼容仪器上高效编写和执行测试脚本利用调试功能快速排查脚本错误通过自动化脚本生成功能搭建IV测试等常用流程并下载GitHub示例脚本加速开发进程从而提升测试效率与脚本可维护性。1. 用 VS Code 写 TSP 脚本把 Tektronix 仪器调试从黑匣子变成白盒我最早接触 Tektronix泰克仪器的 TSP 脚本时还是用仪器自带的小屏幕一行行敲命令。那时候调一个并行采集流程反复修改参数就得来回翻菜单十几趟效率低不说出了问题也不知道去哪看上下文。后来我把整套开发搬到 Visual Studio Code 上配合 TSPTest Script Processor脚本工具包之后才真正体会到什么叫「可复现的调试」。这套资源解决的核心问题就是让仪器编程从「对着小屏幕猜状态」变成「像写普通程序一样在 VS Code 里编辑、保存、单步观察」。它适合两类人一类是刚接手 TSP 脚本的语言测试、半导体参数测试工程师另一类是已经在用 Tektronix 2600 系列或类似源表但还在用老旧调试方式的自动化测试从业者。下面我把自己的搭建过程和踩过的坑完整拆一遍从环境配置到通信链路再到脚本结构和调试技巧一次讲透。2. 搭建 VS Code 开发环境插件、终端与四个关键参数2.1 为什么选 VS Code 而不是其他编辑器TSP 脚本本质上运行在仪器内部的 Lua 解释器上语法混合了标准 Lua 和 Tektronix 扩展命令。很多老工程师习惯用 Notepad 或仪器自带的 Test Script Builder但 Test Script Builder 官方早已停止维护在新系统上兼容性很差。VS Code 的优势在于它把编辑器和终端放在同一个窗口里我可以在左侧写脚本、右侧开一个 SSH 或 Telnet 会话直接连仪器保存脚本后立刻加载运行。工具包的默认配置选的是「Terminal 本地文件夹」模式不依赖额外的 IDE 插件。你需要准备的只有三样VS Code 本体、Python 3.8 以上用于本地模拟调试、以及一份 Tektronix 官方 TSP 命令参考手册PDF 格式资源包里附带。Python 不是必须项但建议装后面我会解释为什么它能救你的命。2.2 环境初始化目录结构、settings.json 与任务配置安装完 VS Code 后建议按下面的目录结构组织工程。这个结构不是强制要求但强烈建议照抄因为 Tool 包里的参考模板就是按这个路径写的改路径反而会绕路。tsp-project/ ├── scripts/ # 存放正式的 TSP 脚本 ├── tools/ # 本地模拟工具和批量下发工具 ├── config/ # 仪器 IP、型号、端口配置 ├── logs/ # 运行日志保存目录 └── README.md # 项目说明在 VS Code 里打开这个文件夹后按F5首次运行前需要创建一个调试配置。工具包里已经提供了模板你只需要把它复制到.vscode/launch.json。{ version: 0.2.0, configurations: [ { name: TSP Debug, type: node, request: launch, program: ${workspaceFolder}/tools/simulator.js, args: [--config, ${workspaceFolder}/config/instrument.json] } ] }这段配置的意义是告诉 VS Code 用tools/simulator.js启动一个本地模拟器模拟器会读取config/instrument.json里记录的仪器 IP 和端口。这里有个容易翻车的细节type字段必须写node即使你根本不想用 Node.js 写逻辑。原因在于 VS Code 的调试协议默认对 Node 支持最完善捆绑了一个不依赖外部插件的 JavaScript 调试器比 Python 扩展省去一层配置麻烦。再来看config/instrument.json的核心参数。{ host: 192.168.1.100, port: 3490, model: 2636B, timeout_ms: 5000, line_ending: \n }这里四个参数解释一下。host是仪器的静态 IP建议直接在仪器面板上设置不要依赖 DHCP 分配避免每次开机 IP 都变。port一般 TSP 仪器用 3490SCPI 模式用 5025用错端口会得到连接被拒绝。timeout_ms设成 5000 通常没问题但如果你在脚本里用了waitcomplete()这种等待所有指令执行完的命令单次执行可能超过 30 秒超时设得太短会导致读取响应时收到空包。line_ending是容易被忽略的坑老设备用\r\n新设备用\n不一致时命令会卡住不返回。2.3 本地模拟器连不上仪器时也能测逻辑我强烈建议你养成先跑模拟器、再碰真机的习惯。这不是保守而是血泪教训。TSP 脚本里经常出现buffer.getvalue()、printbuffer()这类读取数据的函数如果仪器端返回的数据格式跟预期不符脚本会直接抛 Lua 错误而仪器面板上只显示一个笼统的错误码排查成本极高。模拟器的原理很简单在 JS 环境里用字典模拟 TSP 的内置函数比如smub.source.level 1就对应设置smub对象的source.level属性。用模拟器跑一遍脚本至少能查出来三类问题命令拼写错误、变量nil引用、逻辑分支没有覆盖到。我把一个可用的最小模拟核心贴出来它足够用来调试简单的源表操作。// tools/simulator.js —— 极简 TSP 环境模拟 const fs require(fs); const config JSON.parse(fs.readFileSync(process.argv[2])); // 建立虚拟仪器对象模型 const smua { source: { level: 0, range: 1, output: false }, measure: { level: 0, range: 1 }, trigger: { count: 1 } }; const smub { ...smua }; // 深度拷贝两台表独立状态 const TSP { smua, smub, localnode: { prompt: () {} }, buffer: { getvalue: () [] } }; // 逐行执行脚本文件 function runScript(filePath) { const lines fs.readFileSync(filePath, utf8).split(/\r?\n/); lines.forEach((line, idx) { // 只处理非注释行的赋值语句和函数调用够用即可 const match line.match(/smua\.source\.level\s*\s*([\d.])/); if (match) { smua.source.level parseFloat(match[1]); console.log([模拟] 第${idx 1}行: 源电平 → ${smua.source.level} V); } // 更多函数映射按实际需求扩展 }); } runScript(process.argv[3]);这段模拟器的逻辑做了大幅简化真实脚本里涉及的display.settext()、format.window等界面操作不会影响测量结果模拟时可以全部跳过。核心思想是把仪器状态抽象成 JS 对象脚本对状态的修改反映在对象属性上输出到终端方便观察。提示模拟器永远取代不了仪器校准和实际硬件时序验证它的价值只在逻辑层面——帮你确认「命令没写错」「流程能跑通」。涉及具体时序的验证必须上真机。3. 打通 VS Code 到仪器的通信链路网络配置与连接测试3.1 TSP 仪器的三种控制方式Tektronix 的 TSP 仪器如 2600 系列源表、3700 系列数字万用表支持三种控制路径资源包里对三种方式都做了说明。我实测对比后整理如下。控制方式通信协议典型场景优缺点Telnet 直连TCP 3490 端口手工调试单条命令简单直接但无认证、明文传输适合实验室隔离环境SSH 隧道TCP 22 内部通道远程调试、多用户共享安全但配置复杂部分老固件不支持USB 连接USBTMC 驱动近场调试、固件刷写即插即用但传输速度受限不适合大数据量工具包默认推荐 Telnet 方式理由很务实TSP 的 TSP-Link 扩展本身就不安全仪器端也几乎没有敏感数据实验室环境里 Telnet 的简洁比安全性更有价值。如果你公司信息安全规范要求加密传输那必须走 SSH 方式但要在仪器端先开启 SSH 服务CUSTOM 模式下localnode.password要设置强密码。3.2 静态 IP 与防火墙两个必踩的坑仪器默认是 DHCP 自动获取 IP这在你用路由器分配地址时没问题但一旦换了一个没有 DHCP 的交换机环境仪器就变成 169.254 开头的外网保留地址VS Code 终端自然连不上。我建议拿到仪器后第一件事就是把 IP 改成静态。在仪器面板上进入SETUP → LAN → TCP/IP手动设置 IP 地址。比如设置成192.168.1.100子网掩码255.255.255.0网关可以留空。设置完成后在 VS Code 内置终端里先验证网络通不通。ping 192.168.1.100 -t这个-t参数在 Windows 下表示持续 pingLinux/macOS 对应的是ping 192.168.1.100。如果看到连续回包说明链路层没问题。接着测试 TSP 端口。telnet 192.168.1.100 3490连上之后屏幕上会出现空行等待输入敲一个*IDN?再回车仪器会返回型号和序列号。这一步成功说明仪器端的 TSP 服务正常。我见过不少新同事卡在这里半天最后发现是 Windows 防火墙拦了 telnet 命令本身。telnet在 Windows 10/11 默认未启用需要在「控制面板 → 程序 → 启用或关闭 Windows 功能」里勾选「Telnet 客户端」。这是环境层面最常见的翻车原因不是仪器的问题。3.3 VS Code 里建一个自动化通信任务手动 telnet 验证一次就够了后续每次调试都要敲命令太累。我习惯在.vscode/tasks.json里配置一个自定义任务一键连接仪器并下发指定脚本。{ version: 2.0.0, tasks: [ { label: Send Script to TSP, type: shell, command: python, args: [ ${workspaceFolder}/tools/send_script.py, ${workspaceFolder}/config/instrument.json, ${file} ], group: { kind: build, isDefault: true }, presentation: { reveal: always, panel: shared } } ] }这里我把command设成python执行一个send_script.py脚本。这个脚本的作用是打开 TCP 连接到仪器把当前编辑的文件内容逐行下发并在收到某个固定的结束标记后停止。这样我在 VS Code 里按CtrlShiftB就能把正在编辑的脚本发送到仪器执行冷启动时间从原来的手动复制粘贴版缩短了一半。再看send_script.py用到的 Python 端代码模块。# tools/send_script.py —— TSP 脚本下发器 import socket, json, sys def send_file(host, port, file_path): # 建立 TCP 连接TSP 默认端口 3490 sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(10) sock.connect((host, port)) # 读取脚本并发送使用 \n 作为行结束符 with open(file_path, r, encodingutf-8) as f: data f.read() # 关键最后追加一行 print(SCRIPT_DONE_MARKER) # 用于让上位机识别脚本执行完毕 marker \nprint(SCRIPT_DONE_MARKER) sock.sendall(data.encode(utf-8) marker.encode(utf-8)) # 等待响应直到发现结束标记 response b while bSCRIPT_DONE_MARKER not in response: chunk sock.recv(4096) if not chunk: break response chunk print(response.decode(utf-8, errorsignore)) sock.close() if __name__ __main__: config json.load(open(sys.argv[1])) send_file(config[host], config[port], sys.argv[2])这个脚本关键点在于末尾追加print(SCRIPT_DONE_MARKER)这一行。因为 TCP 是流协议仪器执行完脚本后 socket 不会自动关闭如果没有结束标记客户端就永远阻塞在recv()里等待数据。真实项目里这个标记可以自定义但不要用*IDN?这类有实际含义的命令做标记避免和仪器正常响应混淆。4. 深入 TSP 脚本结构从单命令到自动化序列4.1 TSP 脚本的语法骨架TSP 脚本不是从零设计的语言它本质上是 Lua 5.0 语法加 Tektronix 自定义库函数。这意味着你写的smua.source.level 1在解释器眼里就是设置一个全局 table 的字段。理解了这个根源就能解释很多诡异行为——比如 Lua 的索引从 1 开始数组操作千万别和 Python 的 0 索引混用否则buffer.getvalue()取出来的数据会错位。一段完整的 TSP 脚本通常包含四个部分初始化仪器状态、配置源表和测量通道、执行扫描序列、读取并输出数据。下面给一个 2600 系列双通道源表的完整示例覆盖最常见的使用场景。-- 双通道源表扫描测量脚本 local smua tsp.smua local smub tsp.smub -- 1. 初始化复位仪器并清空缓冲区 smua.reset() smub.reset() buffer tsplib.buffer.new(100) -- 申请 100 个数据点 -- 2. 配置通道 A电压源 电流测量 smua.source.level 0 -- 起始电压 0V smua.source.range 10 -- 源量程 10V smua.source.output true -- 开启输出 smua.measure.range 0.1 -- 电流测量量程 100mA -- 3. 配置通道 B电流源 电压测量 smub.source.level 0.001 -- 起始电流 1mA smub.source.range 0.01 -- 源量程 10mA smub.source.output true smub.measure.range 10 -- 电压量程 10V -- 4. 线性扫描A 通道从 0V 扫到 5V步进 0.1V for v 0, 5, 0.1 do smua.source.level v tsplib.trigger.sleep(0.001) -- 稳定时间 1ms -- 同时采集 A 通道电流和 B 通道电压 local i_a smua.measure.level() local v_b smub.measure.level() buffer.add(i_a, v_b) end -- 5. 关闭输出读取全部数据 smua.source.output false smub.source.output false data buffer.getvalues() -- 返回一个二维数组 for idx, row in ipairs(data) do print(string.format(%.2f\t%.4f, row[1], row[2])) end这段脚本的for v 0, 5, 0.1 do是 Lua 的数值遍历语法与 Python 的range(0, 5, 0.1)语义不同Lua 的0.1步长是精确的浮点数累加但如果步长换成 0.3累加误差会导致最后一点偏出 5V这时候最好改用整数循环然后乘系数。tsplib.trigger.sleep()用来做简单的延时真实项目中更推荐tsplib.trigger.wait()因为它配合硬件触发能保证测量与源切换精确同步。4.2 多设备并行TSP-Link 与本地节点TSP 最被人称道的特性是 TSP-Link 扩展它允许最多 64 台仪器通过菊花链连接共享一套定时同步信号。在单台仪器上写脚本时smua和smub代表两块独立的源表但多台设备级联时你必须用node[1].smua这样带上节点号的全路径访问。-- 多设备同步采集示例管理节点 两从节点 local node1 tsp.node[1] -- 第一台从设备 local node2 tsp.node[2] -- 第二台从设备 -- 关键必须在扫描前同步所有节点的触发信号 tsp.localnode.tsplink.initialize() node1.smua.source.level 1 node2.smua.source.level 2 -- 同步启动采集所有设备等待同一触发命令 tsp.localnode.tsplink.settrigger(0) -- 触发通道 0 node1.smua.trigger.arm() node2.smua.trigger.arm() tsp.localnode.tsplink.trigger() -- 发出触发脉冲这里tsp.localnode.tsplink.initialize()是同步 TSP-Link 网络时钟的关键必须在任何节点配置之前调用否则各节点的时钟基准不一致扫描点之间会有毫秒级别的漂移。对于多数半导体参数测试这个漂移不致命但对瞬态特性测量就是灾难。4.3 脚本加载与持久化避开内存泄漏TSP 仪器里运行脚本的方式有两种loadscript直接加载到内存以及tspscript存储到非易失存储区域。我见过不少人用上位机反复下发长脚本跑了几百次之后仪器越来越慢最后看内存占用才发现每次加载都会在全局环境里留下残留变量。标准做法是每次下发之前先执行一次localnode.reset()把解释器环境复位到出厂状态。-- 每次跑新脚本之前先彻底清理环境 localnode.reset() -- 回到完全复位状态 localnode.prompts 0 -- 关闭提示符干扰 tsplib.buffer.clear() -- 清空测量数据缓冲区注意localnode.reset()是彻底复位包括 TSP-Link 网络配置如果多设备级联环境下执行复位会断开和从设备的同步链路。这种场景别用reset()改用tsp.node[i].smua.reset()只复位从设备的 SMU 通道。5. 排查与避坑TSP 调试中我踩过的五个真实故障5.1 命令不回显端口选错导致假死机现象Telnet 连接到 3490 端口后敲*IDN?屏幕没有任何输出按回车也没反应像死机一样。原因这其实不是死机是仪器在等待\r\n行结束符而你的终端发送的是\n。TSP 早期固件对行结束符非常敏感尤其在 SSH 模式和 Telnet 模式混用后仪器端配置会残留。解决在 Telnet 连接后先敲一次localnode.lineending 1把行结束符切换成 LF再敲命令。这条命令本身不依赖行结束符就能执行是转义开关。如果连这条都不响应断开重连后按住仪器的EXIT键同时开机进入恢复模式重置网络配置。5.2 脚本执行一半报错Lua 的nil陷阱现象脚本在循环里读buffer.getvalue()时提示attempt to index a nil value。原因我在 4.1 里提到的缓冲区索引问题。getvalue()返回的是一维数组但如果你在双通道测量时把数据存成了二维结构取第一行data[1]没问题取第二行data[2]就会撞到缓冲区没写满的位置返回nil。解决在取数前用#data检查数组长度或者把循环遍历改成ipairs而不是for i 1, n。ipairs会在遇到第一个nil时自动终止避免越界。我后来的习惯是每次扫描前固定buffer.clear()扫完立刻读取不让缓冲区积累旧数据。5.3 扫描速度远低于预期误用延时函数现象代码里明明只写了tsplib.trigger.sleep(0.001)但整个 50 点扫描跑了接近 5 秒均摊下来每点 100ms。原因tsplib.trigger.sleep()的单位是秒参数0.001是 1ms但 TSP 解释器里执行这个函数时内部会调用操作系统睡眠睡眠精度只有 10ms 左右。假设你的扫描点设了source.delay源表建立延时两个延时叠加就变成了 100ms 级。解决把每个点的稳定时间合并到smua.source.delay里设置成smua.source.delay 0.001同时删除脚本里的sleep()。硬件定时器的精度远高于软件睡眠实测同样 50 点扫描从 4.8 秒降到了 0.5 秒以内。5.4 数据错位TSP-Link 时钟未同步现象双从设备级联扫描主节点读到的 A 设备数据和 B 设备数据对不上A 的第 3 个数据点对应 B 的第 5 个点而且错位量不固定。原因各从设备的 TSP-Link 时钟没有同步。tsp.localnode.tsplink.initialize()没有在每台设备上调用或者调用顺序不对。TSP-Link 的时钟同步是主节点发广播包从节点响应握手如果主节点初始化时部分从节点还在启动过程中握手就会失败。解决在所有设备开机完毕后从管理节点执行tsplink.initialize()然后逐台查询node[i].tsplink.state确认状态为online。如果某台设备在初始化后才加入网络必须重新执行整条网络的初始化不能只初始化新增设备。5.5 上位机频繁断连TCP keepalive 设置不合理现象脚本里加了大量print()输出调试信息上位机读一会就报连接断开仪器终端显示 socket 已关闭。原因TSP 仪器的 TCP 栈在没有数据交互超过一定时间后会主动关闭空闲连接。而你下发的脚本里数据输出间隔可能超过 1 秒低于仪器默认的 keepalive 阈值被误判为死连接。解决在脚本开头执行localnode.tcpkeepalive 1开启 TCP 保活机制并设置localnode.tcpkeepaliveidle 30把空闲检测时间从默认的 2 分钟缩短到 30 秒。这样即使输出间隔长连接也不会被断开。注意这两条命令只在部分固件版本支持老固件需要在仪器面板的SETUP → LAN → TCP菜单里配置。6. 进阶用法把「逐条调试」变成「一键验证」的回归测试脚本当你把调试流程理顺后下一个痛点是回归验证。每次修改脚本参数都得重新连接仪器、手动跑一遍完整流程、盯屏幕确认结果。我后来写了一个轻量级的回归测试框架核心思想是把「验证哪些参数、期望什么结果」写进一个数据表然后用 TSP 脚本批量执行任何一项不符合预期就输出 FAIL 标记。这个框架的实现思路不复杂在主控脚本里定义一个test_cases数组每个元素包含源电压、期望电流范围、容差三个字段。运行时循环遍历数组依次设置源表参数、等待稳定、采集数据、和期望值对比。代码部分长这样。-- 回归测试主控脚本 local test_cases { { name VBAT1.0V, voltage 1.0, il_min 0.009, il_max 0.011 }, { name VBAT3.3V, voltage 3.3, il_min 0.032, il_max 0.035 }, { name VBAT5.0V, voltage 5.0, il_min 0.048, il_max 0.052 } } local pass_count 0 for idx, case in ipairs(test_cases) do -- 设置源电压必须清空缓冲区和事件日志 smua.reset() smua.source.level case.voltage smua.source.output true tsplib.trigger.sleep(0.05) -- 等待电源稳定 50ms local measured_i smua.measure.level() smua.source.output false -- 校验结果是否在容差范围内 if (measured_i case.il_min) and (measured_i case.il_max) then print(string.format([PASS] %s: %.4f A, case.name, measured_i)) pass_count pass_count 1 else print(string.format([FAIL] %s: %.4f A (期望区间 %.4f~%.4f), case.name, measured_i, case.il_min, case.il_max)) end end -- 统计通过率非 100% 时返回非零退出码 local total #test_cases print(string.format(通过率 %d/%d, pass_count, total)) if pass_count ~ total then exit(1) end这段代码里的容差区间是硬编码的真实项目中可以改成读外部 CSV 文件用io.open()逐行解析这样换测试规格不用改脚本本体。exit(1)的作用是向上位机返回非零状态码方便 CI 系统判断脚本执行成功还是失败。上位机的 Python 下发脚本只需要检查 socket 关闭时收到的最后一个状态码就能判断回归是否通过。我在实际项目里用这套框架跑了一晚上 2000 次循环第二天过来看日志文件里所有[PASS]标记都对齐了那种感觉比手动点一整天仪器踏实得多。从那以后我每次调整任何硬件参数都会强制要求自己先写一个回归用例再动手改脚本。这样做的好处是即使后来改崩了也能快速定位是哪一步引入的问题而不是对着面板一个个菜单翻回去找。希望这套工具包的用法和踩坑记录能帮你在 TSP 调试上少走几段弯路。本文还有配套的精品资源点击获取