電装工芸日記
- 舞台照明機器の製作とか -
全年2月6日の投稿［5件］
2025年 この範囲を時系列順で読む この範囲をファイルに出力する
デスクワークの合間に Antari F1-FAZER の続きをやってます。
カタログを見直しますとリキッドの消費量は 8.5ml/min とあります。１時間あたりに換算しますと 510ml です。100%出力の設計値だと思いますが結構な量です。実用では１リットルボトル満タンで３時間以上使えたと思いますが、この状態を目指し維持すればいいのかな？
修理機の現状は３時間で 50～80ml です。カタログ値の 1/20～30 ですから煙が少ないのも当たり前です。
とはいうものの、つい数日前のツン状態では６時間で 10ml も吸いませんでした。比率としては改善しているのでヨシとしましょう。長時間の空焚きの効果は大きいようです。
今は煙の量ではなく溶液の消費量で評価しています。目視では光の加減と気分で評価が一定しないからです。
試行錯誤で行ったり来たりしていますが、当面は一日空焚き、翌日は脈打ち戻りが一番強い状態で溶液を吸わせることにします。本業もそれほどヒマではないので朝昼夕に様子を見る程度にしたいってのもあります。夜も実施すれば作業効率はいいのですが、半壊れの発熱器を無人放置は出来ません。
#器具の修理
カタログを見直しますとリキッドの消費量は 8.5ml/min とあります。１時間あたりに換算しますと 510ml です。100%出力の設計値だと思いますが結構な量です。実用では１リットルボトル満タンで３時間以上使えたと思いますが、この状態を目指し維持すればいいのかな？
修理機の現状は３時間で 50～80ml です。カタログ値の 1/20～30 ですから煙が少ないのも当たり前です。
とはいうものの、つい数日前のツン状態では６時間で 10ml も吸いませんでした。比率としては改善しているのでヨシとしましょう。長時間の空焚きの効果は大きいようです。
今は煙の量ではなく溶液の消費量で評価しています。目視では光の加減と気分で評価が一定しないからです。
試行錯誤で行ったり来たりしていますが、当面は一日空焚き、翌日は脈打ち戻りが一番強い状態で溶液を吸わせることにします。本業もそれほどヒマではないので朝昼夕に様子を見る程度にしたいってのもあります。夜も実施すれば作業効率はいいのですが、半壊れの発熱器を無人放置は出来ません。
#器具の修理
Antari F1-FAZER のツンデレ具合いはナカナカのものです。今日はデレです。
昨日は丸一日空焚きを実施し、今日はエタノール３：フォグリキッド１の溶液を吸わせていますが、発煙量も溶液の吸い込み量も増えています。
ツンデレの原因は外れた焦げカスが再度詰まってしまうことだろうと思っていますが、このツンデレをいつまで相手にするか悩みどころです。もはや発火はしないだろうと思いますので、監視している必要がないならあと一か月くらい根気強く続けてみましょう。３歩進んで２歩下がっても進んではいるのですし。
先日も書いていますが、エタノールを使用するなら本体のポンプを使わず圧送ボトルを使います。本体のポンプにエタノールを長時間通すとたぶん壊れるからです。真似をされる方はくれぐれもご注意ください。
圧力は0.1～0.2MPaにしてます。脈打ち戻りが強く回数が多い状態に調整しています。
#器具の修理
昨日は丸一日空焚きを実施し、今日はエタノール３：フォグリキッド１の溶液を吸わせていますが、発煙量も溶液の吸い込み量も増えています。
ツンデレの原因は外れた焦げカスが再度詰まってしまうことだろうと思っていますが、このツンデレをいつまで相手にするか悩みどころです。もはや発火はしないだろうと思いますので、監視している必要がないならあと一か月くらい根気強く続けてみましょう。３歩進んで２歩下がっても進んではいるのですし。
先日も書いていますが、エタノールを使用するなら本体のポンプを使わず圧送ボトルを使います。本体のポンプにエタノールを長時間通すとたぶん壊れるからです。真似をされる方はくれぐれもご注意ください。
圧力は0.1～0.2MPaにしてます。脈打ち戻りが強く回数が多い状態に調整しています。
#器具の修理
2023年 この範囲を時系列順で読む この範囲をファイルに出力する
本業はちょいちょいで終わったのでArtNet-Engineを書き進めました。
ユニバースによる処理時間のムラはサンプルデータとして使っているMAdot2の仕様によるものみたいです。細かくは計測していませんが、８ユニバース出すとして、ユニバース毎に均等の時間割りで送信するのではなく、８ユニバースを一気に送信して長い休みを入れているようです。このため、最初のユニバースでは処理が重くなり、後のユニバースでは処理が軽くなる現象が起きるのだと思われます。主にArtNet-Engineからの送信に影響があったようで、受信したら即送信していたものを一時スタックしてからユニバース毎に均等の時間割りで送信する様にしたところムラが無くなりました。RaspberryPiの送信処理に何か負担がかかっていたのでしょう。
現時点での１フェーズの処理時間は平均して100usec以下です。出現確率が高い例外値が250usecくらいで、極マレに出てくる最大値が900usecくらいです。処理時間が保証されないOSですからこんなもん？。
作りたい物にはなりそうですが、８ユニバース８卓(６４ユニバース入力)は厳しい気がします。これに対応するには１フェーズが確実に350usec未満でなければなりませんが、例外値がやってきた時にプリフリーズを起こしそうです。登録できる調光卓(送信元)は８台ですが、同時に使える(HTPミックスの対象となる)のを３-４台くらいにしておけば現実的かもしれません。Art-Netの規格書に「マルチキャストは４０ユニバースが上限だと思いますよ」と書いてあるのは伊達じゃないようです。
どの要素が時間を使っているのか不明なので組んで実測しますかね。ダメなら減らすダケです。
ただ、構造体とポインタが使えるとこういったデータ処理は楽です。構造体はPythonのタプルに似ていますがシンプルなのでPythonより書きやすいかもしれません。ポインタは参照渡しですのでデータの扱いが速いのです。それ以前に何をするにも速いですけど。
追記
調整したところ、１ユニバース受信する１フェーズが平均30usec、例外値が200usec程度になりました。
同時に８卓使っても１本のArt-Netに統合する現場はマレだと思いますケド、間に合いそうな数値が出たので、その様に書いて後で調整します。増やすのは大変ですが減らすのは簡単ですから。
送信の間隔はユニバース数と希望fps数から自動計算にしました。将来的にfpsを設定して調整出来れば良いかなと。
#[Art-Net] #Ｃ言語
ユニバースによる処理時間のムラはサンプルデータとして使っているMAdot2の仕様によるものみたいです。細かくは計測していませんが、８ユニバース出すとして、ユニバース毎に均等の時間割りで送信するのではなく、８ユニバースを一気に送信して長い休みを入れているようです。このため、最初のユニバースでは処理が重くなり、後のユニバースでは処理が軽くなる現象が起きるのだと思われます。主にArtNet-Engineからの送信に影響があったようで、受信したら即送信していたものを一時スタックしてからユニバース毎に均等の時間割りで送信する様にしたところムラが無くなりました。RaspberryPiの送信処理に何か負担がかかっていたのでしょう。
現時点での１フェーズの処理時間は平均して100usec以下です。出現確率が高い例外値が250usecくらいで、極マレに出てくる最大値が900usecくらいです。処理時間が保証されないOSですからこんなもん？。
作りたい物にはなりそうですが、８ユニバース８卓(６４ユニバース入力)は厳しい気がします。これに対応するには１フェーズが確実に350usec未満でなければなりませんが、例外値がやってきた時にプリフリーズを起こしそうです。登録できる調光卓(送信元)は８台ですが、同時に使える(HTPミックスの対象となる)のを３-４台くらいにしておけば現実的かもしれません。Art-Netの規格書に「マルチキャストは４０ユニバースが上限だと思いますよ」と書いてあるのは伊達じゃないようです。
どの要素が時間を使っているのか不明なので組んで実測しますかね。ダメなら減らすダケです。
ただ、構造体とポインタが使えるとこういったデータ処理は楽です。構造体はPythonのタプルに似ていますがシンプルなのでPythonより書きやすいかもしれません。ポインタは参照渡しですのでデータの扱いが速いのです。それ以前に何をするにも速いですけど。
追記
調整したところ、１ユニバース受信する１フェーズが平均30usec、例外値が200usec程度になりました。
同時に８卓使っても１本のArt-Netに統合する現場はマレだと思いますケド、間に合いそうな数値が出たので、その様に書いて後で調整します。増やすのは大変ですが減らすのは簡単ですから。
送信の間隔はユニバース数と希望fps数から自動計算にしました。将来的にfpsを設定して調整出来れば良いかなと。
#[Art-Net] #Ｃ言語
本業もやらねばなりませんがArtNet-Engineも進めたい。
ArtNet-Engineの課題はデータ処理の構成です。
まずは入力です。同じネットワークに複数の調光卓を繋ぐことは出来ますが、ユニバースの重複によるトラブルには対策が必要です。
送信元IPアドレスで仕訳けることが基本になると思いますが、どうせなら選択しつつマージしてしまおうかと。
フェスなどでは複数の調光卓を設置して使い分けるのはよくあることです。単純な差し替えとかネットワーク切り替え機などを使ってもいいのですが、選択とマージ(HTPミックス)が出来たらそれはそれでいいかなと。バックアップ卓を併設することも出来るし。
内部的には８ユニバースのパッチを考えていますが卓も８台想定します。６４ユニバースの交通整理をするのでRaspberryPiの処理能力で間に合うのかわかりませんがダメなら数を減らします。
当面は送信元の仕分けと６４ユニバースを８ユニバースにマージする処理を書きます。
処理の構造をどうするか考えていますが、データの保存には構造体配列や構造体の中に構造体を入れるなど複雑な変数構成が必要になりそうです。
Pythonとは違い、for文が速いＣ言語なら繰り返しと条件分岐を織り交ぜた処理も書きやすそうです。Ｃ言語の習得の難所でもあるポインタもこういった処理では効果を発揮します。
#[Art-Net] #Ｃ言語
ArtNet-Engineの課題はデータ処理の構成です。
まずは入力です。同じネットワークに複数の調光卓を繋ぐことは出来ますが、ユニバースの重複によるトラブルには対策が必要です。
送信元IPアドレスで仕訳けることが基本になると思いますが、どうせなら選択しつつマージしてしまおうかと。
フェスなどでは複数の調光卓を設置して使い分けるのはよくあることです。単純な差し替えとかネットワーク切り替え機などを使ってもいいのですが、選択とマージ(HTPミックス)が出来たらそれはそれでいいかなと。バックアップ卓を併設することも出来るし。
内部的には８ユニバースのパッチを考えていますが卓も８台想定します。６４ユニバースの交通整理をするのでRaspberryPiの処理能力で間に合うのかわかりませんがダメなら数を減らします。
当面は送信元の仕分けと６４ユニバースを８ユニバースにマージする処理を書きます。
処理の構造をどうするか考えていますが、データの保存には構造体配列や構造体の中に構造体を入れるなど複雑な変数構成が必要になりそうです。
Pythonとは違い、for文が速いＣ言語なら繰り返しと条件分岐を織り交ぜた処理も書きやすそうです。Ｃ言語の習得の難所でもあるポインタもこういった処理では効果を発揮します。
#[Art-Net] #Ｃ言語
2022年 この範囲を時系列順で読む この範囲をファイルに出力する
ANSIエスケープシーケンスですが、RaspberryPi上のPythonでは期待する動画が出来ないかもしれません。形にはなるのですがチラつきます。
開発作業用と画面の試作を兼ねてDMXスロットの値を一覧表示する画面を作っています。値の表示は遅くとも0.1～0.2秒くらいで更新しなければなりませんが、前の表示が完了していないのに次の表示が実行されているような感じで、行単位での一瞬の点滅が不規則に発生します。
細かいことはともかく、これではダメです。
動画を表示出来るのですからテキスト画面の更新を0.1秒間隔でやるなど楽勝だろうと思っていたのですが、そもそもテキスト表示の書き換えにこんなレスポンスは不要だと作られているのかもしれません。
基本的な動作だけに余裕を持って動いてくれないと困ります。
RaspberryPiの作り的に、ANSIエスケープシーケンスでテキスト画面を構成するより、グラフィカルな画面に今どきの方法で表を書いた方がいいのかもしれません。
#RaspberryPi #Python
開発作業用と画面の試作を兼ねてDMXスロットの値を一覧表示する画面を作っています。値の表示は遅くとも0.1～0.2秒くらいで更新しなければなりませんが、前の表示が完了していないのに次の表示が実行されているような感じで、行単位での一瞬の点滅が不規則に発生します。
細かいことはともかく、これではダメです。
動画を表示出来るのですからテキスト画面の更新を0.1秒間隔でやるなど楽勝だろうと思っていたのですが、そもそもテキスト表示の書き換えにこんなレスポンスは不要だと作られているのかもしれません。
基本的な動作だけに余裕を持って動いてくれないと困ります。
RaspberryPiの作り的に、ANSIエスケープシーケンスでテキスト画面を構成するより、グラフィカルな画面に今どきの方法で表を書いた方がいいのかもしれません。
#RaspberryPi #Python