電装工芸日記
- 舞台照明機器の製作とか -
2022年7月の投稿(時系列順)［31件］
2022年7月1日 この範囲を新しい順で読む この範囲をファイルに出力する
とにかく暑い。いや、熱い。
電力事情が悪化していますが、エアコンを適度につかって乗り切りたいものです。
ちなみにですが、今どきのエアコンとテレビを比較するとエアコンの方が電気喰いません。たぶんですけど。
エアコンはピーク動作時は電力喰います。コンプレッサーが動くときです。ですが、それ以外では大した電力を喰いません。比べてテレビは常に一定の電力を喰います。
テレビを観なくても死にゃしませんが、熱中症になればリアルに死の危険性を伴います。
エアコン切ってテレビを観るのが最も愚かな選択肢であることは間違いありません。
#雑談
電力事情が悪化していますが、エアコンを適度につかって乗り切りたいものです。
ちなみにですが、今どきのエアコンとテレビを比較するとエアコンの方が電気喰いません。たぶんですけど。
エアコンはピーク動作時は電力喰います。コンプレッサーが動くときです。ですが、それ以外では大した電力を喰いません。比べてテレビは常に一定の電力を喰います。
テレビを観なくても死にゃしませんが、熱中症になればリアルに死の危険性を伴います。
エアコン切ってテレビを観るのが最も愚かな選択肢であることは間違いありません。
#雑談
2022年7月2日 この範囲を新しい順で読む この範囲をファイルに出力する
auが障害を起こしています。
かく言う私はIDOから数えて30年来のauユーザーですので障害が直撃しております。
ただ、通話はダメですが4Gでもwi-fiでもネットは繋がります。通話をあまり使わないので直接的な被害は僅かです。
今回の件、交換機に相当するVoLTEと呼ばれる装置の故障だとか。間違ってもamazonでは手に入らないオーダーメイドの機械でしょうから数日で復旧するとは思えません。
罵声を浴びせてもゴネてもダメなモノはダメなんですからしばらく待ちましょう。3.11の直後だってしばらくは使えなかったのですから同じことです。無きゃ無いで無いなりに何とかすりゃいいんです。それに、クレームを言うためにショップに並ぶ時間あるなら急ぎの要件は無いのでしょうから静かにして欲しいかも。
今回の件、みつほ銀行の一件と近い匂いがします。
「動いているのでナゼ交換する！？」
て奴です。
この思想が厄介でして、イザ故障してサービスが落ちると
「なんで対策してなかったんだ！！」
とされるワケです。技術側からすれば踏んだり蹴ったりです。
権限があるだけのコストダウンを勘違いした機械音痴が原因となって発生するトラブルの典型例ですね。システム障害ですがその実は人災です。技術者のモチベーションも測定限界以下まで下がります。
今回の真相はまだ不明ですが、上級技術者ほど連絡が取れないとの話もありますので、あれだけ言ったのにそれを無視した権限があるだけのアホの尻拭いを休日出勤してまでしてやる気はねーし、お客には悪いけどアホには痛い目を見てもらいましょう、といったところだと想像します。
関係者に連絡する手段がauの携帯なので通じないって話もありますが。
「動いているのにナゼ交換する！？」は裏を返せば「サービスが落ちてもかまわない！！」と言っているのと等しいんですけど、権限というか権力を求める人ほどこういったことが理解出来ない傾向にあるようです。求める権力の裏付けは何？と聞きたいけど。
この流れで長期停電も起こるんでしょうかねぇ。
#雑談
かく言う私はIDOから数えて30年来のauユーザーですので障害が直撃しております。
ただ、通話はダメですが4Gでもwi-fiでもネットは繋がります。通話をあまり使わないので直接的な被害は僅かです。
今回の件、交換機に相当するVoLTEと呼ばれる装置の故障だとか。間違ってもamazonでは手に入らないオーダーメイドの機械でしょうから数日で復旧するとは思えません。
罵声を浴びせてもゴネてもダメなモノはダメなんですからしばらく待ちましょう。3.11の直後だってしばらくは使えなかったのですから同じことです。無きゃ無いで無いなりに何とかすりゃいいんです。それに、クレームを言うためにショップに並ぶ時間あるなら急ぎの要件は無いのでしょうから静かにして欲しいかも。
今回の件、みつほ銀行の一件と近い匂いがします。
「動いているのでナゼ交換する！？」
て奴です。
この思想が厄介でして、イザ故障してサービスが落ちると
「なんで対策してなかったんだ！！」
とされるワケです。技術側からすれば踏んだり蹴ったりです。
権限があるだけのコストダウンを勘違いした機械音痴が原因となって発生するトラブルの典型例ですね。システム障害ですがその実は人災です。技術者のモチベーションも測定限界以下まで下がります。
今回の真相はまだ不明ですが、上級技術者ほど連絡が取れないとの話もありますので、あれだけ言ったのにそれを無視した権限があるだけのアホの尻拭いを休日出勤してまでしてやる気はねーし、お客には悪いけどアホには痛い目を見てもらいましょう、といったところだと想像します。
関係者に連絡する手段がauの携帯なので通じないって話もありますが。
「動いているのにナゼ交換する！？」は裏を返せば「サービスが落ちてもかまわない！！」と言っているのと等しいんですけど、権限というか権力を求める人ほどこういったことが理解出来ない傾向にあるようです。求める権力の裏付けは何？と聞きたいけど。
この流れで長期停電も起こるんでしょうかねぇ。
#雑談
2022年7月4日 この範囲を新しい順で読む この範囲をファイルに出力する
auの回線が復帰していました。
まずは現場の技術者の皆様に感謝とお疲れ様をお伝えしたいです。
正直、通話依存が高い人は大騒ぎしていましたが、ネットは早々に回復したので通話依存が低い人は「仕方ねーなー」って感じでそれほど気にしてない様子でした。
私は、実家の父母以外、連絡の大半がメール、LINE、SMSですので大きな問題なりませんでした。連絡相手の大半が電話を取れない時が多い方々だからです。
数年前にソフトバンクでも似たようなことがあったのですから、２日で治ったのなら取り立てて大騒ぎしなくてもいいっしょ。
今回の件、誰が悪いとかいう魔女裁判など聞いても意味がありません。こういうのは権限のある人が逃げて逃げにくい人が責任を取らされることが多いからです。現場の技術者に責任を押し付けることなく原因を明らかにしてもらいたいものです。
昭和の時代は上司が盾になって部下を守る感じがありましたが、今は部下を盾に上司が逃げる感じが強いです。必ずしもではありますが、この件に関してはそうならないことを祈ります。
ただ、記者会見などでの上層部の言い訳を聞くと「あーぁ」って感じはします。現場の落ち度であって経営陣はむしろ被害者なんよと聞こえてしまう。問題の原因となったVoLTEを最終的に決めたのは誰なんよと聞きたい。
私個人が現場の技術側を擁護したい気持ちが強いのもありますけど(笑
#雑談
まずは現場の技術者の皆様に感謝とお疲れ様をお伝えしたいです。
正直、通話依存が高い人は大騒ぎしていましたが、ネットは早々に回復したので通話依存が低い人は「仕方ねーなー」って感じでそれほど気にしてない様子でした。
私は、実家の父母以外、連絡の大半がメール、LINE、SMSですので大きな問題なりませんでした。連絡相手の大半が電話を取れない時が多い方々だからです。
数年前にソフトバンクでも似たようなことがあったのですから、２日で治ったのなら取り立てて大騒ぎしなくてもいいっしょ。
今回の件、誰が悪いとかいう魔女裁判など聞いても意味がありません。こういうのは権限のある人が逃げて逃げにくい人が責任を取らされることが多いからです。現場の技術者に責任を押し付けることなく原因を明らかにしてもらいたいものです。
昭和の時代は上司が盾になって部下を守る感じがありましたが、今は部下を盾に上司が逃げる感じが強いです。必ずしもではありますが、この件に関してはそうならないことを祈ります。
ただ、記者会見などでの上層部の言い訳を聞くと「あーぁ」って感じはします。現場の落ち度であって経営陣はむしろ被害者なんよと聞こえてしまう。問題の原因となったVoLTEを最終的に決めたのは誰なんよと聞きたい。
私個人が現場の技術側を擁護したい気持ちが強いのもありますけど(笑
#雑談
2022年7月5日 この範囲を新しい順で読む この範囲をファイルに出力する
auの障害のせいで通話が出来ず高額の契約を落としたなんて書き込みをする方がいます。ありえないとは言い切れませんが、本当にそうなのかな？
疑問なのは、そんなレベルの契約を担当する方が手持ちの携帯電話が使えなくなっただけで仕事が出来なくなるほど不器用だとは思えないことです。他のキャリアを持つ同僚知人、固定電話、数は減っても公衆電話もあります。タクシー飛ばして直接話しをしに行ってもいい。
本当ならお悔み申し上げますが、未熟者の自己紹介のようなブラフはネタだとしても書くもんぢゃありません。
#雑談
疑問なのは、そんなレベルの契約を担当する方が手持ちの携帯電話が使えなくなっただけで仕事が出来なくなるほど不器用だとは思えないことです。他のキャリアを持つ同僚知人、固定電話、数は減っても公衆電話もあります。タクシー飛ばして直接話しをしに行ってもいい。
本当ならお悔み申し上げますが、未熟者の自己紹介のようなブラフはネタだとしても書くもんぢゃありません。
#雑談
現場がひと段落したらホール資料の図面描きです。こちらの別件や作業量など考慮されずに知らないところで決まった納期とはいえ、過ぎていますから１日でも早く出さなきゃなりません。
建築のCADデータの使い方は要領が見えたのでピッチを上げましょう。
つか、どんな資料が必要か依頼主から仕様が来ないので何をどう描いたらいいかよくわからんのですけどね。
#本業
建築のCADデータの使い方は要領が見えたのでピッチを上げましょう。
つか、どんな資料が必要か依頼主から仕様が来ないので何をどう描いたらいいかよくわからんのですけどね。
#本業
2022年7月7日 この範囲を新しい順で読む この範囲をファイルに出力する
現場もホール資料の作成も一息つきました。
終わっていませんが、自分の領分に区切りが付いて投げたところなのでしばらくは少しサボれます。
なので、Art-Netエンジンを再開しています。
基本的な機能の製作は済んでいるので最適化をします。常にそれなりの負荷で動くモジュールなので可能な限り動作負荷を軽減し例外エラーも出にくくしたいからです。
特に処理の順位とタイミングの精査が重要です。無駄な繰り返し処理を極力減らし、やるべきことは適切に実行させるのです。パッと見はスマートでも順位が最適じゃないとか、状況確認のIF文が無駄に実行されていたりするのはよくあることです。自然な流れで実際の処理量をどれだけ減らせるかが勝負です。
改めてフローを書いています。実験段階ではフローを書かず処理が成立するかコマンドを試しながら思いつきで書くことが多いのですが、最適化をするには分割した部分を並べ直して見直すのがいいようです。いわゆるフローチャートを書くのではなく、付箋に要素を書いてホワイトボードに並べるブレインストーミングみたいな作業です。一人作業なのでパソコンの中でやってますけど、LibreOfficeのドローがこの作業では使いやすいですね。
時間も開発費も乏しいところですが、出来るだけ多くの製品を作りたいものです。
#[Art-Net]
終わっていませんが、自分の領分に区切りが付いて投げたところなのでしばらくは少しサボれます。
なので、Art-Netエンジンを再開しています。
基本的な機能の製作は済んでいるので最適化をします。常にそれなりの負荷で動くモジュールなので可能な限り動作負荷を軽減し例外エラーも出にくくしたいからです。
特に処理の順位とタイミングの精査が重要です。無駄な繰り返し処理を極力減らし、やるべきことは適切に実行させるのです。パッと見はスマートでも順位が最適じゃないとか、状況確認のIF文が無駄に実行されていたりするのはよくあることです。自然な流れで実際の処理量をどれだけ減らせるかが勝負です。
改めてフローを書いています。実験段階ではフローを書かず処理が成立するかコマンドを試しながら思いつきで書くことが多いのですが、最適化をするには分割した部分を並べ直して見直すのがいいようです。いわゆるフローチャートを書くのではなく、付箋に要素を書いてホワイトボードに並べるブレインストーミングみたいな作業です。一人作業なのでパソコンの中でやってますけど、LibreOfficeのドローがこの作業では使いやすいですね。
時間も開発費も乏しいところですが、出来るだけ多くの製品を作りたいものです。
#[Art-Net]
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]
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
2022年7月8日 この範囲を新しい順で読む この範囲をファイルに出力する
シリアル化の手順は次の通りです。
オレメモです。
1) ライブラリをインポートします。
>>> import numpy as np
>>> import pickle
2) テスト用のnumpy.arrayを作ります。とりあえずはすべてゼロのuint8です。
>>> z = np.zeros(( 192, 8, 512 ), dtype=np.uint8 )
※ dtypeで変数の型を指定します。指定しないとOSのbit長のintになります。
※ 値の計算をするならuint16以上の型にしなければなりませんが、今のところArt-Netエンジン内では置き換えと比較しかしませんのでuint8で運用できそうです。
3) テスト用のtupleを作ります。
>>> y = ( 'tests', z )
※ 'tests'という文字列と(2)で作ったnumpy.arrayのtupleです。
4) シリアル化します。
>>> x = pickle.dumps( y )
これでtuple:yが一列のバイナリとなり、scoketで通信できる状態になります。
5) 復号します。
>>> w = pickle.loads( x )
※ wはyと同じtupleです。正しく復号されました。
numpy自体にもシリアル化/復号の方法があるようですが、型の違うデータを一括でやり取りしたいのでtupleをpickleで扱います。
この処理の速度が十分かどうかはこれからの確認です。
#Python
オレメモです。
1) ライブラリをインポートします。
>>> import numpy as np
>>> import pickle
2) テスト用のnumpy.arrayを作ります。とりあえずはすべてゼロのuint8です。
>>> z = np.zeros(( 192, 8, 512 ), dtype=np.uint8 )
※ dtypeで変数の型を指定します。指定しないとOSのbit長のintになります。
※ 値の計算をするならuint16以上の型にしなければなりませんが、今のところArt-Netエンジン内では置き換えと比較しかしませんのでuint8で運用できそうです。
3) テスト用のtupleを作ります。
>>> y = ( 'tests', z )
※ 'tests'という文字列と(2)で作ったnumpy.arrayのtupleです。
4) シリアル化します。
>>> x = pickle.dumps( y )
これでtuple:yが一列のバイナリとなり、scoketで通信できる状態になります。
5) 復号します。
>>> w = pickle.loads( x )
※ wはyと同じtupleです。正しく復号されました。
numpy自体にもシリアル化/復号の方法があるようですが、型の違うデータを一括でやり取りしたいのでtupleをpickleで扱います。
この処理の速度が十分かどうかはこれからの確認です。
#Python