電装工芸日記
- 舞台照明機器の製作とか -
2026年2月 この範囲を時系列順で読む この範囲をファイルに出力する
よかれと思って公開しても何かあったら補償しろと言われるのはイヤなのでGPLライセンスで公開しようと思います。手の内は全部見せるし自由に使ってもらっていいけどサポートも補償もしないよってことです。運よく出来上がってからの話ですが、コードを書き始める前に発生しうる責任問題の対策は考えておきたいのです。
そこで色々考えたのですが、コンテナのDockerを使おうかなと。ご存じ無い方に説明する語彙力は持ち合わせておりませんが、インストーラーではありませんがコマンド一発でインストールが出来る環境構築の母体です。公開するソースコードはもちろんライセンスの宣言なども入れておけるので「知らんがな」にも対応出来そうです。これらをGitHubで公開して履歴を残します。Dockerはとにかく便利です。もしシステムがおかしくなってもDockerのパッケージを入れ直すだけですべてが元に戻るからです。インストール説明書を作る手間も省けます。細かいことを知りたい方はAIさんに聞いてください。
課題があまりに多くなりすぎてどこから手をつけたモノか困っていますが、一つ一つ片づけていきましょう。
#ガチ工作 #[Art-Net] #器具の製作
そこで色々考えたのですが、コンテナのDockerを使おうかなと。ご存じ無い方に説明する語彙力は持ち合わせておりませんが、インストーラーではありませんがコマンド一発でインストールが出来る環境構築の母体です。公開するソースコードはもちろんライセンスの宣言なども入れておけるので「知らんがな」にも対応出来そうです。これらをGitHubで公開して履歴を残します。Dockerはとにかく便利です。もしシステムがおかしくなってもDockerのパッケージを入れ直すだけですべてが元に戻るからです。インストール説明書を作る手間も省けます。細かいことを知りたい方はAIさんに聞いてください。
課題があまりに多くなりすぎてどこから手をつけたモノか困っていますが、一つ一つ片づけていきましょう。
#ガチ工作 #[Art-Net] #器具の製作
猛烈に忙しかった一か月でしたが、落ち着いてきたのでＣ言語の勉強を再開しています。
データ蓄積の話です。変数と呼ばれる入れ子に数値を代入して一時保存するのが普通のやり方です。ですが、その実体はメモリに保存するに他なりません。
Ｃ言語は「高級アセンブリ言語」と呼ばれることもあり、派生の歴史はマシンコードが違うハードウェア間でソフトウェアの移植性を高めることにあったとか。AI/Geminiさんとやりとりをしてわかってきたことですが、Ｃ言語はソフトウェアを書きやすくするのとは少し違った方向性のようです。Pythonの様な言語に慣れてしまうと「どうしてこうなのか？」「不便だな」と思うことが多々ありますが、アセンブリ言語として捉えると「こりゃ便利だ」と思えます。この感覚はアセンブリ言語を書いたことがないとピンと来ないことかもれませんが、ハードウェアは何をしているのか、ＯＳは何をしているのか、コンパイラは何をしているか、この辺りをイメージ出来るとＣ言語の書式の意味が見えてくるように思います。
変数はメモリ領域を確保しインデックス(ステータス・メタ情報)を関連付けることで成立します。確保しただけのメモリ領域を「Raw」とも呼ぶそうですが、「Raw」のアドレスを示すのがポインタです。変数という作法(インデックス)を使って読み書きしてもいいのですが、ポインタというメモリアドレスで直接読み書きすることも出来るようです。私が知るアセンブリ言語はPIC16のそれしかありませんが、変数とはどういう機構なのか？を理解出来るとポインタのイメージをすんなり受け止められました。typedefも「オレ専用の型」作っておくClassみたいな作法だと思えば自然と理解。
ここまできたところ、構造体(Structure)と共用体(Union)の違いや使い方もすんなり理解。どちらもメモリ領域を確保してインデックスを関連付けることは同じですが、共用体は複数のインデックスを関連付けることが出来ることが違う。Art-NetでDMXのデータを扱うArtDMXパケットは受信した際は530バイトのバイナリですが、その何バイト目がどんな意味のデータかとなるので、同じデータ群であっても530バイトのバイト配列であったり構造体であったりするので、共用体として保存するが適当ぢゃないかと思ってきたところです。
mmapも意味や作法がイマイチわからなかったのですが、Ｃ言語の深堀り出来てきた気がしています。
#Ｃ言語
データ蓄積の話です。変数と呼ばれる入れ子に数値を代入して一時保存するのが普通のやり方です。ですが、その実体はメモリに保存するに他なりません。
Ｃ言語は「高級アセンブリ言語」と呼ばれることもあり、派生の歴史はマシンコードが違うハードウェア間でソフトウェアの移植性を高めることにあったとか。AI/Geminiさんとやりとりをしてわかってきたことですが、Ｃ言語はソフトウェアを書きやすくするのとは少し違った方向性のようです。Pythonの様な言語に慣れてしまうと「どうしてこうなのか？」「不便だな」と思うことが多々ありますが、アセンブリ言語として捉えると「こりゃ便利だ」と思えます。この感覚はアセンブリ言語を書いたことがないとピンと来ないことかもれませんが、ハードウェアは何をしているのか、ＯＳは何をしているのか、コンパイラは何をしているか、この辺りをイメージ出来るとＣ言語の書式の意味が見えてくるように思います。
変数はメモリ領域を確保しインデックス(ステータス・メタ情報)を関連付けることで成立します。確保しただけのメモリ領域を「Raw」とも呼ぶそうですが、「Raw」のアドレスを示すのがポインタです。変数という作法(インデックス)を使って読み書きしてもいいのですが、ポインタというメモリアドレスで直接読み書きすることも出来るようです。私が知るアセンブリ言語はPIC16のそれしかありませんが、変数とはどういう機構なのか？を理解出来るとポインタのイメージをすんなり受け止められました。typedefも「オレ専用の型」作っておくClassみたいな作法だと思えば自然と理解。
ここまできたところ、構造体(Structure)と共用体(Union)の違いや使い方もすんなり理解。どちらもメモリ領域を確保してインデックスを関連付けることは同じですが、共用体は複数のインデックスを関連付けることが出来ることが違う。Art-NetでDMXのデータを扱うArtDMXパケットは受信した際は530バイトのバイナリですが、その何バイト目がどんな意味のデータかとなるので、同じデータ群であっても530バイトのバイト配列であったり構造体であったりするので、共用体として保存するが適当ぢゃないかと思ってきたところです。
mmapも意味や作法がイマイチわからなかったのですが、Ｃ言語の深堀り出来てきた気がしています。
#Ｃ言語
昨日の午後から自宅のネット回線が不通。
支払いが滞っていたのかもと不安を感じつつ、プロバイダさんやNTTさんに連絡せにゃと思っていたのですが、いつの間にか復旧したみたい。
何が原因だったのかわかりませんが、ONUの光回線パイロットランプが消灯していましたので光回線がどこかで切れていたのでしょう。
まいいか。
#雑談
支払いが滞っていたのかもと不安を感じつつ、プロバイダさんやNTTさんに連絡せにゃと思っていたのですが、いつの間にか復旧したみたい。
何が原因だったのかわかりませんが、ONUの光回線パイロットランプが消灯していましたので光回線がどこかで切れていたのでしょう。
まいいか。
#雑談
Art-Net切替＆パッチマシンは AI/Gemini さんのご協力を得て基本構成が決まりつつあります。
Gemini さんからの情報は鵜吞みにせず自ら検証をするものだと思っていますが、ドキュメントやネット検索から自分でまとめるよりも結論に近い位置から始められていると思います。
基本方針ですが、本機は Art-Net の ArtDMX パケットを受信、加工、送信する装置です。通信スタイルはブロードキャストのみ。ArtDMX 以外のパケットは扱いません (特にRDMは方言が多くて扱いが難しく、ArtDMXだけでも調光操作に支障がないためです)。
ハードウェアの基本構成は次の通り。
１）主装置
RsaspbrryPi-CM4 + CM4-Dual-Eth-Base
２）ネットワーク
1000Base-T × ２ (Art-Net用・スイッチングハブで分岐)
WLAN (製作・メンテナンス用)
３）拡張基板
RaspberryPiのGPIOに搭載する専用基板。
設定保存用 EEPROM (24LC64など,I2C接続)、レガシーDMX受信回路 (LT1785等) + 取り込みマイコン (PIC16(RAM2kB以上),SPI接続)、RS232インターフェース回路 (UARTコンソール用)。
ソフトウェアの基本構成は次の通り。
１）受信モジュール
Art-Net 上の ArtDMX を受信してバッファに保存する。保存する際、検索用のインデックス(クエリ)も作成する。
２）加工モジュール
受信した値を加工する。パッチ、プロファイルカーブ、ディレイ等の処理はここで行う。
３）送信モジュール
加工モジュールから出力された値を送信する。
４）タイムアウト監視モジュール
送信元や受信パケットがタイムアウトしたら(存在しなくなったら)適切に処理する。
５）ユーザーインターフェース(UI)モジュール
画面表示やキーボード操作を司る。
上記(1)-(4)で用いる設定はここで起こす。
これらを /dev/shm 上に作る共有ファイルで結び付けて動作させます。
#ガチ工作 #[Art-Net] #器具の製作
Gemini さんからの情報は鵜吞みにせず自ら検証をするものだと思っていますが、ドキュメントやネット検索から自分でまとめるよりも結論に近い位置から始められていると思います。
基本方針ですが、本機は Art-Net の ArtDMX パケットを受信、加工、送信する装置です。通信スタイルはブロードキャストのみ。ArtDMX 以外のパケットは扱いません (特にRDMは方言が多くて扱いが難しく、ArtDMXだけでも調光操作に支障がないためです)。
ハードウェアの基本構成は次の通り。
１）主装置
RsaspbrryPi-CM4 + CM4-Dual-Eth-Base
２）ネットワーク
1000Base-T × ２ (Art-Net用・スイッチングハブで分岐)
WLAN (製作・メンテナンス用)
３）拡張基板
RaspberryPiのGPIOに搭載する専用基板。
設定保存用 EEPROM (24LC64など,I2C接続)、レガシーDMX受信回路 (LT1785等) + 取り込みマイコン (PIC16(RAM2kB以上),SPI接続)、RS232インターフェース回路 (UARTコンソール用)。
ソフトウェアの基本構成は次の通り。
１）受信モジュール
Art-Net 上の ArtDMX を受信してバッファに保存する。保存する際、検索用のインデックス(クエリ)も作成する。
２）加工モジュール
受信した値を加工する。パッチ、プロファイルカーブ、ディレイ等の処理はここで行う。
３）送信モジュール
加工モジュールから出力された値を送信する。
４）タイムアウト監視モジュール
送信元や受信パケットがタイムアウトしたら(存在しなくなったら)適切に処理する。
５）ユーザーインターフェース(UI)モジュール
画面表示やキーボード操作を司る。
上記(1)-(4)で用いる設定はここで起こす。
これらを /dev/shm 上に作る共有ファイルで結び付けて動作させます。
#ガチ工作 #[Art-Net] #器具の製作
今後、出来上がった物を公開する際はＧＰＬライセンスとします。
ＧＰＬライセンスとはソースコードや回路図を無償で公開するし使用や書き換えは自由だけれどサポートはしませんしバグがあってもトラブっても一切関知しませんってライセンスです。他にも色々ありますので詳細はその筋の情報をご覧ください。ものすごく簡単に言うなら著作権は放棄しないけど自己責任で自由に使ってくださいってのがＧＰＬライセンスです。日本国内の法的にも有効です。
カスタマーサポートはしたくないし、本業の日程によってはサポートは不可能だからです。これまで製品を販売したことはありますが、カスハラ対応は非生産的で無駄。よかれと思って安く提供しても勉強も努力もしない輩に荒らされるのは私に何のメリットもありません。ここしばらく何も販売していなかったのはここにあります。
今作っている Art-Net 切替＆パッチマシンは価値を感じてくれる人が少なからずいると思いますので広く提供する前提で考えていますが、商売として成立する価格にしたら高価になりそうですし、かといって同業者のよしみで安価にしたらサポートで私のメンタルが潰れます。そんならＧＰＬライセンスにしようってことです。話をわかってくれる知人には完成試作品を試してもらいますし、専用基板は「部品」として安価に販売しますけど。RaspberryPiをコマンドラインで使え、gccでコンパイル出来、PICマイコンのIDEが使えて書き込みが出来、専用基板の回路図を読める人には難しくない工作です。
自分が欲しい物を自分のために作るのが前提ですから、購買者は神だと勘違いしたアホのことなど知ったことではありません。こんな悪意と嫌味と皮肉を垂れ流すほどカスハラで嫌な思いをしたのですが、知識と技能を持った人なら組める情報と専用部品を提供するので勘弁してください。
まだ「絵に描いた餅」ですけど(笑
#ガチ工作 #[Art-Net] #器具の製作
ＧＰＬライセンスとはソースコードや回路図を無償で公開するし使用や書き換えは自由だけれどサポートはしませんしバグがあってもトラブっても一切関知しませんってライセンスです。他にも色々ありますので詳細はその筋の情報をご覧ください。ものすごく簡単に言うなら著作権は放棄しないけど自己責任で自由に使ってくださいってのがＧＰＬライセンスです。日本国内の法的にも有効です。
カスタマーサポートはしたくないし、本業の日程によってはサポートは不可能だからです。これまで製品を販売したことはありますが、カスハラ対応は非生産的で無駄。よかれと思って安く提供しても勉強も努力もしない輩に荒らされるのは私に何のメリットもありません。ここしばらく何も販売していなかったのはここにあります。
今作っている Art-Net 切替＆パッチマシンは価値を感じてくれる人が少なからずいると思いますので広く提供する前提で考えていますが、商売として成立する価格にしたら高価になりそうですし、かといって同業者のよしみで安価にしたらサポートで私のメンタルが潰れます。そんならＧＰＬライセンスにしようってことです。話をわかってくれる知人には完成試作品を試してもらいますし、専用基板は「部品」として安価に販売しますけど。RaspberryPiをコマンドラインで使え、gccでコンパイル出来、PICマイコンのIDEが使えて書き込みが出来、専用基板の回路図を読める人には難しくない工作です。
自分が欲しい物を自分のために作るのが前提ですから、購買者は神だと勘違いしたアホのことなど知ったことではありません。こんな悪意と嫌味と皮肉を垂れ流すほどカスハラで嫌な思いをしたのですが、知識と技能を持った人なら組める情報と専用部品を提供するので勘弁してください。
まだ「絵に描いた餅」ですけど(笑
#ガチ工作 #[Art-Net] #器具の製作
DMX の受信処理をするにあたって必要且つ面倒なのがタイムアウト。規格では１秒間更新が無ければ送信がされていないと判断します。
ユニバースが１つのレガシーDMXの装置なら監視するタイムスタンプは一つですからそれほどの負荷ではありませんが、ArtDMX を大量にバッファする機構ではどうするか。
アイデアですが、受信してバッファされている全ての ArtDMX は監視しません。最新値だけ評価すればいいのですからインデックスを覗きます。送信元のインデックスのタイムスタンプでタイムアウトを確認し、登録されている送信元なら無送信のフラグを立てユニバースのインデックスを消去し、登録されていない送信元ならぶら下がるユニバースのインエックスと共に消去します。この後、送信元のチェックで消去されていないユニバースのタイムアウトをチェックします。最後に送信元とユニバースのインデックスをソートします。
タイムアウトは例外処理の一種ですから、どのようなメッセージを出すか、スロットの一覧表示をしていた際にどのような挙動にするか、カレントの送信元としてバスにリレーしていた場合にどうするか、この辺りはあらかじめ決めておいた方がよさそうです。
#[Art-Net]
ユニバースが１つのレガシーDMXの装置なら監視するタイムスタンプは一つですからそれほどの負荷ではありませんが、ArtDMX を大量にバッファする機構ではどうするか。
アイデアですが、受信してバッファされている全ての ArtDMX は監視しません。最新値だけ評価すればいいのですからインデックスを覗きます。送信元のインデックスのタイムスタンプでタイムアウトを確認し、登録されている送信元なら無送信のフラグを立てユニバースのインデックスを消去し、登録されていない送信元ならぶら下がるユニバースのインエックスと共に消去します。この後、送信元のチェックで消去されていないユニバースのタイムアウトをチェックします。最後に送信元とユニバースのインデックスをソートします。
タイムアウトは例外処理の一種ですから、どのようなメッセージを出すか、スロットの一覧表示をしていた際にどのような挙動にするか、カレントの送信元としてバスにリレーしていた場合にどうするか、この辺りはあらかじめ決めておいた方がよさそうです。
#[Art-Net]
現場への移動が長かったので Art-Net 切替＆パッチマシンのアイデアを AI の Gemini さんに投げてみました。
受信は socket で行いますが、受信したデータ(バイナリ)、受信日時、送信元のIPアドレスとMACアドレス、ユニバース番号を mmap を使ったループバッファでとにかく保存します。約２秒分の最大数を構造体配列に保存します。コンソール８台、それぞれユニバース１６(使うのは８ですが、使いたいユニバースを取り溢したくないで多めに監視して１６とします)、２秒分ですから88フレーム、１フレームあたり600バイトくらいとするなら６MBくらいです。PICマイコンなら厳しいですが、RaspberryPi なら楽勝です。ただし、mmap を OS がスワップ領域に移動すると困るので mlock などでメモリに常駐させる設定は必要です。受信順に保存するだけでは後処理で探しにくいのでインテックスも作ります。送信元とそこにぶら下がるユニバースやデータを階層で表し、ループバッファから目的のデータを最短手順で取り出せるようにします。データベース Access のクエリやリレーショナルデータベースの１対ｎ関係などの参照構造を作っておくイメージです。受信データから送信元を、送信元から受信データを参照しやすくするのです。
あとは、受信、送信、エフェクト、表示、操作をプロセスやスレッドで分割するワケですが、これらはそれぞれ勝手に動作するようにします。どこかがどこかへ指示を送って返り値を得る構造ですとタイミングの管理が難しい。設定書を書き換えるだけでコール・アンド・レスポンスは使わないのです。装置はデータを加工しながら一方向に流す機構ですから、それをそのままに素直に形にすればいいのです。ユーザーは流れているデータを覗き見たり流れ方を変更しますが、覗くのは加工の邪魔をしない隙間で読み出すだけですし、設定書は書き換えて適切な場所に置いておけば加工する側が勝手に読むのでいいのです。mmap の読み書きは衝突の可能性がありますが flock をかければ事足りると思われます。
といったことを Gemini さんに投げたのですが「よいんでない？」とのこと。ただ、AI はユーザーを認めて誉める言葉が多い。「だっせーこと言ってんじゃねーよ」的な言葉があってもいいと思う。
#[Art-Net]
受信は socket で行いますが、受信したデータ(バイナリ)、受信日時、送信元のIPアドレスとMACアドレス、ユニバース番号を mmap を使ったループバッファでとにかく保存します。約２秒分の最大数を構造体配列に保存します。コンソール８台、それぞれユニバース１６(使うのは８ですが、使いたいユニバースを取り溢したくないで多めに監視して１６とします)、２秒分ですから88フレーム、１フレームあたり600バイトくらいとするなら６MBくらいです。PICマイコンなら厳しいですが、RaspberryPi なら楽勝です。ただし、mmap を OS がスワップ領域に移動すると困るので mlock などでメモリに常駐させる設定は必要です。受信順に保存するだけでは後処理で探しにくいのでインテックスも作ります。送信元とそこにぶら下がるユニバースやデータを階層で表し、ループバッファから目的のデータを最短手順で取り出せるようにします。データベース Access のクエリやリレーショナルデータベースの１対ｎ関係などの参照構造を作っておくイメージです。受信データから送信元を、送信元から受信データを参照しやすくするのです。
あとは、受信、送信、エフェクト、表示、操作をプロセスやスレッドで分割するワケですが、これらはそれぞれ勝手に動作するようにします。どこかがどこかへ指示を送って返り値を得る構造ですとタイミングの管理が難しい。設定書を書き換えるだけでコール・アンド・レスポンスは使わないのです。装置はデータを加工しながら一方向に流す機構ですから、それをそのままに素直に形にすればいいのです。ユーザーは流れているデータを覗き見たり流れ方を変更しますが、覗くのは加工の邪魔をしない隙間で読み出すだけですし、設定書は書き換えて適切な場所に置いておけば加工する側が勝手に読むのでいいのです。mmap の読み書きは衝突の可能性がありますが flock をかければ事足りると思われます。
といったことを Gemini さんに投げたのですが「よいんでない？」とのこと。ただ、AI はユーザーを認めて誉める言葉が多い。「だっせーこと言ってんじゃねーよ」的な言葉があってもいいと思う。
#[Art-Net]
2026年1月 この範囲を時系列順で読む この範囲をファイルに出力する
Art-Net 切替器もパッチも基本的に同じ物として考えています。
基本構成は受信部と送信部があり、間に値を加工するエフェクターを挟みます。
内部は８ユニバースとし、これらをバスと呼称します。
ミキサーというかマージは一番若いバスのみ一般照明向けとしてHTPで考えています。演出操作用ではなく小型サブ卓による作業灯や非常灯用と割り切り、レガシーDMXの入力を１本だけマージするかもしれません(エキストラマージ)。
受信部はIPアドレスやMACアドレスで送信元を選択し、Art-Net ユニバースをバスに渡します。切替器の実体はここです。
エフェクターとはバスの値を加工します。エキストラマージ、パッチ、プロファイルカーブ、ディレイなどはエフェクターとして扱います。ここで何もしなければ単なる切替器です。
送信部はバスの値を Art-Net で送信します。
RDM には対応しません。
複数のコンソールを設置する環境ならば切替器から見てフィクスチャー側に RDM コンソールを繋いだ方が良いと思うからです。
#[Art-Net]
基本構成は受信部と送信部があり、間に値を加工するエフェクターを挟みます。
内部は８ユニバースとし、これらをバスと呼称します。
ミキサーというかマージは一番若いバスのみ一般照明向けとしてHTPで考えています。演出操作用ではなく小型サブ卓による作業灯や非常灯用と割り切り、レガシーDMXの入力を１本だけマージするかもしれません(エキストラマージ)。
受信部はIPアドレスやMACアドレスで送信元を選択し、Art-Net ユニバースをバスに渡します。切替器の実体はここです。
エフェクターとはバスの値を加工します。エキストラマージ、パッチ、プロファイルカーブ、ディレイなどはエフェクターとして扱います。ここで何もしなければ単なる切替器です。
送信部はバスの値を Art-Net で送信します。
RDM には対応しません。
複数のコンソールを設置する環境ならば切替器から見てフィクスチャー側に RDM コンソールを繋いだ方が良いと思うからです。
#[Art-Net]
現場が早く終わって空き時間。とは言っても中途半端な時間なので Art-Net の算数を少々。
切替器やパッチマシンを作るとしてコンソールは何台まで接続可能なのか？です。
今時の EtherNet の通信スペックは 1Gbps が一般的ですが、ケーブルやハブなどに古い物を使ってしまうと 100Mbps になることもあるでしょうし wi-fi を使うと 20Mbpsくらいまで下がる可能性があります。仮に 20Mbps としてコンソールを何台使えるか考えてみます。
ArtDMXのパケットは530バイトです。EtherNetの諸々のデータが貼り付いても600バイトくらい見ておけばいいかな。
EhterNetは１バイト送るのに10ビット必要です。
DMX512の送信レートは最大で44fpsくらいです。
となると、１ユニバース送るのに１秒間に 264kbps くらいの通信速度が最低必要です。DMX512の 250kbps より少し多いですがこんなもんでしょう。
単純に 20Mbps を 264kpbs で割ると 75.757・・・です。Art-Net上に 75 ユニバース存在可能となります。各コンソールから８ユニバース送り出すならコンソールは９台まで不可能ではないとなります。
今のイメージはコンソール８台、合計 64ユニバースですから収まっています。
あとは RaspberryPi の処理能力が足りるかどうかです。
44fps/64ユニバースなら１パケットあたりに許される処理時間は 355usec(0.000355秒) です。以前試作した際は１パケットの処理に150から250usec程度かかっていましたので一応収まります。
先日 AI の Gemini さんとお話をしていたらCPUコアの割り当てや占有の方法がわかったのですが、上記の時間はOSの処理も含めて１つのCPUコアで処理しての値ですから、Art-Netで占有できるCPUコアを設定出来ればもう少し軽くなるかな？
主な処理を書いて１ユニバースあたりの処理時間を計測して最大コンソール数を決めることにしましょう。現実の現場ではバックアップを入れても仕込まれるコンソールは４台くらいでしょうから大丈夫な気はしています。
つか、８台並べてテストする環境を作るのが大変かな？〇ッシュシステムの〇山さんに相談ですね(笑
#[Art-Net]
切替器やパッチマシンを作るとしてコンソールは何台まで接続可能なのか？です。
今時の EtherNet の通信スペックは 1Gbps が一般的ですが、ケーブルやハブなどに古い物を使ってしまうと 100Mbps になることもあるでしょうし wi-fi を使うと 20Mbpsくらいまで下がる可能性があります。仮に 20Mbps としてコンソールを何台使えるか考えてみます。
ArtDMXのパケットは530バイトです。EtherNetの諸々のデータが貼り付いても600バイトくらい見ておけばいいかな。
EhterNetは１バイト送るのに10ビット必要です。
DMX512の送信レートは最大で44fpsくらいです。
となると、１ユニバース送るのに１秒間に 264kbps くらいの通信速度が最低必要です。DMX512の 250kbps より少し多いですがこんなもんでしょう。
単純に 20Mbps を 264kpbs で割ると 75.757・・・です。Art-Net上に 75 ユニバース存在可能となります。各コンソールから８ユニバース送り出すならコンソールは９台まで不可能ではないとなります。
今のイメージはコンソール８台、合計 64ユニバースですから収まっています。
あとは RaspberryPi の処理能力が足りるかどうかです。
44fps/64ユニバースなら１パケットあたりに許される処理時間は 355usec(0.000355秒) です。以前試作した際は１パケットの処理に150から250usec程度かかっていましたので一応収まります。
先日 AI の Gemini さんとお話をしていたらCPUコアの割り当てや占有の方法がわかったのですが、上記の時間はOSの処理も含めて１つのCPUコアで処理しての値ですから、Art-Netで占有できるCPUコアを設定出来ればもう少し軽くなるかな？
主な処理を書いて１ユニバースあたりの処理時間を計測して最大コンソール数を決めることにしましょう。現実の現場ではバックアップを入れても仕込まれるコンソールは４台くらいでしょうから大丈夫な気はしています。
つか、８台並べてテストする環境を作るのが大変かな？〇ッシュシステムの〇山さんに相談ですね(笑
#[Art-Net]
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131