0dc85886.jpg  今日のお客さんからも質問があったので、このブログで解説しようと思うのが、ノードを入れると照明の信号が遅れるという話。 これはアナログからDMXへの移行期にもありましたが、すべてのシステムがイーサネットネイティブにならない限り、過渡期にはどうしても問われ続ける問題ではないでしょうか?実際、DMXの出始めの頃も同じことを言われました。 さて、もちろんDMXダイレクトとノードを入れた場合とでは、遅れがでてしまいます。間に余計なものが入るため、それはそうですね。ただ、この遅れが、ノードなどの処理で遅れるのではなく、DMXという信号の遅さが原因だと言う事をここで説明したいです。イーサネットそのものはDMXよりもずっと高速で、イーサネット化することで遅れるのではなく、DMXそのものが足を引っ張っているという真実です。 ここから本題です。DMXをイーサネットに変換することで、2つの大きな遅れが発生することを説明します。まず最初にDMXの入力時、これはDMXをインプットノードに入れてアートネットに変換する際に発生します。 DMXインプットエンジンはDMXをキャプチャーする時、入って来るDMXスロットをカウントし、 513番目のスロットが受け取られた後、DMXパッケージデータをArtNet変換エンジンに渡します。その結果、DMXの全スロットの長さだけ、ノードは待つ事になるので、ここにディレイが発生することがわかります。その長さは下記のようなものです BREAKタイム + MARK AFTER BREAKタイム + 513スロットのタイム 例: BreakTime = 92μs MarkAfterBreak = 12μs Start code スロットと512データスロットの時間の合計 Delay = 92μs + 12μs + (513×11×4μs) = 22676μs = 22.7ms ( DMXの一般的なBit timeは4μsで、ビットレートは250kb/s) これはDMX自体が持つブレイクタイムやデータがすべて到達するまでの時間の合計で、DMXをノードに入れた時点で、すでにこれだけ遅れるわけです。そしてこれはDMXの仕組みのせいで、イーサネットの遅さではない。Luminexのノードでは変換処理にかかる時間は、大きい値で5ms程度です。 次に出力側で起こるディレイについてです。これはフレームレートに依存します。よって値は可変します。 例えば、新しいDMXデータは次のDMXパッケージで送られてきます。新しいデータがない場合、次の新しいデータが利用可能になるまで、最後に送られたDMXパッケージが繰り返し利用されます。よって、最後に送られたデータの次に新しいデータがない場合は、そこに特別なDelayは発生しません。しかし、新しいデータが到着すると、エンジンはこれを次のDMXパッケージとして送信します。これにより最悪の場合、Delayは2つのDMXパッケージ間のBreak からBreakの時間と等しくなり、これはすなわち1/フレームレイトとなります。よってここで起こるDelayは、0から1/フレームレイトの可変タイムということになります。 例 : BREAK: 92 μs MARK AFTER BREAK 12 μs START Code SLOT and 512 データスロット Framerate 25 frames/s Delay は 0 ms から 40 ms程度の間で可変 これでおわかりのように、いかにDMXが遅いかがわかると思います。いくつもの待ち時間があり、これによりトータルすると遅れが目立つ訳で、ノードを2重で通すと最悪は57msくらいの遅れになることもあるでしょう。 しかしこれは、多くの場合、513スロットのDMXパッケージの遅れであり、DMXとアートネットへの変換により発生する遅れは、入力と出力の計で6msから10msの遅れでしかありません。そしてDMX出力の遅れは、フレームレイトにより異なり、フレームレイトが高ければ高いほど、Delayは少なくなります。そしてここにはあえて入れてませんが、イーサネットのスイッチを通すことで起こるディレイはもはやDMX自体の遅さに比べればわずかなため、これは無視してもいいと思います。やはり根本原因はDMXという信号を5pinのXLRを使い、RS485に準拠した規格で伝送するために、大きな遅れが出るのです。これをすべてイーサネットにすれば、この問題はなくなります。