202204reverse

295文字編集

電装工芸 (admin) 2022年4月1日金曜日 21:31:05 Post No.216

　明日はオフなので、Art-Netの処理を書き進めたい。
　初めて手掛ける難しい処理は頭を全振りして半日以上没頭して書きたいのですが、ここ半月はコロナの反動需要と年度末が重なって思うように時間が取れませんでした。
　そんな日々から解放されましたし、Delayのアイデア主であるプランナーさんに「連休前にはアルファ版見せます」と断言して締め切りを目の前にぶら下げましたので、これから半月は飛ばしましょう。開発費を頂戴している案件ではありませんから純然たる趣味の領域ですが、怠け者はお尻に火が点かんと怠けっぱなしです。

　こんな日(4/1)ですが、ウソではありません。

#ノリと勢いスイッチ

348文字編集

電装工芸 (admin) 2022年4月3日日曜日 21:44:34 Post No.217

　Art-Netパッチは入力部の書き直しが終わったようです。
　「ようです」というのは動作確認が済んでいないからです。一見正常に動いていますが、エラーが出る条件を考えて色々試さないといけません。
　今回の書き直しはマルチマスタ対応です。HTPミキサー化とも言えますが、ミキサーにするのはオマケで、Art-Net送信機を複数繋げてもおかしな挙動に陥らない様にする対策です。
　複数の送信機のデータをHTPでミックスして内部の時間単位で並べます。[ 時間単位, ルート, スロットアドレス ]の３次元配列でデータをスタックします。
　パッチにしてもディレイにしても、この３次元配列からデータを取り出して処理しますから、これがどれだけ堅固に動作するかが肝です。

#Python #[Art-Net]

153文字編集

電装工芸 (admin) 2022年4月4日月曜日 11:38:39 Post No.218

　昨日、LED-BARの箱で使う本体の受けにポリエステル樹脂を塗布しました。今回はエアガンです。
　エアガンに慣れがないので上手くいったとは言えませんが、硬化すると表面が硬く滑らかに仕上がります。いいですね。
　ガス圧を低めにして先日作った換気扇を併用すると飛び散りが少なく作業が出来ます。

#ガチ工作

876文字編集

電装工芸 (admin) 2022年4月4日月曜日 19:17:28 Post No.219

　荒天のため時間が空いたので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]

196文字編集

電装工芸 (admin) 2022年4月5日火曜日 12:54:03 Post No.220

　マルチマスタ処理はHTPではなく選択式が良い気がしてきました。
　HTPは同じスロットの高い値を採用しますが、ムービングの制御においてはよくありません。かといってLTPが良いワケでもない。
　ならば受信する卓(送信元IPアドレス)を選択したらどうかというアイデア。

　この処理をするには入力部の大幅な変更が必要です。
　・・・まだまだかかるなぁ。

#Python #[Art-Net]

448文字編集

電装工芸 (admin) 2022年4月5日火曜日 19:24:18 Post No.221

　送信元をIPアドレスで選択する方法は簡単でした。丁寧に書いてきたおかげで左程の書き換えもせずに対応できそうです。
　現在受信中の送信元一覧を得るためのプロセス間通信チャンネルを追加し、指定した送信元のデータだけを取り出す試験はものの数分で終わりました。
　この後、一連の処理を関数化すれば完成です。
　ただ、ライトアップのバラシに気力体力が奪われているので方向性が見えたところで終わりにします。丸一日、お日様を浴びながら立ったりかがんだりを延々繰り返していたので流石にシンドイ。集中力が落ちている時に書き進めるといいことはありません。

　受信モジュールから取り出す際、それなりに大きな３次元配列からスロット毎の最大値を取り出す処理が不要になったので処理が少し軽くなりました。
　送信元を選択式にするとバックアップ卓の切り替えに使えますし、フェスなどで複数の卓を切り替えて使う際にも使えます。パッチは一意で卓を切り替えて使えるとかなり便利だと思います。

#Python #[Art-Net]

516文字編集

電装工芸 (admin) 2022年4月6日水曜日 19:57:38 Post No.222

　送信元をIPアドレスで選択する方法は完成。ライブラリの段階ですから、コマンドで現在受信中の送信元一覧を取得し、IPアドレスを送って設定する機能の追加です。最終的にはユーザーインターフェースからこれらのコマンドを使って指示します。
　その他の訂正は、Delayのためのスタック順を逆にし、定数を出来るだけ外から設定するようにしました。
　スタック順を逆にしたのは、Delay値で読み出す際の計算を簡単にするためです。スタックの際にポインタを加算で行うと読み出しでは減算になりますが、配列のインデックスを得る際に加算とmodを使うと配列を一括計算出来ますから、スタックの際のポインタ計算を減算にしました。なんのこと？ですけど・・・。

　そんなこんな、基本機能の煮詰めをしていたら時間オーバー。
　今日も今日とてライトアップのバラシをしてきた昭和産まれのオジサンは、これ以上頑張ると明日に差し障ります。
　風呂して一杯飲んで寝る時間です。

　基本機能は見るたびに直しや追加が出てなかなか終わりませんが、ここが肝なので、アタマが働く状態で取り組んで後で直しが出ないようにした方が良さそうです。

#Python #[Art-Net]

459文字編集

電装工芸 (admin) 2022年4月7日木曜日 18:20:33 Post No.223

　ライトアップのバラシで半日イントレに登っていたら気力の残量がゼロ。
　今日は工作作業をオフです。

