https://www.densokogei.jp/tegalog/tegalog.cgi ja Copyright 2026 Wed, 03 Jun 2026 15:33:11 +0900 Powered by てがろぐ Ver 3.4.0 ]]> 　現場があるのは嬉しいことでありますが、発注側の段取りの悪さの尻拭いで時間を割かれることが多く気分は良くない。

　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] -- Posted by 電装工芸 〔804文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=251 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=251 tegalog Sat, 30 Apr 2022 20:23:53 +0900 　Pythonについて継続して調べていますが、そんな中で遭遇した「PythonはC++で書かれたライブラリを呼び出すプラットホーム」というご意見に納得。
　Pythonは処理が遅い。変数の型の定義が曖昧でも何となく動くのは便利だけど、大事な時に変数の型のミスマッチでエラーが出るのは面倒。けれど処理の構図を作る生産性は高く、変数の型も意識して書けば問題になりません。C++で部分の関数を書いてPythonでまとめるのは良い方法だと思うのです。
　なので、先のご意見には納得なのです。
　Cythonではなく、Pythonコードから完全なバイナリに直接コンパイルする方法があったらなと思います。

#Python -- Posted by 電装工芸 〔347文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=250 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=250 tegalog Wed, 27 Apr 2022 21:39:35 +0900 　岸田首相の掲げる「誰ひとり取り残されないデジタル化」を実現するための方策とのこと。
　平均的にパソコンやスマホを苦手とする年配者にそれらの使い方を教える先生的な役割らしい。
　雇用の促進になるならいいんでないか？と思ったら、交通費等の必要経費は出るものの無給だそうな。。。
　耳を疑う話ですが、デジタルな知識や技術に社会的な価値は無いとデジタル庁が言っているに等しい。
　専門知識と人に教える技能と忍耐を持った人でなければ何の成果も出ないのにアホかと思います。

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

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

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

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

#雑談 -- Posted by 電装工芸 〔933文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=249 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=249 tegalog Wed, 27 Apr 2022 14:12:40 +0900 　案外複雑なバックアップも取っていますので、これらの動作確認も大切です。

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

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

#本業 -- Posted by 電装工芸 〔264文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=248 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=248 tegalog Wed, 27 Apr 2022 09:51:24 +0900 　時間が余ったので電話の交換器の無停電電源のバッテリーと内部メモリー用のボタン電池も交換。設定のバックアップも整理して保存。電池交換の際に設定データが消えますがバックアップを使って回復。
　用務員風味な一週間でした。

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

#照明器具 #サーバー -- Posted by 電装工芸 〔939文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=246 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=246 tegalog Thu, 21 Apr 2022 18:12:51 +0900
　社内のサーバーの整備です。ファイルサーバーの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が良いようです。

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

#サーバー -- Posted by 電装工芸 〔1029文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=245 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=245 tegalog Thu, 21 Apr 2022 11:48:42 +0900 　この手の器具はビームが細いレインライト的な物が大半ですが、このLED-BARは広角なのでLHQの代わりに使えます。LHQの1.2kw(100w電球)に対し90wですからかなりの低消費電力です。
　箱は丁度良さそうなプラ箱に受けの間仕切りを入れています。脚となる付属の金具は使い勝手が好みに合わないので作りました。
　箱の機構は完成しているので、本体と箱にカッティングシートでマーキングして金具類を取付けたら仕上がりです。

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

#照明器具 -- Posted by 電装工芸 〔705文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=244 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=244 tegalog Wed, 20 Apr 2022 09:39:50 +0900 　基板に付いているサージアブゾーバーは680vの物です。計算値よりも少し高めの物を使うのはわかりますが、電源にほぼ直結のFETの定格は400v。守るべき部品の定格電圧よりもサージアブゾーバーのクリッピング電圧がこんなに高くていいのでしょうか。
　この電源モジュールはFETを何度か交換しています。交換する度に治るには治るのですが、使っているウチに同じ故障に陥ります。故障に陥るのは現場で最初に電源を投入する瞬間なので保護回路がダメなんじゃねーかと思っていましたが、アナログ回路が苦手な私でも被保護部品が400vで保護部品が680vでは意味を成していないように思います。FETは在庫を切らしているので入荷待ちですが、サージアブゾーバーは331K(クリップ電圧330v)が手持ちにあるので付け替えてみようと思います。FETは近しいスペックでスイッチング抵抗が半分以下の物で耐圧は500vです。

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

