電装工芸日記
- 舞台照明機器の製作とか -
時系列順［862件］（24ページ目）
2022年4月 この範囲を新しい順で読む この範囲をファイルに出力する
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]
ライトアップの片づけはほぼ終了。
これからは少ない現場を淡々とこなしていく日々が続くので開発のペースを上げられそうです。
作り変えたArt-Netの受送信処理は正しく動いているように見えます。この手の物にはコマンドの書き間違えではなくハードウェアの理解不足に起因するエラーが隠れていることがあるので、それを見つけることが難しかったりします。・・・そういった意味では、PICマイコンをアセンブラで書く方が楽だったりします。アセンブラは馬鹿正直ですから。
#Python #[Art-Net]
これからは少ない現場を淡々とこなしていく日々が続くので開発のペースを上げられそうです。
作り変えたArt-Netの受送信処理は正しく動いているように見えます。この手の物にはコマンドの書き間違えではなくハードウェアの理解不足に起因するエラーが隠れていることがあるので、それを見つけることが難しかったりします。・・・そういった意味では、PICマイコンをアセンブラで書く方が楽だったりします。アセンブラは馬鹿正直ですから。
#Python #[Art-Net]
Art-Netはテスト用のマップでパッチとディレイが機能しました。プロファイルカーブはこれからですが、パッチとディレイが動けば理屈は同じです。
ただ、配列変数の扱いで少し難儀しました。参照渡しになる規則がまだわからん・・・
ドライバレベルの基本動作がようやく出来た段階なので先は長いですが、処理負荷も軽くていいんじゃないかと。
ただ、処理を増やしたのに処理負荷が減っている。動くべきは動いているのに何故？
追記
プロファイルカーブの処理も試し書きが一発OK。
ムービングで試しましたが、ディマーだけノンディマーになる。
もちろん、ディマーにだけディレイをかけられる。
なんか面白い。
どうやら処理の核は出来たらしい。
一晩寝かせてから総チェックします。
#Python #[Art-Net]
ただ、配列変数の扱いで少し難儀しました。参照渡しになる規則がまだわからん・・・
ドライバレベルの基本動作がようやく出来た段階なので先は長いですが、処理負荷も軽くていいんじゃないかと。
ただ、処理を増やしたのに処理負荷が減っている。動くべきは動いているのに何故？
追記
プロファイルカーブの処理も試し書きが一発OK。
ムービングで試しましたが、ディマーだけノンディマーになる。
もちろん、ディマーにだけディレイをかけられる。
なんか面白い。
どうやら処理の核は出来たらしい。
一晩寝かせてから総チェックします。
#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を書き書き。
ライブラリ化が完了。importしてインスタンスを作ればArt-Netの受送信が始まり、インスタンスから関数を呼び出して設定変更や現在値の読み出しが出来ます。
とりあえずこんなもんかな。
追記
送信元を切り替える動作も確認しました。
まだユーザーが選択するようにはしていませんが、５秒毎に切り替えるテストプログラムで正常に動作。
SPI-DMXの処理もイメージがまとまってきました。Art-Netの出力処理内にthreadingで間借りすればすんなりいきそうです。
#Python #[Art-Net]
ライブラリ化が完了。importしてインスタンスを作ればArt-Netの受送信が始まり、インスタンスから関数を呼び出して設定変更や現在値の読み出しが出来ます。
とりあえずこんなもんかな。
追記
送信元を切り替える動作も確認しました。
まだユーザーが選択するようにはしていませんが、５秒毎に切り替えるテストプログラムで正常に動作。
SPI-DMXの処理もイメージがまとまってきました。Art-Netの出力処理内にthreadingで間借りすればすんなりいきそうです。
#Python #[Art-Net]
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]
RaspberryPiのpythonでSPIで使うためのライブラリspidevの本家はこちら。
本家とは違いますが、こちらのサイトはRapberryPiのSPIについてよくまとめられています。ロシア語なんで原文のままではちっともわかりませんが、本家を読んでもわからなかったことがここで解決します。翻訳して転載したらすごく参考になるかも。
一見簡素な内容ですが、SPIの何たるかはこのサイトがわかりやすいかも。SPIには４つのモードがありますが、その違いを分かりやすく書いてくれている資料が少なくて困っていたところ、このサイトを読んで理解できました。シリアル通信に何の知識も無い人に向けた資料ではありませんが、UARTやI2CはわかるけどSPIがイマイチなぁ～って人にはお勧めです。SPIは少し独特な考え方を持っていますが、そのツボ処だけ簡潔に抽出しています。私は、マイコン全般の教科書と言ってもいいPICのマニュアルを読んでもSPIがどうしても理解できなかったのですが、このサイトを参考にPICのマニュアルを読み直したところ「なるほどー！」となりました。
#RaspberryPi #[Art-Net]
本家とは違いますが、こちらのサイトはRapberryPiのSPIについてよくまとめられています。ロシア語なんで原文のままではちっともわかりませんが、本家を読んでもわからなかったことがここで解決します。翻訳して転載したらすごく参考になるかも。
一見簡素な内容ですが、SPIの何たるかはこのサイトがわかりやすいかも。SPIには４つのモードがありますが、その違いを分かりやすく書いてくれている資料が少なくて困っていたところ、このサイトを読んで理解できました。シリアル通信に何の知識も無い人に向けた資料ではありませんが、UARTやI2CはわかるけどSPIがイマイチなぁ～って人にはお勧めです。SPIは少し独特な考え方を持っていますが、そのツボ処だけ簡潔に抽出しています。私は、マイコン全般の教科書と言ってもいいPICのマニュアルを読んでもSPIがどうしても理解できなかったのですが、このサイトを参考にPICのマニュアルを読み直したところ「なるほどー！」となりました。
#RaspberryPi #[Art-Net]
Art-Netドライバには追加しないといけないことがあります。
受信したデータにパッチなどを施して送信することには成功しているのですが、現時点ではフリーフェーダーやスタックフェーダーを考慮していません。
当初は[受信するプロセス]-[受信部からデータを取り出して加工するプロセス]-[加工したデータを受け取って送信するプロセス]と分けてイメージしていたので加工するプロセスで出来るだろうと思っていたのですが、プロセス間通信のオーバーヘッドを軽減するためにこれらを１つのプロセスにしましたので同じ考え方はできません。
今もパッチ等のマップデータはプロセス間通信で差し込んでいますが、マップデータが変更された時だけ実行すればいいので頻度が低く問題になりません。されど、即反応して欲しいフェーダー操作の情報は違ってきます。データをどう扱うか、どの位置で処理するか、ちょっと難しくなってきます。
フリーフェーダーだけなら特別なIPアドレス(例えば127.0.0.1)を用いた特別な経路でデータを取り込んでArt-Netと同列に処理する方法もありますが、スタックフェーダーにするにはちょっと無理があるように思ったりします。
ただ、これらのフェーダーはバックアップ的な意味合いが強いので反応がやや遅くてもいいかもしれません。これが許されるならプロセス間通信でデータを差し込んでもいいでしょう。
次のステップに入る前にここは片付けておかないといけません。
追記
スタックフェーダーの方法はアイデアが出ました。Art-Netの入力を記憶します。ただし、記憶するユニバースなりスロットを指定出来ないとディマー以外の動作を邪魔することがあるので一種のフィルターが必要です。フィルターがあればフリーフェーダー的にも機能します。排他的ではなくHTPミックスになりますが、この方がいいでしょう。
操作としては、記憶したい状態でスタックフェーダーとユニバースやスロットを指定してストアします。ユニバースやスロットが無指定ならすべてを記憶です。
#Python #[Art-Net]
受信したデータにパッチなどを施して送信することには成功しているのですが、現時点ではフリーフェーダーやスタックフェーダーを考慮していません。
当初は[受信するプロセス]-[受信部からデータを取り出して加工するプロセス]-[加工したデータを受け取って送信するプロセス]と分けてイメージしていたので加工するプロセスで出来るだろうと思っていたのですが、プロセス間通信のオーバーヘッドを軽減するためにこれらを１つのプロセスにしましたので同じ考え方はできません。
今もパッチ等のマップデータはプロセス間通信で差し込んでいますが、マップデータが変更された時だけ実行すればいいので頻度が低く問題になりません。されど、即反応して欲しいフェーダー操作の情報は違ってきます。データをどう扱うか、どの位置で処理するか、ちょっと難しくなってきます。
フリーフェーダーだけなら特別なIPアドレス(例えば127.0.0.1)を用いた特別な経路でデータを取り込んでArt-Netと同列に処理する方法もありますが、スタックフェーダーにするにはちょっと無理があるように思ったりします。
ただ、これらのフェーダーはバックアップ的な意味合いが強いので反応がやや遅くてもいいかもしれません。これが許されるならプロセス間通信でデータを差し込んでもいいでしょう。
次のステップに入る前にここは片付けておかないといけません。
追記
スタックフェーダーの方法はアイデアが出ました。Art-Netの入力を記憶します。ただし、記憶するユニバースなりスロットを指定出来ないとディマー以外の動作を邪魔することがあるので一種のフィルターが必要です。フィルターがあればフリーフェーダー的にも機能します。排他的ではなくHTPミックスになりますが、この方がいいでしょう。
操作としては、記憶したい状態でスタックフェーダーとユニバースやスロットを指定してストアします。ユニバースやスロットが無指定ならすべてを記憶です。
#Python #[Art-Net]
中国からの物品が滞る状況が続いています。
先日も、中華電器にお試し買いの発注をしたのですが、期日までに発送されず自動キャンセル。
その外にも、中国で作っているであろう半導体部品が在庫切れなことが多く、RaspberryPiも小売りでは在庫切れが続いています。
RaspberryPiは少し在庫しているので当面のソフトウェア開発には支障ありませんが、製品を作ることはできません。
木材も高騰です。合板も角材も数倍の価格。まさか捨て材扱いされるような杉や赤松の野縁(30×40角)が高級品の様な価格になるとは思ってもいませんでした。しかも、手に入るのは節、捻じれ、曲がり物ばかり。ちょっとした物は鉄の角パイプで作った方が安いくらいです。新型コロナの影響に加え、ウクライナ侵攻によりロシアからの輸入が減ったことも大きいそうです。
中国国内では新型コロナによるロックダウンで街全体が監禁状態と聞きます。発令された瞬間に居た場所から移動を禁じられ、自宅に居た人は自宅から出られず、勤務先に居た人は勤務先から帰宅出来ないそうです。何よりも、移動しないと仕事にならない運送業まで同じ扱いらしく、物流がほぼ止まっているのだそうです。もちろん、中国全域の話ではないのでしょうが、ロックダウンに至った地域は人が多く、人が多いのは商業産業が盛んな地域でしょうから、全体としてみれば生産活動が大幅に鈍っているのでしょう。
報道から耳に入る話でもありますが、知り合いの工場は中国に協力会社を持っているのでリアルな話が聞けます。とにかく物が入ってこないそうです。電力が無い、人が行き出来ない、完成しても送れないとなればどうにもならんですよね。
もちろん、我々が使う機材類も新規購入が難しくなるワケです。
コロナがなんとなく過ぎ去った感じを受けて開催が増えていますが、それに合わせて機材を買い増ししようとしても今までの様にいきません。先日も音響系の問屋さんが来社されましたが、売りたくても売るものが入荷しにくいと言ってました。これではゴネても解決はしません。
機材の買い増し手配はお早めに。
#雑談 #本業
先日も、中華電器にお試し買いの発注をしたのですが、期日までに発送されず自動キャンセル。
その外にも、中国で作っているであろう半導体部品が在庫切れなことが多く、RaspberryPiも小売りでは在庫切れが続いています。
RaspberryPiは少し在庫しているので当面のソフトウェア開発には支障ありませんが、製品を作ることはできません。
木材も高騰です。合板も角材も数倍の価格。まさか捨て材扱いされるような杉や赤松の野縁(30×40角)が高級品の様な価格になるとは思ってもいませんでした。しかも、手に入るのは節、捻じれ、曲がり物ばかり。ちょっとした物は鉄の角パイプで作った方が安いくらいです。新型コロナの影響に加え、ウクライナ侵攻によりロシアからの輸入が減ったことも大きいそうです。
中国国内では新型コロナによるロックダウンで街全体が監禁状態と聞きます。発令された瞬間に居た場所から移動を禁じられ、自宅に居た人は自宅から出られず、勤務先に居た人は勤務先から帰宅出来ないそうです。何よりも、移動しないと仕事にならない運送業まで同じ扱いらしく、物流がほぼ止まっているのだそうです。もちろん、中国全域の話ではないのでしょうが、ロックダウンに至った地域は人が多く、人が多いのは商業産業が盛んな地域でしょうから、全体としてみれば生産活動が大幅に鈍っているのでしょう。
報道から耳に入る話でもありますが、知り合いの工場は中国に協力会社を持っているのでリアルな話が聞けます。とにかく物が入ってこないそうです。電力が無い、人が行き出来ない、完成しても送れないとなればどうにもならんですよね。
もちろん、我々が使う機材類も新規購入が難しくなるワケです。
コロナがなんとなく過ぎ去った感じを受けて開催が増えていますが、それに合わせて機材を買い増ししようとしても今までの様にいきません。先日も音響系の問屋さんが来社されましたが、売りたくても売るものが入荷しにくいと言ってました。これではゴネても解決はしません。
機材の買い増し手配はお早めに。
#雑談 #本業
Art-Netドライバはボチボチです。
現場が無い日の定時後に2-3時間の作業ですから進みは遅いのですが、完成イメージは具体的になってきました。
されど、まだまだ追加しないといけない要素は多いのです。
今の課題はスタックフェーダーです。
数本のスタックフェーダーを構成するのは簡単そうに思えますが、スロット一つ一つに対して条件分岐をして数値をいじるような処理ではいけません。条件分岐を多用して書くと意図が読み取りやすいソースになりますが処理は遅いのです。同じことを短周期で何回も繰り返す処理は、PICのアセンブラを書いてきたクセですが、単純な計算結果にフラグの意図も持たせたりして条件分岐を減らしたいのです。例えば、一定の範囲で繰り返す加算カウンタを作るとして、一定数になったことで条件分岐して初期値に戻すのが基本的な考え方だと思いますが、カウンタを繰り返し数で割った余りも同じ数値になります(この方法は一つの配列で複数のカウンタを構成する場合にも便利な方法です)。割り算が苦手なシステムでは無謀な方法ですが、Pythonは条件分岐が遅いように感じるので、この様な方法で軽くなることもあるようです。
こんな感じで計算の中に条件分岐も含めるのは、将棋で数手先を考えるのとどこか似ています。
#[Art-Net]
現場が無い日の定時後に2-3時間の作業ですから進みは遅いのですが、完成イメージは具体的になってきました。
されど、まだまだ追加しないといけない要素は多いのです。
今の課題はスタックフェーダーです。
数本のスタックフェーダーを構成するのは簡単そうに思えますが、スロット一つ一つに対して条件分岐をして数値をいじるような処理ではいけません。条件分岐を多用して書くと意図が読み取りやすいソースになりますが処理は遅いのです。同じことを短周期で何回も繰り返す処理は、PICのアセンブラを書いてきたクセですが、単純な計算結果にフラグの意図も持たせたりして条件分岐を減らしたいのです。例えば、一定の範囲で繰り返す加算カウンタを作るとして、一定数になったことで条件分岐して初期値に戻すのが基本的な考え方だと思いますが、カウンタを繰り返し数で割った余りも同じ数値になります(この方法は一つの配列で複数のカウンタを構成する場合にも便利な方法です)。割り算が苦手なシステムでは無謀な方法ですが、Pythonは条件分岐が遅いように感じるので、この様な方法で軽くなることもあるようです。
こんな感じで計算の中に条件分岐も含めるのは、将棋で数手先を考えるのとどこか似ています。
#[Art-Net]