電装工芸日記
- 舞台照明機器の製作とか -
時系列順［861件］（23ページ目）
2022年4月 この範囲を新しい順で読む この範囲をファイルに出力する
送信元をIPアドレスで選択する方法は簡単でした。丁寧に書いてきたおかげで左程の書き換えもせずに対応できそうです。
現在受信中の送信元一覧を得るためのプロセス間通信チャンネルを追加し、指定した送信元のデータだけを取り出す試験はものの数分で終わりました。
この後、一連の処理を関数化すれば完成です。
ただ、ライトアップのバラシに気力体力が奪われているので方向性が見えたところで終わりにします。丸一日、お日様を浴びながら立ったりかがんだりを延々繰り返していたので流石にシンドイ。集中力が落ちている時に書き進めるといいことはありません。
受信モジュールから取り出す際、それなりに大きな３次元配列からスロット毎の最大値を取り出す処理が不要になったので処理が少し軽くなりました。
送信元を選択式にするとバックアップ卓の切り替えに使えますし、フェスなどで複数の卓を切り替えて使う際にも使えます。パッチは一意で卓を切り替えて使えるとかなり便利だと思います。
#Python #[Art-Net]
現在受信中の送信元一覧を得るためのプロセス間通信チャンネルを追加し、指定した送信元のデータだけを取り出す試験はものの数分で終わりました。
この後、一連の処理を関数化すれば完成です。
ただ、ライトアップのバラシに気力体力が奪われているので方向性が見えたところで終わりにします。丸一日、お日様を浴びながら立ったりかがんだりを延々繰り返していたので流石にシンドイ。集中力が落ちている時に書き進めるといいことはありません。
受信モジュールから取り出す際、それなりに大きな３次元配列からスロット毎の最大値を取り出す処理が不要になったので処理が少し軽くなりました。
送信元を選択式にするとバックアップ卓の切り替えに使えますし、フェスなどで複数の卓を切り替えて使う際にも使えます。パッチは一意で卓を切り替えて使えるとかなり便利だと思います。
#Python #[Art-Net]
送信元をIPアドレスで選択する方法は完成。ライブラリの段階ですから、コマンドで現在受信中の送信元一覧を取得し、IPアドレスを送って設定する機能の追加です。最終的にはユーザーインターフェースからこれらのコマンドを使って指示します。
その他の訂正は、Delayのためのスタック順を逆にし、定数を出来るだけ外から設定するようにしました。
スタック順を逆にしたのは、Delay値で読み出す際の計算を簡単にするためです。スタックの際にポインタを加算で行うと読み出しでは減算になりますが、配列のインデックスを得る際に加算とmodを使うと配列を一括計算出来ますから、スタックの際のポインタ計算を減算にしました。なんのこと？ですけど・・・。
そんなこんな、基本機能の煮詰めをしていたら時間オーバー。
今日も今日とてライトアップのバラシをしてきた昭和産まれのオジサンは、これ以上頑張ると明日に差し障ります。
風呂して一杯飲んで寝る時間です。
基本機能は見るたびに直しや追加が出てなかなか終わりませんが、ここが肝なので、アタマが働く状態で取り組んで後で直しが出ないようにした方が良さそうです。
#Python #[Art-Net]
その他の訂正は、Delayのためのスタック順を逆にし、定数を出来るだけ外から設定するようにしました。
スタック順を逆にしたのは、Delay値で読み出す際の計算を簡単にするためです。スタックの際にポインタを加算で行うと読み出しでは減算になりますが、配列のインデックスを得る際に加算とmodを使うと配列を一括計算出来ますから、スタックの際のポインタ計算を減算にしました。なんのこと？ですけど・・・。
そんなこんな、基本機能の煮詰めをしていたら時間オーバー。
今日も今日とてライトアップのバラシをしてきた昭和産まれのオジサンは、これ以上頑張ると明日に差し障ります。
風呂して一杯飲んで寝る時間です。
基本機能は見るたびに直しや追加が出てなかなか終わりませんが、ここが肝なので、アタマが働く状態で取り組んで後で直しが出ないようにした方が良さそうです。
#Python #[Art-Net]
ライトアップのバラシで半日イントレに登っていたら気力の残量がゼロ。
今日は工作作業をオフです。
そういえば中国に頼んでいた基板が入荷。
とてもキレイです。こんな上物がこの数でこの価格？と素直に思えます。有難いを越えて商売になっているのか心配になるほどです。
リフローハンダで使おうと思って手配した工業用のホットプレートも入荷。
気力が残っていれば、次のオフでリフローハンダの実験をしたいなと。
リフローハンダが上手くいけば、随分前に試作だけしたTASCAM製プレイヤーのリモコンも作ろうかなと。
所属会社の音響君たち曰く、バックアッププレイヤーも同時制御出来ると心強いらしい。同じソースを入れておくのは言うまでもありませんが、RS232を２分配するだけで２台同時に動くので難しいことはありません。
今となってはMD/CDではなくCDプレイヤーが主になっていますが、TASCAM製のプレイヤーはRS232による制御方法がほぼ同じなので基本的な機能だけなら高い互換性を持たせられます。
#電子工作
今日は工作作業をオフです。
そういえば中国に頼んでいた基板が入荷。
とてもキレイです。こんな上物がこの数でこの価格？と素直に思えます。有難いを越えて商売になっているのか心配になるほどです。
リフローハンダで使おうと思って手配した工業用のホットプレートも入荷。
気力が残っていれば、次のオフでリフローハンダの実験をしたいなと。
リフローハンダが上手くいけば、随分前に試作だけしたTASCAM製プレイヤーのリモコンも作ろうかなと。
所属会社の音響君たち曰く、バックアッププレイヤーも同時制御出来ると心強いらしい。同じソースを入れておくのは言うまでもありませんが、RS232を２分配するだけで２台同時に動くので難しいことはありません。
今となってはMD/CDではなくCDプレイヤーが主になっていますが、TASCAM製のプレイヤーはRS232による制御方法がほぼ同じなので基本的な機能だけなら高い互換性を持たせられます。
#電子工作
ロシアのウクライナ侵攻に解決が見えませんね。
報道からは絶対悪のロシアと絶対正義のウクライナとしか聞こえてきません。
本当にそうでしょうか。
ロシアが武力で国境を侵したことは間違っていると思いますが、ウクライナが一方的に正しいとは思えないのです。
前提として、共通の損得って意味で越えてはいけないボーダーラインはあると思いますが、正義は人の数だけ存在する概念であって絶対正義は存在しないと考えています。どんな宗教でも経典を解釈する人次第で神の意志が違うことからも明白な事実です。聖書を根拠に指導者を越えた権力者がいることも権力を欲する人の正義ですから。
国は人の集合体であり、限られた人の思惑が方針を大きく左右するとしても、概念的には総意で方針が決まるモノです。かのナチスであっても、先進的とされたワイマール憲法の上で民意を受けた正式な手続きを経て発生しています。一定以上の権力を得た後、あのような流れになったことは残念でありますが、民意がそれを作ったことは歴史に明記されております。
こんなことから、目先の「かわいそう」で被害者と加害者を線引きしている今の風潮にはナチスが発生した経緯と同じこと感じ、危険な匂いすらします。
この件は「火のない所にナントやら」だと思うのです。経済的に余裕があるとは思えないロシアが膨大な戦費がかかることを承知でこんなことをしたがるのでしょうか。権力者の強欲やプライドがあったとしても、それだけを理由にこのようなことをするメリットは思い浮かびません。戦争は経済活動の極端な方法だと私は考えますが、今回の侵攻が強欲から来ているとするなら経済的なメリットが全く思い浮かばないのです。
とするなら、ウクライナがロシアに対してプライド的に許せない非礼を働いたとするのが自然だと思うのです。感情的になれば経済的なメリットは後回しになりますからね。第一次世界大戦も、某国の王族の王子が暗殺されたことが発端ですが、一部の高貴な方々のプライドから世界大戦にまでなっています。なんとなく似ているような感じがします。
もちろん、ウクライナ国民が総勢でロシアに非礼を働いたとは思いませんけど。
ただ一つ、危惧するのは現在のウクライナ政府がネオナチ系と噂されることです。
前述の通りナチスは正式な民意を受けて権力を得ていますが、その過程においてはベルサイユ条約によって卑下されたドイツ国民を煽って扇動した経緯があります。あくまで私の勘であって説明出来ることではないのですが、今のロシア絶対悪的な報道にナチスが権力を握る流れと同じ匂いを感じてしまうのです。
もちろん、何の悪意も持たず、平和に過ごしたいと思っている一般市民が戦争被害者になっている現実は許せることではありません。
ただ、被害者がいるからその国の政府は正義とするのは短絡過ぎるのではないか？と疑問に思うのです。
なんかこう、予想外の攻勢で第三帝国が潰される発端を作ったソビエト連邦にネオナチが罠を仕込んで仕返しをしているようにも思えたりします。
ハイウッド映画風に解釈すればですが(笑
#雑談
報道からは絶対悪のロシアと絶対正義のウクライナとしか聞こえてきません。
本当にそうでしょうか。
ロシアが武力で国境を侵したことは間違っていると思いますが、ウクライナが一方的に正しいとは思えないのです。
前提として、共通の損得って意味で越えてはいけないボーダーラインはあると思いますが、正義は人の数だけ存在する概念であって絶対正義は存在しないと考えています。どんな宗教でも経典を解釈する人次第で神の意志が違うことからも明白な事実です。聖書を根拠に指導者を越えた権力者がいることも権力を欲する人の正義ですから。
国は人の集合体であり、限られた人の思惑が方針を大きく左右するとしても、概念的には総意で方針が決まるモノです。かのナチスであっても、先進的とされたワイマール憲法の上で民意を受けた正式な手続きを経て発生しています。一定以上の権力を得た後、あのような流れになったことは残念でありますが、民意がそれを作ったことは歴史に明記されております。
こんなことから、目先の「かわいそう」で被害者と加害者を線引きしている今の風潮にはナチスが発生した経緯と同じこと感じ、危険な匂いすらします。
この件は「火のない所にナントやら」だと思うのです。経済的に余裕があるとは思えないロシアが膨大な戦費がかかることを承知でこんなことをしたがるのでしょうか。権力者の強欲やプライドがあったとしても、それだけを理由にこのようなことをするメリットは思い浮かびません。戦争は経済活動の極端な方法だと私は考えますが、今回の侵攻が強欲から来ているとするなら経済的なメリットが全く思い浮かばないのです。
とするなら、ウクライナがロシアに対してプライド的に許せない非礼を働いたとするのが自然だと思うのです。感情的になれば経済的なメリットは後回しになりますからね。第一次世界大戦も、某国の王族の王子が暗殺されたことが発端ですが、一部の高貴な方々のプライドから世界大戦にまでなっています。なんとなく似ているような感じがします。
もちろん、ウクライナ国民が総勢でロシアに非礼を働いたとは思いませんけど。
ただ一つ、危惧するのは現在のウクライナ政府がネオナチ系と噂されることです。
前述の通りナチスは正式な民意を受けて権力を得ていますが、その過程においてはベルサイユ条約によって卑下されたドイツ国民を煽って扇動した経緯があります。あくまで私の勘であって説明出来ることではないのですが、今のロシア絶対悪的な報道にナチスが権力を握る流れと同じ匂いを感じてしまうのです。
もちろん、何の悪意も持たず、平和に過ごしたいと思っている一般市民が戦争被害者になっている現実は許せることではありません。
ただ、被害者がいるからその国の政府は正義とするのは短絡過ぎるのではないか？と疑問に思うのです。
なんかこう、予想外の攻勢で第三帝国が潰される発端を作ったソビエト連邦にネオナチが罠を仕込んで仕返しをしているようにも思えたりします。
ハイウッド映画風に解釈すればですが(笑
#雑談
体中が痛い。病気ではありません。
昨日はテレビの中継現場でした。夜桜がネタだったので当然ライトアップするのですが、落差10mはあろう谷底に桜がありました。その谷を降りたり登ったりを繰り返したワケです。当然脚を酷使しますから疲労困憊。今日もライトアップのバラシでしたので輪をかけて疲労困憊。オッサンにやらせる日程ではない。
今日も工作はオフですが、作業の合間にArt-Netの処理をまとめましたので、明日は少し進めようと思います。
今のところArt-Netの処理は堅調です。
このまま書き進めれば使い物になりそうです。
#[Art-Net]
昨日はテレビの中継現場でした。夜桜がネタだったので当然ライトアップするのですが、落差10mはあろう谷底に桜がありました。その谷を降りたり登ったりを繰り返したワケです。当然脚を酷使しますから疲労困憊。今日もライトアップのバラシでしたので輪をかけて疲労困憊。オッサンにやらせる日程ではない。
今日も工作はオフですが、作業の合間にArt-Netの処理をまとめましたので、明日は少し進めようと思います。
今のところArt-Netの処理は堅調です。
このまま書き進めれば使い物になりそうです。
#[Art-Net]
昨日はオフでしたが、体中が痛くて身動き取れず。
リフローハンダの試験をしたいのですが、何時になることやら・・・
今日も今日とてライトアップのバラシ。
日中は春らしく暖かくなってきましたが、陽が暮れると気温が下がりますので、朝早めに始めて定時間やって上がりにしています。
せめてArt-Netのライブラリを進めておくことにします。
#[Art-Net]
リフローハンダの試験をしたいのですが、何時になることやら・・・
今日も今日とてライトアップのバラシ。
日中は春らしく暖かくなってきましたが、陽が暮れると気温が下がりますので、朝早めに始めて定時間やって上がりにしています。
せめてArt-Netのライブラリを進めておくことにします。
#[Art-Net]
Art-Netを書き進めていました。
ようやく卓を２枚使える状況になったので、複数の送信元を受ける処理を試してみました。
基本的には問題なく動くのですが・・・受信するユニバース総数、いや、送信されるユニバースの総数が10以上になると動作がおかしくなります。こういった装置ですから処理できる量に限度はあるものですが、それにしても挙動がおかしい。
いろいろ試したところ、multiprocessingでプロセス間通信をするmultiprocessing.queueが遅いことによるタイミング遅れであることが判明。せっかくプロセスを分けて処理効率を上げようとしてもプロセス間の通信が遅くては本末転倒。８ユニバースくらいのデータなら扱えるものの、さらにプロセスを増やす必要があるのにこれでは困る。
Python3.8以降で追加された共有メモリが使えれば解決するっぽいけれど、現在使っているRasbianはDebian10(buster)ベースなのでPython3.7。Debian11(buleseye)ベースのRasbianに上げればPython3.9.2になるけれど、bulesyeは過去との互換性に少し難があるらしい。Pythonは動くと思うけど、他から引っ張ってくるドライバに不安がある。
プロセス間通信には他の方法もあるけれど、どの方法をとってもかなりの書き直しが必要になりそう。
トホホ気分ではありますが仕方ありません。
追記
悩んでも始まらないので、Rasbianをbullseyeにアップグレードしています。
たぶん、古い流儀を引っ張るより、最新にした方が良いと思うからです。
ダメならダメでbusterを再インストール。
#Python #[Art-Net]
ようやく卓を２枚使える状況になったので、複数の送信元を受ける処理を試してみました。
基本的には問題なく動くのですが・・・受信するユニバース総数、いや、送信されるユニバースの総数が10以上になると動作がおかしくなります。こういった装置ですから処理できる量に限度はあるものですが、それにしても挙動がおかしい。
いろいろ試したところ、multiprocessingでプロセス間通信をするmultiprocessing.queueが遅いことによるタイミング遅れであることが判明。せっかくプロセスを分けて処理効率を上げようとしてもプロセス間の通信が遅くては本末転倒。８ユニバースくらいのデータなら扱えるものの、さらにプロセスを増やす必要があるのにこれでは困る。
Python3.8以降で追加された共有メモリが使えれば解決するっぽいけれど、現在使っているRasbianはDebian10(buster)ベースなのでPython3.7。Debian11(buleseye)ベースのRasbianに上げればPython3.9.2になるけれど、bulesyeは過去との互換性に少し難があるらしい。Pythonは動くと思うけど、他から引っ張ってくるドライバに不安がある。
プロセス間通信には他の方法もあるけれど、どの方法をとってもかなりの書き直しが必要になりそう。
トホホ気分ではありますが仕方ありません。
追記
悩んでも始まらないので、Rasbianをbullseyeにアップグレードしています。
たぶん、古い流儀を引っ張るより、最新にした方が良いと思うからです。
ダメならダメでbusterを再インストール。
#Python #[Art-Net]
Rasbianをbullseyeのアップグレードしてみました。
今までにない設定が少しありましたが普通にDebianです。
Pythonは3.9.2まで上がっています。ここ数年で追加された新機能がほとんど使えます。
すべての方法を試したワケではありませんが、Pythonのプロセス間通信は全般的に遅いのかもしれません。マルチプロセス処理は、常に通信しながらの並行処理ではなく、重い処理を別なところでやって結果を取り込むという発想で作られている感じがします。
となると、ユーザー操作や設定データ(パッチマップ、プロファイルカーブマップなど)の作成は別プロセスで行うとしても、受信から送信までのArt-Netの一連の処理はシングルプロセスで行うのがいいのかもしれません。プロセス間通信のオーバーヘッドを無くすためです。
追記
少し調べを進めてみました。
Queueは使い勝手がいいのですが、トラブルが起きにくい様にマネージされているので挙動が遅いようです。
プロセス間通信にはPipeや共有メモリなどQueue以外にも幾つか方法がありますが、速度が出る方法は管理が難しく、管理が簡単な方法は速度が出ないという関係にあるようで、管理が簡単で速度が出る方法は無い様子。
仮に速度が出るとされる方法を使ってもカレントプロセスの変数を扱うほどの速度は出ませんので、外部とのやりとりはQueueなどを使うとしても、常駐する繰り返し処理はシングルプロセスで単純化を狙った方が良い結果になりそうです。
全体的にマルチプロセスで外に出すってことです。
#Python #[Art-Net]
今までにない設定が少しありましたが普通にDebianです。
Pythonは3.9.2まで上がっています。ここ数年で追加された新機能がほとんど使えます。
すべての方法を試したワケではありませんが、Pythonのプロセス間通信は全般的に遅いのかもしれません。マルチプロセス処理は、常に通信しながらの並行処理ではなく、重い処理を別なところでやって結果を取り込むという発想で作られている感じがします。
となると、ユーザー操作や設定データ(パッチマップ、プロファイルカーブマップなど)の作成は別プロセスで行うとしても、受信から送信までのArt-Netの一連の処理はシングルプロセスで行うのがいいのかもしれません。プロセス間通信のオーバーヘッドを無くすためです。
追記
少し調べを進めてみました。
Queueは使い勝手がいいのですが、トラブルが起きにくい様にマネージされているので挙動が遅いようです。
プロセス間通信にはPipeや共有メモリなどQueue以外にも幾つか方法がありますが、速度が出る方法は管理が難しく、管理が簡単な方法は速度が出ないという関係にあるようで、管理が簡単で速度が出る方法は無い様子。
仮に速度が出るとされる方法を使ってもカレントプロセスの変数を扱うほどの速度は出ませんので、外部とのやりとりはQueueなどを使うとしても、常駐する繰り返し処理はシングルプロセスで単純化を狙った方が良い結果になりそうです。
全体的にマルチプロセスで外に出すってことです。
#Python #[Art-Net]
今日も今日とてライトアップのバラシ。
規模は大きいですが、10日間で終わりが見えてきました。
そんな現場作業をしながらArt-Netの受信処理を考え直しています。やらなきゃならない処理内容は見えましたから、主に処理の順序の整理です。
順序を整理していくとコンパクトでシンプルな内容になってきます。これまで書いてきたモノは試しながら書き加えをしてきましたから、部分というより基本的な構造に無駄があったようです。
#Python #[Art-Net]
規模は大きいですが、10日間で終わりが見えてきました。
そんな現場作業をしながらArt-Netの受信処理を考え直しています。やらなきゃならない処理内容は見えましたから、主に処理の順序の整理です。
順序を整理していくとコンパクトでシンプルな内容になってきます。これまで書いてきたモノは試しながら書き加えをしてきましたから、部分というより基本的な構造に無駄があったようです。
#Python #[Art-Net]
どうしたのか、所属会社のネットワークがインターネットに接続出来なくなる。LANで内側サーバー機にアクセスする分には正常。
ゲートウェアサーバーを覗くとPPPoEのインターフェースにIPアドレスが表示されない。これは光回線側が落ちているサイン。
ゲートウェアサーバーと光回線インターフェースを再起動したりと、わちゃわちゃしているウチに何事もなかった様に接続が回復。
ライトアップのバラシから上がってきてこういった対応をするのは気が滅入ります。
#サーバー
ゲートウェアサーバーを覗くとPPPoEのインターフェースにIPアドレスが表示されない。これは光回線側が落ちているサイン。
ゲートウェアサーバーと光回線インターフェースを再起動したりと、わちゃわちゃしているウチに何事もなかった様に接続が回復。
ライトアップのバラシから上がってきてこういった対応をするのは気が滅入ります。
#サーバー