#電子工作 -- Posted by 電装工芸 〔657文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=243 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=243 tegalog Tue, 19 Apr 2022 11:02:39 +0900
　電源モジュールがダメな機体もあります。
　起動しない機体、起動はするけど点灯させたり動かすと落ちる機体の２種類。

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

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

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

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

#電子工作 -- Posted by 電装工芸 〔819文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=242 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=242 tegalog Mon, 18 Apr 2022 16:28:03 +0900 　不調の現象は機体によって違いますが、今いじっている機種では特定の色が正常に点灯しない物が多い。点かなかったりフルにならなかったりです。
　一番困るのが、しばらくすると点かなくなる機体です。マイコンからの信号が途絶えるのか、ドライバICがサーマルプロテクトに入るのか、その他か・・・

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

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

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

#電子工作 -- Posted by 電装工芸 〔684文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=241 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=241 tegalog Mon, 18 Apr 2022 15:42:52 +0900 　現場が無い日の定時後に2-3時間の作業ですから進みは遅いのですが、完成イメージは具体的になってきました。
　されど、まだまだ追加しないといけない要素は多いのです。

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

#[Art-Net] -- Posted by 電装工芸 〔563文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=240 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=240 tegalog Mon, 18 Apr 2022 11:09:29 +0900 　先日も、中華電器にお試し買いの発注をしたのですが、期日までに発送されず自動キャンセル。
　その外にも、中国で作っているであろう半導体部品が在庫切れなことが多く、RaspberryPiも小売りでは在庫切れが続いています。
　RaspberryPiは少し在庫しているので当面のソフトウェア開発には支障ありませんが、製品を作ることはできません。

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

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

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

#雑談 #本業 -- Posted by 電装工芸 〔903文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=239 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=239 tegalog Mon, 18 Apr 2022 10:36:46 +0900 　受信したデータにパッチなどを施して送信することには成功しているのですが、現時点ではフリーフェーダーやスタックフェーダーを考慮していません。
　当初は[受信するプロセス]-[受信部からデータを取り出して加工するプロセス]-[加工したデータを受け取って送信するプロセス]と分けてイメージしていたので加工するプロセスで出来るだろうと思っていたのですが、プロセス間通信のオーバーヘッドを軽減するためにこれらを１つのプロセスにしましたので同じ考え方はできません。
　今もパッチ等のマップデータはプロセス間通信で差し込んでいますが、マップデータが変更された時だけ実行すればいいので頻度が低く問題になりません。されど、即反応して欲しいフェーダー操作の情報は違ってきます。データをどう扱うか、どの位置で処理するか、ちょっと難しくなってきます。
　フリーフェーダーだけなら特別なIPアドレス(例えば127.0.0.1)を用いた特別な経路でデータを取り込んでArt-Netと同列に処理する方法もありますが、スタックフェーダーにするにはちょっと無理があるように思ったりします。
　ただ、これらのフェーダーはバックアップ的な意味合いが強いので反応がやや遅くてもいいかもしれません。これが許されるならプロセス間通信でデータを差し込んでもいいでしょう。
　次のステップに入る前にここは片付けておかないといけません。

追記

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

#Python #[Art-Net] -- Posted by 電装工芸 〔889文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=238 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=238 tegalog Sat, 16 Apr 2022 18:10:30 +0900 ライブラリspidevの本家はこちら。
　本家とは違いますが、こちらのサイトはRapberryPiのSPIについてよくまとめられています。ロシア語なんで原文のままではちっともわかりませんが、本家を読んでもわからなかったことがここで解決します。翻訳して転載したらすごく参考になるかも。
　一見簡素な内容ですが、SPIの何たるかはこのサイトがわかりやすいかも。SPIには４つのモードがありますが、その違いを分かりやすく書いてくれている資料が少なくて困っていたところ、このサイトを読んで理解できました。シリアル通信に何の知識も無い人に向けた資料ではありませんが、UARTやI2CはわかるけどSPIがイマイチなぁ～って人にはお勧めです。SPIは少し独特な考え方を持っていますが、そのツボ処だけ簡潔に抽出しています。私は、マイコン全般の教科書と言ってもいいPICのマニュアルを読んでもSPIがどうしても理解できなかったのですが、このサイトを参考にPICのマニュアルを読み直したところ「なるほどー！」となりました。

