電装工芸日記
- 舞台照明機器の製作とか -
全年7月7日の投稿［5件］
2025年 この範囲を時系列順で読む この範囲をファイルに出力する
今どきのデジタルコンソールは音響でも照明でも起動に数分かかります。瞬間停電であっても卓電源が落ちるのは避けたい。この対策には無停電電源装置(UPS)が効果的です。
前々から UPS のパッケージを組もうと思っていたのですが、本格的組むことにしたので製品調べ。OMRONさん一択です。海外製で安価な物はありますが将来必ず必要になる交換バッテリーの入手に不安があります。その点OMRONさんには安心感があります。
と、久しぶりにOMRONさんのサイトを見たら製品ラインナップが大きく変わっていました。
UPSの機能を大別しますと、
１）常時バッテリー供給か平時は入力電源供給で停電時バッテリー供給か。
２）バックアップ時の出力がPWMによる疑似ACか正弦波か。
となります。
望ましいのは常時バッテリー供給の正弦波ですが、こういった製品は一般的に高価です。
そんな基準で見ていたら、OMRONさんの廉価版が平時入力電源供給の停電時正弦波になっていました。PWMによる疑似ACは最廉価版だけになってます。これはスゲー。
さぞお高くなったろうなと思ったら意外や意外、価格は据え置きの機能アップでした。
製品は「BY120S」と「BY80S」です。BY120Sが負荷容量720w/重量8.5kg、BY80Sが負荷容量500w/重量6.4kgです。手ごろ感があります。
定価は微妙に躊躇しますが実売は4万～6万円です。トラブル損金の前払いと考えたら安価でしょう。これが高価と言われたらトラブルを真正面から受け止めて頂くしかありません。
これを3Uのラックケースに入れるのが基本方針です。
無垢のラックパネルを削るのは大変ですし、タカチ電機さんに加工を依頼すると高額です。友人が三代目社長をやっている鉄工所にラックパネルの製作を依頼しました。
#器具の製作
前々から UPS のパッケージを組もうと思っていたのですが、本格的組むことにしたので製品調べ。OMRONさん一択です。海外製で安価な物はありますが将来必ず必要になる交換バッテリーの入手に不安があります。その点OMRONさんには安心感があります。
と、久しぶりにOMRONさんのサイトを見たら製品ラインナップが大きく変わっていました。
UPSの機能を大別しますと、
１）常時バッテリー供給か平時は入力電源供給で停電時バッテリー供給か。
２）バックアップ時の出力がPWMによる疑似ACか正弦波か。
となります。
望ましいのは常時バッテリー供給の正弦波ですが、こういった製品は一般的に高価です。
そんな基準で見ていたら、OMRONさんの廉価版が平時入力電源供給の停電時正弦波になっていました。PWMによる疑似ACは最廉価版だけになってます。これはスゲー。
さぞお高くなったろうなと思ったら意外や意外、価格は据え置きの機能アップでした。
製品は「BY120S」と「BY80S」です。BY120Sが負荷容量720w/重量8.5kg、BY80Sが負荷容量500w/重量6.4kgです。手ごろ感があります。
定価は微妙に躊躇しますが実売は4万～6万円です。トラブル損金の前払いと考えたら安価でしょう。これが高価と言われたらトラブルを真正面から受け止めて頂くしかありません。
これを3Uのラックケースに入れるのが基本方針です。
無垢のラックパネルを削るのは大変ですし、タカチ電機さんに加工を依頼すると高額です。友人が三代目社長をやっている鉄工所にラックパネルの製作を依頼しました。
#器具の製作
2023年 この範囲を時系列順で読む この範囲をファイルに出力する
LTC Player はいい感じに進んできました。
PlayListには「Continue」って項目を入れています。音終わりで止める(AutoPauseする)か曲を続けるかの設定です。単に止めて続けても面白くないし、曲間の時間を設定出来たら面白そうなので、曲が終わって次の曲が始まるまでの待ち時間を設定出来るようにしました。0秒にしておけば普通の曲ツナギです。もちろん、待ち時間が終わらなくても PLAY を押せば次の曲に行きます。ついでにマイナス秒も設定出来るようにしてみました。前倒しで曲を終りにする機能です。お尻の無音が長い曲を曲続きにしたい場合に便利かなと。使う人がいるかわかりませんが、ソースを見たら簡単に入れ込めそうだったので欲を出してみました。ライブラリがVLCなので厳密な時間再現は出来ませんけどね。
それにしても、Python のソースなのに明らかにアセンブラっぽい。どう見ても一般的な Python の流儀から外れています。勉強しながら考えなら書いていると体に染みついたアセンブラ風味になってしまうようです。ソースコードを誰かに納品するワケじゃありませんのでオレ流で構わないのですけどね。けど、オブジェクト指向でクラス・インスタンスをベースにするより、フラグベースでリニアな処理手順にした方が分岐が少なくてバグを見つけやすいかもと思ったり。リニアに書くのが非合理的なのでオブジェクト指向なんでしょ！という正論は聞きませんwww
#Python
PlayListには「Continue」って項目を入れています。音終わりで止める(AutoPauseする)か曲を続けるかの設定です。単に止めて続けても面白くないし、曲間の時間を設定出来たら面白そうなので、曲が終わって次の曲が始まるまでの待ち時間を設定出来るようにしました。0秒にしておけば普通の曲ツナギです。もちろん、待ち時間が終わらなくても PLAY を押せば次の曲に行きます。ついでにマイナス秒も設定出来るようにしてみました。前倒しで曲を終りにする機能です。お尻の無音が長い曲を曲続きにしたい場合に便利かなと。使う人がいるかわかりませんが、ソースを見たら簡単に入れ込めそうだったので欲を出してみました。ライブラリがVLCなので厳密な時間再現は出来ませんけどね。
それにしても、Python のソースなのに明らかにアセンブラっぽい。どう見ても一般的な Python の流儀から外れています。勉強しながら考えなら書いていると体に染みついたアセンブラ風味になってしまうようです。ソースコードを誰かに納品するワケじゃありませんのでオレ流で構わないのですけどね。けど、オブジェクト指向でクラス・インスタンスをベースにするより、フラグベースでリニアな処理手順にした方が分岐が少なくてバグを見つけやすいかもと思ったり。リニアに書くのが非合理的なのでオブジェクト指向なんでしょ！という正論は聞きませんwww
#Python
2022年 この範囲を時系列順で読む この範囲をファイルに出力する
numpy.arrayを含むtupleをsocketで送るにはシリアル化ってのをすればいいらしい。pythonのオブジェクトをバイナリ化する方法とのこと。
pickleというライブラリを使います。pickle.dumps()でシリアル化し、pickle.loads()で戻します。
テキストと３次元のnumpy.arrayが混在するtupleが一発で処理出来ました。
変換したデータのtypeはbytesですからsocketで送れるハズです。
ただ、pickleのシリアル化/復号には時間がかかる様子。
先人の調査によると、scoket自体はとても速いけれどpickleの処理が案外遅くて総処理時間は他の方法と似たり寄ったりみたい。
ただ、先人の比較方法はデータ量を起点にする比較が主で、都度のデータは少なくコネクションの回数が多いケースの比較ではありません。multiprocessingのQueueはコネクション毎のマネージ処理が重い感じがするので、コネクション自体は軽いsocketに分があるかもしれません。
また、DMXのスロットデータを格納するnumpy.arrayは何も指定しないとint32やint64になりますが、uint8やuint16を指定すれば１スロット当たりのデータ長は小さくなります。つまり、データ総量が小さくなります。
試さないとわからんですけど、オーバーヘッドが大きい通信処理でデータ量を減らせば十分な速度を確保できる期待感があります。DMXの1スロットは1バイトですから、Art-Netエンジンではスロットに対する計算処理をせずにuint8で運用するのがいいのかもしれません。今のところ、比較抽出のnumpy.maxはあってもスロットデータに計算らしい計算は当てないのでuint8で運用しても問題無さそう。
つか、通信自体はsocketが凄く軽いことに驚いた。PythonというよりOS本体に依存するので当然かもしれませんが。
#Python
pickleというライブラリを使います。pickle.dumps()でシリアル化し、pickle.loads()で戻します。
テキストと３次元のnumpy.arrayが混在するtupleが一発で処理出来ました。
変換したデータのtypeはbytesですからsocketで送れるハズです。
ただ、pickleのシリアル化/復号には時間がかかる様子。
先人の調査によると、scoket自体はとても速いけれどpickleの処理が案外遅くて総処理時間は他の方法と似たり寄ったりみたい。
ただ、先人の比較方法はデータ量を起点にする比較が主で、都度のデータは少なくコネクションの回数が多いケースの比較ではありません。multiprocessingのQueueはコネクション毎のマネージ処理が重い感じがするので、コネクション自体は軽いsocketに分があるかもしれません。
また、DMXのスロットデータを格納するnumpy.arrayは何も指定しないとint32やint64になりますが、uint8やuint16を指定すれば１スロット当たりのデータ長は小さくなります。つまり、データ総量が小さくなります。
試さないとわからんですけど、オーバーヘッドが大きい通信処理でデータ量を減らせば十分な速度を確保できる期待感があります。DMXの1スロットは1バイトですから、Art-Netエンジンではスロットに対する計算処理をせずにuint8で運用するのがいいのかもしれません。今のところ、比較抽出のnumpy.maxはあってもスロットデータに計算らしい計算は当てないのでuint8で運用しても問題無さそう。
つか、通信自体はsocketが凄く軽いことに驚いた。PythonというよりOS本体に依存するので当然かもしれませんが。
#Python
Art-Netエンジンの構成を整理していますが、そういやプロセス間通信はどうしましょう。
PythonではmultiprocessingのQueueが予想以上に遅くて使い物になりません。便利なんですけどね。
ネットの情報ではPipeや共有メモリが速いとあります。ですが、socketもQueueより速そうなレポートが多く見受けられます。
実験してみないとわかりませんが、速度が足りるならsocketにした方が将来性があります。なぜなら、内部でのプロセス間通信も別プロセッサとの協調動作も設定するIPアドレスとポートが違うだけで全く同じプログラムで実現可能だからです。Pipeや共有メモリよりもsocketはシンプルで扱いやすいので速度が十分なら尚更です。
Art-NetとEtherNetを共用するのは避けた方が良さそうですが、ローレベルのハードウェアを扱いやすいRaspberryPiと計算能力が高いPCを組合せば得意分野を活かして良い結果を出せるような気がします。もし調光卓を考えるならこの方法は必須かもしれません。もちろん、Art-NetエンジンそのものをPCに実装するのもアリでですけど。
これまではQueueベースで書いてきましたが、タプルをバイナリ化してsocketで通信する方法から試してみましょう。
#Python #[Art-Net]
PythonではmultiprocessingのQueueが予想以上に遅くて使い物になりません。便利なんですけどね。
ネットの情報ではPipeや共有メモリが速いとあります。ですが、socketもQueueより速そうなレポートが多く見受けられます。
実験してみないとわかりませんが、速度が足りるならsocketにした方が将来性があります。なぜなら、内部でのプロセス間通信も別プロセッサとの協調動作も設定するIPアドレスとポートが違うだけで全く同じプログラムで実現可能だからです。Pipeや共有メモリよりもsocketはシンプルで扱いやすいので速度が十分なら尚更です。
Art-NetとEtherNetを共用するのは避けた方が良さそうですが、ローレベルのハードウェアを扱いやすいRaspberryPiと計算能力が高いPCを組合せば得意分野を活かして良い結果を出せるような気がします。もし調光卓を考えるならこの方法は必須かもしれません。もちろん、Art-NetエンジンそのものをPCに実装するのもアリでですけど。
これまではQueueベースで書いてきましたが、タプルをバイナリ化してsocketで通信する方法から試してみましょう。
#Python #[Art-Net]
現場もホール資料の作成も一息つきました。
終わっていませんが、自分の領分に区切りが付いて投げたところなのでしばらくは少しサボれます。
なので、Art-Netエンジンを再開しています。
基本的な機能の製作は済んでいるので最適化をします。常にそれなりの負荷で動くモジュールなので可能な限り動作負荷を軽減し例外エラーも出にくくしたいからです。
特に処理の順位とタイミングの精査が重要です。無駄な繰り返し処理を極力減らし、やるべきことは適切に実行させるのです。パッと見はスマートでも順位が最適じゃないとか、状況確認のIF文が無駄に実行されていたりするのはよくあることです。自然な流れで実際の処理量をどれだけ減らせるかが勝負です。
改めてフローを書いています。実験段階ではフローを書かず処理が成立するかコマンドを試しながら思いつきで書くことが多いのですが、最適化をするには分割した部分を並べ直して見直すのがいいようです。いわゆるフローチャートを書くのではなく、付箋に要素を書いてホワイトボードに並べるブレインストーミングみたいな作業です。一人作業なのでパソコンの中でやってますけど、LibreOfficeのドローがこの作業では使いやすいですね。
時間も開発費も乏しいところですが、出来るだけ多くの製品を作りたいものです。
#[Art-Net]
終わっていませんが、自分の領分に区切りが付いて投げたところなのでしばらくは少しサボれます。
なので、Art-Netエンジンを再開しています。
基本的な機能の製作は済んでいるので最適化をします。常にそれなりの負荷で動くモジュールなので可能な限り動作負荷を軽減し例外エラーも出にくくしたいからです。
特に処理の順位とタイミングの精査が重要です。無駄な繰り返し処理を極力減らし、やるべきことは適切に実行させるのです。パッと見はスマートでも順位が最適じゃないとか、状況確認のIF文が無駄に実行されていたりするのはよくあることです。自然な流れで実際の処理量をどれだけ減らせるかが勝負です。
改めてフローを書いています。実験段階ではフローを書かず処理が成立するかコマンドを試しながら思いつきで書くことが多いのですが、最適化をするには分割した部分を並べ直して見直すのがいいようです。いわゆるフローチャートを書くのではなく、付箋に要素を書いてホワイトボードに並べるブレインストーミングみたいな作業です。一人作業なのでパソコンの中でやってますけど、LibreOfficeのドローがこの作業では使いやすいですね。
時間も開発費も乏しいところですが、出来るだけ多くの製品を作りたいものです。
#[Art-Net]