Packet Sender：把现场测试指令存成清单反复跑

它到底解决什么

展厅交付前有一道绕不开的工序：把所有设备的控制指令重新验一遍。十几台设备、每台三五条指令，加起来几十条。这活本身不难，难的是它要做不止一次——中控程序改了要复验，设备换了要复验，网络调整了要复验，甲方验收前还要再来一遍。

用普通调试助手做这件事，每次都是从头手敲。敲到第三轮，人会开始跳步，跳步就会漏，漏掉的那条往往就是验收当天出问题的那条。

Packet Sender 的解法是把每条指令存成一个条目——名字、目标地址、端口、协议、内容，全都记下来。存好之后，整个清单就是一份可以反复执行的测试用例。第二轮验证不用重新敲，照着清单点过去就行；换个人来做，把清单文件给他即可。

这一点听起来朴素，但它把「验证」从一件依赖记性的事变成了一件有据可查的事。展厅项目交付时甲方常问「你们都测了什么」，一份能导出的指令清单比口头保证有说服力得多。

另外它是跨平台的，Windows、macOS、Linux 都有版本。展厅行业里 Mac 用户不少（做内容和视觉的同事基本都是），而串口调试类工具几乎清一色只有 Windows 版，这个差别有时候很实在。TCP 该用在哪、UDP 又该用在哪，背景见TCP 与 UDP 网络控制速查；PJLink 投影机网络控制连不上、手头没有 telnet 时，也能拿它顶上去验证链路，见PJLink 无响应排查。

展厅哪道工序会用到它

联调期建立基线。 每台设备第一次调通时，就把当时用的指令存进清单，注明设备名。等全场调完，你手里自然就有一份完整的控制指令清单，不用事后回忆整理。

交付前回归验证。 照着清单从头跑一遍，哪条不通当场就知道是哪台设备。这一步能拦下的问题类型很典型：某台设备被人重启后 IP 变了、某台设备的网线在吊顶施工时被碰松了、某个交换机端口被改了 VLAN。这些都是交付前一周最容易发生的事。

运维期的快速体检。 交付之后现场报「有个展项不动了」，把清单跑一遍，通不通一目了然，比现场逐台去点设备快很多。

它还能被脚本调用，这意味着可以把「每天早上自动把全场设备点一遍」做成一个定时任务。这已经接近监控的范畴了，虽然不如专业的监控系统完备，但成本极低。要做正经监控的话看 Uptime Kuma。

怎么获取

官网 packetsender.com 提供三个平台的安装包；它是开源项目，源码在 GitHub 的 dannagle/PacketSender，许可证 GPL-2.0。

Windows 上通常有安装版和便携版两种形式，去甲方现场建议带便携版——工程机不让装软件是常态。

最短可用路径

1. 打开软件，界面上方是发送区：填目标 IP、端口，选协议（TCP 还是 UDP），填要发的内容。
2. 内容同样区分字符和十六进制两种写法，界面上有专门的十六进制输入位置。填错这一项是最常见的失败原因，现象是发出去毫无反应。
3. 点发送，下方日志区会显示发出去的内容和收到的回复。
4. 验证通过之后，给这条起个名字保存下来——名字要写得让别人看懂，比如「一楼投影 开机」，不要写成「test1」。
5. 全部存完，把清单导出成文件，跟项目文档放一起。

顺带说一句它的 UDP 用法：展厅里有些设备的控制走 UDP 广播或组播，这类链路的验证比 TCP 麻烦，因为发出去没有确认。用它发完之后要在接收侧另开一个监听确认真的收到了，不能只看发送侧「已发送」就当通了。背景见 UDP 广播在展厅里怎么用。

展厅工程里真正要改的那几个设置

清单里的条目名称要按设备实际位置写。 这看起来是小事，实际决定了这份清单能不能被第二个人用。写「投影1」没人知道是哪台，写「一楼序厅 左投」谁都能对上。运维交接时这份清单就是资产。

保存清单时注意别把敏感信息带出去。 清单里有全场设备的 IP 和端口，这份文件相当于一张网络地图。给甲方运维可以，往外发要过一遍。

它能同时监听端口。 和 Hercules 一样，它也可以当服务端等设备连过来。展厅里雷达、地感这类主动上报的设备，验证时要用这个能力。开监听之前先确认 Windows 防火墙放行了。

踩坑与排错清单

什么时候别用它

临时试一两条指令，别为它建清单。 那种场合随手一个串口/网口调试助手更快。它的价值在于重复执行，只跑一次的事用不上。

串口为主的现场，它不是首选。 它的重心在网络侧，串口场景下 sscom 或 Hercules 更顺手。

要按协议语义操作，别用它。 Modbus 的寄存器读写用摩尔信使 MThings；BACnet 的点位浏览用 YABE；OSC 用 Protokol。用字节流工具去啃有语义的协议，你会把大量时间花在手算校验上。

要查「为什么时好时坏」，别用它。 这类问题的答案在链路里，得抓包看。

与本站方案的衔接

一份能反复跑的指令清单，本质上是把交付质量从「靠人负责」变成「靠流程保证」。这个思路再往前一步，就是把验证做进系统本身——设备状态持续巡检、异常自动告警、故障自动重试。

企服君中控 SoftControl 承接的正是这一段：调试期验证过的指令沉淀成设备驱动，运行期由系统自己巡检和重试。集成商每年交付多个项目时，这部分复用是实打实的工期节省，授权与年费方式见集成商年费方案。

交付前的完整验证清单，见展项 7×24 交付前老化怎么做；调试工具的分工见指令到底发没发？六款调试工具怎么分工。