電装工芸日記
- 舞台照明機器の製作とか -
2022年3月 この範囲を時系列順で読む この範囲をファイルに出力する
実機を離れて考えを進めると抜けが見えてきます。
一つ前のオレメモはArt-Netを受信していないときの対策です。タイムアウトを設定しませんと延々と待つだけの無限ループになり、適切な終了すら出来なくなります。一定時間受信が無いならそれをユーザーに伝えることも大切な処理です。
その前の送信元が複数になった時の対策もそうです。ミキサー機能が無いと謳っても複数の接続をする人が居ないとも限りませんし、そんな人に限って勝手な想像通りに動かないと作った奴が悪いとかダメな製品だとかレッテルを貼ってくるものです。この件については副産物としてミキサー機能に至れそうな可能性が見えましたので「災い転じて何とやら」ですが、先入観を排除して可能性を熟慮することの大切さを改めて痛感です。
受信処理は試行錯誤しながらディレイを可能にしたことでソースコードが読みにくくなってきましたので、タイムアウトと複数の送信元への対応を加えながら読みやすく書き直しです。
パラメータが増えてくると変数の命名に配慮するだけでも読みやすさが違ってきますので、この辺りも含めてよく考えていきます。
ここまでやってきて、思った以上に受信処理が大切なことに驚いています。
ミキサーしかり、ディレイしかり、思い描いている機能の大半が受信直後の処理にかかっていたとは当初は全く思いもしませんでした。
この辺りは所詮アマチュアの所業でありますが、まだまだ修行です。
#Python #[Art-Net]
一つ前のオレメモはArt-Netを受信していないときの対策です。タイムアウトを設定しませんと延々と待つだけの無限ループになり、適切な終了すら出来なくなります。一定時間受信が無いならそれをユーザーに伝えることも大切な処理です。
その前の送信元が複数になった時の対策もそうです。ミキサー機能が無いと謳っても複数の接続をする人が居ないとも限りませんし、そんな人に限って勝手な想像通りに動かないと作った奴が悪いとかダメな製品だとかレッテルを貼ってくるものです。この件については副産物としてミキサー機能に至れそうな可能性が見えましたので「災い転じて何とやら」ですが、先入観を排除して可能性を熟慮することの大切さを改めて痛感です。
受信処理は試行錯誤しながらディレイを可能にしたことでソースコードが読みにくくなってきましたので、タイムアウトと複数の送信元への対応を加えながら読みやすく書き直しです。
パラメータが増えてくると変数の命名に配慮するだけでも読みやすさが違ってきますので、この辺りも含めてよく考えていきます。
ここまでやってきて、思った以上に受信処理が大切なことに驚いています。
ミキサーしかり、ディレイしかり、思い描いている機能の大半が受信直後の処理にかかっていたとは当初は全く思いもしませんでした。
この辺りは所詮アマチュアの所業でありますが、まだまだ修行です。
#Python #[Art-Net]
オレメモ
Pythonのsocket.recvfromでタイムアウト処理をする。
socketのインスタンスをsockとした場合、sock.recvfromの前に
sock.settimeout(<タイムアウトの秒数>)
とする。
sock.recvfrom(<バッファ数>) を try: で実行し、except socket.timeout: でタイムアウトエラーを拾う。
#Python
Pythonのsocket.recvfromでタイムアウト処理をする。
socketのインスタンスをsockとした場合、sock.recvfromの前に
sock.settimeout(<タイムアウトの秒数>)
とする。
sock.recvfrom(<バッファ数>) を try: で実行し、except socket.timeout: でタイムアウトエラーを拾う。
#Python
本日は久しぶりの現地照明。現場って感じでホッとします。
実機での研究や試験は出来ませんが、アイデアが出てきたら整理しています。今日出てきたアイデアはArt-Netの受信に関するものです。
Art-Netは複数の送信機を同じネットワークに接続することが出来ます。正しくはないけど間違ってもいない使い方ですが、期待してない挙動が起こっても面白くないので対応しといた方が良さそう。
socketによる受信からはデータと送信元アドレスを取り出せますから、送信元アドレスをキーにデータを仕分けます。採用するデータは送信元を一つに限るのが道理な気もしますが、同じユニバース・スロットの最大値を採用したらHTPのミキサーになってしまいます。
ミキサーは欲しい機能ですが、バカよけを施した副産物でミキサーになりそう。
#[Art-Net]
実機での研究や試験は出来ませんが、アイデアが出てきたら整理しています。今日出てきたアイデアはArt-Netの受信に関するものです。
Art-Netは複数の送信機を同じネットワークに接続することが出来ます。正しくはないけど間違ってもいない使い方ですが、期待してない挙動が起こっても面白くないので対応しといた方が良さそう。
socketによる受信からはデータと送信元アドレスを取り出せますから、送信元アドレスをキーにデータを仕分けます。採用するデータは送信元を一つに限るのが道理な気もしますが、同じユニバース・スロットの最大値を採用したらHTPのミキサーになってしまいます。
ミキサーは欲しい機能ですが、バカよけを施した副産物でミキサーになりそう。
#[Art-Net]
レガシーDMX512の出力インターフェースを作るには少し工夫が必要です。
RaspberryPiでもPICでも使えるインターフェースで十分な速度を持つのはSPIです。I2Cは便利ですがPICが最大400kbpsなので１ユニバースしか扱えません。
かといって、高速のSPIで複数のPICで扱うのはかなり難しい。解決するにはロジックICを用いた分岐回路を用いるのが良さそうですが、ICが5個くらい必要なので実装面積に問題があります。
ならばGALを使うのはどうかと。FPGAやCPLDの祖先であり、今回の構成に丁度良いスペックです。何と言っても安い。
ただし、GALはすでに過去の物で開発は終わっています。決して多くないニーズに応えて生産されているだけですし、開発ソフトウェアも正規対応がWindowsXP止まり。
されど、１０個未満のTTL-ICで組む様な事を１個で組めるのは便利ですし、数十MHzまで対応するので、RaspberryPiなどのLinux系小型マイコンの外付け回路を組むには丁度良いと思います。
便利そうですが微妙なので導入を控えていましたが、改めて調べたところ書き込み装置などの開発用品が安くなっていたので、この際環境を整えてみましょう。
RaspberryPiとPICとGALを組み合わせれば製品が作りやすくなるような気がします。
#電子工作
RaspberryPiでもPICでも使えるインターフェースで十分な速度を持つのはSPIです。I2Cは便利ですがPICが最大400kbpsなので１ユニバースしか扱えません。
かといって、高速のSPIで複数のPICで扱うのはかなり難しい。解決するにはロジックICを用いた分岐回路を用いるのが良さそうですが、ICが5個くらい必要なので実装面積に問題があります。
ならばGALを使うのはどうかと。FPGAやCPLDの祖先であり、今回の構成に丁度良いスペックです。何と言っても安い。
ただし、GALはすでに過去の物で開発は終わっています。決して多くないニーズに応えて生産されているだけですし、開発ソフトウェアも正規対応がWindowsXP止まり。
されど、１０個未満のTTL-ICで組む様な事を１個で組めるのは便利ですし、数十MHzまで対応するので、RaspberryPiなどのLinux系小型マイコンの外付け回路を組むには丁度良いと思います。
便利そうですが微妙なので導入を控えていましたが、改めて調べたところ書き込み装置などの開発用品が安くなっていたので、この際環境を整えてみましょう。
RaspberryPiとPICとGALを組み合わせれば製品が作りやすくなるような気がします。
#電子工作
Art-Netは受信したデータのスタックの仕方を変えてうまくいきました。
約1/100秒毎でスタックし、1/40秒毎で出力しています。
試験的な処理ですが、Delayもユニバース単位で綺麗に動きます。
Art-Netの送受信の試験製作はこれにて終了。
ただ、テストで使っていた中華電器のArt-Netデコーダが不良品でした。
8アウトの製品ですが、普通に使うとDMXポートが１つしか信号を出さない。
組み合わせを吟味すると半分の４ポートは出力されますが、マニュアル通りに使って正しく動かないのでは現場じゃ使えません。
届いた時にMAdot2でテストしてちゃんと動いたような気がするのですが・・・
Art-Netのデコーダは市販品もありますが、RaspberryPiでここまで出来てしまうと自作した方が圧倒的に安い。市販品の国内価格は7-8万円ですが、材料費だけなら2万もしません。
レガシーDMXのインターフェースは基板から自作になりますが、PICマイコンでSPIからDMXにプロトコル変換するだけなのでそれほど難しくないハズ。パッチマシンとしてまとめる際には必要ですから作ってしまいましょう。
#RaspberryPi #[Art-Net]
約1/100秒毎でスタックし、1/40秒毎で出力しています。
試験的な処理ですが、Delayもユニバース単位で綺麗に動きます。
Art-Netの送受信の試験製作はこれにて終了。
ただ、テストで使っていた中華電器のArt-Netデコーダが不良品でした。
8アウトの製品ですが、普通に使うとDMXポートが１つしか信号を出さない。
組み合わせを吟味すると半分の４ポートは出力されますが、マニュアル通りに使って正しく動かないのでは現場じゃ使えません。
届いた時にMAdot2でテストしてちゃんと動いたような気がするのですが・・・
Art-Netのデコーダは市販品もありますが、RaspberryPiでここまで出来てしまうと自作した方が圧倒的に安い。市販品の国内価格は7-8万円ですが、材料費だけなら2万もしません。
レガシーDMXのインターフェースは基板から自作になりますが、PICマイコンでSPIからDMXにプロトコル変換するだけなのでそれほど難しくないハズ。パッチマシンとしてまとめる際には必要ですから作ってしまいましょう。
#RaspberryPi #[Art-Net]
客席テーブルのポリエステル樹脂は大丈夫でしょう。
先日「爪で掻くと薄い線が付く」と書きましたが、ポリエステル樹脂が削れるのではなく、爪が僅かに削れて痕が残るようです。
シリコンオフで拭くと取れますので、チョークで書いた様なものでしょうか。
#ガチ工作
先日「爪で掻くと薄い線が付く」と書きましたが、ポリエステル樹脂が削れるのではなく、爪が僅かに削れて痕が残るようです。
シリコンオフで拭くと取れますので、チョークで書いた様なものでしょうか。
#ガチ工作
Art-Netの入力の扱いについて考えを進めています。
受信の更新頻度に合わせた処理ではフリッカーが発生することが確定。送られてくる頻度が変化するために起こることですが、根本的に何か変えないと解決しません。
対策は、十分に早い頻度で入力をサンプリングし、内部処理を整えて値の変化を滑らかにすることです。
例えば、1/30秒の頻度から1/10秒の頻度を見たとき、更新が1/3回と見るのではなく、3回同じデータが送られているとみるべきなのです。
DMX512の規格を読み解くと更新頻度は1秒～1/44秒の範囲になりますが、更新頻度の違いによるフリッカーを防止するには1/44秒よりも短い頻度でサンプリングすることが肝のようです。
短ければ短いほど安定すると思われますが、実際に作って落としどころを見つけましょう。
#[Art-Net]
受信の更新頻度に合わせた処理ではフリッカーが発生することが確定。送られてくる頻度が変化するために起こることですが、根本的に何か変えないと解決しません。
対策は、十分に早い頻度で入力をサンプリングし、内部処理を整えて値の変化を滑らかにすることです。
例えば、1/30秒の頻度から1/10秒の頻度を見たとき、更新が1/3回と見るのではなく、3回同じデータが送られているとみるべきなのです。
DMX512の規格を読み解くと更新頻度は1秒～1/44秒の範囲になりますが、更新頻度の違いによるフリッカーを防止するには1/44秒よりも短い頻度でサンプリングすることが肝のようです。
短ければ短いほど安定すると思われますが、実際に作って落としどころを見つけましょう。
#[Art-Net]
客席テーブルに塗布したポリエステル樹脂はよさげです。
YAMAHAのPC2002を１台と7.5kgの砂袋を２個乗せて丸１日様子をみましたが、ラックケースのゴム足の汚れが移るくらいで変化はありません。汚れは雑巾で拭けば落ちます。
爪で掻くと薄い線が付きますので鉄板やデコラ板より柔らかいのですが、ラッカーなどの１液式塗料に比べたら圧倒的に丈夫です。ポリエステル樹脂は造形に使う物で、塗料は装飾性を上げたり風化を抑える物ですから機械強度が違って当然ですけど。
あとは、ボールロックピンの紛失防止ワイヤーの固定と脚を収納する受けの塗装です。
脚は塗装をし直したい感じもあります。溶接によって寸法が狂ったところがあるのですが、補正をすると塗料が剥げるので、どうせなら防錆(「必殺錆封じ」という防錆剤の塗布)からやり直したいかも。
ちょいと忙しくなってきた本業を片付けつつ最終仕上げまでやってしまいたい。
#ガチ工作
YAMAHAのPC2002を１台と7.5kgの砂袋を２個乗せて丸１日様子をみましたが、ラックケースのゴム足の汚れが移るくらいで変化はありません。汚れは雑巾で拭けば落ちます。
爪で掻くと薄い線が付きますので鉄板やデコラ板より柔らかいのですが、ラッカーなどの１液式塗料に比べたら圧倒的に丈夫です。ポリエステル樹脂は造形に使う物で、塗料は装飾性を上げたり風化を抑える物ですから機械強度が違って当然ですけど。
あとは、ボールロックピンの紛失防止ワイヤーの固定と脚を収納する受けの塗装です。
脚は塗装をし直したい感じもあります。溶接によって寸法が狂ったところがあるのですが、補正をすると塗料が剥げるので、どうせなら防錆(「必殺錆封じ」という防錆剤の塗布)からやり直したいかも。
ちょいと忙しくなってきた本業を片付けつつ最終仕上げまでやってしまいたい。
#ガチ工作
ユニバース単位の試験的な物ですがDelayが出来ました。精度はともかく遅れます。
ただ、卓の更新頻度による問題発生。
MAdot2は値が変化しているときの更新頻度が1/30秒くらいですが、値の変化が無いときの更新頻度は1/10秒くらいです。卓としては間違っていない動作ですが、この違いのためにカットチェンジとフェードチェンジではDelayタイムが見た目で違ってしまいます。1/30なら0.033秒、1/10なら0.1秒の潜在的な遅れが処理のキータイムになってしまうからです。
こうなると入力を遅らせるのではなく出力を遅らせないといけないのかな？スロット単位にDelayをかけたいけど出力側のユニバース単位が現実的かなぁ～。
・・・考えを進めてみました。
今は受信のタイミングでデータをスタックしていますが、一定時間でスタックをしたらどうか。
DMX512は最大1/44秒毎くらいですが、1/100秒毎くらいで最後に受信したデータをスタックしていくのです。タイミングとピッチが違う情報をサンプリングの頻度を上げることで整えて滑らかにします。また、スタックの時間間隔が一定なら日時情報をスタックせずに済みますし、ソート並みに重い近似値抽出も不要です。
スタックが多くなっても処理全体が軽くなるならアリかも。
#Python #[Art-Net]
ただ、卓の更新頻度による問題発生。
MAdot2は値が変化しているときの更新頻度が1/30秒くらいですが、値の変化が無いときの更新頻度は1/10秒くらいです。卓としては間違っていない動作ですが、この違いのためにカットチェンジとフェードチェンジではDelayタイムが見た目で違ってしまいます。1/30なら0.033秒、1/10なら0.1秒の潜在的な遅れが処理のキータイムになってしまうからです。
こうなると入力を遅らせるのではなく出力を遅らせないといけないのかな？スロット単位にDelayをかけたいけど出力側のユニバース単位が現実的かなぁ～。
・・・考えを進めてみました。
今は受信のタイミングでデータをスタックしていますが、一定時間でスタックをしたらどうか。
DMX512は最大1/44秒毎くらいですが、1/100秒毎くらいで最後に受信したデータをスタックしていくのです。タイミングとピッチが違う情報をサンプリングの頻度を上げることで整えて滑らかにします。また、スタックの時間間隔が一定なら日時情報をスタックせずに済みますし、ソート並みに重い近似値抽出も不要です。
スタックが多くなっても処理全体が軽くなるならアリかも。
#Python #[Art-Net]
客席テーブルは天板に塗布したポリエステル樹脂の強度・耐久試験をしています。
音響のアンプが入ったゴム足付きのラックケースを載せているだけですが、以前の塗装では調光卓を2-3日載せたらゴム足の形に凹んでしまったので重要な試験です。
今のところ、半日経過しても凹む様子はありません。明日は重量を増やしてみましょう。3-4日そのままにして大丈夫ならＯＫとします。
全体の結論が出るまで加工や塗装が出来なかった部分の仕上げは残っていますが、軽量化を図りつつあと2-3台作りたいです。
#ガチ工作
音響のアンプが入ったゴム足付きのラックケースを載せているだけですが、以前の塗装では調光卓を2-3日載せたらゴム足の形に凹んでしまったので重要な試験です。
今のところ、半日経過しても凹む様子はありません。明日は重量を増やしてみましょう。3-4日そのままにして大丈夫ならＯＫとします。
全体の結論が出るまで加工や塗装が出来なかった部分の仕上げは残っていますが、軽量化を図りつつあと2-3台作りたいです。
#ガチ工作
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