電装工芸日記
- 舞台照明機器の製作とか -
タグ「Art-Net」を含む投稿(時系列順)［93件］（4ページ目）
SPI-DMXを使うにはSPIに渡す配列に少し工夫が必要です。
レベル値の２次元配列[ユニバース,スロットアドレス]を１次元配列[スロットアドレス]に変換してSPIに渡すのですが、<ユニバースnのスロットx>を<n.x>と書くなら、
[<0.1>,<1.1>,<2.1>,・・・,<6.1>,<7.1>,<0.2>,<1.2>,<2.2>,・・・,<6.2>,<7.2>,
・・・,
<0.512>,<1.512>,<2.512>,・・・,<6.512>,<7.512>]
としなければなりません。[ユニバース,スロットアドレス]だったものを[スロットアドレス,ユニバース]の順番で１次元配列にするのです。
ちなみに元のスロットデータは
[[<0.1>,<0.2>,<0.3>,・・・,<0.512>],
[<1.1>,<1.2>,<1.3>,・・・,<1.512>],
・・・,
[<7.1>,<7.2>,<7.3>,・・・,<7.512>]]
こんな２次元配列です。
元のスロットデータをout_routeとし、SPIに渡すスロットデータをout_spi_arrayとするなら
out_spi_array = out_route.ravel( 'F' )
あれま、たった一行。
カッコ内の'F'はravelの動作モードを表すものらしい。
これまたPythonの繰り返しコマンドを用いずにnumpyだけで変換出来てしまった。
numpy素晴らしい。
#Python #[Art-Net]
レベル値の２次元配列[ユニバース,スロットアドレス]を１次元配列[スロットアドレス]に変換してSPIに渡すのですが、<ユニバースnのスロットx>を<n.x>と書くなら、
[<0.1>,<1.1>,<2.1>,・・・,<6.1>,<7.1>,<0.2>,<1.2>,<2.2>,・・・,<6.2>,<7.2>,
・・・,
<0.512>,<1.512>,<2.512>,・・・,<6.512>,<7.512>]
としなければなりません。[ユニバース,スロットアドレス]だったものを[スロットアドレス,ユニバース]の順番で１次元配列にするのです。
ちなみに元のスロットデータは
[[<0.1>,<0.2>,<0.3>,・・・,<0.512>],
[<1.1>,<1.2>,<1.3>,・・・,<1.512>],
・・・,
[<7.1>,<7.2>,<7.3>,・・・,<7.512>]]
こんな２次元配列です。
元のスロットデータをout_routeとし、SPIに渡すスロットデータをout_spi_arrayとするなら
out_spi_array = out_route.ravel( 'F' )
あれま、たった一行。
カッコ内の'F'はravelの動作モードを表すものらしい。
これまたPythonの繰り返しコマンドを用いずにnumpyだけで変換出来てしまった。
numpy素晴らしい。
#Python #[Art-Net]
ちょっと忙しかった今月もヒト段落。
本業があるのは有難いことですが、訛りきった感覚と体では押っ付けるのが大変でした。
良くも悪くもしばらくヒマです。
４月は例年ヒマですから、コロナが収束傾向にあっても増える元がありません。
そんなワケでArt-Netパッチを進めます。
まずは入力部を手直しして複数の送信機への対応です。結果的にHTPミキサーになるのですが、間違って複数を接続しても破綻しない様にすることが目的です。入力部を出来るだけ無駄なく丁寧に作ることが機能を実現する上で重要です。
あとは、人が操作する部分を後付けで作っても無理が出ない様にしておくことです。主機能と操作部を完全に切り離し、指示経路を一本化しつつ出来るだけシンプルにします。経路にqueueを使うかsocketを使うか考えていますが、queueの方が速度が出ますしpythonの変数のまま送受信できるメリットがありますが、操作部との通信には速度を求めていないのでscoketにした方がいいかもしれません。socketにしておけば操作部を別なデバイスにすることも可能なのでいいかなと。書いたことも調べたこともありませんが、iPadなどを操作部にすることも可能だと思うのです。
#Python #[Art-Net]
本業があるのは有難いことですが、訛りきった感覚と体では押っ付けるのが大変でした。
良くも悪くもしばらくヒマです。
４月は例年ヒマですから、コロナが収束傾向にあっても増える元がありません。
そんなワケでArt-Netパッチを進めます。
まずは入力部を手直しして複数の送信機への対応です。結果的にHTPミキサーになるのですが、間違って複数を接続しても破綻しない様にすることが目的です。入力部を出来るだけ無駄なく丁寧に作ることが機能を実現する上で重要です。
あとは、人が操作する部分を後付けで作っても無理が出ない様にしておくことです。主機能と操作部を完全に切り離し、指示経路を一本化しつつ出来るだけシンプルにします。経路にqueueを使うかsocketを使うか考えていますが、queueの方が速度が出ますしpythonの変数のまま送受信できるメリットがありますが、操作部との通信には速度を求めていないのでscoketにした方がいいかもしれません。socketにしておけば操作部を別なデバイスにすることも可能なのでいいかなと。書いたことも調べたこともありませんが、iPadなどを操作部にすることも可能だと思うのです。
#Python #[Art-Net]
Art-Netパッチは入力部の書き直しが終わったようです。
「ようです」というのは動作確認が済んでいないからです。一見正常に動いていますが、エラーが出る条件を考えて色々試さないといけません。
今回の書き直しはマルチマスタ対応です。HTPミキサー化とも言えますが、ミキサーにするのはオマケで、Art-Net送信機を複数繋げてもおかしな挙動に陥らない様にする対策です。
複数の送信機のデータをHTPでミックスして内部の時間単位で並べます。[ 時間単位, ルート, スロットアドレス ]の３次元配列でデータをスタックします。
パッチにしてもディレイにしても、この３次元配列からデータを取り出して処理しますから、これがどれだけ堅固に動作するかが肝です。
#Python #[Art-Net]
「ようです」というのは動作確認が済んでいないからです。一見正常に動いていますが、エラーが出る条件を考えて色々試さないといけません。
今回の書き直しはマルチマスタ対応です。HTPミキサー化とも言えますが、ミキサーにするのはオマケで、Art-Net送信機を複数繋げてもおかしな挙動に陥らない様にする対策です。
複数の送信機のデータをHTPでミックスして内部の時間単位で並べます。[ 時間単位, ルート, スロットアドレス ]の３次元配列でデータをスタックします。
パッチにしてもディレイにしても、この３次元配列からデータを取り出して処理しますから、これがどれだけ堅固に動作するかが肝です。
#Python #[Art-Net]
荒天のため時間が空いたのでArt-Netを書き進めてみました。
処理の整理とマルチプロセス化です。
マルチプロセス化は多コア、多スレッドのCPUを有効に使う手段です。何もせずにPythonを実行しますとシングルコア(スレッド)ですべてが実行されるので能力を引き出せません。RaspberryPi4Bは4コア4スレッドですから、単純に４倍とはいきませんが、プロセスを分割することで処理負荷が複数のCPUスレッドに分散されるようです。
どの処理がどのCPUスレッドに割り当てられているかはOS次第なので実際のところどうなのかはわかりませんけど、topで処理負荷を見る限り、総処理負荷は100/400%、プロセス当たりの負荷は最大でも50%くらいになったので良いと思われます。
ここまで負荷のかかる処理をさせるならC++で書けって話もありますが、処理の大半はプロセス間通信とnumpyなので、私がC++で書いても軽くなるのか？って疑問はあります。numpyは達人がC++で書いたライブラリですからね。
このまま書き進め、Art-Netのフロントエンドのライブラリとしてまとめましょう。
今後の課題はパッチ処理です。早々に手を付けるつもりでしたが、パッチ処理のアイデアに変更が出るとArt-Net処理に書き直しが多発し３歩進んで何とやらを繰り返していたのです。
パッチ処理はnumpyの「ファンシーインデックス」に全面的に頼ります。詳細は以前の書き込みを読んで頂きたいのですが、マップファイルを与えるとそれに従ってデータを抽出して配列を生成します。つまり、「ファンシーインデックス」の流儀に合わせたパッチマップを作ればnumpyのコマンドに与えるだけです。パッチマップの生成はレスポンスを求めませんし頻繁に更新されるものではありません。
処理の構造をよく考えて進めましょう。
マルチマスタ化(HTPミックス)の確認は、荒天で別棟に置いてあるもう一台の卓を取りに行けず、動作確認は明日以降です。
#Python #[Art-Net]
処理の整理とマルチプロセス化です。
マルチプロセス化は多コア、多スレッドのCPUを有効に使う手段です。何もせずにPythonを実行しますとシングルコア(スレッド)ですべてが実行されるので能力を引き出せません。RaspberryPi4Bは4コア4スレッドですから、単純に４倍とはいきませんが、プロセスを分割することで処理負荷が複数のCPUスレッドに分散されるようです。
どの処理がどのCPUスレッドに割り当てられているかはOS次第なので実際のところどうなのかはわかりませんけど、topで処理負荷を見る限り、総処理負荷は100/400%、プロセス当たりの負荷は最大でも50%くらいになったので良いと思われます。
ここまで負荷のかかる処理をさせるならC++で書けって話もありますが、処理の大半はプロセス間通信とnumpyなので、私がC++で書いても軽くなるのか？って疑問はあります。numpyは達人がC++で書いたライブラリですからね。
このまま書き進め、Art-Netのフロントエンドのライブラリとしてまとめましょう。
今後の課題はパッチ処理です。早々に手を付けるつもりでしたが、パッチ処理のアイデアに変更が出るとArt-Net処理に書き直しが多発し３歩進んで何とやらを繰り返していたのです。
パッチ処理はnumpyの「ファンシーインデックス」に全面的に頼ります。詳細は以前の書き込みを読んで頂きたいのですが、マップファイルを与えるとそれに従ってデータを抽出して配列を生成します。つまり、「ファンシーインデックス」の流儀に合わせたパッチマップを作ればnumpyのコマンドに与えるだけです。パッチマップの生成はレスポンスを求めませんし頻繁に更新されるものではありません。
処理の構造をよく考えて進めましょう。
マルチマスタ化(HTPミックス)の確認は、荒天で別棟に置いてあるもう一台の卓を取りに行けず、動作確認は明日以降です。
#Python #[Art-Net]
マルチマスタ処理はHTPではなく選択式が良い気がしてきました。
HTPは同じスロットの高い値を採用しますが、ムービングの制御においてはよくありません。かといってLTPが良いワケでもない。
ならば受信する卓(送信元IPアドレス)を選択したらどうかというアイデア。
この処理をするには入力部の大幅な変更が必要です。
・・・まだまだかかるなぁ。
#Python #[Art-Net]
HTPは同じスロットの高い値を採用しますが、ムービングの制御においてはよくありません。かといってLTPが良いワケでもない。
ならば受信する卓(送信元IPアドレス)を選択したらどうかというアイデア。
この処理をするには入力部の大幅な変更が必要です。
・・・まだまだかかるなぁ。
#Python #[Art-Net]
送信元をIPアドレスで選択する方法は簡単でした。丁寧に書いてきたおかげで左程の書き換えもせずに対応できそうです。
現在受信中の送信元一覧を得るためのプロセス間通信チャンネルを追加し、指定した送信元のデータだけを取り出す試験はものの数分で終わりました。
この後、一連の処理を関数化すれば完成です。
ただ、ライトアップのバラシに気力体力が奪われているので方向性が見えたところで終わりにします。丸一日、お日様を浴びながら立ったりかがんだりを延々繰り返していたので流石にシンドイ。集中力が落ちている時に書き進めるといいことはありません。
受信モジュールから取り出す際、それなりに大きな３次元配列からスロット毎の最大値を取り出す処理が不要になったので処理が少し軽くなりました。
送信元を選択式にするとバックアップ卓の切り替えに使えますし、フェスなどで複数の卓を切り替えて使う際にも使えます。パッチは一意で卓を切り替えて使えるとかなり便利だと思います。
#Python #[Art-Net]
現在受信中の送信元一覧を得るためのプロセス間通信チャンネルを追加し、指定した送信元のデータだけを取り出す試験はものの数分で終わりました。
この後、一連の処理を関数化すれば完成です。
ただ、ライトアップのバラシに気力体力が奪われているので方向性が見えたところで終わりにします。丸一日、お日様を浴びながら立ったりかがんだりを延々繰り返していたので流石にシンドイ。集中力が落ちている時に書き進めるといいことはありません。
受信モジュールから取り出す際、それなりに大きな３次元配列からスロット毎の最大値を取り出す処理が不要になったので処理が少し軽くなりました。
送信元を選択式にするとバックアップ卓の切り替えに使えますし、フェスなどで複数の卓を切り替えて使う際にも使えます。パッチは一意で卓を切り替えて使えるとかなり便利だと思います。
#Python #[Art-Net]
送信元をIPアドレスで選択する方法は完成。ライブラリの段階ですから、コマンドで現在受信中の送信元一覧を取得し、IPアドレスを送って設定する機能の追加です。最終的にはユーザーインターフェースからこれらのコマンドを使って指示します。
その他の訂正は、Delayのためのスタック順を逆にし、定数を出来るだけ外から設定するようにしました。
スタック順を逆にしたのは、Delay値で読み出す際の計算を簡単にするためです。スタックの際にポインタを加算で行うと読み出しでは減算になりますが、配列のインデックスを得る際に加算とmodを使うと配列を一括計算出来ますから、スタックの際のポインタ計算を減算にしました。なんのこと？ですけど・・・。
そんなこんな、基本機能の煮詰めをしていたら時間オーバー。
今日も今日とてライトアップのバラシをしてきた昭和産まれのオジサンは、これ以上頑張ると明日に差し障ります。
風呂して一杯飲んで寝る時間です。
基本機能は見るたびに直しや追加が出てなかなか終わりませんが、ここが肝なので、アタマが働く状態で取り組んで後で直しが出ないようにした方が良さそうです。
#Python #[Art-Net]
その他の訂正は、Delayのためのスタック順を逆にし、定数を出来るだけ外から設定するようにしました。
スタック順を逆にしたのは、Delay値で読み出す際の計算を簡単にするためです。スタックの際にポインタを加算で行うと読み出しでは減算になりますが、配列のインデックスを得る際に加算とmodを使うと配列を一括計算出来ますから、スタックの際のポインタ計算を減算にしました。なんのこと？ですけど・・・。
そんなこんな、基本機能の煮詰めをしていたら時間オーバー。
今日も今日とてライトアップのバラシをしてきた昭和産まれのオジサンは、これ以上頑張ると明日に差し障ります。
風呂して一杯飲んで寝る時間です。
基本機能は見るたびに直しや追加が出てなかなか終わりませんが、ここが肝なので、アタマが働く状態で取り組んで後で直しが出ないようにした方が良さそうです。
#Python #[Art-Net]
体中が痛い。病気ではありません。
昨日はテレビの中継現場でした。夜桜がネタだったので当然ライトアップするのですが、落差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]