　そういえば中国に頼んでいた基板が入荷。
　とてもキレイです。こんな上物がこの数でこの価格？と素直に思えます。有難いを越えて商売になっているのか心配になるほどです。
　リフローハンダで使おうと思って手配した工業用のホットプレートも入荷。
　気力が残っていれば、次のオフでリフローハンダの実験をしたいなと。

　リフローハンダが上手くいけば、随分前に試作だけしたTASCAM製プレイヤーのリモコンも作ろうかなと。
　所属会社の音響君たち曰く、バックアッププレイヤーも同時制御出来ると心強いらしい。同じソースを入れておくのは言うまでもありませんが、RS232を２分配するだけで２台同時に動くので難しいことはありません。
　今となってはMD/CDではなくCDプレイヤーが主になっていますが、TASCAM製のプレイヤーはRS232による制御方法がほぼ同じなので基本的な機能だけなら高い互換性を持たせられます。

#電子工作

1303文字編集

電装工芸 (admin) 2022年4月8日金曜日 23:04:10 Post No.224

　ロシアのウクライナ侵攻に解決が見えませんね。
　報道からは絶対悪のロシアと絶対正義のウクライナとしか聞こえてきません。
　本当にそうでしょうか。
　ロシアが武力で国境を侵したことは間違っていると思いますが、ウクライナが一方的に正しいとは思えないのです。

　前提として、共通の損得って意味で越えてはいけないボーダーラインはあると思いますが、正義は人の数だけ存在する概念であって絶対正義は存在しないと考えています。どんな宗教でも経典を解釈する人次第で神の意志が違うことからも明白な事実です。聖書を根拠に指導者を越えた権力者がいることも権力を欲する人の正義ですから。
　国は人の集合体であり、限られた人の思惑が方針を大きく左右するとしても、概念的には総意で方針が決まるモノです。かのナチスであっても、先進的とされたワイマール憲法の上で民意を受けた正式な手続きを経て発生しています。一定以上の権力を得た後、あのような流れになったことは残念でありますが、民意がそれを作ったことは歴史に明記されております。
　こんなことから、目先の「かわいそう」で被害者と加害者を線引きしている今の風潮にはナチスが発生した経緯と同じこと感じ、危険な匂いすらします。

　この件は「火のない所にナントやら」だと思うのです。経済的に余裕があるとは思えないロシアが膨大な戦費がかかることを承知でこんなことをしたがるのでしょうか。権力者の強欲やプライドがあったとしても、それだけを理由にこのようなことをするメリットは思い浮かびません。戦争は経済活動の極端な方法だと私は考えますが、今回の侵攻が強欲から来ているとするなら経済的なメリットが全く思い浮かばないのです。
　とするなら、ウクライナがロシアに対してプライド的に許せない非礼を働いたとするのが自然だと思うのです。感情的になれば経済的なメリットは後回しになりますからね。第一次世界大戦も、某国の王族の王子が暗殺されたことが発端ですが、一部の高貴な方々のプライドから世界大戦にまでなっています。なんとなく似ているような感じがします。
　もちろん、ウクライナ国民が総勢でロシアに非礼を働いたとは思いませんけど。

　ただ一つ、危惧するのは現在のウクライナ政府がネオナチ系と噂されることです。
　前述の通りナチスは正式な民意を受けて権力を得ていますが、その過程においてはベルサイユ条約によって卑下されたドイツ国民を煽って扇動した経緯があります。あくまで私の勘であって説明出来ることではないのですが、今のロシア絶対悪的な報道にナチスが権力を握る流れと同じ匂いを感じてしまうのです。

　もちろん、何の悪意も持たず、平和に過ごしたいと思っている一般市民が戦争被害者になっている現実は許せることではありません。
　ただ、被害者がいるからその国の政府は正義とするのは短絡過ぎるのではないか？と疑問に思うのです。

　なんかこう、予想外の攻勢で第三帝国が潰される発端を作ったソビエト連邦にネオナチが罠を仕込んで仕返しをしているようにも思えたりします。
　ハイウッド映画風に解釈すればですが(笑

#雑談

278文字編集

電装工芸 (admin) 2022年4月9日土曜日 18:40:54 Post No.225

　体中が痛い。病気ではありません。
　昨日はテレビの中継現場でした。夜桜がネタだったので当然ライトアップするのですが、落差10mはあろう谷底に桜がありました。その谷を降りたり登ったりを繰り返したワケです。当然脚を酷使しますから疲労困憊。今日もライトアップのバラシでしたので輪をかけて疲労困憊。オッサンにやらせる日程ではない。

　今日も工作はオフですが、作業の合間にArt-Netの処理をまとめましたので、明日は少し進めようと思います。

　今のところArt-Netの処理は堅調です。
　このまま書き進めれば使い物になりそうです。

#[Art-Net]

182文字編集

電装工芸 (admin) 2022年4月11日月曜日 16:16:11 Post No.226

　昨日はオフでしたが、体中が痛くて身動き取れず。
　リフローハンダの試験をしたいのですが、何時になることやら・・・
　今日も今日とてライトアップのバラシ。
　日中は春らしく暖かくなってきましたが、陽が暮れると気温が下がりますので、朝早めに始めて定時間やって上がりにしています。
　せめてArt-Netのライブラリを進めておくことにします。

#[Art-Net]

748文字編集

電装工芸 (admin) 2022年4月11日月曜日 20:03:14 Post No.227

　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]

699文字編集

電装工芸 (admin) 2022年4月12日火曜日 09:01:03 Post No.228

　Rasbianをbullseyeのアップグレードしてみました。
　今までにない設定が少しありましたが普通にDebianです。
　Pythonは3.9.2まで上がっています。ここ数年で追加された新機能がほとんど使えます。

