点击蓝字 关注我们

有线系统的"接线"是一根电缆的事，无线系统的"接线"则是一套完整协议的事。配对（Pairing）就是有线系统中"插上电缆连接"的等价操作——它是设备获得身份、参数、通信资源的关键一步。而在配对之前，主站得先"发现"周围有哪些设备在等待接入；配对之后，主站还要决定每个设备挂在哪个端口下。发现、配对、映射，三步构成完整的组网闭环。

Scan：在配置信道上"点名"

设备发现的第一步很朴素：上电之后，每个未配对的 W-Device 就守在配置频率信道上，等待 W-Master 来"点名"。当用户（或上位应用）发起设备发现请求，W-Master 就在配置信道上周期性地发送 Scan Request 下行消息，消息里带着一个不断递增的请求号（Request_N）。

收到 Scan Request 的未配对 W-Device 必须回应一条 Scan Response 上行包，把自己的 UniqueID（唯一标识符） 交出来——这相当于设备在"报到"时报上自己的身份证号，供配对前的认证使用。有了这套机制，W-Master 附近所有未配对设备都能被"盘"出来，应用再决定跟谁配对。

麻烦在于，同一时刻可能有多台设备同时应答，撞在一起怎么办？规范的解法是用 UniqueID 做散列（Hashing）：设备响应时的等待子周期数 Frame_N = (Σ UniqueID 前 9 字节) mod 30（Equation 7），响应时隙 Slot_N = 2 × (Σ UniqueID) mod 4（Equation 8）——每台设备的 UniqueID 不同，算出的响应时机和时隙就不同，天然错开。万一还是没收到确认（ACK），设备不会立刻在下一个子周期重试（那会造成新的碰撞），而是随机等待 2 到 31 个配置子周期后再来。这套"错峰 + 退避"的组合，把多设备同时发现的冲突概率压得很低。

Pairing by UniqueID：工程工具里的常规配对

扫描找到了设备，接下来是确认身份。Pairing by UniqueID 是规范定义的常规调试机制（normal commissioning mechanism）：适用于把一台 W-Device 配给一台预先配置好的 W-Master。它的核心是用 UniqueID 在配对流程中自动识别设备——主站端已经通过工程工具（Engineering Tool）或 HMI（比如 PDCT）预置了要配对的设备名单，配对时两边对身份证号，对上了就往下走。

序列非常清晰：W-Master 依次下发 Pairing Request 下行 → W-Device 回 Pairing Response 上行 → 主站再发 Negotiation 1 Request → 从站回 Negotiation 1 Response → 主站发 Negotiation 2 Request → 从站回 Negotiation 2 Response。三轮握手完成，ConnectionParameters（连接参数）在协商过程中安全下发，设备随即进入 Paired_4 状态、开始与主站同步并切换到正常跳频表工作。任何一轮 DLink 或 ULink 丢失，都在下一个配置子周期原样重传，重传上限由服务超时兜底。

Pairing by Button：两手按下，双端确认

不是所有现场都有工程工具——设备坏了临时换一台，或调试时手边没有软件，怎么办？Pairing by Button 就是为此设计的：它不需要任何软件工具，也不要求操作者了解 W-Device 的细节，代价是配对必须在两端由人手确认——主站侧按一下配对按钮，设备侧也按一下，双方"点头"了配对才成立。两个 Button Press 一个在主站端、一个在设备端，之后走与 UniqueID 配对相同的 Request → Response → Negotiation 1 → Negotiation 2 流程。

规范还专门留了一个 Re-Pairing by Button 分支：一台之前配过旧主站的设备，如果还留着旧主站的连接参数，按下按钮可临时切到 Re_Pairing 状态，在新主站的配置信道上等待配对请求——设备换主人不用重刷参数，按个钮的事。

ConnectionParameter：配对时交到手里的"钥匙串"

配对谈判的最终产物是一串连接参数，规范把它单列成 ConnectionParameter（Table 153），包含六项：MasterID（主站身份，5 bit）、Slot_N（时隙号，3 bit）、Track_N（轨道号，3 bit）、HoppingTable（跳频表）、DataSyncword（数据同步字，3 字节）、SlotType（时隙类型，2 bit）。这套参数在配对期间传输给 W-Device，由介质访问层（MAC Layer）管理，应用层根本碰不到——这正是"连接参数"的定位：它们描述的是物理通信怎么跑，不是业务数据是什么。

存储策略也有讲究：普通设备（Normal-Device）把参数存进非易失性存储器，断电重启后自动回到工作状态，实现真正的"配一次、永久用"；漫游设备（Roaming-Device）只存易失性存储器，断开即弃，为的是在多主站小区间自由移动而不留痕迹。

️ Unpairing：好聚好散的收尾流程

有配就有拆。Unpairing 是解除 W-Device 与 W-Master 通信关系的标准流程：操作者通过 HMI 等途径触发主站，主站对指定设备发送 unpairing 请求，设备回一个确认；随后设备侧的 ConnectionParameters 与主站侧对应的 W-Port 配置被一并删除——双方都恢复"素不相识"的状态，设备回到配置信道上等待下一次被扫描。这个流程干净利落，没有残留配置，为设备跨产线、跨系统周转提供了便利。

TDMapper：W-Port 的"虚拟交换机"

配对完成之后还有一个关键问题：设备到底挂在主站的哪个"口"上？ 有线系统里，设备插哪个端口就用哪个端口；无线系统里，这个关系是软件映射出来的——靠的就是 TDMapper（W-Track 与 W-Device 映射器）。它把每个 W-Port（应用端口）映射到具体的 W-Track 号和 Slot 号，而 Slot_N 正是在配对时分配给对应 W-Device 的（与 ConnectionParameter 里的 Slot_N 一脉相承）。

TDMapper 的配置由 SM_SetPortConfig 服务（经由 DL_TDConfig） 完成，它带来的灵活性很实用：同一台设备可以随时重新分配到不同的 W-Track 或 Slot，而 W-Port 编号保持不变——上层应用从头到尾看到的还是那个端口号，物理位置却可以弹性调整，这正是无线组网比有线灵活的地方。

✅ 写在最后

把整个组网流程收拢成一句话：扫描解决"发现"，配对解决"确认身份与下发参数"，TDMapper 解决"挂到哪个口"，Unpairing 解决"干净离场"。四步各司其职，拼在一起，就是 IO-Link Wireless 那句"即插即用"背后真正的工程含量。

关注我们 阅读更多好文