https://www.densokogei.jp/tegalog/tegalog.cgi ja Copyright 2026 Fri, 24 Apr 2026 10:26:19 +0900 Powered by てがろぐ Ver 3.4.0 ]]> 　前々から UPS のパッケージを組もうと思っていたのですが、本格的組むことにしたので製品調べ。OMRONさん一択です。海外製で安価な物はありますが将来必ず必要になる交換バッテリーの入手に不安があります。その点OMRONさんには安心感があります。
　と、久しぶりにOMRONさんのサイトを見たら製品ラインナップが大きく変わっていました。
　UPSの機能を大別しますと、
１）常時バッテリー供給か平時は入力電源供給で停電時バッテリー供給か。
２）バックアップ時の出力がPWMによる疑似ACか正弦波か。
　となります。
　望ましいのは常時バッテリー供給の正弦波ですが、こういった製品は一般的に高価です。
　そんな基準で見ていたら、OMRONさんの廉価版が平時入力電源供給の停電時正弦波になっていました。PWMによる疑似ACは最廉価版だけになってます。これはスゲー。
　さぞお高くなったろうなと思ったら意外や意外、価格は据え置きの機能アップでした。
　製品は「BY120S」と「BY80S」です。BY120Sが負荷容量720w/重量8.5kg、BY80Sが負荷容量500w/重量6.4kgです。手ごろ感があります。

　定価は微妙に躊躇しますが実売は4万～6万円です。トラブル損金の前払いと考えたら安価でしょう。これが高価と言われたらトラブルを真正面から受け止めて頂くしかありません。
　これを3Uのラックケースに入れるのが基本方針です。
　無垢のラックパネルを削るのは大変ですし、タカチ電機さんに加工を依頼すると高額です。友人が三代目社長をやっている鉄工所にラックパネルの製作を依頼しました。

#器具の製作 -- Posted by 電装工芸 〔786文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=1089 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=1089 tegalog Mon, 07 Jul 2025 18:52:26 +0900 　PlayListには「Continue」って項目を入れています。音終わりで止める(AutoPauseする)か曲を続けるかの設定です。単に止めて続けても面白くないし、曲間の時間を設定出来たら面白そうなので、曲が終わって次の曲が始まるまでの待ち時間を設定出来るようにしました。0秒にしておけば普通の曲ツナギです。もちろん、待ち時間が終わらなくても PLAY を押せば次の曲に行きます。ついでにマイナス秒も設定出来るようにしてみました。前倒しで曲を終りにする機能です。お尻の無音が長い曲を曲続きにしたい場合に便利かなと。使う人がいるかわかりませんが、ソースを見たら簡単に入れ込めそうだったので欲を出してみました。ライブラリがVLCなので厳密な時間再現は出来ませんけどね。
　それにしても、Python のソースなのに明らかにアセンブラっぽい。どう見ても一般的な Python の流儀から外れています。勉強しながら考えなら書いていると体に染みついたアセンブラ風味になってしまうようです。ソースコードを誰かに納品するワケじゃありませんのでオレ流で構わないのですけどね。けど、オブジェクト指向でクラス・インスタンスをベースにするより、フラグベースでリニアな処理手順にした方が分岐が少なくてバグを見つけやすいかもと思ったり。リニアに書くのが非合理的なのでオブジェクト指向なんでしょ！という正論は聞きませんwww

#Python -- Posted by 電装工芸 〔635文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=664 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=664 tegalog Fri, 07 Jul 2023 20:57:40 +0900 　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 -- Posted by 電装工芸 〔850文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=324 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=324 tegalog Thu, 07 Jul 2022 21:08:52 +0900
　PythonではmultiprocessingのQueueが予想以上に遅くて使い物になりません。便利なんですけどね。
　ネットの情報ではPipeや共有メモリが速いとあります。ですが、socketもQueueより速そうなレポートが多く見受けられます。
　実験してみないとわかりませんが、速度が足りるならsocketにした方が将来性があります。なぜなら、内部でのプロセス間通信も別プロセッサとの協調動作も設定するIPアドレスとポートが違うだけで全く同じプログラムで実現可能だからです。Pipeや共有メモリよりもsocketはシンプルで扱いやすいので速度が十分なら尚更です。
　Art-NetとEtherNetを共用するのは避けた方が良さそうですが、ローレベルのハードウェアを扱いやすいRaspberryPiと計算能力が高いPCを組合せば得意分野を活かして良い結果を出せるような気がします。もし調光卓を考えるならこの方法は必須かもしれません。もちろん、Art-NetエンジンそのものをPCに実装するのもアリでですけど。

　これまではQueueベースで書いてきましたが、タプルをバイナリ化してsocketで通信する方法から試してみましょう。

#Python #[Art-Net] -- Posted by 電装工芸 〔586文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=323 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=323 tegalog Thu, 07 Jul 2022 19:06:20 +0900 　終わっていませんが、自分の領分に区切りが付いて投げたところなのでしばらくは少しサボれます。
　なので、Art-Netエンジンを再開しています。
　基本的な機能の製作は済んでいるので最適化をします。常にそれなりの負荷で動くモジュールなので可能な限り動作負荷を軽減し例外エラーも出にくくしたいからです。
　特に処理の順位とタイミングの精査が重要です。無駄な繰り返し処理を極力減らし、やるべきことは適切に実行させるのです。パッと見はスマートでも順位が最適じゃないとか、状況確認のIF文が無駄に実行されていたりするのはよくあることです。自然な流れで実際の処理量をどれだけ減らせるかが勝負です。
　改めてフローを書いています。実験段階ではフローを書かず処理が成立するかコマンドを試しながら思いつきで書くことが多いのですが、最適化をするには分割した部分を並べ直して見直すのがいいようです。いわゆるフローチャートを書くのではなく、付箋に要素を書いてホワイトボードに並べるブレインストーミングみたいな作業です。一人作業なのでパソコンの中でやってますけど、LibreOfficeのドローがこの作業では使いやすいですね。

　時間も開発費も乏しいところですが、出来るだけ多くの製品を作りたいものです。

#[Art-Net] -- Posted by 電装工芸 〔576文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=322 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=322 tegalog Thu, 07 Jul 2022 15:57:43 +0900