電装工芸日記
- 舞台照明機器の製作とか -
全年全月28日の投稿［24件］
2024年3月 この範囲を時系列順で読む この範囲をファイルに出力する
2024年2月 この範囲を時系列順で読む この範囲をファイルに出力する
SP13 の筐体はPE(ポリエチレン)ぽい感じです。刻印が無いとPE(ポリエチレン)なのかPP(ポリプロピレン)なのかABSなのか判別し難いのですが、どれも難接着素材です。ホームセンターの選択肢で接着するならスーパーXハイバーくらいです。ただ、本気で接着されるので、最悪の場合に取り外したいニーズに合いません。
ロックタイト271と243を試しましたが硬化せず。これらは金属用であり、嫌気性(空気を遮断すると硬化する)だけでなく金属イオンにも反応して硬化するのは本当の様です。
気になる製品をすべて試すのは不可能ですから、ロックタイト425が良いのでしょうか。超強力な接着をするモノは沢山ありますが、ホドホドの接着をしてくれるものは少ない。手では回らないけど工具を使えば回るって具合いを求めたいのです。
明日入荷なのでお試しです。
追記
モノタロウさんからロックタイト425が入荷しました。
早速試したところいい感じ。求めているのは工具を使えば分解出来るけれど手では動かない固定ですが、正にそんな感じがします。完全硬化は常温で24時間とのことですので、後日あらためて分解テストをしてみます。
比較的高価な接着剤ですがコネクタ１個当たりの使用量はほんのわずかですし、代替品も見当たりませんので価格に疑問はありません。
#工具と資材
ロックタイト271と243を試しましたが硬化せず。これらは金属用であり、嫌気性(空気を遮断すると硬化する)だけでなく金属イオンにも反応して硬化するのは本当の様です。
気になる製品をすべて試すのは不可能ですから、ロックタイト425が良いのでしょうか。超強力な接着をするモノは沢山ありますが、ホドホドの接着をしてくれるものは少ない。手では回らないけど工具を使えば回るって具合いを求めたいのです。
明日入荷なのでお試しです。
追記
モノタロウさんからロックタイト425が入荷しました。
早速試したところいい感じ。求めているのは工具を使えば分解出来るけれど手では動かない固定ですが、正にそんな感じがします。完全硬化は常温で24時間とのことですので、後日あらためて分解テストをしてみます。
比較的高価な接着剤ですがコネクタ１個当たりの使用量はほんのわずかですし、代替品も見当たりませんので価格に疑問はありません。
#工具と資材
2023年12月 この範囲を時系列順で読む この範囲をファイルに出力する
JANDS ESP Ⅱ の為に仕入れたスライドボリュームとフェーダーツマミは思ったより良い品です。価格の割には、、、ではなく動きはスムーズで普通良い。廃番になった日本抵抗器さんの物に比べたら強度は劣りますが、日本抵抗器さんのが丈夫過ぎただけだしね。
基板デザインするのも一苦労ですが、やってやりましょう。
#器具の修理
基板デザインするのも一苦労ですが、やってやりましょう。
#器具の修理
2023年9月 この範囲を時系列順で読む この範囲をファイルに出力する
客席テーブルについて頭が空いている時に色々考えてみました。
軽量化には強い材料に替えるか材料を少なくするかのどちらかが主軸になります。
となると材料の強度を評価できなければなりません。
ようやくわかったことですが、材料の耐荷重強度は形状寸法と荷重支持条件、「ヤング率」と「断面２次モーメント」で求められるようです。ヤング率とは材質の強度。断面２次モーメントは断面形状の強度らしい。
計算式は条件によって様々ありますが、評価の目安ならこの二つの数の積で行えます。試作品は必要な強度を持っていますので、これが持つ値を評価値として使えばいいからです。
試作品の梁はファルカタ合板9.0tを縦方向に使っています。ラワン合板のヤング率は6.9G/Paとのこと。ファルカタは少し強度が落ちますので減るハズですが、塗装によって強度が増していますし、安全率の一部と考えてこのまま使います。断面２次モーメントは 32N/cm4 くらいなので、評価値を 220 くらいとします。
他の材質のヤング率の目安ですが、鉄なら200G/Paくらい、アルミなら70G/Paくらいです。
この辺りの数値をもとに、コストやら加工条件やらを加味し、評価値程度の材料を見繕えばいいのかなと。
#ガチ工作
軽量化には強い材料に替えるか材料を少なくするかのどちらかが主軸になります。
となると材料の強度を評価できなければなりません。
ようやくわかったことですが、材料の耐荷重強度は形状寸法と荷重支持条件、「ヤング率」と「断面２次モーメント」で求められるようです。ヤング率とは材質の強度。断面２次モーメントは断面形状の強度らしい。
計算式は条件によって様々ありますが、評価の目安ならこの二つの数の積で行えます。試作品は必要な強度を持っていますので、これが持つ値を評価値として使えばいいからです。
試作品の梁はファルカタ合板9.0tを縦方向に使っています。ラワン合板のヤング率は6.9G/Paとのこと。ファルカタは少し強度が落ちますので減るハズですが、塗装によって強度が増していますし、安全率の一部と考えてこのまま使います。断面２次モーメントは 32N/cm4 くらいなので、評価値を 220 くらいとします。
他の材質のヤング率の目安ですが、鉄なら200G/Paくらい、アルミなら70G/Paくらいです。
この辺りの数値をもとに、コストやら加工条件やらを加味し、評価値程度の材料を見繕えばいいのかなと。
#ガチ工作
2023年4月 この範囲を時系列順で読む この範囲をファイルに出力する
TRUE1のＴ分岐を配線してみました。
ケーブルは圧着したタブ端子がハウジングより顔を出す長さにしましたが、TRUE1のレセプタクルを回してケーブルを捩じりながら押し込むと収まります。
ただ、捩じることによってケーブルが引っ張られるため、マレにですが、先に固定したレセプタクルのタブ端子が半抜けすることがあります。
ハウジングの構造上、組付け後の状態確認が出来ませんのでちょっと怖い。何らかの固定方法が必要です。
タブ端子は全カバーの物を使っていますが、半カバーの物にしてハンダ付けで固定でしょうか。もしくは、TRUE1のタブ端子にケーブルをハンダで直付けでしょうか。
#器具の製作
ケーブルは圧着したタブ端子がハウジングより顔を出す長さにしましたが、TRUE1のレセプタクルを回してケーブルを捩じりながら押し込むと収まります。
ただ、捩じることによってケーブルが引っ張られるため、マレにですが、先に固定したレセプタクルのタブ端子が半抜けすることがあります。
ハウジングの構造上、組付け後の状態確認が出来ませんのでちょっと怖い。何らかの固定方法が必要です。
タブ端子は全カバーの物を使っていますが、半カバーの物にしてハンダ付けで固定でしょうか。もしくは、TRUE1のタブ端子にケーブルをハンダで直付けでしょうか。
#器具の製作
2023年2月 この範囲を時系列順で読む この範囲をファイルに出力する
中華電機の小さなムービングライトが全数戻ってきたので修理をしています。これまでの修理で確認すべき点が出ているので全台予防修理です。
作業は主にハンダ付けの確認です。正常に動く機体でもハンダコテを当てると故障機体と同じ症状が見られますのでやっておいた方がいいでしょう。１年生部下でもここまでヘタには出来ないよねってくらい酷い施工なので念には念をです。
一度にやりきれない台数ですからヒマを見てボチボチと。
#器具の修理
作業は主にハンダ付けの確認です。正常に動く機体でもハンダコテを当てると故障機体と同じ症状が見られますのでやっておいた方がいいでしょう。１年生部下でもここまでヘタには出来ないよねってくらい酷い施工なので念には念をです。
一度にやりきれない台数ですからヒマを見てボチボチと。
#器具の修理
2023年1月 この範囲を時系列順で読む この範囲をファイルに出力する
キー入力はファンクションキーや矢印キーが複数バイトのデータなので、先のプログラムではこれらを正しく判別出来ません。0x1Bを得てもESCキーなのか矢印キーなのか区別できないからです。
これらのデータが一度にキャッシュに入って連続した読み出しとなる(タイムアウト無しに連続して読み出せる)ならいいですが、そうでないと面倒です。いずれにしてもこの辺りの挙動をチェックする必要があります。今は１バイトのcharとして処理していますが、８バイトくらいのchar配列、つまり文字列として処理することになりそうです。
#Ｃ言語
これらのデータが一度にキャッシュに入って連続した読み出しとなる(タイムアウト無しに連続して読み出せる)ならいいですが、そうでないと面倒です。いずれにしてもこの辺りの挙動をチェックする必要があります。今は１バイトのcharとして処理していますが、８バイトくらいのchar配列、つまり文字列として処理することになりそうです。
#Ｃ言語
キー入力の処理が出来ましたが、願わくば押し下げと解放も拾いたいところではあります。
ですが、ハードウェアが汎用ですし、キーボードが押されたことを検知しているのではなく、入力された文字コードを得る処理ですので、これ以上細かいことはもう少し勉強しないとダメかな。
socketの検証は場所も時間も潤沢に必要なので、もう少し本業を終わらせないと手を付けられませんが、キー入力によるコマンド処理をどうしようか考えています。
入力されたアルファベットをコマンドショートカットとし、数字は数字として扱うことを基本にしようと思います。キーに対して処理を割り付けるのではなく、得たASCIIテキストに対して処理を割り付ければ標準入力だろうがUARTだろうがsocketだろうが何でも良く、ハードウェアに合わせた入口さえ作ればその先の処理は同じでいけます。こうするのは専用入力端末が壊れた時に汎用のキーボードでも対応したいからです。
では、得たASCIIテキストをどう処理するかです。
入力されたASCIIテキストは文字列として普通に扱えばいいでしょう。画面にコマンド列を表示したいならそれを変換すればいいし、コマンドを実行するなら関数に文字列として投げればいい。
せめて、入力に制限をかけてありえない文字列にならないようにした方がいいでしょう。「コレの後にありえる入力はコレ」といった制限です。一種のルールマップを作り、条件に合致しない入力は応答しないかエラーを出すのです。数値に最大値の制限もかけたいですが、これはコマンド実行関数側の仕事であって入力時にチェックするものでもないかな？
#[Art-Net] #Ｃ言語
ですが、ハードウェアが汎用ですし、キーボードが押されたことを検知しているのではなく、入力された文字コードを得る処理ですので、これ以上細かいことはもう少し勉強しないとダメかな。
socketの検証は場所も時間も潤沢に必要なので、もう少し本業を終わらせないと手を付けられませんが、キー入力によるコマンド処理をどうしようか考えています。
入力されたアルファベットをコマンドショートカットとし、数字は数字として扱うことを基本にしようと思います。キーに対して処理を割り付けるのではなく、得たASCIIテキストに対して処理を割り付ければ標準入力だろうがUARTだろうがsocketだろうが何でも良く、ハードウェアに合わせた入口さえ作ればその先の処理は同じでいけます。こうするのは専用入力端末が壊れた時に汎用のキーボードでも対応したいからです。
では、得たASCIIテキストをどう処理するかです。
入力されたASCIIテキストは文字列として普通に扱えばいいでしょう。画面にコマンド列を表示したいならそれを変換すればいいし、コマンドを実行するなら関数に文字列として投げればいい。
せめて、入力に制限をかけてありえない文字列にならないようにした方がいいでしょう。「コレの後にありえる入力はコレ」といった制限です。一種のルールマップを作り、条件に合致しない入力は応答しないかエラーを出すのです。数値に最大値の制限もかけたいですが、これはコマンド実行関数側の仕事であって入力時にチェックするものでもないかな？
#[Art-Net] #Ｃ言語
2022年12月 この範囲を時系列順で読む この範囲をファイルに出力する
書き方を考えています。
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スレッドを最大限利用するにはマルチプロセスで書くことが最低条件となるようです。
マルチプロセス化する方法はいくつかありますが、プロセスとプロセスの間に継承と共有をする情報があるならば工夫が必要です。これらを都度の例外とするのは開発においてもメンテナンスにおいても効率が良くありませんので、継承と共有の仕組みを最初から作っておくのが良いと思います。
これから取り組もうとしている工夫は正にコレです。この仕組みがまとまればＣ言語での開発が飛躍的に発展します。
#Ｃ言語
マルチプロセスについて調べていました。
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()、共有メモリの３点セットが理解出来たところです。
話を戻しますが、共有メモリの情報を別プロセスに渡す方法も含め、具体的に解決した感じです。
これなら、複数ある機能のどれかから別機能のプロセスを起動するより、必要な機能の全プロセスを起動するだけのメインプログラムを書いた方が管理しやすいような気がします。共有メモリなどを設定し、機能ごとのプロセスを起動していく最初に起動するプログラムです。一種のランチャーですね。
うーん、やっぱりＣ言語は高級言語というよりアセンブラ風味だなぁ。
#Ｃ言語