　すべての方法を試したワケではありませんが、Pythonのプロセス間通信は全般的に遅いのかもしれません。マルチプロセス処理は、常に通信しながらの並行処理ではなく、重い処理を別なところでやって結果を取り込むという発想で作られている感じがします。
　となると、ユーザー操作や設定データ(パッチマップ、プロファイルカーブマップなど)の作成は別プロセスで行うとしても、受信から送信までのArt-Netの一連の処理はシングルプロセスで行うのがいいのかもしれません。プロセス間通信のオーバーヘッドを無くすためです。

追記

　少し調べを進めてみました。
　Queueは使い勝手がいいのですが、トラブルが起きにくい様にマネージされているので挙動が遅いようです。
　プロセス間通信にはPipeや共有メモリなどQueue以外にも幾つか方法がありますが、速度が出る方法は管理が難しく、管理が簡単な方法は速度が出ないという関係にあるようで、管理が簡単で速度が出る方法は無い様子。
　仮に速度が出るとされる方法を使ってもカレントプロセスの変数を扱うほどの速度は出ませんので、外部とのやりとりはQueueなどを使うとしても、常駐する繰り返し処理はシングルプロセスで単純化を狙った方が良い結果になりそうです。
　全体的にマルチプロセスで外に出すってことです。

#Python #[Art-Net]

230文字編集

電装工芸 (admin) 2022年4月13日水曜日 10:55:29 Post No.229

　今日も今日とてライトアップのバラシ。
　規模は大きいですが、10日間で終わりが見えてきました。

　そんな現場作業をしながらArt-Netの受信処理を考え直しています。やらなきゃならない処理内容は見えましたから、主に処理の順序の整理です。
　順序を整理していくとコンパクトでシンプルな内容になってきます。これまで書いてきたモノは試しながら書き加えをしてきましたから、部分というより基本的な構造に無駄があったようです。

#Python #[Art-Net]

232文字編集

電装工芸 (admin) 2022年4月13日水曜日 16:18:04 Post No.230

　どうしたのか、所属会社のネットワークがインターネットに接続出来なくなる。LANで内側サーバー機にアクセスする分には正常。
　ゲートウェアサーバーを覗くとPPPoEのインターフェースにIPアドレスが表示されない。これは光回線側が落ちているサイン。
　ゲートウェアサーバーと光回線インターフェースを再起動したりと、わちゃわちゃしているウチに何事もなかった様に接続が回復。
　ライトアップのバラシから上がってきてこういった対応をするのは気が滅入ります。

#サーバー

603文字編集

電装工芸 (admin) 2022年4月13日水曜日 21:09:57 Post No.231

　Art-Netの受信送信処理を書き直しました。
　multiprocessing.Processで単独のプロセスにしていますが、一つの関数で受信から送信まで一貫処理です。
　処理単位で関数化しないのはPythonらしくない書き方ですが、細かく分けるとデータの受け渡しの時間が勿体ないので、ソースの美しさや読みやすさよりも動作速度に余裕を持たせたいところです。とはいうものの、関数に分けることも可能な書き方をしています。関数化しても他から読み出すことがない処理ばかりですからひとまとめの平文でもいいでしょう。
　処理負荷をtopで見ると26%くらい。今までよりも15～20%くらい軽くなっています。今後パッチ、ディレイ、プロファイルカーブの処理もこの関数・プロセスに追加していきますが、現段階では余裕があるように思います。
　もちろん複数の卓を繋げた時のオーバーフローによる遅延は解消しています。受信の入口に近いところにIPアドレスによるフィルタを入れて余計な処理を減らしたためです。現在８ユニバースですが、気になる遅れはありません。受信している卓のIPアドレスはすべてキャッシュしていますから、将来的に現在受信中のIPアドレスを表示することは可能です。
　本丸のパッチ処理をなかなか書き始められませんが、結果的にソースがすっきりして軽くなったのでヨシとしましょう。

#Python #[Art-Net]

251文字編集

電装工芸 (admin) 2022年4月14日木曜日 11:28:25 Post No.232

　ライトアップの片づけはほぼ終了。
　これからは少ない現場を淡々とこなしていく日々が続くので開発のペースを上げられそうです。
　作り変えたArt-Netの受送信処理は正しく動いているように見えます。この手の物にはコマンドの書き間違えではなくハードウェアの理解不足に起因するエラーが隠れていることがあるので、それを見つけることが難しかったりします。・・・そういった意味では、PICマイコンをアセンブラで書く方が楽だったりします。アセンブラは馬鹿正直ですから。

#Python #[Art-Net]
　

360文字編集

電装工芸 (admin) 2022年4月14日木曜日 23:14:18 Post No.233

　Art-Netはテスト用のマップでパッチとディレイが機能しました。プロファイルカーブはこれからですが、パッチとディレイが動けば理屈は同じです。
　ただ、配列変数の扱いで少し難儀しました。参照渡しになる規則がまだわからん・・・
　ドライバレベルの基本動作がようやく出来た段階なので先は長いですが、処理負荷も軽くていいんじゃないかと。
　ただ、処理を増やしたのに処理負荷が減っている。動くべきは動いているのに何故？

追記

　プロファイルカーブの処理も試し書きが一発OK。
　ムービングで試しましたが、ディマーだけノンディマーになる。
　もちろん、ディマーにだけディレイをかけられる。
　なんか面白い。

　どうやら処理の核は出来たらしい。
　一晩寝かせてから総チェックします。

#Python #[Art-Net]

699文字編集

電装工芸 (admin) 2022年4月15日金曜日 01:19:03 Post No.234

