電装工芸日記
- 舞台照明機器の製作とか -
全年全月8日の投稿［43件］
2026年2月 この範囲を時系列順で読む この範囲をファイルに出力する
昨日の午後から自宅のネット回線が不通。
支払いが滞っていたのかもと不安を感じつつ、プロバイダさんや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] #器具の製作
2025年11月 この範囲を時系列順で読む この範囲をファイルに出力する
穴空け治具を作ったのでPAR缶のお尻を加工してコネクターポートを取り付けてみました。
内部のケーブル取り回しを確認して寸法の調整はありますがイイ感じに見えます。
３穴はDMX5PのIN/THRUとTRUE1のINです。
#器具の製作
内部のケーブル取り回しを確認して寸法の調整はありますがイイ感じに見えます。
３穴はDMX5PのIN/THRUとTRUE1のINです。
#器具の製作
2025年9月 この範囲を時系列順で読む この範囲をファイルに出力する
３Ｄプリンタをポチリました。
QIDI-Q2 です。置き場所は届いてから考えることにしました。
逝ってしまったプリンタは QIDI 社製です。このメーカーにこだわっているワケではありませんが、サポートやツールの取得に不満を感じたことがないし他のメーカを評価する暇もないのでいいかなと。
このプリンタの面白いところは、専用のツールとフィラメントを使うとTシャツにプリントが出来ること。Tシャツに書けるなら他の布地にも書けそうなことが選んだ理由だったりして。
ポチったのはフルオプションの「Q2 Combo(Q2+QIDI BOX)」で10万弱。新発売特価とはいえ小遣いには辛い価格ですが、このところ本業用品を大量にプリントして所属会社に費用を請求しましたので自腹は少しで済んでます。ボれるところからはボれというのが口癖の社長からボるのは当然(笑
#３Ｄプリンタ
QIDI-Q2 です。置き場所は届いてから考えることにしました。
逝ってしまったプリンタは QIDI 社製です。このメーカーにこだわっているワケではありませんが、サポートやツールの取得に不満を感じたことがないし他のメーカを評価する暇もないのでいいかなと。
このプリンタの面白いところは、専用のツールとフィラメントを使うとTシャツにプリントが出来ること。Tシャツに書けるなら他の布地にも書けそうなことが選んだ理由だったりして。
ポチったのはフルオプションの「Q2 Combo(Q2+QIDI BOX)」で10万弱。新発売特価とはいえ小遣いには辛い価格ですが、このところ本業用品を大量にプリントして所属会社に費用を請求しましたので自腹は少しで済んでます。ボれるところからはボれというのが口癖の社長からボるのは当然(笑
#３Ｄプリンタ
LED-PAR の筐体にアングルを入れてネジ穴を空けました。
強度は十分過ぎです。加工は粗いですが、接着剤が硬化したらつや消し黒で塗装しますし、マジマジと見るモノでもありませんのでこんなところかなと。
重要なのは防水です。塗装まで終わったら中身を入れる前に仮組みしてバケツにドボンして漏水チェックです。水が漏れるなら廃棄です。
追記
生乾きですが、塗装したので１枚。
キレイではないけど、こんなもんでしょ。
数日放置して漏水チェックです。
作業は実質３時間くらい。
こんな故障が頻繁にあったら困りますが、機能を回復できるならアリでしょう。
とりあえず、アルミ材はキープしておきます。
#器具の修理
強度は十分過ぎです。加工は粗いですが、接着剤が硬化したらつや消し黒で塗装しますし、マジマジと見るモノでもありませんのでこんなところかなと。
重要なのは防水です。塗装まで終わったら中身を入れる前に仮組みしてバケツにドボンして漏水チェックです。水が漏れるなら廃棄です。
追記
生乾きですが、塗装したので１枚。
キレイではないけど、こんなもんでしょ。
数日放置して漏水チェックです。
作業は実質３時間くらい。
こんな故障が頻繁にあったら困りますが、機能を回復できるならアリでしょう。
とりあえず、アルミ材はキープしておきます。
#器具の修理
３Ｄプリンタが逝きました。
最も重要な抽出機が完全に目詰まりしてどうにもなりません。10年以上前の機種なので部品が手に入りませんが、ここ数か月間昼夜を問わず働いていたので寿命と諦めましょう。
ちょうど多色刷りが出来る後継機種が発売されたので購入を検討します。まさか壊れたプリンタより高性能でしょうけど、置き場所を確保できるかが検討課題です。
取り急ぎのプリントは終わっているのでジックリ考えましょう。
#３Dプリンタ
最も重要な抽出機が完全に目詰まりしてどうにもなりません。10年以上前の機種なので部品が手に入りませんが、ここ数か月間昼夜を問わず働いていたので寿命と諦めましょう。
ちょうど多色刷りが出来る後継機種が発売されたので購入を検討します。まさか壊れたプリンタより高性能でしょうけど、置き場所を確保できるかが検討課題です。
取り急ぎのプリントは終わっているのでジックリ考えましょう。
#３Dプリンタ
2025年8月 この範囲を時系列順で読む この範囲をファイルに出力する
3Dプリンタの消耗品。
主な物は「フィラメント」「ノズル」「ヒートベッドシート」の３つです。
フィラメントにはポリメーカーのABSを使っています。ABSはPLAに比べ加工条件を出すのが難しいのですが、機械強度が良く保管温度も高いので愛用しています。安物ですと冷めてからの収縮が大きいのですが、ポリメーカーのABSは比較的縮みません。
ノズルは中華電機で買っていますが互換品をその都度選んでいます。中華電機は同じ商品が１年後にも買えることは少ないのでブックマークしておいても意味がありません。それ程高い物ではないので見つけたらまとめ買いしています。
ヒートベッドシートはEnderの物を使っています。サイズが少し大きいのでカッターで切っています。貼り付きが強すぎてプリント物を剥がすのに難儀することがありますが、足が浮いて変形するよりはマシです。
３Ｄプリンタの仕上がりは、消耗品の組み合わせとプリンタの調整で大きく違います。
前提、CADで描いた通りにはプリントされません。間違っても金型射出成型の様なキレイな仕上がりにはなりません。根気強く条件出しをすることと、プリントし易いデザイン・設計を心がけることなどが必要です。
#３Ｄプリンタ
主な物は「フィラメント」「ノズル」「ヒートベッドシート」の３つです。
フィラメントにはポリメーカーのABSを使っています。ABSはPLAに比べ加工条件を出すのが難しいのですが、機械強度が良く保管温度も高いので愛用しています。安物ですと冷めてからの収縮が大きいのですが、ポリメーカーのABSは比較的縮みません。
ノズルは中華電機で買っていますが互換品をその都度選んでいます。中華電機は同じ商品が１年後にも買えることは少ないのでブックマークしておいても意味がありません。それ程高い物ではないので見つけたらまとめ買いしています。
ヒートベッドシートはEnderの物を使っています。サイズが少し大きいのでカッターで切っています。貼り付きが強すぎてプリント物を剥がすのに難儀することがありますが、足が浮いて変形するよりはマシです。
３Ｄプリンタの仕上がりは、消耗品の組み合わせとプリンタの調整で大きく違います。
前提、CADで描いた通りにはプリントされません。間違っても金型射出成型の様なキレイな仕上がりにはなりません。根気強く条件出しをすることと、プリントし易いデザイン・設計を心がけることなどが必要です。
#３Ｄプリンタ
2025年6月 この範囲を時系列順で読む この範囲をファイルに出力する
と、なると、って書き出しは私のアタマの中の言葉のままですが、プロセスかスレッドかはともかく、処理のスジを次の様に分けようかと。
１）アプリの起動部で、共有物を設定して以下のモジュールを呼ぶ「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 の扱いを送信元８、ユニバース各８、44fpsにしますと毎秒の最大受信パケット数は2,816です。１パケットあたり355usec以下で捌かないといけません。実用においてここまでの量になることは無いと思いますし、確認する環境を整えるのも現実的ではありませんが、一度は想定最大負荷をかけてみたいものです。
実作業を始められるのがいつになるかわかりませんが基本設計は進めます。アタマが空いてる時のヒマ潰しにはちょうどいいですし。
#器具の製作
実作業を始められるのがいつになるかわかりませんが基本設計は進めます。アタマが空いてる時のヒマ潰しにはちょうどいいですし。
#器具の製作