ユニバースを8本から40本に増やした翌日、ライトが数分おきに固まりはじめた
こんな構成を想像してほしい（説明のための想定例だ）。
照明卓の出力を8ユニバースから40ユニバースへ増やした。卓の設定は触っていない。ケーブルもそのままだ。ところが翌日のリハから、ムービングライトの一部が数分おきに動きを止め、また何事もなかったように動き出す。DMXケーブルを疑って全数を交換した。ノードの電源も入れ直した。直らない。
原因はケーブルでも、ライトでも、卓でもなかった。ネットワークの「配り方」だった。
照明のIP化は、映像のIP化より気づかれにくい。画面が黒くなるわけではないからだ。ライトが1台、半拍遅れる。色が一瞬だけ戻る。そのたびに「たまたま」で済ませてしまう。この記事では、その「たまたま」の正体を分解する。
数字で見ると、構造は意外なほど単純だ
照明の基本信号であるDMX512は、1本のケーブルで最大512チャンネルを運ぶ。このひとまとまりを「ユニバース」と呼ぶ。1回の送信に要する時間は約22.7ミリ秒で、1秒間に約44回、同じ内容を送り直している（計算：88µs＋8µs＋513スロット×44µs＝22,668µs。1秒÷22,668µs≒44.1回。出典：ANSI E1.11 DMX512-A、ENTTEC公式解説）。
これをIPネットワークに載せたのがArt-NetとsACNだ。ユニバース1本ぶんが毎秒44パケットになる。40ユニバースなら毎秒1,760パケットだ（40×44）。送り方を「全員宛て（ブロードキャスト）」にしていると、同じネットワークにつながる機器の全員が、毎秒1,760パケットを受け取って中身を確認する羽目になる（出典：ENTTEC「Art-Net network design」）。
もうひとつ。マルチキャストで配る方式（sACN）では、スイッチが「誰がどの放送を聞きたがっているか」を覚えておく仕組み（IGMPスヌーピング）に頼る。この「覚えておく時間」の理論値は260秒、つまり4分20秒だ（計算：ロバストネス変数2×クエリ間隔125秒＋応答時間10秒。出典：RFC 3376 §8.1〜8.4）。
数分おきに症状が出る。この周期感に、心当たりはないだろうか。
あなたの腕が悪かったわけではない
回覧板にたとえよう。
町内の全戸に、毎秒44回、分厚い回覧板を投げ込む。住人は自分に関係する1ページしか読まない。それでも、受け取って、めくって、「これは自分宛てではない」と判断する作業は避けられない。家が8軒なら苦にならない。40軒分のページが毎秒1,760通届けば、玄関先は回覧板で埋まる。
住人の根気が足りないのではない。配り方が、軒数に合っていないのだ。
照明のネットワークも同じ構造をしている。卓のメニューには「ユニバース数」と「出力先」が並んでいる。けれど、その裏側で何通の郵便が走っているかは、画面に出ない。見えないものは、設計できない。だから失敗する。あなたのせいではない。見える化の順番を、誰も教えてくれなかっただけだ。
方法はある。しかも、順番が決まっている
信号は4つの区間を通って光になる。どの区間が壊れても症状は似ている。だから、勘で探すと遠回りになる。逆に、区間ごとに決まった順で確かめれば、1台のノートPCと15分のキャプチャで場所を絞れる。
この記事では、その順番と、各区間の合格ラインを数字で書く。
この記事で手に入るもの
- 信号が通る4つの区間と、区間ごとの合格ライン（数値つき）
- ブロードキャストからユニバース単位の配信へ切り替える判断基準
- IGMPの調停役を1台に決める手順と、確認用のキャプチャ条件
- 同じユニバースを2台が送ってしまった時の優先順位の組み立て方
- 本番前10分で回せるチェックリストと、症状から場所を逆引きする早見表
この設定を知らないまま次の現場に入ると
IGMPの調停役が不在、または2台いる状態では、理論値でいえば260秒ごとに配信が途切れる余地が生まれる。ライトは、理由の分からない動きを4分20秒ごとに繰り返しうる。
その手順が、このあとにある。
コメント