電装工芸日記
- 舞台照明機器の製作とか -
タグ「Art-Net」を含む投稿［147件］（4ページ目）
試さんといけないことが残っています。Art-Net を wi-fi で飛ばすことです。なんちゃって DMX-Wireless です。
本線ではなくサポート的なワイヤレスが欲しいのです。例えば、大尽裏の拠点から舞台奥までとか、短い距離だけどケーブルを通したくない通せないところのサポートです。
引き枠屋台とかにも魅力があります。灯体がLEDなら容量多めのバッテリー電源を積めばコストを抑えて照明をワイヤレスに出来ます。キャスト頭上に小さなムービング仕込んでみたい。
#[Art-Net]
本線ではなくサポート的なワイヤレスが欲しいのです。例えば、大尽裏の拠点から舞台奥までとか、短い距離だけどケーブルを通したくない通せないところのサポートです。
引き枠屋台とかにも魅力があります。灯体がLEDなら容量多めのバッテリー電源を積めばコストを抑えて照明をワイヤレスに出来ます。キャスト頭上に小さなムービング仕込んでみたい。
#[Art-Net]
オレメモです。
「Ether over COAX」には「MoCA」と呼ばれる規格もあります。最大ケーブル長は短いですが、n対n接続(同一経路上に複数を設置)が可能です。EoCは1対1に限ります。
大きな違いはEoCが75Ω同軸ケーブルを用いるの対し、MoCAは50Ω同軸ケーブルを用います。どちらも既設の同軸ケーブルを活用してLANを構成することが目的ですが、片や映像ケーブル、片やアンテナケーブルです。
EoCはビルや大規模施設の監視カメラを更新するために作られたようです。今となってはwebカメラが便利で安価ですが、ケーブルを換える費用の方が高くつくので、なんなら既にある同軸ケーブルにEthernetを通してしまえって発想みたいです。
MoCAは、特にアメリカらしいですが、部屋ごとにテレビを置くことが当たり前ですとどの部屋にもアンテナ線が来ています。もちろんテレビ信号と同居出来ることが条件とはなりますが、これも既にある同軸ケーブルを利用してしまえってことみたいです。
そもそも、Ethernetは無線通信でコンピュータ同士を繋げることから始まっているので10Base2といった同軸ケーブルを使う規格もあったワケです。これをアップグレードしたと思えば自然です。変調帯域が違えば混合使用も普通のことです。
EoCは100Mbps、MoCAは400Mbpsと違いますが、数ユニバースの Art-Net を通すなら100Mbpsあれば十分なので転送速度の最大値は関係ないかなと。grandMA2/3 の能力を最大限利用するなら黙って光Etherを使って10Gbpsくらいの帯域確保でしょうけどね。
ひょっとするとMoCAの方がいいのかな？って感じもするのですが、EoCの方が製品単価が控えめで動作が安定している感じがあります。
#[Art-Net]
「Ether over COAX」には「MoCA」と呼ばれる規格もあります。最大ケーブル長は短いですが、n対n接続(同一経路上に複数を設置)が可能です。EoCは1対1に限ります。
大きな違いはEoCが75Ω同軸ケーブルを用いるの対し、MoCAは50Ω同軸ケーブルを用います。どちらも既設の同軸ケーブルを活用してLANを構成することが目的ですが、片や映像ケーブル、片やアンテナケーブルです。
EoCはビルや大規模施設の監視カメラを更新するために作られたようです。今となってはwebカメラが便利で安価ですが、ケーブルを換える費用の方が高くつくので、なんなら既にある同軸ケーブルにEthernetを通してしまえって発想みたいです。
MoCAは、特にアメリカらしいですが、部屋ごとにテレビを置くことが当たり前ですとどの部屋にもアンテナ線が来ています。もちろんテレビ信号と同居出来ることが条件とはなりますが、これも既にある同軸ケーブルを利用してしまえってことみたいです。
そもそも、Ethernetは無線通信でコンピュータ同士を繋げることから始まっているので10Base2といった同軸ケーブルを使う規格もあったワケです。これをアップグレードしたと思えば自然です。変調帯域が違えば混合使用も普通のことです。
EoCは100Mbps、MoCAは400Mbpsと違いますが、数ユニバースの Art-Net を通すなら100Mbpsあれば十分なので転送速度の最大値は関係ないかなと。grandMA2/3 の能力を最大限利用するなら黙って光Etherを使って10Gbpsくらいの帯域確保でしょうけどね。
ひょっとするとMoCAの方がいいのかな？って感じもするのですが、EoCの方が製品単価が控えめで動作が安定している感じがあります。
#[Art-Net]
PoE の Hub で「LINOVISION 同軸LANコンバーター」が動きました。
これなら「コンソール・パック」や「ステージ・パック」を作って良さそうです。
仕様を決めていきましょう。
#[Art-Net]
これなら「コンソール・パック」や「ステージ・パック」を作って良さそうです。
仕様を決めていきましょう。
#[Art-Net]
中華電機の Art-Net node を EoC で接続してみました。
EoC とは「Ethernet over COAX」の略で、Ethernet を同軸ケーブルに通す手法です。75Ωの映像ケーブルに通せます。
卓 → <EtherCable> → EoC → <75Ω同軸ケーブル> → EoC → <EtherCable> → node です。
EoC の機器は「LINOVISION 同軸LANコンバーター」を使っています。
電源供給は PoEです。Receiver に PoE で電源を供給すると Transmitter 側の電源は同軸ケーブルで供給されます。
Receiver と Transmitter の違いはどちらが電源の入力かってだけで Ethernet はごく普通に双方向です。
今のところは PoEインジェクターを使っていますが、PoE の Ethernet-Hub も試してみるつもりです。
#[Art-Net]
EoC とは「Ethernet over COAX」の略で、Ethernet を同軸ケーブルに通す手法です。75Ωの映像ケーブルに通せます。
卓 → <EtherCable> → EoC → <75Ω同軸ケーブル> → EoC → <EtherCable> → node です。
EoC の機器は「LINOVISION 同軸LANコンバーター」を使っています。
電源供給は PoEです。Receiver に PoE で電源を供給すると Transmitter 側の電源は同軸ケーブルで供給されます。
Receiver と Transmitter の違いはどちらが電源の入力かってだけで Ethernet はごく普通に双方向です。
今のところは PoEインジェクターを使っていますが、PoE の Ethernet-Hub も試してみるつもりです。
#[Art-Net]
研究用に中華電機から Art-Net の node を買ってみました。
タイムラグとかは実機を繋げて CUE として動かさないとわかりませんが、倉庫でのテストでは IN も OUT も極々当たり前に動きます。設定はPCからになりますが、設定アプリも素直で使いやすい。残念ながら5P仕様はありませんが、こんなんが15,000円くらいで買えてしまうのですから驚きです。同じメーカーと思わしき２ユニバースの物もあります。これは6,000円程度です。node を自作することも考えていますが、価格からすると買った方がいいですね。
ただ、中華製のこの手にはアイソレーターが入っていません。自作のスプリッター基板と共にパッケージすればいいのかな？
追記
5pin 仕様もありました。
DoctorMX で見ますと綺麗なデータが出ています。
#[Art-Net]
タイムラグとかは実機を繋げて CUE として動かさないとわかりませんが、倉庫でのテストでは IN も OUT も極々当たり前に動きます。設定はPCからになりますが、設定アプリも素直で使いやすい。
ただ、中華製のこの手にはアイソレーターが入っていません。自作のスプリッター基板と共にパッケージすればいいのかな？
追記
5pin 仕様もありました。
DoctorMX で見ますと綺麗なデータが出ています。
#[Art-Net]
現場ですが、簡単なひな壇を組むだけの現地道具なので終演までヒマです。
ArtNetPatch の ap_transmitter の構造を構造体配列を元に整理したのですが、割り切って構成したら案外軽い処理になりました。メモリの節約など考えず、条件分岐や計算を出来るだけ減らし繰り返しをヒトまとめにする方針だからでしょうか。
実際に組んで実行時間を計測しなければなりませんが、パッチ処理の後にもディレイやプロファイルカーブの処理を入れられそうな予感がします。
receive(受信)、bind(入力ユニバースを内部Bus(ユニバース)にパッチ、ここで数値をマージしてHTPミキサーとします)、pre-delay、pre-profile-curve、patch、post-delay、post-profile-curve、transmit といった流れで考えています。
ついてはモジュール構成を少し変えます。
ap_transmitter の中の数値操作と Art-net の出力を分割します。
fps はともかく、すべてのユニバースを連続して送るのは避けた方がいいかなと思うので、ユニバース毎にインターバルを持たせるためです。
１）アプリの起動部とし、共有物を設定して以下のモジュールを呼ぶ「ap_main」
２）画面表示やユーザー操作を司る「ap_console」
３）Art-Netを受信する「ap_receiver」
４）受信値や設定値から出力値をまとめる「ap_effect」
５）Art-Net を出力する「ap_transmitter」
６）データのタイムアウト管理をする「ap_timeout」
今後はタイムラグを減らす工夫を考えてみましょう。
出力の目標は 30fps 以上、出来れば 36fps ですが、1/36秒以内に処理を一巡出来るなら遅れても1フレームとなります。無理ならスレッド的なアプローチで考えて出来るだけ遅れを少なくしましょう。
何にしても、試作をして処理時間と処理負荷の計測が必要です。
こんな複雑なシステムは10回くらい書き直すつもりで試すしかありません。素人の私が結果を完全に予測するなんで無理ですもん。
#[Art-Net] #器具の製作 #Ｃ言語
ArtNetPatch の ap_transmitter の構造を構造体配列を元に整理したのですが、割り切って構成したら案外軽い処理になりました。メモリの節約など考えず、条件分岐や計算を出来るだけ減らし繰り返しをヒトまとめにする方針だからでしょうか。
実際に組んで実行時間を計測しなければなりませんが、パッチ処理の後にもディレイやプロファイルカーブの処理を入れられそうな予感がします。
receive(受信)、bind(入力ユニバースを内部Bus(ユニバース)にパッチ、ここで数値をマージしてHTPミキサーとします)、pre-delay、pre-profile-curve、patch、post-delay、post-profile-curve、transmit といった流れで考えています。
ついてはモジュール構成を少し変えます。
ap_transmitter の中の数値操作と Art-net の出力を分割します。
fps はともかく、すべてのユニバースを連続して送るのは避けた方がいいかなと思うので、ユニバース毎にインターバルを持たせるためです。
１）アプリの起動部とし、共有物を設定して以下のモジュールを呼ぶ「ap_main」
２）画面表示やユーザー操作を司る「ap_console」
３）Art-Netを受信する「ap_receiver」
４）受信値や設定値から出力値をまとめる「ap_effect」
５）Art-Net を出力する「ap_transmitter」
６）データのタイムアウト管理をする「ap_timeout」
今後はタイムラグを減らす工夫を考えてみましょう。
出力の目標は 30fps 以上、出来れば 36fps ですが、1/36秒以内に処理を一巡出来るなら遅れても1フレームとなります。無理ならスレッド的なアプローチで考えて出来るだけ遅れを少なくしましょう。
何にしても、試作をして処理時間と処理負荷の計測が必要です。
こんな複雑なシステムは10回くらい書き直すつもりで試すしかありません。素人の私が結果を完全に予測するなんで無理ですもん。
#[Art-Net] #器具の製作 #Ｃ言語
ArtNetPatch の構成イメージが見えてきました。
この後は「ap_transmitter」の具体化でしょうか。これが ArtNetPatch の核であり一番重い処理です。
モジュール間を繋ぐ構造体配列が見えればその他のモジュールを作ることは可能ですし、画面表示とか作って手ごたえを感じたいってのはありますが、最終的にデータを取りまとめる「ap_transmitter」が見えませんと構造体配列を決めることが出来ません。
#[Art-Net] #器具の製作
この後は「ap_transmitter」の具体化でしょうか。これが ArtNetPatch の核であり一番重い処理です。
モジュール間を繋ぐ構造体配列が見えればその他のモジュールを作ることは可能ですし、画面表示とか作って手ごたえを感じたいってのはありますが、最終的にデータを取りまとめる「ap_transmitter」が見えませんと構造体配列を決めることが出来ません。
#[Art-Net] #器具の製作
と、なると、って書き出しは私のアタマの中の言葉のままですが、プロセスかスレッドかはともかく、処理のスジを次の様に分けようかと。
１）アプリの起動部で、共有物を設定して以下のモジュールを呼ぶ「ap_main」
２）画面表示やユーザー操作を司る「ap_console」
３）Art-Netを受信する「ap_receiver」
４）受信値や設定値から出力値まとめ、Art-Net を出力する「ap_transmitter」
５）データのタイムアウト管理をする「ap_timeout」
大きなデータは共有メモリ「mmap」と「semaphore」でやりとりし、指示や返答は「queue」で繋げます。自分ナリに得手不得手を検討した結果です。
タイムアウトを別枠で勝手にやらせる発想が出たら役割分担が楽になりました。
これが出来るのも共有メモリとセマフォのオカゲです。
まだまだ決定ではありませんが、タイミングがラフなところはOS に任せてしまえ！って思えたら気が楽になったかも。
メモリ管理も処理タイミングの管理も OS に頼った方が間違いないのです。
この役割分担をしたら RaspberryPi でも処理しきれそうな気になってきたかも。
追記
成り行き任せで後回しにしても構わない処理はプロセスやスレッドを別にして区切りのいいところに短い「sleep」を入れればいい。こうすると OS のジャッジで急ぎと思われるプロセスやスレッドを優先的に処理をしてくれるようです。
厳密なタイミング管理が必要なら「RTOS」ベースのカーネルを使ってガチガチに管理するのが良いと思いますが、そこまででない処理のため導入の敷居が高い RTOS を使うのはどうかと。
#[Art-Net] #器具の製作
１）アプリの起動部で、共有物を設定して以下のモジュールを呼ぶ「ap_main」
２）画面表示やユーザー操作を司る「ap_console」
３）Art-Netを受信する「ap_receiver」
４）受信値や設定値から出力値まとめ、Art-Net を出力する「ap_transmitter」
５）データのタイムアウト管理をする「ap_timeout」
大きなデータは共有メモリ「mmap」と「semaphore」でやりとりし、指示や返答は「queue」で繋げます。自分ナリに得手不得手を検討した結果です。
タイムアウトを別枠で勝手にやらせる発想が出たら役割分担が楽になりました。
これが出来るのも共有メモリとセマフォのオカゲです。
まだまだ決定ではありませんが、タイミングがラフなところはOS に任せてしまえ！って思えたら気が楽になったかも。
メモリ管理も処理タイミングの管理も OS に頼った方が間違いないのです。
この役割分担をしたら RaspberryPi でも処理しきれそうな気になってきたかも。
追記
成り行き任せで後回しにしても構わない処理はプロセスやスレッドを別にして区切りのいいところに短い「sleep」を入れればいい。こうすると OS のジャッジで急ぎと思われるプロセスやスレッドを優先的に処理をしてくれるようです。
厳密なタイミング管理が必要なら「RTOS」ベースのカーネルを使ってガチガチに管理するのが良いと思いますが、そこまででない処理のため導入の敷居が高い RTOS を使うのはどうかと。
#[Art-Net] #器具の製作
Art-Net の処理についてタイミングをイロイロ検討してみました。
まず、全受信のスタックと受信の次の工程に送るスタックは完全に別物にした方が良さそうです。先日の書き込みと真逆のことですが、Art-Net 全体のモニターをするためのスタックとパッチの前工程のスタックは別物にするってことです。細かい理由は割愛しますが、同じ結果を得られるならメモリを大食いしても処理は軽い方がいい。DMXの処理で使うメモリ量など増えても数KBですから、GBクラスのメモリを持った RaspberryPi で気にするこっちゃありません。また、全受信のスタックを元にすべてを行うと最低でも２秒分の履歴を残さなければなりませんが、モニターするだけなら最新値のスタックだけで済みますし、Delay では深い履歴が必要でもパッチにおけるユニバース数だけあればいいので、想定される入力のすべてを数秒分スタックするほどのメモリは不要です。結果、処理が軽くなってメモリの使用量が減るなら御の字ってことです。あとは、タイムアウトの処理も大きな理由です。パケット毎に受信時刻のチェックをすることになりますが、チェックするパケットの数が減り、モニターならチェック頻度を落としてタイムアウトの実効値が２秒とか３秒でも大丈夫です。
データをどのように取り込んでスタックして処理するかのイメージを整理して処理時間や工数が最も少ないであろう構成を決めてからソースコードを書こうと思っています。
追記
上記の考え方にするなら、パッチの前工程の処理をする位置や共有メモリの扱いを明確にしておけばソースを書き始められるかも。完全に Art-Net モニタです。受信の後の各種処理や画面表示を別プロセスにするのでまだまだ考えることはありますけどね。
今思い付いたのですが、タイムアウトの処理を別プロセスや別スレッドにしたら受信プロセスが凄く簡単になるかも。socket の受信をタイムアウトせずに何かを受信するまでブロックするってことです。シングルプロセスの PIC マイコンに慣れ過ぎて手作業のマルチスレッド処理がアタマの中で前提になっているようです。ブロックすることが一般的な処理をあえてタイムアウトさせてエラー処理するくらいならプロセスを分けてタイムアウトさせずに待たせればいいのです。OSが得意な部分はOSにやってもらえばいいのです。
#[Art-Net] #器具の製作
まず、全受信のスタックと受信の次の工程に送るスタックは完全に別物にした方が良さそうです。先日の書き込みと真逆のことですが、Art-Net 全体のモニターをするためのスタックとパッチの前工程のスタックは別物にするってことです。細かい理由は割愛しますが、同じ結果を得られるならメモリを大食いしても処理は軽い方がいい。DMXの処理で使うメモリ量など増えても数KBですから、GBクラスのメモリを持った RaspberryPi で気にするこっちゃありません。また、全受信のスタックを元にすべてを行うと最低でも２秒分の履歴を残さなければなりませんが、モニターするだけなら最新値のスタックだけで済みますし、Delay では深い履歴が必要でもパッチにおけるユニバース数だけあればいいので、想定される入力のすべてを数秒分スタックするほどのメモリは不要です。結果、処理が軽くなってメモリの使用量が減るなら御の字ってことです。あとは、タイムアウトの処理も大きな理由です。パケット毎に受信時刻のチェックをすることになりますが、チェックするパケットの数が減り、モニターならチェック頻度を落としてタイムアウトの実効値が２秒とか３秒でも大丈夫です。
データをどのように取り込んでスタックして処理するかのイメージを整理して処理時間や工数が最も少ないであろう構成を決めてからソースコードを書こうと思っています。
追記
上記の考え方にするなら、パッチの前工程の処理をする位置や共有メモリの扱いを明確にしておけばソースを書き始められるかも。完全に Art-Net モニタです。受信の後の各種処理や画面表示を別プロセスにするのでまだまだ考えることはありますけどね。
今思い付いたのですが、タイムアウトの処理を別プロセスや別スレッドにしたら受信プロセスが凄く簡単になるかも。socket の受信をタイムアウトせずに何かを受信するまでブロックするってことです。シングルプロセスの PIC マイコンに慣れ過ぎて手作業のマルチスレッド処理がアタマの中で前提になっているようです。ブロックすることが一般的な処理をあえてタイムアウトさせてエラー処理するくらいならプロセスを分けてタイムアウトさせずに待たせればいいのです。OSが得意な部分はOSにやってもらえばいいのです。
#[Art-Net] #器具の製作
Art-Netの扱いにアイデアを一つ。
送信元を識別するにはIPv4アドレスがキーになると思います。運が悪くなければ送信元毎にユニークなハズです。これの扱い。
IPv4アドレスは4バイト長(32bit)で構成され、文字列で表しても7～15文字です。
これを一つの整数にまとめてしまうアイデアです。一般的にint型は4バイト長ですから、丸めてしまえばint型にしても情報は欠落しません。
こうすれば、4つの数字や7～15文字のテキストよりも扱いが簡単で軽くなると思うのです。IPアドレスとしての情報は別途残すとして、識別IDにこれを使うのです。
ユニバースも同じ考え方でいいでしょう。15bit長ですからshort型でも収まりますが、噂に聞くところではint型の方が処理が軽いらしいのでこの型にしておこうかなと。
この両者を合わせた8バイトのlong型もしくはLongLong型を併記しておいてもいいかもしれません。なぜこの様なことを考えるかと言いますと、複数のユニバースを保管する配列から特定のものを探し出す処理を軽くしたいからです。処理の方針にもよりますが、受信したものを一旦スタックして一定の時間間隔で取り出そうというのが今の考え方ですので、クエリに相当するインデックスを作るのは当然としてもキーワードが簡素なことは重要だと思うのです。一定の時間間隔で作れらたLoop配列ならばその並びが時間情報となりますので、Delay を求めても受信日時と現在日時を比較する必要がありません。
Art-Netのモニターも兼ねたいので、使う使わないはともかく、受信したデータを全て一時保管するつもりです。
かといってモニターのための保管とパッチのための保管を別々にするのは気に入らないので、受信をすべて保管してそこから必要なモノを取り出したいのです。
仮に、送信元８、それぞれ８ユニバースとするなら、最大44fpsとして１秒間に2,816件のスタックをしなければなりません。１パケット当たりのデータ長は540バイトくらいですから1.5MB/秒くらいです。2秒分のスタックをしても3MBです。動画の１フレーム当たりのデータ長は640x480の16bitカラーで1.8MBくらいですので55MB/秒です。動画に比べたらArt-Netの情報量は余裕っしょ。
#[Art-Net] #Ｃ言語
送信元を識別するにはIPv4アドレスがキーになると思います。運が悪くなければ送信元毎にユニークなハズです。これの扱い。
IPv4アドレスは4バイト長(32bit)で構成され、文字列で表しても7～15文字です。
これを一つの整数にまとめてしまうアイデアです。一般的にint型は4バイト長ですから、丸めてしまえばint型にしても情報は欠落しません。
こうすれば、4つの数字や7～15文字のテキストよりも扱いが簡単で軽くなると思うのです。IPアドレスとしての情報は別途残すとして、識別IDにこれを使うのです。
ユニバースも同じ考え方でいいでしょう。15bit長ですからshort型でも収まりますが、噂に聞くところではint型の方が処理が軽いらしいのでこの型にしておこうかなと。
この両者を合わせた8バイトのlong型もしくはLongLong型を併記しておいてもいいかもしれません。なぜこの様なことを考えるかと言いますと、複数のユニバースを保管する配列から特定のものを探し出す処理を軽くしたいからです。処理の方針にもよりますが、受信したものを一旦スタックして一定の時間間隔で取り出そうというのが今の考え方ですので、クエリに相当するインデックスを作るのは当然としてもキーワードが簡素なことは重要だと思うのです。一定の時間間隔で作れらたLoop配列ならばその並びが時間情報となりますので、Delay を求めても受信日時と現在日時を比較する必要がありません。
Art-Netのモニターも兼ねたいので、使う使わないはともかく、受信したデータを全て一時保管するつもりです。
かといってモニターのための保管とパッチのための保管を別々にするのは気に入らないので、受信をすべて保管してそこから必要なモノを取り出したいのです。
仮に、送信元８、それぞれ８ユニバースとするなら、最大44fpsとして１秒間に2,816件のスタックをしなければなりません。１パケット当たりのデータ長は540バイトくらいですから1.5MB/秒くらいです。2秒分のスタックをしても3MBです。動画の１フレーム当たりのデータ長は640x480の16bitカラーで1.8MBくらいですので55MB/秒です。動画に比べたらArt-Netの情報量は余裕っしょ。
#[Art-Net] #Ｃ言語