灯光协议输出：串口 / DMX 实时控制的稳定写法

灯光控制链路末端是协议输出。UI 上推杆每秒可能触发几十次参数变更，但 DMX512 设备侧需要稳定帧率（常见 25–44 Hz）与可预期延迟。把发送逻辑写在按钮 Click 里，或跟 UI 绑定同一刷新循环，现场一定抖、一定 lag。

输出线程独立

UI 线程只更新「期望状态」——各通道目标值、优先级、效果层叠加结果。独立输出线程按固定节拍（如 25ms）取样当前期望态，编码成 DMX Universe 帧经串口或网络发出。线程优先级可略高于普通后台任务，但不要用实时优先级误伤系统调度。

合并变更

短时间内的重复变更合并为最新值再编码，避免把串口写队列塞满。渐变效果在输出线程做插值，而不是 UI 每帧发一条指令。效果层叠加规则（HTP/LTP）在取样点统一计算，避免 UI 与输出各算一遍不一致。

背压与丢弃策略

来不及发时，保留最新值、丢弃中间过渡帧——灯光更在意「现在对不对」，而不是历史每一帧都送达。检测到写超时连续发生时，应降频或告警，而不是无限堆积 Buffer 导致延迟越来越大。监控发送间隔的实际抖动，比只看「有没有在发」更有用。

多 Universe

大型场布多路 DMX 输出时，每路独立发送线程或独立定时器，避免一路阻塞拖死全局。通道映射表启动时加载，运行期变更走原子替换，不在发送循环里改字典。Art-Net 与串口 DMX 可并存，但同一灯具避免双路径重复驱动。

故障可见

端口断开、校验失败、设备 NAK 立刻反映到控制台状态灯，并写入环形日志（时间戳与帧序号）。支持热重连：拔插 USB-RS485 后自动 reopen，恢复发送前发一帧 safe look 或全零，防止乱码帧误触灯具。操作员无需重启整个编排软件。

与 UI 的边界

Avalonia 绑定层不要直接调 SerialPort.Write。用线程安全的状态容器或 Channel 传递意图，输出线程是唯一写端口的地方。单元测试可 mock 输出层，验证「给定期望态序列，编码结果是否正确」，无需接真实硬件。

典型坑

• 在 UI 线程 Thread.Sleep 等 ACK：会卡界面，应异步或专用 IO 线程
• DMX Break / MAB 时序不对：部分调光器不认帧，需按设备手册实现
• 演出结束停止发帧：部分设备进入未知态，应 configurable idle 帧策略

联调建议

先在回路里接 DMX 监视器或软件模拟器，确认帧率与通道值，再接真实灯具。串口参数（波特率、终端电阻）与走线长度问题，软件层应能报「连续写失败」而不是默默丢帧。

RDM 与设备发现（若适用）

部分设备支持 RDM 读地址、读状态。发现流程不应阻塞常规发送线程，单独低优先级任务轮询即可。RDM 失败时降级为静态地址表，现场仍可手动继续。

安全上限

输出层应对通道值做 clamp，防止 UI bug 或错误映射把调光器推到非预期功率。黑场、应急场景优先级最高，应能 override 正在播放的效果层，无需等当前 cue 播完。

长时间运行

彩排或展会可能连续运行十几个小时。注意串口句柄泄漏、定时器重复注册、日志文件无限增长。输出线程异常退出时，UI 应明显告警并尝试自愈重启线程，而不是静默停发直到有人发现灯全暗。

实时控制的工程重点，是节奏，不是吞吐峰值。稳定 40 Hz 的正确值，胜过偶尔 burst 大量帧却越来越 lag。

小结

实时控灯看重稳定节拍与最新值优先，而不是历史帧全送达。输出线程独立、端口热重连与安全上限，是演出夜少出事的关键设计。长时间运行要关注句柄与缓冲泄漏，彩排不够，正式场更容易暴露。