電装工芸日記
- 舞台照明機器の製作とか -
全年全月6日の投稿［45件］（4ページ目）
2023年4月 この範囲を時系列順で読む この範囲をファイルに出力する
試してはいませんが、Linux系で音源を再生するのは簡単っぽいです。
モジュールの種類はいくつもありますし、コマンドに音源ファイル名を付けて叩くだけの物もあります。
ファイルブラウザを作れるなら、プレーヤー自体を作ることは難易度が低そうです。
ただ、再生中の音源が現在何分何秒目かを得る方法が見当たりません。音源再生のライブラリに秒数を得る関数あるかもしれませんが、ネットの記事には「簡単に音源を再生出来るぢょ♪」という趣旨の物が多いのでそこまで解説してなくても仕方ないのかな？。タイム情報はガチのプレーヤーを作らなきゃ不要ですしね。
合間に調べを進めましょう。
目指す物は、音源に手を加えず、音源にタイムコードを加えたのと同じ結果を得られるプレーヤーです。
#Ｃ言語 #RaspberryPi
モジュールの種類はいくつもありますし、コマンドに音源ファイル名を付けて叩くだけの物もあります。
ファイルブラウザを作れるなら、プレーヤー自体を作ることは難易度が低そうです。
ただ、再生中の音源が現在何分何秒目かを得る方法が見当たりません。音源再生のライブラリに秒数を得る関数あるかもしれませんが、ネットの記事には「簡単に音源を再生出来るぢょ♪」という趣旨の物が多いのでそこまで解説してなくても仕方ないのかな？。タイム情報はガチのプレーヤーを作らなきゃ不要ですしね。
合間に調べを進めましょう。
目指す物は、音源に手を加えず、音源にタイムコードを加えたのと同じ結果を得られるプレーヤーです。
#Ｃ言語 #RaspberryPi
2023年2月 この範囲を時系列順で読む この範囲をファイルに出力する
本業はちょいちょいで終わったので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] #Ｃ言語
2023年1月 この範囲を時系列順で読む この範囲をファイルに出力する
現場が早く終わったので、開発用のRaspberryPiをノートパソコンのVSCodeと繋いでおきました。ここまでしておけば比較的身軽に開発が出来ます。
本格的に開発を進めましょう。
Ｃ言語でのsocketについて調べてみましたが、PythonのscoketライブラリはＣ言語のsocketをほぼそのまま橋渡ししているだけみたいです。引数の書式にわずかな違いはありますが、ほぼ同様に使えそうです。Art-Netを受信してそのまま転送する処理から試しましょう。
#Ｃ言語 #[Art-Net]
本格的に開発を進めましょう。
Ｃ言語でのsocketについて調べてみましたが、PythonのscoketライブラリはＣ言語のsocketをほぼそのまま橋渡ししているだけみたいです。引数の書式にわずかな違いはありますが、ほぼ同様に使えそうです。Art-Netを受信してそのまま転送する処理から試しましょう。
#Ｃ言語 #[Art-Net]
2022年11月 この範囲を時系列順で読む この範囲をファイルに出力する
久しぶりに３Ｄプリンタを使ったのですが、室温が低すぎてプリントが荒れまくり。
ワーク周辺の気温が摂氏25～30度だといいのですが、プリントするために部屋全体を暖めるのは勿体ない。
幸い３Ｄプリンタはオープンフレームではなくケース式です。amazonさんを覗いたら300wの小さなヒーターがあったので、これを庫内に入れて温度リレーで動かすことにしました。温度リレーはある仕事のために数十個買った際の予備があります。温度の精度はそれほど必要ないのでこんな安物の組み合わせでもいいかなと。
ヒーターは２日後に入荷予定です。
#ガチ工作
ワーク周辺の気温が摂氏25～30度だといいのですが、プリントするために部屋全体を暖めるのは勿体ない。
幸い３Ｄプリンタはオープンフレームではなくケース式です。amazonさんを覗いたら300wの小さなヒーターがあったので、これを庫内に入れて温度リレーで動かすことにしました。温度リレーはある仕事のために数十個買った際の予備があります。温度の精度はそれほど必要ないのでこんな安物の組み合わせでもいいかなと。
ヒーターは２日後に入荷予定です。
#ガチ工作
2022年10月 この範囲を時系列順で読む この範囲をファイルに出力する
こんなんす。ほぼ函の習作。
PSEの壁があるので販売出来ない製品。
全てではないのですが、商用電源を直接入力する機器はPSEに引っかかることが多いのです。
電源モジュールを名目別売りにし、購入者が最終組み立てをしたことにすれば逃れられるって話もありますけど。
#電子工作
PSEの壁があるので販売出来ない製品。
全てではないのですが、商用電源を直接入力する機器はPSEに引っかかることが多いのです。
電源モジュールを名目別売りにし、購入者が最終組み立てをしたことにすれば逃れられるって話もありますけど。
#電子工作
編集うまいなぁ～
#雑談
#雑談
2022年9月 この範囲を時系列順で読む この範囲をファイルに出力する
裸族のパイのUSB-LANアダプタですが、不調の原因が判明。
原因はUSB3.0のA-Aケーブルがクロス結線なことでした。電源は無関係でした。
USBは[RaspberryPi/USB3.0]-[USB3.0/A-A_Cable]-[USB3.0/A-A_KeyStone]-[USB-LAN]と繋いでいますが、ケーブルがクロス結線でキーストーンがストレート結線なのでRaspberryPiに対しUSB-LANアダプタは結線間違いになっていたのです。ケーブルを２本つなぐと正常に動くという摩訶不思議な現象だったので配線を当たったところ判明。
正直、「なんでクロス結線！？」と思いますが、USB3.0のA-Aケーブルはクロス結線が普通でストレートは例外みたいです。
対策は、キーストーンの中身を無理やりクロス結線に変え、クロスからクロスでストレートにしました。
ちなみに、USB3.0/A-Aのクロス結線は・・・
1-1 ※1番ピンから4番ピンはUSB2.0互換
2-2
3-3
4-4
5-8
6-9
7-7
8-5
9-6
です。
USB3.0のメモリを挿して動いたのであまり気にしていませんでしたが、USBメモリは3.0がダメなら2.0に切り替えてしまうみたいです。正確なところはわかりませんけどね。
紆余曲折ありましたが「裸族のパイ」が完成しました。作り方を忘れないウチにもう２台作ってしまいたいけどしばらく無理かなぁ～。
今後、裸族のパイの耐久試験を実施し、大丈夫なら自宅サーバーをコレに切り替えるつもりです。
#サーバー #RaspberryPi
原因はUSB3.0のA-Aケーブルがクロス結線なことでした。電源は無関係でした。
USBは[RaspberryPi/USB3.0]-[USB3.0/A-A_Cable]-[USB3.0/A-A_KeyStone]-[USB-LAN]と繋いでいますが、ケーブルがクロス結線でキーストーンがストレート結線なのでRaspberryPiに対しUSB-LANアダプタは結線間違いになっていたのです。ケーブルを２本つなぐと正常に動くという摩訶不思議な現象だったので配線を当たったところ判明。
正直、「なんでクロス結線！？」と思いますが、USB3.0のA-Aケーブルはクロス結線が普通でストレートは例外みたいです。
対策は、キーストーンの中身を無理やりクロス結線に変え、クロスからクロスでストレートにしました。
ちなみに、USB3.0/A-Aのクロス結線は・・・
1-1 ※1番ピンから4番ピンはUSB2.0互換
2-2
3-3
4-4
5-8
6-9
7-7
8-5
9-6
です。
USB3.0のメモリを挿して動いたのであまり気にしていませんでしたが、USBメモリは3.0がダメなら2.0に切り替えてしまうみたいです。正確なところはわかりませんけどね。
紆余曲折ありましたが「裸族のパイ」が完成しました。作り方を忘れないウチにもう２台作ってしまいたいけどしばらく無理かなぁ～。
今後、裸族のパイの耐久試験を実施し、大丈夫なら自宅サーバーをコレに切り替えるつもりです。
#サーバー #RaspberryPi
2022年8月 この範囲を時系列順で読む この範囲をファイルに出力する
2022年5月 この範囲を時系列順で読む この範囲をファイルに出力する
方針を変えたので部品が揃っていませんが、裸族のパイを仮組みしてHDDのセッティングをしています。
以前はLVMがいいかなぁ～って思っていましたが、データの保存性や保守はRAID1が良いかなと。
LVMは、複数のHDDを一つのストレージに見立てることで大きな容量を得ることが出来、不良が発生したストレージからデータを他に移して交換することが出来ますが、ストレージが物理的に壊れた際にはデータを失う可能性があります。RAID1は複数のストレージを並列で使うため１台が完全に壊れても他が生きていればデータを失うことはありません。RAID5やRAID10はRAID1より重装備ですが扱いが少し難しいので却下。
どれを使うかはお好みですが、データの保存性を優先したいのでRAID1にしようと思います。ディスクを入れ替える際の保守も比較的簡単だし。
#サーバー
以前はLVMがいいかなぁ～って思っていましたが、データの保存性や保守はRAID1が良いかなと。
LVMは、複数のHDDを一つのストレージに見立てることで大きな容量を得ることが出来、不良が発生したストレージからデータを他に移して交換することが出来ますが、ストレージが物理的に壊れた際にはデータを失う可能性があります。RAID1は複数のストレージを並列で使うため１台が完全に壊れても他が生きていればデータを失うことはありません。RAID5やRAID10はRAID1より重装備ですが扱いが少し難しいので却下。
どれを使うかはお好みですが、データの保存性を優先したいのでRAID1にしようと思います。ディスクを入れ替える際の保守も比較的簡単だし。
#サーバー