　Art-Netパッチは一番の課題をクリアしたワケです。
　規格書を翻訳するところから始まって４ヶ月間、ヒマが無くても考え続けてきましたから、嬉しいと言えば嬉しいですが、肩の荷が下りてホッとした気持ちが強いです。
　予想外の何かは残っていると思いますが、一番大きな山を越えたのかな。

　今後はimport出来るライブラリとしてまとめ上げ、先日基板を作ったSPI-DMXの試作です。
　ライブラリにするのはそれほど難しくありません。動作試験用に書いたmainを機能別に関数化して外から呼べるようにするだけです。
　SPI-DMXは、Art-Netパッチに組み込むか、別の装置としてArt-Netデコーダにするか、試作しながら考えたいと思います。RaspberryPiのSPIで大きなデータを扱ったことがないので、Art-Netパッチに組み入れられるかわからんのです。

　最終的な装置にまとめ上げるには筐体の製作もあります。簡単そうで難しい電源の入り切りや停電対策などもあります。
　まだまだやらねばならないことが多く、主機能が一応動いたからと喜んでもいられんのです。

　近々の目標は、最低限の設定操作が出来るところまで作ってDMX-Delayをリクエストしてくださったプランナーさんに主機能を確認して頂くことです。望まれているニュアンスで遅れるかが最も大事ですから。
　ベニヤ板に基板やモジュールをネジ止めした姿での確認になりそうですが、中身が決まらないと筐体の設計は出来ませんのでよいのです。

