電装工芸日記
- 舞台照明機器の製作とか -
全年全月28日の投稿(時系列順)［24件］（2ページ目）
2022年8月 この範囲を新しい順で読む この範囲をファイルに出力する
mdadmによるRAID1は正常になったようです。不調だった原因が私の操作なのか温度なのかはわかりませんケド。
温度が心配なのでケースに穴を空けようと思います。
ちなみに、アクセスランプが２秒くらいの間隔で点滅を繰り返していました。数時間でおさまりましたが、ext4の何某なのか、mdadmの何某なのか、原因は不明です。最終的に正常になればいいのですが、こういった挙動は収まるまで待つしかありません。
#サーバー
温度が心配なのでケースに穴を空けようと思います。
ちなみに、アクセスランプが２秒くらいの間隔で点滅を繰り返していました。数時間でおさまりましたが、ext4の何某なのか、mdadmの何某なのか、原因は不明です。最終的に正常になればいいのですが、こういった挙動は収まるまで待つしかありません。
#サーバー
2022年10月 この範囲を新しい順で読む この範囲をファイルに出力する
JASRACの敗訴が確定したそうです。
yahooニュース
著作権者の権利と利益を守ることは大切ですが、言い掛かりにも等しい理由で取り立て先を増やそうとするのはどうかと。
器を大きくしたり中身を増やそうとせずに自分の取り分だけより多く求めるのは半島貴族っぽい思考ですねぇ。まぁ、そういうことなんでしょうケド。
私が気に入らないのは「包括的利用許諾契約」。誰に支払われるのかわからん金を支払えってやつ。あと、足切りと呼ばれる利用率が低い著作権者には支払いがされない制度。
どちらも１曲単位で管理するのは事務処理が膨大で現実的に無理という理由。権利を預かって金銭を取り立てる立場が許される言い訳なのか？。
音楽著作権の管理が利用された回数ならカラオケ屋さんのシステムを利用すればいいのに。誰が作ったナンて曲が何回再生されたか１曲単位で瞬時にわかるので不透明さが無い。明瞭会計。
明瞭だと困るから今のシステムなんだろうなぁ、って勘繰ってしまいますけどね。
#雑談
yahooニュース
著作権者の権利と利益を守ることは大切ですが、言い掛かりにも等しい理由で取り立て先を増やそうとするのはどうかと。
器を大きくしたり中身を増やそうとせずに自分の取り分だけより多く求めるのは半島貴族っぽい思考ですねぇ。まぁ、そういうことなんでしょうケド。
私が気に入らないのは「包括的利用許諾契約」。誰に支払われるのかわからん金を支払えってやつ。あと、足切りと呼ばれる利用率が低い著作権者には支払いがされない制度。
どちらも１曲単位で管理するのは事務処理が膨大で現実的に無理という理由。権利を預かって金銭を取り立てる立場が許される言い訳なのか？。
音楽著作権の管理が利用された回数ならカラオケ屋さんのシステムを利用すればいいのに。誰が作ったナンて曲が何回再生されたか１曲単位で瞬時にわかるので不透明さが無い。明瞭会計。
明瞭だと困るから今のシステムなんだろうなぁ、って勘繰ってしまいますけどね。
#雑談
2022年11月 この範囲を新しい順で読む この範囲をファイルに出力する
薄合板とスタイロフォームを貼り合わせた試材を確認してみました。
スタイロフォームは30mm厚、薄合板はラワンの2.0mm厚、双方３×６サイズ。
接着は木工用ボンドCH38を50%水で薄めたモノ(元の重量に対し半分の重量の水を加えたモノ)をローラーで両材に塗布して貼り合わせ。
丸３日放置しましたが思った以上に頑丈です。板の３尺辺に角材を挟んで私(約68kg)が乗ってたわみが15～20mm。接着が剥がれたところがありましたが、折れることなく耐えました。
接着の剥がれはスタイロフォームが丸ノコの下敷きで使っていたジャンクで切り傷があったことと接着剤を薄め過ぎたことが原因だと思います。剥がれたのは丸ノコで削られていたところですから、新品のスタイロフォームにローラーで塗布できるギリギリの粘度に薄めた木工用ボンドを塗布すれば耐えるでしょう。
今回はありものでのお試しでしたが、引っ張り強度が強い薄材でスタイロフォームをサンドイッチする方法には期待が持てます。
次のお試しは、スタイロフォームを厚くして50mm厚にし、50×12mmの杉材を縁に入れ、脚を付ける場所には木のブロックを入れてみます。
スタイロフォームの厚さが過剰な気がしないでもありませんが、不足感とやり過ぎ感の両方を試しませんと落としどころは見つかりません。
#ガチ工作
スタイロフォームは30mm厚、薄合板はラワンの2.0mm厚、双方３×６サイズ。
接着は木工用ボンドCH38を50%水で薄めたモノ(元の重量に対し半分の重量の水を加えたモノ)をローラーで両材に塗布して貼り合わせ。
丸３日放置しましたが思った以上に頑丈です。板の３尺辺に角材を挟んで私(約68kg)が乗ってたわみが15～20mm。接着が剥がれたところがありましたが、折れることなく耐えました。
接着の剥がれはスタイロフォームが丸ノコの下敷きで使っていたジャンクで切り傷があったことと接着剤を薄め過ぎたことが原因だと思います。剥がれたのは丸ノコで削られていたところですから、新品のスタイロフォームにローラーで塗布できるギリギリの粘度に薄めた木工用ボンドを塗布すれば耐えるでしょう。
今回はありものでのお試しでしたが、引っ張り強度が強い薄材でスタイロフォームをサンドイッチする方法には期待が持てます。
次のお試しは、スタイロフォームを厚くして50mm厚にし、50×12mmの杉材を縁に入れ、脚を付ける場所には木のブロックを入れてみます。
スタイロフォームの厚さが過剰な気がしないでもありませんが、不足感とやり過ぎ感の両方を試しませんと落としどころは見つかりません。
#ガチ工作
分岐カバーを９個同時にプリントしています。
これが欲しいというよりプリンタの試験です。プラットホームの場所によって仕上がりが違う気がしたのですが、プラットホームに３×３の９個乗ったので試験に丁度いいかなと。
分岐カバーも１個や２個では試験にならないので、ついでに作れるなら丁度いいかなと。
CAM曰く２日と14時間かかるそうです。明日の夕方には終わるかなと。
全天候型のLEDスポットに中華TRUE1を取り付けて使っていますが、水没さえしなければ思った以上に雨風に耐えてくれるので便利です。直電源のケーブル類はすべて中華TRUE1にしてもいいかなと思ったりしているのですが、分岐が出来ないと不便です。防滴の分岐も中華電器で手に入りますがちょっと高価だし、中華電器ではコピー品以外の製品は同じモノを継続的に入手することが期待できませんので二の足を踏んでいるのです。
分岐はリングスリーブで繋げた部分に機械強度を与えて風雨から保護できればいいので、シンプルを極めた機能的な物を模索しています。
#3D #照明器具
これが欲しいというよりプリンタの試験です。プラットホームの場所によって仕上がりが違う気がしたのですが、プラットホームに３×３の９個乗ったので試験に丁度いいかなと。
分岐カバーも１個や２個では試験にならないので、ついでに作れるなら丁度いいかなと。
CAM曰く２日と14時間かかるそうです。明日の夕方には終わるかなと。
全天候型のLEDスポットに中華TRUE1を取り付けて使っていますが、水没さえしなければ思った以上に雨風に耐えてくれるので便利です。直電源のケーブル類はすべて中華TRUE1にしてもいいかなと思ったりしているのですが、分岐が出来ないと不便です。防滴の分岐も中華電器で手に入りますがちょっと高価だし、中華電器ではコピー品以外の製品は同じモノを継続的に入手することが期待できませんので二の足を踏んでいるのです。
分岐はリングスリーブで繋げた部分に機械強度を与えて風雨から保護できればいいので、シンプルを極めた機能的な物を模索しています。
#3D #照明器具
2022年12月 この範囲を新しい順で読む この範囲をファイルに出力する
マルチプロセスについて調べていました。
fork()、exec()、共有メモリをセットで使えば良いようです。
Linuxプロセスの生成と実行 fork／exec
fork()は現プロセスを別プロセスに完全コピーします。実行状態も含めてです。同じプログラムが別々のプロセスでfork()を実行する直前のコンディションで並列実行されますが、自身がコピーされた子プロセスなら別プロセスで実行したいプログラムをexec()で起動するというもの。exec()で別プログラムを起動すると呼び出したプログラムは終了しますので、結果として別プロセスで別プログラムが起動したことになります。共有メモリなどの設定を済ませてからfork()を実行すれば、共有メモリの情報を別プロセスの別プログラムに簡単に渡せるのでスマートです。
以下、いささか愚痴ですし、教えを頂いている立場が言うことではないのですが、fork()、exec()、共有メモリがセットであることに触れずにfork()だけを切り取った情報が多いこと多いこと。ゴッタ煮説明が理解しにくいのは事実ですが、fork()だけではfork()の意味すらわからないと思うのです。私と同じことを調べている方がいたら、exec()に触れずにfork()だけを力説している情報は読み飛ばした方がいいと思います。もちろん、瞬間的に計算能力を増やすのにサブルーチン的な別プロセスを使う方法あるのでexec()を用いずfork()と共有メモリで組むこともあるとは思いますけど。
マルチプロセスというとfork()単独の話ばかりが目につきますが、共有メモリをキーに掘り下げたところfork()、exec()、共有メモリの３点セットが理解出来たところです。
話を戻しますが、共有メモリの情報を別プロセスに渡す方法も含め、具体的に解決した感じです。
これなら、複数ある機能のどれかから別機能のプロセスを起動するより、必要な機能の全プロセスを起動するだけのメインプログラムを書いた方が管理しやすいような気がします。共有メモリなどを設定し、機能ごとのプロセスを起動していく最初に起動するプログラムです。一種のランチャーですね。
うーん、やっぱりＣ言語は高級言語というよりアセンブラ風味だなぁ。
#Ｃ言語
fork()、exec()、共有メモリをセットで使えば良いようです。
Linuxプロセスの生成と実行 fork／exec
fork()は現プロセスを別プロセスに完全コピーします。実行状態も含めてです。同じプログラムが別々のプロセスでfork()を実行する直前のコンディションで並列実行されますが、自身がコピーされた子プロセスなら別プロセスで実行したいプログラムをexec()で起動するというもの。exec()で別プログラムを起動すると呼び出したプログラムは終了しますので、結果として別プロセスで別プログラムが起動したことになります。共有メモリなどの設定を済ませてからfork()を実行すれば、共有メモリの情報を別プロセスの別プログラムに簡単に渡せるのでスマートです。
以下、いささか愚痴ですし、教えを頂いている立場が言うことではないのですが、fork()、exec()、共有メモリがセットであることに触れずにfork()だけを切り取った情報が多いこと多いこと。ゴッタ煮説明が理解しにくいのは事実ですが、fork()だけではfork()の意味すらわからないと思うのです。私と同じことを調べている方がいたら、exec()に触れずにfork()だけを力説している情報は読み飛ばした方がいいと思います。もちろん、瞬間的に計算能力を増やすのにサブルーチン的な別プロセスを使う方法あるのでexec()を用いずfork()と共有メモリで組むこともあるとは思いますけど。
マルチプロセスというとfork()単独の話ばかりが目につきますが、共有メモリをキーに掘り下げたところfork()、exec()、共有メモリの３点セットが理解出来たところです。
話を戻しますが、共有メモリの情報を別プロセスに渡す方法も含め、具体的に解決した感じです。
これなら、複数ある機能のどれかから別機能のプロセスを起動するより、必要な機能の全プロセスを起動するだけのメインプログラムを書いた方が管理しやすいような気がします。共有メモリなどを設定し、機能ごとのプロセスを起動していく最初に起動するプログラムです。一種のランチャーですね。
うーん、やっぱりＣ言語は高級言語というよりアセンブラ風味だなぁ。
#Ｃ言語
書き方を考えています。
PICマイコンを書く場合は、表面の機能からではなく、全体の構造からまとめていくからです。
表面的な機能だけで装置は動きません。これらを後回しにすることを推奨するのではありませんが、機能と機能を能動的に結びつけなければ結果に至らないからです。
DMXのディマーも、DMXを受信するだけでなく、アドレスを設定したり、ACの波長とゼロクロスポイントを取得したり、得た情報を結びつけて適切なタイミングでSCRをON/OFFしなければなりません。
PICにおいてはハードウェアモジュールの割り込みフラグを用いるのは当然としても、１個のタイマーで複数の実行タイミングを生成出来なければなりません。タイマーはほんの数個しかありませんので、実行モジュール毎にタイマーを割り付けてタイムアップを取るのは不可能だからです。細かい構造は割愛しますが、環境に合わせた工夫を仕込んでおかないと動くモノも動かないのです。
PICとは事情が違いますが、RaspberryPiを開発するなら複数のCPUスレッドに仕事を分散させて処理能力を出来るだけ引き出さないといけません。
PythonでもＣ言語でも、プログラムをマルチスレッド化するだけならプロセスは一つでありCPUスレッドは１つしか使われません。CPUスレッドを振り分けるのはOSの仕事でプログラムの記述で指定することは出来ないようですが、CPUスレッドを最大限利用するにはマルチプロセスで書くことが最低条件となるようです。
マルチプロセス化する方法はいくつかありますが、プロセスとプロセスの間に継承と共有をする情報があるならば工夫が必要です。これらを都度の例外とするのは開発においてもメンテナンスにおいても効率が良くありませんので、継承と共有の仕組みを最初から作っておくのが良いと思います。
これから取り組もうとしている工夫は正にコレです。この仕組みがまとまればＣ言語での開発が飛躍的に発展します。
#Ｃ言語
PICマイコンを書く場合は、表面の機能からではなく、全体の構造からまとめていくからです。
表面的な機能だけで装置は動きません。これらを後回しにすることを推奨するのではありませんが、機能と機能を能動的に結びつけなければ結果に至らないからです。
DMXのディマーも、DMXを受信するだけでなく、アドレスを設定したり、ACの波長とゼロクロスポイントを取得したり、得た情報を結びつけて適切なタイミングでSCRをON/OFFしなければなりません。
PICにおいてはハードウェアモジュールの割り込みフラグを用いるのは当然としても、１個のタイマーで複数の実行タイミングを生成出来なければなりません。タイマーはほんの数個しかありませんので、実行モジュール毎にタイマーを割り付けてタイムアップを取るのは不可能だからです。細かい構造は割愛しますが、環境に合わせた工夫を仕込んでおかないと動くモノも動かないのです。
PICとは事情が違いますが、RaspberryPiを開発するなら複数のCPUスレッドに仕事を分散させて処理能力を出来るだけ引き出さないといけません。
PythonでもＣ言語でも、プログラムをマルチスレッド化するだけならプロセスは一つでありCPUスレッドは１つしか使われません。CPUスレッドを振り分けるのはOSの仕事でプログラムの記述で指定することは出来ないようですが、CPUスレッドを最大限利用するにはマルチプロセスで書くことが最低条件となるようです。
マルチプロセス化する方法はいくつかありますが、プロセスとプロセスの間に継承と共有をする情報があるならば工夫が必要です。これらを都度の例外とするのは開発においてもメンテナンスにおいても効率が良くありませんので、継承と共有の仕組みを最初から作っておくのが良いと思います。
これから取り組もうとしている工夫は正にコレです。この仕組みがまとまればＣ言語での開発が飛躍的に発展します。
#Ｃ言語
2023年1月 この範囲を新しい順で読む この範囲をファイルに出力する
キー入力の処理が出来ましたが、願わくば押し下げと解放も拾いたいところではあります。
ですが、ハードウェアが汎用ですし、キーボードが押されたことを検知しているのではなく、入力された文字コードを得る処理ですので、これ以上細かいことはもう少し勉強しないとダメかな。
socketの検証は場所も時間も潤沢に必要なので、もう少し本業を終わらせないと手を付けられませんが、キー入力によるコマンド処理をどうしようか考えています。
入力されたアルファベットをコマンドショートカットとし、数字は数字として扱うことを基本にしようと思います。キーに対して処理を割り付けるのではなく、得たASCIIテキストに対して処理を割り付ければ標準入力だろうがUARTだろうがsocketだろうが何でも良く、ハードウェアに合わせた入口さえ作ればその先の処理は同じでいけます。こうするのは専用入力端末が壊れた時に汎用のキーボードでも対応したいからです。
では、得たASCIIテキストをどう処理するかです。
入力されたASCIIテキストは文字列として普通に扱えばいいでしょう。画面にコマンド列を表示したいならそれを変換すればいいし、コマンドを実行するなら関数に文字列として投げればいい。
せめて、入力に制限をかけてありえない文字列にならないようにした方がいいでしょう。「コレの後にありえる入力はコレ」といった制限です。一種のルールマップを作り、条件に合致しない入力は応答しないかエラーを出すのです。数値に最大値の制限もかけたいですが、これはコマンド実行関数側の仕事であって入力時にチェックするものでもないかな？
#[Art-Net] #Ｃ言語
ですが、ハードウェアが汎用ですし、キーボードが押されたことを検知しているのではなく、入力された文字コードを得る処理ですので、これ以上細かいことはもう少し勉強しないとダメかな。
socketの検証は場所も時間も潤沢に必要なので、もう少し本業を終わらせないと手を付けられませんが、キー入力によるコマンド処理をどうしようか考えています。
入力されたアルファベットをコマンドショートカットとし、数字は数字として扱うことを基本にしようと思います。キーに対して処理を割り付けるのではなく、得たASCIIテキストに対して処理を割り付ければ標準入力だろうがUARTだろうがsocketだろうが何でも良く、ハードウェアに合わせた入口さえ作ればその先の処理は同じでいけます。こうするのは専用入力端末が壊れた時に汎用のキーボードでも対応したいからです。
では、得たASCIIテキストをどう処理するかです。
入力されたASCIIテキストは文字列として普通に扱えばいいでしょう。画面にコマンド列を表示したいならそれを変換すればいいし、コマンドを実行するなら関数に文字列として投げればいい。
せめて、入力に制限をかけてありえない文字列にならないようにした方がいいでしょう。「コレの後にありえる入力はコレ」といった制限です。一種のルールマップを作り、条件に合致しない入力は応答しないかエラーを出すのです。数値に最大値の制限もかけたいですが、これはコマンド実行関数側の仕事であって入力時にチェックするものでもないかな？
#[Art-Net] #Ｃ言語
キー入力はファンクションキーや矢印キーが複数バイトのデータなので、先のプログラムではこれらを正しく判別出来ません。0x1Bを得てもESCキーなのか矢印キーなのか区別できないからです。
これらのデータが一度にキャッシュに入って連続した読み出しとなる(タイムアウト無しに連続して読み出せる)ならいいですが、そうでないと面倒です。いずれにしてもこの辺りの挙動をチェックする必要があります。今は１バイトのcharとして処理していますが、８バイトくらいのchar配列、つまり文字列として処理することになりそうです。
#Ｃ言語
これらのデータが一度にキャッシュに入って連続した読み出しとなる(タイムアウト無しに連続して読み出せる)ならいいですが、そうでないと面倒です。いずれにしてもこの辺りの挙動をチェックする必要があります。今は１バイトのcharとして処理していますが、８バイトくらいのchar配列、つまり文字列として処理することになりそうです。
#Ｃ言語
2023年2月 この範囲を新しい順で読む この範囲をファイルに出力する
中華電機の小さなムービングライトが全数戻ってきたので修理をしています。これまでの修理で確認すべき点が出ているので全台予防修理です。
作業は主にハンダ付けの確認です。正常に動く機体でもハンダコテを当てると故障機体と同じ症状が見られますのでやっておいた方がいいでしょう。１年生部下でもここまでヘタには出来ないよねってくらい酷い施工なので念には念をです。
一度にやりきれない台数ですからヒマを見てボチボチと。
#器具の修理
作業は主にハンダ付けの確認です。正常に動く機体でもハンダコテを当てると故障機体と同じ症状が見られますのでやっておいた方がいいでしょう。１年生部下でもここまでヘタには出来ないよねってくらい酷い施工なので念には念をです。
一度にやりきれない台数ですからヒマを見てボチボチと。
#器具の修理
2023年4月 この範囲を新しい順で読む この範囲をファイルに出力する
TRUE1のＴ分岐を配線してみました。
ケーブルは圧着したタブ端子がハウジングより顔を出す長さにしましたが、TRUE1のレセプタクルを回してケーブルを捩じりながら押し込むと収まります。
ただ、捩じることによってケーブルが引っ張られるため、マレにですが、先に固定したレセプタクルのタブ端子が半抜けすることがあります。
ハウジングの構造上、組付け後の状態確認が出来ませんのでちょっと怖い。何らかの固定方法が必要です。
タブ端子は全カバーの物を使っていますが、半カバーの物にしてハンダ付けで固定でしょうか。もしくは、TRUE1のタブ端子にケーブルをハンダで直付けでしょうか。
#器具の製作
ケーブルは圧着したタブ端子がハウジングより顔を出す長さにしましたが、TRUE1のレセプタクルを回してケーブルを捩じりながら押し込むと収まります。
ただ、捩じることによってケーブルが引っ張られるため、マレにですが、先に固定したレセプタクルのタブ端子が半抜けすることがあります。
ハウジングの構造上、組付け後の状態確認が出来ませんのでちょっと怖い。何らかの固定方法が必要です。
タブ端子は全カバーの物を使っていますが、半カバーの物にしてハンダ付けで固定でしょうか。もしくは、TRUE1のタブ端子にケーブルをハンダで直付けでしょうか。
#器具の製作