電装工芸日記
- 舞台照明機器の製作とか -
2022年4月 この範囲を時系列順で読む この範囲をファイルに出力する
Art-Netはテスト用のマップでパッチとディレイが機能しました。プロファイルカーブはこれからですが、パッチとディレイが動けば理屈は同じです。
ただ、配列変数の扱いで少し難儀しました。参照渡しになる規則がまだわからん・・・
ドライバレベルの基本動作がようやく出来た段階なので先は長いですが、処理負荷も軽くていいんじゃないかと。
ただ、処理を増やしたのに処理負荷が減っている。動くべきは動いているのに何故？
追記
プロファイルカーブの処理も試し書きが一発OK。
ムービングで試しましたが、ディマーだけノンディマーになる。
もちろん、ディマーにだけディレイをかけられる。
なんか面白い。
どうやら処理の核は出来たらしい。
一晩寝かせてから総チェックします。
#Python #[Art-Net]
ただ、配列変数の扱いで少し難儀しました。参照渡しになる規則がまだわからん・・・
ドライバレベルの基本動作がようやく出来た段階なので先は長いですが、処理負荷も軽くていいんじゃないかと。
ただ、処理を増やしたのに処理負荷が減っている。動くべきは動いているのに何故？
追記
プロファイルカーブの処理も試し書きが一発OK。
ムービングで試しましたが、ディマーだけノンディマーになる。
もちろん、ディマーにだけディレイをかけられる。
なんか面白い。
どうやら処理の核は出来たらしい。
一晩寝かせてから総チェックします。
#Python #[Art-Net]
ライトアップの片づけはほぼ終了。
これからは少ない現場を淡々とこなしていく日々が続くので開発のペースを上げられそうです。
作り変えたArt-Netの受送信処理は正しく動いているように見えます。この手の物にはコマンドの書き間違えではなくハードウェアの理解不足に起因するエラーが隠れていることがあるので、それを見つけることが難しかったりします。・・・そういった意味では、PICマイコンをアセンブラで書く方が楽だったりします。アセンブラは馬鹿正直ですから。
#Python #[Art-Net]
これからは少ない現場を淡々とこなしていく日々が続くので開発のペースを上げられそうです。
作り変えたArt-Netの受送信処理は正しく動いているように見えます。この手の物にはコマンドの書き間違えではなくハードウェアの理解不足に起因するエラーが隠れていることがあるので、それを見つけることが難しかったりします。・・・そういった意味では、PICマイコンをアセンブラで書く方が楽だったりします。アセンブラは馬鹿正直ですから。
#Python #[Art-Net]
Art-Netの受信送信処理を書き直しました。
multiprocessing.Processで単独のプロセスにしていますが、一つの関数で受信から送信まで一貫処理です。
処理単位で関数化しないのはPythonらしくない書き方ですが、細かく分けるとデータの受け渡しの時間が勿体ないので、ソースの美しさや読みやすさよりも動作速度に余裕を持たせたいところです。とはいうものの、関数に分けることも可能な書き方をしています。関数化しても他から読み出すことがない処理ばかりですからひとまとめの平文でもいいでしょう。
処理負荷をtopで見ると26%くらい。今までよりも15～20%くらい軽くなっています。今後パッチ、ディレイ、プロファイルカーブの処理もこの関数・プロセスに追加していきますが、現段階では余裕があるように思います。
もちろん複数の卓を繋げた時のオーバーフローによる遅延は解消しています。受信の入口に近いところにIPアドレスによるフィルタを入れて余計な処理を減らしたためです。現在８ユニバースですが、気になる遅れはありません。受信している卓のIPアドレスはすべてキャッシュしていますから、将来的に現在受信中のIPアドレスを表示することは可能です。
本丸のパッチ処理をなかなか書き始められませんが、結果的にソースがすっきりして軽くなったのでヨシとしましょう。
#Python #[Art-Net]
multiprocessing.Processで単独のプロセスにしていますが、一つの関数で受信から送信まで一貫処理です。
処理単位で関数化しないのはPythonらしくない書き方ですが、細かく分けるとデータの受け渡しの時間が勿体ないので、ソースの美しさや読みやすさよりも動作速度に余裕を持たせたいところです。とはいうものの、関数に分けることも可能な書き方をしています。関数化しても他から読み出すことがない処理ばかりですからひとまとめの平文でもいいでしょう。
処理負荷をtopで見ると26%くらい。今までよりも15～20%くらい軽くなっています。今後パッチ、ディレイ、プロファイルカーブの処理もこの関数・プロセスに追加していきますが、現段階では余裕があるように思います。
もちろん複数の卓を繋げた時のオーバーフローによる遅延は解消しています。受信の入口に近いところにIPアドレスによるフィルタを入れて余計な処理を減らしたためです。現在８ユニバースですが、気になる遅れはありません。受信している卓のIPアドレスはすべてキャッシュしていますから、将来的に現在受信中のIPアドレスを表示することは可能です。
本丸のパッチ処理をなかなか書き始められませんが、結果的にソースがすっきりして軽くなったのでヨシとしましょう。
#Python #[Art-Net]
どうしたのか、所属会社のネットワークがインターネットに接続出来なくなる。LANで内側サーバー機にアクセスする分には正常。
ゲートウェアサーバーを覗くとPPPoEのインターフェースにIPアドレスが表示されない。これは光回線側が落ちているサイン。
ゲートウェアサーバーと光回線インターフェースを再起動したりと、わちゃわちゃしているウチに何事もなかった様に接続が回復。
ライトアップのバラシから上がってきてこういった対応をするのは気が滅入ります。
#サーバー
ゲートウェアサーバーを覗くとPPPoEのインターフェースにIPアドレスが表示されない。これは光回線側が落ちているサイン。
ゲートウェアサーバーと光回線インターフェースを再起動したりと、わちゃわちゃしているウチに何事もなかった様に接続が回復。
ライトアップのバラシから上がってきてこういった対応をするのは気が滅入ります。
#サーバー
今日も今日とてライトアップのバラシ。
規模は大きいですが、10日間で終わりが見えてきました。
そんな現場作業をしながらArt-Netの受信処理を考え直しています。やらなきゃならない処理内容は見えましたから、主に処理の順序の整理です。
順序を整理していくとコンパクトでシンプルな内容になってきます。これまで書いてきたモノは試しながら書き加えをしてきましたから、部分というより基本的な構造に無駄があったようです。
#Python #[Art-Net]
規模は大きいですが、10日間で終わりが見えてきました。
そんな現場作業をしながらArt-Netの受信処理を考え直しています。やらなきゃならない処理内容は見えましたから、主に処理の順序の整理です。
順序を整理していくとコンパクトでシンプルな内容になってきます。これまで書いてきたモノは試しながら書き加えをしてきましたから、部分というより基本的な構造に無駄があったようです。
#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]
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]
昨日はオフでしたが、体中が痛くて身動き取れず。
リフローハンダの試験をしたいのですが、何時になることやら・・・
今日も今日とてライトアップのバラシ。
日中は春らしく暖かくなってきましたが、陽が暮れると気温が下がりますので、朝早めに始めて定時間やって上がりにしています。
せめてArt-Netのライブラリを進めておくことにします。
#[Art-Net]
リフローハンダの試験をしたいのですが、何時になることやら・・・
今日も今日とてライトアップのバラシ。
日中は春らしく暖かくなってきましたが、陽が暮れると気温が下がりますので、朝早めに始めて定時間やって上がりにしています。
せめてArt-Netのライブラリを進めておくことにします。
#[Art-Net]
体中が痛い。病気ではありません。
昨日はテレビの中継現場でした。夜桜がネタだったので当然ライトアップするのですが、落差10mはあろう谷底に桜がありました。その谷を降りたり登ったりを繰り返したワケです。当然脚を酷使しますから疲労困憊。今日もライトアップのバラシでしたので輪をかけて疲労困憊。オッサンにやらせる日程ではない。
今日も工作はオフですが、作業の合間にArt-Netの処理をまとめましたので、明日は少し進めようと思います。
今のところArt-Netの処理は堅調です。
このまま書き進めれば使い物になりそうです。
#[Art-Net]
昨日はテレビの中継現場でした。夜桜がネタだったので当然ライトアップするのですが、落差10mはあろう谷底に桜がありました。その谷を降りたり登ったりを繰り返したワケです。当然脚を酷使しますから疲労困憊。今日もライトアップのバラシでしたので輪をかけて疲労困憊。オッサンにやらせる日程ではない。
今日も工作はオフですが、作業の合間にArt-Netの処理をまとめましたので、明日は少し進めようと思います。
今のところArt-Netの処理は堅調です。
このまま書き進めれば使い物になりそうです。
#[Art-Net]
ロシアのウクライナ侵攻に解決が見えませんね。
報道からは絶対悪のロシアと絶対正義のウクライナとしか聞こえてきません。
本当にそうでしょうか。
ロシアが武力で国境を侵したことは間違っていると思いますが、ウクライナが一方的に正しいとは思えないのです。
前提として、共通の損得って意味で越えてはいけないボーダーラインはあると思いますが、正義は人の数だけ存在する概念であって絶対正義は存在しないと考えています。どんな宗教でも経典を解釈する人次第で神の意志が違うことからも明白な事実です。聖書を根拠に指導者を越えた権力者がいることも権力を欲する人の正義ですから。
国は人の集合体であり、限られた人の思惑が方針を大きく左右するとしても、概念的には総意で方針が決まるモノです。かのナチスであっても、先進的とされたワイマール憲法の上で民意を受けた正式な手続きを経て発生しています。一定以上の権力を得た後、あのような流れになったことは残念でありますが、民意がそれを作ったことは歴史に明記されております。
こんなことから、目先の「かわいそう」で被害者と加害者を線引きしている今の風潮にはナチスが発生した経緯と同じこと感じ、危険な匂いすらします。
この件は「火のない所にナントやら」だと思うのです。経済的に余裕があるとは思えないロシアが膨大な戦費がかかることを承知でこんなことをしたがるのでしょうか。権力者の強欲やプライドがあったとしても、それだけを理由にこのようなことをするメリットは思い浮かびません。戦争は経済活動の極端な方法だと私は考えますが、今回の侵攻が強欲から来ているとするなら経済的なメリットが全く思い浮かばないのです。
とするなら、ウクライナがロシアに対してプライド的に許せない非礼を働いたとするのが自然だと思うのです。感情的になれば経済的なメリットは後回しになりますからね。第一次世界大戦も、某国の王族の王子が暗殺されたことが発端ですが、一部の高貴な方々のプライドから世界大戦にまでなっています。なんとなく似ているような感じがします。
もちろん、ウクライナ国民が総勢でロシアに非礼を働いたとは思いませんけど。
ただ一つ、危惧するのは現在のウクライナ政府がネオナチ系と噂されることです。
前述の通りナチスは正式な民意を受けて権力を得ていますが、その過程においてはベルサイユ条約によって卑下されたドイツ国民を煽って扇動した経緯があります。あくまで私の勘であって説明出来ることではないのですが、今のロシア絶対悪的な報道にナチスが権力を握る流れと同じ匂いを感じてしまうのです。
もちろん、何の悪意も持たず、平和に過ごしたいと思っている一般市民が戦争被害者になっている現実は許せることではありません。
ただ、被害者がいるからその国の政府は正義とするのは短絡過ぎるのではないか？と疑問に思うのです。
なんかこう、予想外の攻勢で第三帝国が潰される発端を作ったソビエト連邦にネオナチが罠を仕込んで仕返しをしているようにも思えたりします。
ハイウッド映画風に解釈すればですが(笑
#雑談
報道からは絶対悪のロシアと絶対正義のウクライナとしか聞こえてきません。
本当にそうでしょうか。
ロシアが武力で国境を侵したことは間違っていると思いますが、ウクライナが一方的に正しいとは思えないのです。
前提として、共通の損得って意味で越えてはいけないボーダーラインはあると思いますが、正義は人の数だけ存在する概念であって絶対正義は存在しないと考えています。どんな宗教でも経典を解釈する人次第で神の意志が違うことからも明白な事実です。聖書を根拠に指導者を越えた権力者がいることも権力を欲する人の正義ですから。
国は人の集合体であり、限られた人の思惑が方針を大きく左右するとしても、概念的には総意で方針が決まるモノです。かのナチスであっても、先進的とされたワイマール憲法の上で民意を受けた正式な手続きを経て発生しています。一定以上の権力を得た後、あのような流れになったことは残念でありますが、民意がそれを作ったことは歴史に明記されております。
こんなことから、目先の「かわいそう」で被害者と加害者を線引きしている今の風潮にはナチスが発生した経緯と同じこと感じ、危険な匂いすらします。
この件は「火のない所にナントやら」だと思うのです。経済的に余裕があるとは思えないロシアが膨大な戦費がかかることを承知でこんなことをしたがるのでしょうか。権力者の強欲やプライドがあったとしても、それだけを理由にこのようなことをするメリットは思い浮かびません。戦争は経済活動の極端な方法だと私は考えますが、今回の侵攻が強欲から来ているとするなら経済的なメリットが全く思い浮かばないのです。
とするなら、ウクライナがロシアに対してプライド的に許せない非礼を働いたとするのが自然だと思うのです。感情的になれば経済的なメリットは後回しになりますからね。第一次世界大戦も、某国の王族の王子が暗殺されたことが発端ですが、一部の高貴な方々のプライドから世界大戦にまでなっています。なんとなく似ているような感じがします。
もちろん、ウクライナ国民が総勢でロシアに非礼を働いたとは思いませんけど。
ただ一つ、危惧するのは現在のウクライナ政府がネオナチ系と噂されることです。
前述の通りナチスは正式な民意を受けて権力を得ていますが、その過程においてはベルサイユ条約によって卑下されたドイツ国民を煽って扇動した経緯があります。あくまで私の勘であって説明出来ることではないのですが、今のロシア絶対悪的な報道にナチスが権力を握る流れと同じ匂いを感じてしまうのです。
もちろん、何の悪意も持たず、平和に過ごしたいと思っている一般市民が戦争被害者になっている現実は許せることではありません。
ただ、被害者がいるからその国の政府は正義とするのは短絡過ぎるのではないか？と疑問に思うのです。
なんかこう、予想外の攻勢で第三帝国が潰される発端を作ったソビエト連邦にネオナチが罠を仕込んで仕返しをしているようにも思えたりします。
ハイウッド映画風に解釈すればですが(笑
#雑談
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 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131