#RaspberryPi #[Art-Net] -- Posted by 電装工芸 〔506文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=237 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=237 tegalog Sat, 16 Apr 2022 13:51:22 +0900 　SPIは受信ハードウェアが無くても送信動作は可能ですから、ソフトウェア的に処理の負荷がかかる様にして試すのは重要です。

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

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

#RaspberryPi #[Art-Net] -- Posted by 電装工芸 〔481文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=236 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=236 tegalog Sat, 16 Apr 2022 08:31:21 +0900 　ライブラリ化が完了。importしてインスタンスを作ればArt-Netの受送信が始まり、インスタンスから関数を呼び出して設定変更や現在値の読み出しが出来ます。
　とりあえずこんなもんかな。

追記

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

#Python #[Art-Net] -- Posted by 電装工芸 〔292文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=235 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=235 tegalog Fri, 15 Apr 2022 15:37:52 +0900 　規格書を翻訳するところから始まって４ヶ月間、ヒマが無くても考え続けてきましたから、嬉しいと言えば嬉しいですが、肩の荷が下りてホッとした気持ちが強いです。
　予想外の何かは残っていると思いますが、一番大きな山を越えたのかな。

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

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

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

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

#Python #[Art-Net] -- Posted by 電装工芸 〔699文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=234 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=234 tegalog Fri, 15 Apr 2022 01:19:03 +0900 　ただ、配列変数の扱いで少し難儀しました。参照渡しになる規則がまだわからん・・・
　ドライバレベルの基本動作がようやく出来た段階なので先は長いですが、処理負荷も軽くていいんじゃないかと。
　ただ、処理を増やしたのに処理負荷が減っている。動くべきは動いているのに何故？

追記

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

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

#Python #[Art-Net] -- Posted by 電装工芸 〔360文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=233 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=233 tegalog Thu, 14 Apr 2022 23:14:18 +0900 　これからは少ない現場を淡々とこなしていく日々が続くので開発のペースを上げられそうです。
　作り変えたArt-Netの受送信処理は正しく動いているように見えます。この手の物にはコマンドの書き間違えではなくハードウェアの理解不足に起因するエラーが隠れていることがあるので、それを見つけることが難しかったりします。・・・そういった意味では、PICマイコンをアセンブラで書く方が楽だったりします。アセンブラは馬鹿正直ですから。

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

#Python #[Art-Net] -- Posted by 電装工芸 〔603文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=231 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=231 tegalog Wed, 13 Apr 2022 21:09:57 +0900 　ゲートウェアサーバーを覗くとPPPoEのインターフェースにIPアドレスが表示されない。これは光回線側が落ちているサイン。
　ゲートウェアサーバーと光回線インターフェースを再起動したりと、わちゃわちゃしているウチに何事もなかった様に接続が回復。
　ライトアップのバラシから上がってきてこういった対応をするのは気が滅入ります。

#サーバー -- Posted by 電装工芸 〔232文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=230 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=230 tegalog Wed, 13 Apr 2022 16:18:04 +0900 　規模は大きいですが、10日間で終わりが見えてきました。

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

#Python #[Art-Net] -- Posted by 電装工芸 〔230文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=229 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=229 tegalog Wed, 13 Apr 2022 10:55:29 +0900 　今までにない設定が少しありましたが普通にDebianです。
　Pythonは3.9.2まで上がっています。ここ数年で追加された新機能がほとんど使えます。

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

追記

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

#Python #[Art-Net] -- Posted by 電装工芸 〔699文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=228 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=228 tegalog Tue, 12 Apr 2022 09:01:03 +0900 　ようやく卓を２枚使える状況になったので、複数の送信元を受ける処理を試してみました。
　基本的には問題なく動くのですが・・・受信するユニバース総数、いや、送信されるユニバースの総数が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] -- Posted by 電装工芸 〔748文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=227 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=227 tegalog Mon, 11 Apr 2022 20:03:14 +0900