　願わくば、Ｐ社のＷ君にも確認してもらいたいなぁ～(笑

#Python #[Art-Net]

292文字編集

電装工芸 (admin) 2022年4月15日金曜日 15:37:52 Post No.235

　オフですが、用事が早く終わったのでArt-Netを書き書き。
　ライブラリ化が完了。importしてインスタンスを作ればArt-Netの受送信が始まり、インスタンスから関数を呼び出して設定変更や現在値の読み出しが出来ます。
　とりあえずこんなもんかな。

追記

　送信元を切り替える動作も確認しました。
　まだユーザーが選択するようにはしていませんが、５秒毎に切り替えるテストプログラムで正常に動作。
　SPI-DMXの処理もイメージがまとまってきました。Art-Netの出力処理内にthreadingで間借りすればすんなりいきそうです。

#Python #[Art-Net]

481文字編集

電装工芸 (admin) 2022年4月16日土曜日 08:31:21 Post No.236

　Art-Netの受送信がまとまったので、SPI通信の復習を始めました。人の操作部も大事ですが、ドライバレベルの繰り返し処理が成り立たなければ始まりません。
　SPIは受信ハードウェアが無くても送信動作は可能ですから、ソフトウェア的に処理の負荷がかかる様にして試すのは重要です。

　SPI通信を使うのはRaspberryPiから複数のDMXを出力する為です。RaspberryPiにはシリアルポートがありますが望む数はありません。何かしらの方法で拡張しなければなりませんが、私が扱える方法で組むならPICをフロントエンドにして数を増やしますので、PICと通信するのにSPIを使います。

　SPIがどんな通信かは諸兄達に任せますが、RspberryPiでもPICでも扱えて複数のDMXを扱うのに十分な速度を持った通信です。
　RaspberryPiにおいては、SPIを扱うハードウェアモジュールが搭載されているためにソフトウェアには負担がかかりませんので、周辺デバイスとの簡素な高速通信としてとても有効です。

#RaspberryPi #[Art-Net]

506文字編集

電装工芸 (admin) 2022年4月16日土曜日 13:51:22 Post No.237

　RaspberryPiのpythonでSPIで使うためのライブラリspidevの本家はこちら。
　本家とは違いますが、こちらのサイトはRapberryPiのSPIについてよくまとめられています。ロシア語なんで原文のままではちっともわかりませんが、本家を読んでもわからなかったことがここで解決します。翻訳して転載したらすごく参考になるかも。
　一見簡素な内容ですが、SPIの何たるかはこのサイトがわかりやすいかも。SPIには４つのモードがありますが、その違いを分かりやすく書いてくれている資料が少なくて困っていたところ、このサイトを読んで理解できました。シリアル通信に何の知識も無い人に向けた資料ではありませんが、UARTやI2CはわかるけどSPIがイマイチなぁ～って人にはお勧めです。SPIは少し独特な考え方を持っていますが、そのツボ処だけ簡潔に抽出しています。私は、マイコン全般の教科書と言ってもいいPICのマニュアルを読んでもSPIがどうしても理解できなかったのですが、このサイトを参考にPICのマニュアルを読み直したところ「なるほどー！」となりました。

#RaspberryPi #[Art-Net]

889文字編集

電装工芸 (admin) 2022年4月16日土曜日 18:10:30 Post No.238

　Art-Netドライバには追加しないといけないことがあります。
　受信したデータにパッチなどを施して送信することには成功しているのですが、現時点ではフリーフェーダーやスタックフェーダーを考慮していません。
　当初は[受信するプロセス]-[受信部からデータを取り出して加工するプロセス]-[加工したデータを受け取って送信するプロセス]と分けてイメージしていたので加工するプロセスで出来るだろうと思っていたのですが、プロセス間通信のオーバーヘッドを軽減するためにこれらを１つのプロセスにしましたので同じ考え方はできません。
　今もパッチ等のマップデータはプロセス間通信で差し込んでいますが、マップデータが変更された時だけ実行すればいいので頻度が低く問題になりません。されど、即反応して欲しいフェーダー操作の情報は違ってきます。データをどう扱うか、どの位置で処理するか、ちょっと難しくなってきます。
　フリーフェーダーだけなら特別なIPアドレス(例えば127.0.0.1)を用いた特別な経路でデータを取り込んでArt-Netと同列に処理する方法もありますが、スタックフェーダーにするにはちょっと無理があるように思ったりします。
　ただ、これらのフェーダーはバックアップ的な意味合いが強いので反応がやや遅くてもいいかもしれません。これが許されるならプロセス間通信でデータを差し込んでもいいでしょう。
　次のステップに入る前にここは片付けておかないといけません。

追記

　スタックフェーダーの方法はアイデアが出ました。Art-Netの入力を記憶します。ただし、記憶するユニバースなりスロットを指定出来ないとディマー以外の動作を邪魔することがあるので一種のフィルターが必要です。フィルターがあればフリーフェーダー的にも機能します。排他的ではなくHTPミックスになりますが、この方がいいでしょう。
　操作としては、記憶したい状態でスタックフェーダーとユニバースやスロットを指定してストアします。ユニバースやスロットが無指定ならすべてを記憶です。

#Python #[Art-Net]

903文字編集

電装工芸 (admin) 2022年4月18日月曜日 10:36:46 Post No.239

　中国からの物品が滞る状況が続いています。
　先日も、中華電器にお試し買いの発注をしたのですが、期日までに発送されず自動キャンセル。
　その外にも、中国で作っているであろう半導体部品が在庫切れなことが多く、RaspberryPiも小売りでは在庫切れが続いています。
　RaspberryPiは少し在庫しているので当面のソフトウェア開発には支障ありませんが、製品を作ることはできません。

　木材も高騰です。合板も角材も数倍の価格。まさか捨て材扱いされるような杉や赤松の野縁(30×40角)が高級品の様な価格になるとは思ってもいませんでした。しかも、手に入るのは節、捻じれ、曲がり物ばかり。ちょっとした物は鉄の角パイプで作った方が安いくらいです。新型コロナの影響に加え、ウクライナ侵攻によりロシアからの輸入が減ったことも大きいそうです。

　中国国内では新型コロナによるロックダウンで街全体が監禁状態と聞きます。発令された瞬間に居た場所から移動を禁じられ、自宅に居た人は自宅から出られず、勤務先に居た人は勤務先から帰宅出来ないそうです。何よりも、移動しないと仕事にならない運送業まで同じ扱いらしく、物流がほぼ止まっているのだそうです。もちろん、中国全域の話ではないのでしょうが、ロックダウンに至った地域は人が多く、人が多いのは商業産業が盛んな地域でしょうから、全体としてみれば生産活動が大幅に鈍っているのでしょう。
　報道から耳に入る話でもありますが、知り合いの工場は中国に協力会社を持っているのでリアルな話が聞けます。とにかく物が入ってこないそうです。電力が無い、人が行き出来ない、完成しても送れないとなればどうにもならんですよね。

　もちろん、我々が使う機材類も新規購入が難しくなるワケです。
　コロナがなんとなく過ぎ去った感じを受けて開催が増えていますが、それに合わせて機材を買い増ししようとしても今までの様にいきません。先日も音響系の問屋さんが来社されましたが、売りたくても売るものが入荷しにくいと言ってました。これではゴネても解決はしません。
　機材の買い増し手配はお早めに。

#雑談 #本業

563文字編集

電装工芸 (admin) 2022年4月18日月曜日 11:09:29 Post No.240

　Art-Netドライバはボチボチです。
　現場が無い日の定時後に2-3時間の作業ですから進みは遅いのですが、完成イメージは具体的になってきました。
　されど、まだまだ追加しないといけない要素は多いのです。

　今の課題はスタックフェーダーです。
　数本のスタックフェーダーを構成するのは簡単そうに思えますが、スロット一つ一つに対して条件分岐をして数値をいじるような処理ではいけません。条件分岐を多用して書くと意図が読み取りやすいソースになりますが処理は遅いのです。同じことを短周期で何回も繰り返す処理は、PICのアセンブラを書いてきたクセですが、単純な計算結果にフラグの意図も持たせたりして条件分岐を減らしたいのです。例えば、一定の範囲で繰り返す加算カウンタを作るとして、一定数になったことで条件分岐して初期値に戻すのが基本的な考え方だと思いますが、カウンタを繰り返し数で割った余りも同じ数値になります(この方法は一つの配列で複数のカウンタを構成する場合にも便利な方法です)。割り算が苦手なシステムでは無謀な方法ですが、Pythonは条件分岐が遅いように感じるので、この様な方法で軽くなることもあるようです。
　こんな感じで計算の中に条件分岐も含めるのは、将棋で数手先を考えるのとどこか似ています。

#[Art-Net]

684文字編集

電装工芸 (admin) 2022年4月18日月曜日 15:42:52 Post No.241

　ムービングの修理をしています。
　不調の現象は機体によって違いますが、今いじっている機種では特定の色が正常に点灯しない物が多い。点かなかったりフルにならなかったりです。
　一番困るのが、しばらくすると点かなくなる機体です。マイコンからの信号が途絶えるのか、ドライバICがサーマルプロテクトに入るのか、その他か・・・

　特定色が点かない機体はハンダ付けの不良が多かったようです。ハンダゴテを当てなおしたら大半が治るのですからクラックが入ってしまったのでしょう。
　しばらく使うと特定色だけ点かなくなるが電源を落としてしばらく放置すると復活する機体は電流検出抵抗のハンダを盛ると治ることが多いようです。ハンダが足りないために熱を帯びて抵抗値が上がってしまい、ドライバICが電流値を誤検出するのが原因と思われます。
　フルにならない機体も原因は同じ傾向のようで、ハンダゴテを当てなおしたりハンダを盛ると大半が回復します。ハンダを当て直しても治らない場合は、電流検出抵抗を交換すると高確率で治ります。

　ではどれが電流検出抵抗かと聞かれても答えるのは難しいです。使われているLEDドライバICのデーターシートを参考に基板の配線から読み解くしかないからです。ただ、機種は違えどLEDのドライブ回路は似たり寄ったりなので、基本的な回路様式を2-3パターン知っていれば読み解くのはそれほど難しくありません。

　もちろん、原因の全てがハンダ付けや電流検出抵抗にあるとは限りません。
　部品の取り付けをよく見て、甘そうなハンダを当て直すのが第一歩という話でした。

#電子工作

819文字編集

電装工芸 (admin) 2022年4月18日月曜日 16:28:03 Post No.242

　修理の話の続きです。

　電源モジュールがダメな機体もあります。
　起動しない機体、起動はするけど点灯させたり動かすと落ちる機体の２種類。

　起動しない機体は電源モジュールが単純に壊れています。大概FETが飛んでいますので交換すれば復活しますが、何故飛ぶかは原因究明が難しい。

　飛ぶFETがトランスより電源側の場合はサージ/スパーク対策の保護回路がダメな奴が多いようです。
　これらはコンセント挿すときに「パチッ！」と言うアレす。パチッとなるのはかなり高い電圧が流れるからですが、これがFETに流れたら一発で壊れます。こういった高電圧ノイズには大きく分けて二つあってサージとスパークです。どちらも定格以上の電圧が発生する現象ですが、前者が電源電圧の数倍で比較的時間が長いもの、後者は静電気の部類で電圧がとても高いのですがほんの一瞬のものです。似たような現象ですが、対策する回路が違います。
　サージ対策にはサージアブゾーバーを使うのが一般的です。ポリスイッチの一種で、高い電圧を受けると短絡してそれ以降の部品にかかる電圧を抑えます。サージ時間が長いと燃えますけどね・・・
　スパーク対策にはスパークキラーを使います。耐電圧が高く反応が速いコンデンサと抵抗をパッケージにした物で、コンデンサでスパーク電流を吸収します。スイッチではないので反応が速いのが特徴です。ただし、サージの対策にはいささか不向きです。
　飛ぶFETがトランスよりも出力側にある場合は原因究明が難しい。私は早々に諦めます。

　起動はするけど点灯させたり動かすと落ちる機体も電源モジュールの不良ですが、出力側のバッファコンデンサに異常があるか、出力電流を検知する回路が定格異常を起こして本来よりも低い電流値でプロテクトに入ってしまうことが原因に多いようです。

　修理は治った時の達成感はなかなかのものですが、その渦中は決して楽しくありません(笑

#電子工作

657文字編集

電装工芸 (admin) 2022年4月19日火曜日 11:02:39 Post No.243

　電源モジュールを見ていて不思議に思ったことがありました。
　基板に付いているサージアブゾーバーは680vの物です。計算値よりも少し高めの物を使うのはわかりますが、電源にほぼ直結のFETの定格は400v。守るべき部品の定格電圧よりもサージアブゾーバーのクリッピング電圧がこんなに高くていいのでしょうか。
　この電源モジュールはFETを何度か交換しています。交換する度に治るには治るのですが、使っているウチに同じ故障に陥ります。故障に陥るのは現場で最初に電源を投入する瞬間なので保護回路がダメなんじゃねーかと思っていましたが、アナログ回路が苦手な私でも被保護部品が400vで保護部品が680vでは意味を成していないように思います。FETは在庫を切らしているので入荷待ちですが、サージアブゾーバーは331K(クリップ電圧330v)が手持ちにあるので付け替えてみようと思います。FETは近しいスペックでスイッチング抵抗が半分以下の物で耐圧は500vです。

　中華電器の販売店さんに電源モジュールを売ってくれないかと相談中です。
　快諾してくれたのはいいですが、すでに廃盤品なので本体を作っていた工場では手に入らないとの回答。さらに探してみると言ってくれていますがどうなることやら。
　電源モジュールは汎用品ではありませんし、かなり小型なので同等品が見つかりません。販売店経由で新品を手に入れるか修理するかです。
　この調子では今後も電源モジュールの不調が発生しそうなので対策を確立しておこうと思います。

#電子工作

705文字編集

電装工芸 (admin) 2022年4月20日水曜日 09:39:50 Post No.244

　ムービングライトの整備作業がヒト段落したので、しばらく前に入荷したLED-BARの整備です。
　この手の器具はビームが細いレインライト的な物が大半ですが、このLED-BARは広角なのでLHQの代わりに使えます。LHQの1.2kw(100w電球)に対し90wですからかなりの低消費電力です。
　箱は丁度良さそうなプラ箱に受けの間仕切りを入れています。脚となる付属の金具は使い勝手が好みに合わないので作りました。
　箱の機構は完成しているので、本体と箱にカッティングシートでマーキングして金具類を取付けたら仕上がりです。

　このLED-BARは入荷した時点で３台NGでした。
　一瞬立ち上がりすぐに落ちます。筐体を開くとLEDモジュールが２セット入っている構成ですが、試しに片方のモジュールを外して起動すると正常に動きます。電源モジュールの定格を見るとギリギリなので、中国の電源(200～260v)での出荷チェックは正常でも日本の電源(100v)では力不足といったところでしょう。PAR球よりも安価な製品ですから、完成品ではなく「半」完成品と思ってローカライズと仕上げを自分でするつもりで買っています。
　解決方法は電源を入れ替えるか追加して電力に余裕を持たせることです。１台で電力を賄える電源モジュールはサイズ的に入りませんので別な電源モジュールを追加です。
　ただ、既設の電源モジュールは電圧が10.8vです。こんな定格電圧の物はレアですから、追加の電源モジュールは12vの製品のセンシング抵抗を替えて電圧を合わせればいいかと。スイッチング電源の制御ICの型番がわかれば比較的簡単な改造です。

#照明器具

1029文字編集

電装工芸 (admin) 2022年4月21日木曜日 11:48:42 Post No.245

　スポットライト群の整備は部品の入荷待ちで一時停止。

　社内のサーバーの整備です。ファイルサーバーのHDDの入れ替えをします。
　WindowsServer2008R2上のRAID1で動かしている２台１組のうち１台が飛んだのですが、飛んだ物を交換した応急処置のままでした。動いているもう１台も同時期の物ですから壊れる前に交換しようという作業です。
　RAIDとは複数のHDDやSSDを１台のストレージとして動かす方法です。RAID0はストライピングと呼ばれ、主に速度の向上を狙ったものです。RAID1はミラーリングと呼ばれ、複数のHDDに同じデータを書き込みバックアップを目的にしたものです。その他にもRAID0やRAID1を複雑に組み合わせる方法もあります。
　ファイルサーバーですからRAID1(ミラーリング)を用いています。複数のHDDに同じデータを書き込みますので、同時に壊れない限りデータを失うことなく機能が継続します。新しいHDDに入れ替えれば自動的にデータがコピーされてミラーリング状態が回復します。同時にバックアップが出来、稼働させながらHDDを交換できるとても便利な方法です。
　ただし、RAIDにはOS(ソフトウェア)によるものとチップセット(ハードウェア)によるものがあり、違うシステムではRAIDとして機能しないばかりでなく読み出せないことがあります。今まで扱った中ではIntelのハードウェア式が他のシステムでも読み出せることが多いので、Windows系を組む場合はIntelのハードウェアRAIDを使うようにしています。これならWindowsでなくてもLinuxでも読み出せます。Linux系であればOS標準のソフトウェアRAIDが良いようです。

　今はバックアップを取っています。
　他のサーバー機で日常的にバックアップを取っていますから余計な手間っちゃ手間ですが、こういった「おまじない」というか「願掛けに」に近いことをしてから進めるようにしています。何故かわかりませんが、どんなに丁寧に日常バックアップを確認してから始めても余計な手間をすっ飛ばして作業すると高確率でデータ異常が発生し、日常バックアップを確認しなくても余計な手間をかけると異常が発生しません。不思議ですが、当然のようにそうなるのです。
　持って生まれた運みたいなものでしょうけど、どうせかかる時間なら精神的なストレスが少ない方がいいかなと。

#サーバー

939文字編集

電装工芸 (admin) 2022年4月21日木曜日 18:12:51 Post No.246

　サーバーはIntelのRSTに便利な機能があって比較的少ない手間でいけていますが、使っているマザーボードが古いためにSATAの上限が2TB。購入当時のお値段は2TBのHDDと大差ありませんでしたが、せっかくの4TBのHDDがフル機能せず。2TBでも容量は十分足りていますが、その制限がわかるまでに余計な時間を使ったかも。将来的にマザーボードを替えれば容量を拡張出来るのでいいでしょう。

　ムービングは部品が入荷したので電源モジュールを修理。
　あえてサージアブゾーバーはそのままにFETだけ替えて試したところ一発アウト。サージアブゾーバーとFETを替えたところOKでした。
　ただ、電源モジュールのコンデンサが完全に空になった状態で試さないと意味がありません。コンデンサが完全に空の状態で電源を投入すると大きな突入電流が発生し、その瞬間に大きな電圧も発生するからです。数日放置して再チェックです。この機体はＲだけ弱い不良もあります。照度計で測ると1/3くらいですが、弱いなりに調光は効くので電流検出抵抗がおかしいと思われます。基板上の計測ですから正確ではありませんが、ツジツマは合うので抵抗を付け替えれば治ると思います。ただ、国内では手に入りにくい抵抗(表面実装の2512サイズ)なので中華電器にオーダー。連休明けに入荷予定です。
　もう一台ダメなのがあります。起動直後は元気一杯動くのですが、LEDフル点灯で動かし続けるとおかしくなってきます。挙動を見ると使っているウチに電源電圧が下がるのだと思われます。この微妙な不良は頂けません。ハンダ不良か部品の不良によって過加熱が起こってのことだと思いますが、原因を特定するのはかなり難しく、電源モジュールを替えたいところです。中華電器の販売店に電源モジュールの手配を相談していますが最終的な返答はありません。
　電源モジュールは12vと24vのデュアル。デュアルで小型だから代替品が無いのです。12vが制御とLED、24vがモーターといった分別みたいです。動きは正常だけどLEDがおかしくなるので12v系がダメなんだと思います。ハンダ不良くらいなら見てわかるからいいけど、そうでないと特定は難しい・・・

#照明器具 #サーバー

197文字編集

電装工芸 (admin) 2022年4月22日金曜日 18:05:02 Post No.247

　サーバーの保守は終了。ストレージの容量が数倍に増えたのでしばらく大丈夫でしょう。読み書き領域の他に読み出し専用の領域も作り、古いデータのアーカイブにしました。
　時間が余ったので電話の交換器の無停電電源のバッテリーと内部メモリー用のボタン電池も交換。設定のバックアップも整理して保存。電池交換の際に設定データが消えますがバックアップを使って回復。
　用務員風味な一週間でした。

#サーバー

264文字編集

電装工芸 (admin) 2022年4月27日水曜日 09:51:24 Post No.248

　サーバーは順調に動いてくれています。RAIDも問題ありません。
　案外複雑なバックアップも取っていますので、これらの動作確認も大切です。

　連休は何気に忙しくなりました。
　コロナが収まった感での「やっぱり開催」的なバレエのおさらい会が数本あります。
　舞監ではなくリノ敷き道具さんですから大変ではありませんけど。

　そんな準備があるので工作は一時休業です。
　Art-Netドライバを仕上げたいところですが、微妙な書き加えなのでアタマを全振りしないと出来ません。空いた時間に少しづつって訳にはいかないのです。

#本業

933文字編集

電装工芸 (admin) 2022年4月27日水曜日 14:12:40 Post No.249

　デジタル庁が「デジタル推進委員」と称する人材を募集するそうです。
　岸田首相の掲げる「誰ひとり取り残されないデジタル化」を実現するための方策とのこと。
　平均的にパソコンやスマホを苦手とする年配者にそれらの使い方を教える先生的な役割らしい。
　雇用の促進になるならいいんでないか？と思ったら、交通費等の必要経費は出るものの無給だそうな。。。
　耳を疑う話ですが、デジタルな知識や技術に社会的な価値は無いとデジタル庁が言っているに等しい。
　専門知識と人に教える技能と忍耐を持った人でなければ何の成果も出ないのにアホかと思います。

　そもそも、年配者にそこまで配慮する必要があるのかな？必要なら自ら学ぶべきことでしょう。
　実母はスマホはおろか携帯すら持ったことのない人ですが、何不自由なく生活してます。
　別段求める訳でもなく、無いなら無いなりに生活出来ている人たちに何を学んでもらおうというのでしょう。

　デジタル化の究極は「電子執事」です。
　主人の意図を読み取って先んじて準備を進めて遅れることなくサービスを提供していれる存在です。
　「デジタル化」と呼ばれることは程度の差はあっても目指している先はこれだと思います。
　ならば、年配者に対してはデジタル化というサービスがまだまだ未熟です。一方的に気を使ってくれるレベルに達していないのですから。

　そもそも「デジタル化に取り残される」とはどういった社会問題なのでしょう？
　政治家さん自身がゴール地点をイメージ出来ているのか？そこが一番の問題点だと思います。

　1985年時点で坂村教授(当時助教授)が提唱したTRONの思想を国が守るべきでした。
　あくまで思想であって商品とは言いませんが、当時坂村教授が書いたTRONに関する書籍を読んで目からウロコでした。
　そして、その本に書かれていた未来像が正に今実現されています。
　必要なのは、過去の事例を沢山知っているだけの専門家ではなく、未来を予言出来る専門家です。そして、その未来像を理解して実現出来る政治家です。
　デジタル化とか言いますが、その実態は機械であっても、そこにある思想が最も大事なことに偉い人がもっと敏感になるべきです。

#雑談

347文字編集

電装工芸 (admin) 2022年4月27日水曜日 21:39:35 Post No.250

　実作業はなかなか進みませんが、Art-Netドライバの方針が整理出来ています。
　Pythonについて継続して調べていますが、そんな中で遭遇した「PythonはC++で書かれたライブラリを呼び出すプラットホーム」というご意見に納得。
　Pythonは処理が遅い。変数の型の定義が曖昧でも何となく動くのは便利だけど、大事な時に変数の型のミスマッチでエラーが出るのは面倒。けれど処理の構図を作る生産性は高く、変数の型も意識して書けば問題になりません。C++で部分の関数を書いてPythonでまとめるのは良い方法だと思うのです。
　なので、先のご意見には納得なのです。
　Cythonではなく、Pythonコードから完全なバイナリに直接コンパイルする方法があったらなと思います。

#Python

804文字編集

電装工芸 (admin) 2022年4月30日土曜日 20:23:53 Post No.251

　このところ本業が忙しい。
　現場があるのは嬉しいことでありますが、発注側の段取りの悪さの尻拭いで時間を割かれることが多く気分は良くない。

　Art-Netはアイデアだけまとまって書くところまで行けてません。ちょっと寂しい。
　ちなみに、Art-Netの処理モジュールは「Art-Netエンジン」と呼ぶことにしました。
　受信したデータにスタックフェーダー、ディレイ、パッチ、プロファイルの処理を施して送信するまでを１プロセスのモジュールにしてしまったので、やっていることがドライバって括りにするには広すぎるからです。
　書き加えてない機能はスタックフェーダーですが、現時点の処理負荷は26%前後です。最終的に50%を割ればいいのではないかと思います。
　処理負荷ですが、ANSIエスケープシーケンスによる表示処理が思った以上に重いことが判明。純Pythonでの繰り返し処理が多いからか、そもそもテキスト表示が遅いのか、いずれにしてもArt-Netエンジンと表示処理は完全にプロセスを分けないといけません。
　まだ試していないのですが、ひょっとするとテキストベースよりもグラフィカルの方が処理が軽い可能性があります。扱う情報量は多くなりますが、ハードウェアでアクセラレーションされてるならひょっとするかもです。

　表示モニタは中華電機で良さそうなのを見つけました。1024x768(4:3)で８インチです。組み込み用のオープンフレームモニタなので取り付けが楽です。価格も案外安い。
　今どき4:3?って気もしますが、表示するのは表ですから、16:9よりも4:3の方が見やすい気がします。
　また、あえての4:3だし、扱っているセラーが多く、組み込み用なので長期間の入手が期待出来ます。普通のモニターですと足が早くて半年後には同じ物が手に入らなくなることが多いのです。

#ガチ工作 #[Art-Net]