電装工芸日記
- 舞台照明機器の製作とか -
どのカテゴリにも属していない投稿［1076件］（85ページ目）
Art-Netの受送信がまとまったので、SPI通信の復習を始めました。人の操作部も大事ですが、ドライバレベルの繰り返し処理が成り立たなければ始まりません。
SPIは受信ハードウェアが無くても送信動作は可能ですから、ソフトウェア的に処理の負荷がかかる様にして試すのは重要です。
SPI通信を使うのはRaspberryPiから複数のDMXを出力する為です。RaspberryPiにはシリアルポートがありますが望む数はありません。何かしらの方法で拡張しなければなりませんが、私が扱える方法で組むならPICをフロントエンドにして数を増やしますので、PICと通信するのにSPIを使います。
SPIがどんな通信かは諸兄達に任せますが、RspberryPiでもPICでも扱えて複数のDMXを扱うのに十分な速度を持った通信です。
RaspberryPiにおいては、SPIを扱うハードウェアモジュールが搭載されているためにソフトウェアには負担がかかりませんので、周辺デバイスとの簡素な高速通信としてとても有効です。
#RaspberryPi #[Art-Net]
SPIは受信ハードウェアが無くても送信動作は可能ですから、ソフトウェア的に処理の負荷がかかる様にして試すのは重要です。
SPI通信を使うのはRaspberryPiから複数のDMXを出力する為です。RaspberryPiにはシリアルポートがありますが望む数はありません。何かしらの方法で拡張しなければなりませんが、私が扱える方法で組むならPICをフロントエンドにして数を増やしますので、PICと通信するのにSPIを使います。
SPIがどんな通信かは諸兄達に任せますが、RspberryPiでもPICでも扱えて複数のDMXを扱うのに十分な速度を持った通信です。
RaspberryPiにおいては、SPIを扱うハードウェアモジュールが搭載されているためにソフトウェアには負担がかかりませんので、周辺デバイスとの簡素な高速通信としてとても有効です。
#RaspberryPi #[Art-Net]
オフですが、用事が早く終わったのでArt-Netを書き書き。
ライブラリ化が完了。importしてインスタンスを作ればArt-Netの受送信が始まり、インスタンスから関数を呼び出して設定変更や現在値の読み出しが出来ます。
とりあえずこんなもんかな。
追記
送信元を切り替える動作も確認しました。
まだユーザーが選択するようにはしていませんが、５秒毎に切り替えるテストプログラムで正常に動作。
SPI-DMXの処理もイメージがまとまってきました。Art-Netの出力処理内にthreadingで間借りすればすんなりいきそうです。
#Python #[Art-Net]
ライブラリ化が完了。importしてインスタンスを作ればArt-Netの受送信が始まり、インスタンスから関数を呼び出して設定変更や現在値の読み出しが出来ます。
とりあえずこんなもんかな。
追記
送信元を切り替える動作も確認しました。
まだユーザーが選択するようにはしていませんが、５秒毎に切り替えるテストプログラムで正常に動作。
SPI-DMXの処理もイメージがまとまってきました。Art-Netの出力処理内にthreadingで間借りすればすんなりいきそうです。
#Python #[Art-Net]
Art-Netパッチは一番の課題をクリアしたワケです。
規格書を翻訳するところから始まって４ヶ月間、ヒマが無くても考え続けてきましたから、嬉しいと言えば嬉しいですが、肩の荷が下りてホッとした気持ちが強いです。
予想外の何かは残っていると思いますが、一番大きな山を越えたのかな。
今後はimport出来るライブラリとしてまとめ上げ、先日基板を作ったSPI-DMXの試作です。
ライブラリにするのはそれほど難しくありません。動作試験用に書いたmainを機能別に関数化して外から呼べるようにするだけです。
SPI-DMXは、Art-Netパッチに組み込むか、別の装置としてArt-Netデコーダにするか、試作しながら考えたいと思います。RaspberryPiのSPIで大きなデータを扱ったことがないので、Art-Netパッチに組み入れられるかわからんのです。
最終的な装置にまとめ上げるには筐体の製作もあります。簡単そうで難しい電源の入り切りや停電対策などもあります。
まだまだやらねばならないことが多く、主機能が一応動いたからと喜んでもいられんのです。
近々の目標は、最低限の設定操作が出来るところまで作ってDMX-Delayをリクエストしてくださったプランナーさんに主機能を確認して頂くことです。望まれているニュアンスで遅れるかが最も大事ですから。
ベニヤ板に基板やモジュールをネジ止めした姿での確認になりそうですが、中身が決まらないと筐体の設計は出来ませんのでよいのです。
願わくば、Ｐ社のＷ君にも確認してもらいたいなぁ～(笑
#Python #[Art-Net]
規格書を翻訳するところから始まって４ヶ月間、ヒマが無くても考え続けてきましたから、嬉しいと言えば嬉しいですが、肩の荷が下りてホッとした気持ちが強いです。
予想外の何かは残っていると思いますが、一番大きな山を越えたのかな。
今後はimport出来るライブラリとしてまとめ上げ、先日基板を作ったSPI-DMXの試作です。
ライブラリにするのはそれほど難しくありません。動作試験用に書いたmainを機能別に関数化して外から呼べるようにするだけです。
SPI-DMXは、Art-Netパッチに組み込むか、別の装置としてArt-Netデコーダにするか、試作しながら考えたいと思います。RaspberryPiのSPIで大きなデータを扱ったことがないので、Art-Netパッチに組み入れられるかわからんのです。
最終的な装置にまとめ上げるには筐体の製作もあります。簡単そうで難しい電源の入り切りや停電対策などもあります。
まだまだやらねばならないことが多く、主機能が一応動いたからと喜んでもいられんのです。
近々の目標は、最低限の設定操作が出来るところまで作ってDMX-Delayをリクエストしてくださったプランナーさんに主機能を確認して頂くことです。望まれているニュアンスで遅れるかが最も大事ですから。
ベニヤ板に基板やモジュールをネジ止めした姿での確認になりそうですが、中身が決まらないと筐体の設計は出来ませんのでよいのです。
願わくば、Ｐ社のＷ君にも確認してもらいたいなぁ～(笑
#Python #[Art-Net]
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]
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