電装工芸日記
- 舞台照明機器の製作とか -
全年2月2日の投稿［3件］
2026年 この範囲を時系列順で読む この範囲をファイルに出力する
現場への移動が長かったので 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]
2023年 この範囲を時系列順で読む この範囲をファイルに出力する
Art-Netのデコード/エンコードも出来ました。受信した１配列のバイナリデータを分類して構造体に取り込むのがデコード、項目別の構造体から送信用のバイナリデータに変換するのがエンコードです。
実験は受信値をデコードして再エンコードして送信です。照明器具としては何の芸も無い状態ですが、これが出来なきゃ先へは進めません。
topコマンドで処理負荷を見ますと、ダンプ表示ありで23%、ダンプ表示無しで7%くらいです。Art-Netのコア処理は思った以上に軽いですが、画面表示が重いっすね。完成イメージの画面表示はもっと重くなりますので、Art-Netのコア処理は画面表示とは別プロセスにしたいですね。出来ることならArt-Netのコア処理でCPUスレッドを１つ占有したいくらいです。ここは余裕をもって確実にしたい処理ですから。
今のところ製作は順調です。３月末までに１日平均3-4時間程度使えますので、「ArtNet-Engine」と呼ぶコア機能はまとめられそうです。
#[Art-Net] #Ｃ言語
実験は受信値をデコードして再エンコードして送信です。照明器具としては何の芸も無い状態ですが、これが出来なきゃ先へは進めません。
topコマンドで処理負荷を見ますと、ダンプ表示ありで23%、ダンプ表示無しで7%くらいです。Art-Netのコア処理は思った以上に軽いですが、画面表示が重いっすね。完成イメージの画面表示はもっと重くなりますので、Art-Netのコア処理は画面表示とは別プロセスにしたいですね。出来ることならArt-Netのコア処理でCPUスレッドを１つ占有したいくらいです。ここは余裕をもって確実にしたい処理ですから。
今のところ製作は順調です。３月末までに１日平均3-4時間程度使えますので、「ArtNet-Engine」と呼ぶコア機能はまとめられそうです。
#[Art-Net] #Ｃ言語
2022年 この範囲を時系列順で読む この範囲をファイルに出力する
２つ目のNICも動作ＯＫと思われます。
将来的にwi-fiでも送信したいので出力側のNICをブリッジ接続にしました。ブリッジ接続とは複数のNICを束ね、内部からは１つの仮想デバイスとして扱う方法です。ハブを作る方法でもあります。
wi-fiはhostapdでルーター化してブリッジに組み入れることができます。試験的ではありますが、ウチのwi-fiルーターの１台はこの方法を用いてRaspberryPiで作ってあります。
Pythonのsocketの動作が実デバイスと仮想デバイスで違いがあるとは思えないけれど、最初から仮想デバイスでやっておけばいいかなと。
#[RaspberryPi]
将来的にwi-fiでも送信したいので出力側のNICをブリッジ接続にしました。ブリッジ接続とは複数のNICを束ね、内部からは１つの仮想デバイスとして扱う方法です。ハブを作る方法でもあります。
wi-fiはhostapdでルーター化してブリッジに組み入れることができます。試験的ではありますが、ウチのwi-fiルーターの１台はこの方法を用いてRaspberryPiで作ってあります。
Pythonのsocketの動作が実デバイスと仮想デバイスで違いがあるとは思えないけれど、最初から仮想デバイスでやっておけばいいかなと。
#[RaspberryPi]