電装工芸日記
- 舞台照明機器の製作とか -
どのカテゴリにも属していない投稿［1157件］（66ページ目）
追い込まれる程ではありませんが、本業がジンワリと忙しくなってきました。開発はボチボチペースで進めます。
ANSIエスケープシーケンスを使った画面表示の試作をしています。フリッカーを起こさないコツがわかったので表示が安定しています。
ただ、罫線の表示で少し疑問。解決はしたのですが不思議。
罫線素片はASCIIコードに含まれていませんのでシステム標準のUTF-8を使います。文字列リテラル"\u2500"とすれば横線が表示されます。"\u"は続く数値がUTF-8の文字コードであることを示すエスケープで"2500"は文字コードです。
不思議なのは、同じ文字列リテラルを16進数で表すと"\xE2\x94\x80"となることです。最初の"\xE2"はエスケープ文字なのでヨシとしても、続く"\x94\x40"がよくわからない。何らかの理由でオフセットしているのは確かですが、オフセット値が中途半端です。また、この表記だとビッグエンディアンなのでリトルエンディアンのRaspberryPiでナゼ？という疑問もあります。罫線素片のコード領域の起点を0x2500から0x9480に置き換えればいいだけなのですが、どうしてこうしたのでしょう。Rasbianが動くRaspberryPiに限った話なのかはわかりませんが動くように使うしかありません。
ということで、テキストのコンソール画面に罫線表示も出来る様になりました。
試作プログラムは不器用なベタ書きですが、ウィンドウマネージャもどきの関数ライブラリにしてみようと思います。
#Ｃ言語 #RaspberryPi
ANSIエスケープシーケンスを使った画面表示の試作をしています。フリッカーを起こさないコツがわかったので表示が安定しています。
ただ、罫線の表示で少し疑問。解決はしたのですが不思議。
罫線素片はASCIIコードに含まれていませんのでシステム標準のUTF-8を使います。文字列リテラル"\u2500"とすれば横線が表示されます。"\u"は続く数値がUTF-8の文字コードであることを示すエスケープで"2500"は文字コードです。
不思議なのは、同じ文字列リテラルを16進数で表すと"\xE2\x94\x80"となることです。最初の"\xE2"はエスケープ文字なのでヨシとしても、続く"\x94\x40"がよくわからない。何らかの理由でオフセットしているのは確かですが、オフセット値が中途半端です。また、この表記だとビッグエンディアンなのでリトルエンディアンのRaspberryPiでナゼ？という疑問もあります。罫線素片のコード領域の起点を0x2500から0x9480に置き換えればいいだけなのですが、どうしてこうしたのでしょう。Rasbianが動くRaspberryPiに限った話なのかはわかりませんが動くように使うしかありません。
ということで、テキストのコンソール画面に罫線表示も出来る様になりました。
試作プログラムは不器用なベタ書きですが、ウィンドウマネージャもどきの関数ライブラリにしてみようと思います。
#Ｃ言語 #RaspberryPi
車で20分くらいのところに水族館があります。
知り合いの職員さんに呼ばれて打ち合わせに行ったのですが、大きな水槽に「イワシ」が群舞。
職人が磨き込んだ銀箔のごとき魚体に思わず、「美味そう！！」と口から零れる。
「・・・やっちまった！」と焦るも、水族館さんにとっては嬉しい誉め言葉だそうな。
飼育担当の方と仲良くなりました。
#雑談
知り合いの職員さんに呼ばれて打ち合わせに行ったのですが、大きな水槽に「イワシ」が群舞。
職人が磨き込んだ銀箔のごとき魚体に思わず、「美味そう！！」と口から零れる。
「・・・やっちまった！」と焦るも、水族館さんにとっては嬉しい誉め言葉だそうな。
飼育担当の方と仲良くなりました。
#雑談
そういや中華電機のムービングが故障しました。
調光以外、起動後の初期化は正常にするけど卓の信号を受け付けない。画面やキー操作は正常。
製品によりますが、ムービングライトは調光、PAN/TILT、その他の機能が別々の脳味噌で制御されていることが多いようです。タコみたいですね。
内部を見ますと、DMXを受信している基板から調光ドライバにPWM信号が出ていて、PAN/TILTとその他の機能の脳味噌に向けて１本のRS485の信号が出ています。
起動後の初期化が正常に出来て一部の機能だけ卓から操作が出来ないとなればRS485信号がPAN/TILTとその他の機能の脳味噌に届いていないとしか思えません。
回転軸を通っているケーブルが断線するのはよくあることですが末端まで正常に導通しています。受信側の脳味噌基板は３枚ですが、初期化動作が正常なのに３枚とも壊れているとは考えにくい。
DMXを受信して中向けのRS485を出している基板が怪しいとなるのですが、この基板上のRS485ドライバICをテスターで当たるとおかしい。3.3v仕様のSN75176互換品みたいですが、SN75176の故障でありがちな症状を示しています。SN75176は静電気にとても弱いので珍しいことではありませんケドね。
このICを交換してみようと思いますが、レア品ではないものの日本国内では1000個単位でしか手に入らない製品なので中華電機に発注。2/15着ですからしばらく待ちです。
#照明器具 #電子工作
調光以外、起動後の初期化は正常にするけど卓の信号を受け付けない。画面やキー操作は正常。
製品によりますが、ムービングライトは調光、PAN/TILT、その他の機能が別々の脳味噌で制御されていることが多いようです。タコみたいですね。
内部を見ますと、DMXを受信している基板から調光ドライバにPWM信号が出ていて、PAN/TILTとその他の機能の脳味噌に向けて１本のRS485の信号が出ています。
起動後の初期化が正常に出来て一部の機能だけ卓から操作が出来ないとなればRS485信号がPAN/TILTとその他の機能の脳味噌に届いていないとしか思えません。
回転軸を通っているケーブルが断線するのはよくあることですが末端まで正常に導通しています。受信側の脳味噌基板は３枚ですが、初期化動作が正常なのに３枚とも壊れているとは考えにくい。
DMXを受信して中向けのRS485を出している基板が怪しいとなるのですが、この基板上のRS485ドライバICをテスターで当たるとおかしい。3.3v仕様のSN75176互換品みたいですが、SN75176の故障でありがちな症状を示しています。SN75176は静電気にとても弱いので珍しいことではありませんケドね。
このICを交換してみようと思いますが、レア品ではないものの日本国内では1000個単位でしか手に入らない製品なので中華電機に発注。2/15着ですからしばらく待ちです。
#照明器具 #電子工作
コレ、欲しいかも。
公道は走れませんけどね。
#雑談
公道は走れませんけどね。
#雑談
RaspberryPi4Bが正価で入手出来たと先日書きました。国内はまだの様ですが、中国からRaspberryPiCM4も正価で入手出来ました。
CM4は組込み用途に特化し過ぎているために単体では何も出来ませんが、用途に合わせてインターフェースボードを作ればコンパクトでスッキリしたハードウェアを構成出来ます。
いずれオリジナルのインターフェースを作ってみたいと思っていますが、とりあえずはEtherNetが２口付いた既製品と共にCM4をオーダー。
ArtNet-PatchはCM4を用いて作りたいのです。プログラミングには4Bを使っていますが、製品にするにはちょっと違うので。
#RaspberryPi #[Art-Net]
CM4は組込み用途に特化し過ぎているために単体では何も出来ませんが、用途に合わせてインターフェースボードを作ればコンパクトでスッキリしたハードウェアを構成出来ます。
いずれオリジナルのインターフェースを作ってみたいと思っていますが、とりあえずはEtherNetが２口付いた既製品と共にCM4をオーダー。
ArtNet-PatchはCM4を用いて作りたいのです。プログラミングには4Bを使っていますが、製品にするにはちょっと違うので。
#RaspberryPi #[Art-Net]
ArtNet-Engineの入口出口キー操作は触るたびに問題点が見えてきます。なかなか次に進めません。
次の課題は受信スタックです。これは得たデータをレーンと呼ぶ内部的な経路と送信元毎に仕分けしたモノです。８レーン８送信元、６４ユニバースの一時保存です。一見データ量が多いようですが32kBです。映像画像に比べたらわずかな量です。
受信毎に本処理まですればいい気もしますが、送信元から送られるデータは時間的に一定ではありませんので、受信の都度本処理までするとややこしくて重くなるのです。
ならば、一定の規則で受信データを整頓し、送信元×レーン毎の入れ子に最新値という形で一時保存してから本処理を行えばシンプルな処理になります。
こんなややこしいことをしてもDMX規格の最大速の１フレーム程度にレイテンシーを抑えようとしています。
もちろんタイムアウトも必要です。DMXはデータが１秒間更新されなければ送信が無くなったと判断する規格ですから受信日時を見て判断します。これは優先度が低い処理ですから優先度が高い処理が実行されない空き時間を用います。極端な話、タイムアウトは１秒が基本でも５秒かかったところで実用上の問題は無いと考えます。そんなにかかることは無いと思いますが、２秒くらいで処理されれば実用だと思います。それ以前にDMXのタイムアウトが１秒ってことを知る人が少ないのですから気にしない。
#[Art-Net]
次の課題は受信スタックです。これは得たデータをレーンと呼ぶ内部的な経路と送信元毎に仕分けしたモノです。８レーン８送信元、６４ユニバースの一時保存です。一見データ量が多いようですが32kBです。映像画像に比べたらわずかな量です。
受信毎に本処理まですればいい気もしますが、送信元から送られるデータは時間的に一定ではありませんので、受信の都度本処理までするとややこしくて重くなるのです。
ならば、一定の規則で受信データを整頓し、送信元×レーン毎の入れ子に最新値という形で一時保存してから本処理を行えばシンプルな処理になります。
こんなややこしいことをしてもDMX規格の最大速の１フレーム程度にレイテンシーを抑えようとしています。
もちろんタイムアウトも必要です。DMXはデータが１秒間更新されなければ送信が無くなったと判断する規格ですから受信日時を見て判断します。これは優先度が低い処理ですから優先度が高い処理が実行されない空き時間を用います。極端な話、タイムアウトは１秒が基本でも５秒かかったところで実用上の問題は無いと考えます。そんなにかかることは無いと思いますが、２秒くらいで処理されれば実用だと思います。それ以前にDMXのタイムアウトが１秒ってことを知る人が少ないのですから気にしない。
#[Art-Net]
本業はちょいちょいで終わったのでArtNet-Engineを書き進めました。
ユニバースによる処理時間のムラはサンプルデータとして使っているMAdot2の仕様によるものみたいです。細かくは計測していませんが、８ユニバース出すとして、ユニバース毎に均等の時間割りで送信するのではなく、８ユニバースを一気に送信して長い休みを入れているようです。このため、最初のユニバースでは処理が重くなり、後のユニバースでは処理が軽くなる現象が起きるのだと思われます。主にArtNet-Engineからの送信に影響があったようで、受信したら即送信していたものを一時スタックしてからユニバース毎に均等の時間割りで送信する様にしたところムラが無くなりました。RaspberryPiの送信処理に何か負担がかかっていたのでしょう。
現時点での１フェーズの処理時間は平均して100usec以下です。出現確率が高い例外値が250usecくらいで、極マレに出てくる最大値が900usecくらいです。処理時間が保証されないOSですからこんなもん？。
作りたい物にはなりそうですが、８ユニバース８卓(６４ユニバース入力)は厳しい気がします。これに対応するには１フェーズが確実に350usec未満でなければなりませんが、例外値がやってきた時にプリフリーズを起こしそうです。登録できる調光卓(送信元)は８台ですが、同時に使える(HTPミックスの対象となる)のを３-４台くらいにしておけば現実的かもしれません。Art-Netの規格書に「マルチキャストは４０ユニバースが上限だと思いますよ」と書いてあるのは伊達じゃないようです。
どの要素が時間を使っているのか不明なので組んで実測しますかね。ダメなら減らすダケです。
ただ、構造体とポインタが使えるとこういったデータ処理は楽です。構造体はPythonのタプルに似ていますがシンプルなのでPythonより書きやすいかもしれません。ポインタは参照渡しですのでデータの扱いが速いのです。それ以前に何をするにも速いですけど。
追記
調整したところ、１ユニバース受信する１フェーズが平均30usec、例外値が200usec程度になりました。
同時に８卓使っても１本のArt-Netに統合する現場はマレだと思いますケド、間に合いそうな数値が出たので、その様に書いて後で調整します。増やすのは大変ですが減らすのは簡単ですから。
送信の間隔はユニバース数と希望fps数から自動計算にしました。将来的にfpsを設定して調整出来れば良いかなと。
#[Art-Net] #Ｃ言語
ユニバースによる処理時間のムラはサンプルデータとして使っているMAdot2の仕様によるものみたいです。細かくは計測していませんが、８ユニバース出すとして、ユニバース毎に均等の時間割りで送信するのではなく、８ユニバースを一気に送信して長い休みを入れているようです。このため、最初のユニバースでは処理が重くなり、後のユニバースでは処理が軽くなる現象が起きるのだと思われます。主にArtNet-Engineからの送信に影響があったようで、受信したら即送信していたものを一時スタックしてからユニバース毎に均等の時間割りで送信する様にしたところムラが無くなりました。RaspberryPiの送信処理に何か負担がかかっていたのでしょう。
現時点での１フェーズの処理時間は平均して100usec以下です。出現確率が高い例外値が250usecくらいで、極マレに出てくる最大値が900usecくらいです。処理時間が保証されないOSですからこんなもん？。
作りたい物にはなりそうですが、８ユニバース８卓(６４ユニバース入力)は厳しい気がします。これに対応するには１フェーズが確実に350usec未満でなければなりませんが、例外値がやってきた時にプリフリーズを起こしそうです。登録できる調光卓(送信元)は８台ですが、同時に使える(HTPミックスの対象となる)のを３-４台くらいにしておけば現実的かもしれません。Art-Netの規格書に「マルチキャストは４０ユニバースが上限だと思いますよ」と書いてあるのは伊達じゃないようです。
どの要素が時間を使っているのか不明なので組んで実測しますかね。ダメなら減らすダケです。
ただ、構造体とポインタが使えるとこういったデータ処理は楽です。構造体はPythonのタプルに似ていますがシンプルなのでPythonより書きやすいかもしれません。ポインタは参照渡しですのでデータの扱いが速いのです。それ以前に何をするにも速いですけど。
追記
調整したところ、１ユニバース受信する１フェーズが平均30usec、例外値が200usec程度になりました。
同時に８卓使っても１本のArt-Netに統合する現場はマレだと思いますケド、間に合いそうな数値が出たので、その様に書いて後で調整します。増やすのは大変ですが減らすのは簡単ですから。
送信の間隔はユニバース数と希望fps数から自動計算にしました。将来的にfpsを設定して調整出来れば良いかなと。
#[Art-Net] #Ｃ言語
本業もやらねばなりませんがArtNet-Engineも進めたい。
ArtNet-Engineの課題はデータ処理の構成です。
まずは入力です。同じネットワークに複数の調光卓を繋ぐことは出来ますが、ユニバースの重複によるトラブルには対策が必要です。
送信元IPアドレスで仕訳けることが基本になると思いますが、どうせなら選択しつつマージしてしまおうかと。
フェスなどでは複数の調光卓を設置して使い分けるのはよくあることです。単純な差し替えとかネットワーク切り替え機などを使ってもいいのですが、選択とマージ(HTPミックス)が出来たらそれはそれでいいかなと。バックアップ卓を併設することも出来るし。
内部的には８ユニバースのパッチを考えていますが卓も８台想定します。６４ユニバースの交通整理をするのでRaspberryPiの処理能力で間に合うのかわかりませんがダメなら数を減らします。
当面は送信元の仕分けと６４ユニバースを８ユニバースにマージする処理を書きます。
処理の構造をどうするか考えていますが、データの保存には構造体配列や構造体の中に構造体を入れるなど複雑な変数構成が必要になりそうです。
Pythonとは違い、for文が速いＣ言語なら繰り返しと条件分岐を織り交ぜた処理も書きやすそうです。Ｃ言語の習得の難所でもあるポインタもこういった処理では効果を発揮します。
#[Art-Net] #Ｃ言語
ArtNet-Engineの課題はデータ処理の構成です。
まずは入力です。同じネットワークに複数の調光卓を繋ぐことは出来ますが、ユニバースの重複によるトラブルには対策が必要です。
送信元IPアドレスで仕訳けることが基本になると思いますが、どうせなら選択しつつマージしてしまおうかと。
フェスなどでは複数の調光卓を設置して使い分けるのはよくあることです。単純な差し替えとかネットワーク切り替え機などを使ってもいいのですが、選択とマージ(HTPミックス)が出来たらそれはそれでいいかなと。バックアップ卓を併設することも出来るし。
内部的には８ユニバースのパッチを考えていますが卓も８台想定します。６４ユニバースの交通整理をするのでRaspberryPiの処理能力で間に合うのかわかりませんがダメなら数を減らします。
当面は送信元の仕分けと６４ユニバースを８ユニバースにマージする処理を書きます。
処理の構造をどうするか考えていますが、データの保存には構造体配列や構造体の中に構造体を入れるなど複雑な変数構成が必要になりそうです。
Pythonとは違い、for文が速いＣ言語なら繰り返しと条件分岐を織り交ぜた処理も書きやすそうです。Ｃ言語の習得の難所でもあるポインタもこういった処理では効果を発揮します。
#[Art-Net] #Ｃ言語
オレメモ
ANSIエスケープシーケンスにおいてカーソルの表示/非表示を定義。
RaspberryPi 4B / Rasbian11_32bit / コンパイラ：OS標準gcc
\e［?25h カーソルの表示
\e［?25l カーソルの非表示
相変わらずの不思議な呪文。
#Ｃ言語
ANSIエスケープシーケンスにおいてカーソルの表示/非表示を定義。
RaspberryPi 4B / Rasbian11_32bit / コンパイラ：OS標準gcc
\e［?25h カーソルの表示
\e［?25l カーソルの非表示
相変わらずの不思議な呪文。
#Ｃ言語
各所の処理タイミングで難儀しましたが、第１フェーズと呼んでもいい段階は終わりました。
まとまったのは次の通り。
１）Art-Netを受信してデコード。
２）エンコードして送信。
３）受信値を表示。
４）カーソルキーでユニバースを切り替えるなど、キーボードによる画面操作。
この程度ではありますが、これから先の基本が多く含まれているのでかなりの進歩だと自画自賛。
スッキリした画面に値がキレイに表示されると気持ち良いです。
ちなみに、画面表示を除く主処理１フェーズの所要時間は平均150usec、最大600usecくらいです(30fps:8ユニバースのArt-Netを受信/デコード/エンコード/送信する処理)。Pythonに比べたら圧倒的に速い。
今後機能を追加してどれくらい重くなっていくのかは未知数ですが、現時点では期待値込みの次第点でしょう。
次はデータ処理の本丸です。
Pythonである程度作れた処理ですが、Pythonならではの便利機能が使えないなら私にとってかなり難しいことなので、処理の手順をキッチリ考えたいと思います。
追記
処理タイミングを調整したところ１フェーズの処理時間が50usec程度減りました。小さな数値ですが比率としては大きい。
不思議なのは、受信している８ユニバース中、０ユニバースに比べ７ユニバースの処理が倍くらい速く処理時間の変動が少ないことです。出力のフレームレートをDoctorMXで計測すると同じ値なので謎です。今は動いているバグですと後々問題になりそうそうなので確認しますが、速いユニバースは１フェーズ90usec前後で安定して動いているのでこれが平均になれば御の字です。この数値で揃えば現在考えている最大規模も処理出来ると思います。
#[Art-Net]
まとまったのは次の通り。
１）Art-Netを受信してデコード。
２）エンコードして送信。
３）受信値を表示。
４）カーソルキーでユニバースを切り替えるなど、キーボードによる画面操作。
この程度ではありますが、これから先の基本が多く含まれているのでかなりの進歩だと自画自賛。
スッキリした画面に値がキレイに表示されると気持ち良いです。
ちなみに、画面表示を除く主処理１フェーズの所要時間は平均150usec、最大600usecくらいです(30fps:8ユニバースのArt-Netを受信/デコード/エンコード/送信する処理)。Pythonに比べたら圧倒的に速い。
今後機能を追加してどれくらい重くなっていくのかは未知数ですが、現時点では期待値込みの次第点でしょう。
次はデータ処理の本丸です。
Pythonである程度作れた処理ですが、Pythonならではの便利機能が使えないなら私にとってかなり難しいことなので、処理の手順をキッチリ考えたいと思います。
追記
処理タイミングを調整したところ１フェーズの処理時間が50usec程度減りました。小さな数値ですが比率としては大きい。
不思議なのは、受信している８ユニバース中、０ユニバースに比べ７ユニバースの処理が倍くらい速く処理時間の変動が少ないことです。出力のフレームレートをDoctorMXで計測すると同じ値なので謎です。今は動いているバグですと後々問題になりそうそうなので確認しますが、速いユニバースは１フェーズ90usec前後で安定して動いているのでこれが平均になれば御の字です。この数値で揃えば現在考えている最大規模も処理出来ると思います。
#[Art-Net]
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116