電装工芸日記
- 舞台照明機器の製作とか -
ユーザ「電装工芸」の投稿［864件］（4ページ目）
2024年3月 この範囲を時系列順で読む(電装工芸の投稿に限定) この範囲をファイルに出力する
中華電機を覗いていたらこんな電圧計を発見！
調整に使うモノではないと思いますが、パイロットランプを兼ねて受電電圧の大雑把な確認には使えると思います。100v200vを間違っていないか、ドロップしていないかの確認ってことです。
これのいいのは薄いことです、奥行きが18mmしかありません。これまでは丸穴で小型の物は奥行きが50mm以上ありましたが、ここまで薄いなら箱のサイズに自由度が出ます。例えばTRUE1のレセプタクルを羊かん箱に実装すると奥行のために箱の表面には大きなブランクが出来ますが、ここを埋める配置で使えそうなので良いかなと。直電源のTRUE1化を少しづつ進めていますが、思案中の分岐ボックスに使えるかなと。
#器具の製作
調整に使うモノではないと思いますが、パイロットランプを兼ねて受電電圧の大雑把な確認には使えると思います。100v200vを間違っていないか、ドロップしていないかの確認ってことです。
これのいいのは薄いことです、奥行きが18mmしかありません。これまでは丸穴で小型の物は奥行きが50mm以上ありましたが、ここまで薄いなら箱のサイズに自由度が出ます。例えばTRUE1のレセプタクルを羊かん箱に実装すると奥行のために箱の表面には大きなブランクが出来ますが、ここを埋める配置で使えそうなので良いかなと。直電源のTRUE1化を少しづつ進めていますが、思案中の分岐ボックスに使えるかなと。
#器具の製作
プロセス間通信を大別しますと、SharedMemory(mmap含む)、Pipe、Queueです。左から「速いけど扱いが難しい」→「扱いが簡単だけど遅い」となるようです。
SharedMemoryは初期定義でメモリサイズを指定しなければなりませんが、型の指定は無く、ポインタを使った変数アクセスの要領で使えます。メモリサイズが最初から固定されるので実質的には型が決まった変数となりますが、読み出してもデータが残ることが特性でしょうか。
PipeはマネージされないQueueと思って捉えています。FIFOみたいな挙動で単純な受け渡しをする一時スタックです。
QueueはPipeが高度にマネージされFIFOまたはLIFOとして機能するイメージです。遅いのが難点ですが、速度を求めないなら便利な手段です。
SharedMemoryとPipeはどちらが速いか論争があるようですが、消さなければ残るメモリーと読みだしたら消える一時スタックというそもそもの違いがある上に、転送速度は誤差レベルの違いしか無いように思われますので、用途に合わせて使い分けるだけかなと・・・。
ネットの情報にも教科書にも、これらの違いを一覧してくれる情報がほとんどありません。関数のパラメータや動作特性などのそもそもの説明がなく、どれが速いか遅いかって比較があればましな方です。コピペの様なソースコードに「俺ってスゲーと思わね？」って感じの斜め上の応用を加えたコードが書かれている物ばかり。説明をしてくれる気持ちはありがたいのだけど、中途半端な応用に本筋が埋もれたサンプルコードを誰が喜ぶのかと疑問を感じたりしています。大変勝手な言い方ですが、検索結果が無駄に多くなって分かりやすい情報が埋もれてしまいますので、ガチのプロは見向きもしない、初心者には伝わらない、そんな「俺スゲーでしょ解説」はお控え願いたいものです。斜め上の応用は書く人それぞれのクセであって一般論とは言い難いのですし。
上記はネット検索で迷宮を彷徨ってしまった思いからの愚痴です。わかってんなら書けよとか言われそうですが、人に教えられる程習得出来たら是非書きたいものです。
#Ｃ言語
SharedMemoryは初期定義でメモリサイズを指定しなければなりませんが、型の指定は無く、ポインタを使った変数アクセスの要領で使えます。メモリサイズが最初から固定されるので実質的には型が決まった変数となりますが、読み出してもデータが残ることが特性でしょうか。
PipeはマネージされないQueueと思って捉えています。FIFOみたいな挙動で単純な受け渡しをする一時スタックです。
QueueはPipeが高度にマネージされFIFOまたはLIFOとして機能するイメージです。遅いのが難点ですが、速度を求めないなら便利な手段です。
SharedMemoryとPipeはどちらが速いか論争があるようですが、消さなければ残るメモリーと読みだしたら消える一時スタックというそもそもの違いがある上に、転送速度は誤差レベルの違いしか無いように思われますので、用途に合わせて使い分けるだけかなと・・・。
ネットの情報にも教科書にも、これらの違いを一覧してくれる情報がほとんどありません。関数のパラメータや動作特性などのそもそもの説明がなく、どれが速いか遅いかって比較があればましな方です。コピペの様なソースコードに「俺ってスゲーと思わね？」って感じの斜め上の応用を加えたコードが書かれている物ばかり。説明をしてくれる気持ちはありがたいのだけど、中途半端な応用に本筋が埋もれたサンプルコードを誰が喜ぶのかと疑問を感じたりしています。大変勝手な言い方ですが、検索結果が無駄に多くなって分かりやすい情報が埋もれてしまいますので、ガチのプロは見向きもしない、初心者には伝わらない、そんな「俺スゲーでしょ解説」はお控え願いたいものです。斜め上の応用は書く人それぞれのクセであって一般論とは言い難いのですし。
上記はネット検索で迷宮を彷徨ってしまった思いからの愚痴です。わかってんなら書けよとか言われそうですが、人に教えられる程習得出来たら是非書きたいものです。
#Ｃ言語
ホール管理の増員で置きダヌキ。
こういう時はArt-Netパッチの設計を進めるのがいい。いつでも作業を切れるって意味でも不便がありません。
構造においてはマルチプロセス化することがとても重要です。RasperryPi4Bは４コアありますが手続き型処理はもちろんマルチスレッドでも１コア動作が原則。Art-Netの入力、パッチ処理、出力、フロントエンドの処理を同時並行で行いたいのですが、複数のコアで動くかはＯＳ次第とはいえプロセスを分散しておけば１コアだけに負担がかかることは無くなるので良いかなと思うのです。
現在の研究課題はプロセス間通信です。例え一つのアプリケーション内でもプロセスを分けてしまうと同じ変数を触ることが出来ません。これを解消するのがプロセス間通信で、SharedMemory、Pipe、Queueなどの手法があります。それぞれに得手不得手があり、扱いが楽な手法は受け渡しが遅く、受け渡しが速い手法は扱いが難しい傾向があります。このどれを使うかで処理構造が違ってくるので、全体の設計を進める上ではどの手法で繋げるかを予め決めておかないと後が面倒なようです。
注意する点は読み書きのタイミングとデータ枠が可変するかどうかです。勉強中なので説明するのは難しいのですが、この辺りを十分に整理して手段を吟味しているところです。
#Ｃ言語 #[Art-Net]
こういう時はArt-Netパッチの設計を進めるのがいい。いつでも作業を切れるって意味でも不便がありません。
構造においてはマルチプロセス化することがとても重要です。RasperryPi4Bは４コアありますが手続き型処理はもちろんマルチスレッドでも１コア動作が原則。Art-Netの入力、パッチ処理、出力、フロントエンドの処理を同時並行で行いたいのですが、複数のコアで動くかはＯＳ次第とはいえプロセスを分散しておけば１コアだけに負担がかかることは無くなるので良いかなと思うのです。
現在の研究課題はプロセス間通信です。例え一つのアプリケーション内でもプロセスを分けてしまうと同じ変数を触ることが出来ません。これを解消するのがプロセス間通信で、SharedMemory、Pipe、Queueなどの手法があります。それぞれに得手不得手があり、扱いが楽な手法は受け渡しが遅く、受け渡しが速い手法は扱いが難しい傾向があります。このどれを使うかで処理構造が違ってくるので、全体の設計を進める上ではどの手法で繋げるかを予め決めておかないと後が面倒なようです。
注意する点は読み書きのタイミングとデータ枠が可変するかどうかです。勉強中なので説明するのは難しいのですが、この辺りを十分に整理して手段を吟味しているところです。
#Ｃ言語 #[Art-Net]
寝床を仮組みしました。
懸案の丸ナットを使った接合はイイ感じ。３方向からの２×４材がガッチリ接合されています。斜め材無しにここまで固まるなら他にも使えそうです。
諸々組んでしまったので写真が撮れませんが、バラして塗装する際に記念撮影をしましょう。
ただ、少し寸法間違いをしました。敷板を105mmほど短く切ってしまったのですが、やり直すとコストがかかるし材料も勿体ない。機能は満たしていますので余り材で誤魔化すことにします。
自宅の改装課題はまだまだありますが、大物の目途が付いたので一山越えた気分です。
#ガチ工作
懸案の丸ナットを使った接合はイイ感じ。３方向からの２×４材がガッチリ接合されています。斜め材無しにここまで固まるなら他にも使えそうです。
諸々組んでしまったので写真が撮れませんが、バラして塗装する際に記念撮影をしましょう。
ただ、少し寸法間違いをしました。敷板を105mmほど短く切ってしまったのですが、やり直すとコストがかかるし材料も勿体ない。機能は満たしていますので余り材で誤魔化すことにします。
自宅の改装課題はまだまだありますが、大物の目途が付いたので一山越えた気分です。
#ガチ工作
先週末は現場が被りまくりでオロオロしてましたが、今週は比較的ヒマなので少しはネタを進められそうです。
プロセス間の共有メモリの読み書き管理はフローチャートレベルではまとまりました。デフォルトでは読み書きを禁止しておき、認証プロセス(スレッド)へ要求を出し読み書きの許可を得るものです。どちらかがアクセスしている間は他方の処理を待たせます。いわゆるセマフォです。
この方法で本当にいいのか、タイムアウトなどの例外処理は必要か、その辺りは今後吟味です。
主処理の実験は以前の試作で済んでいますので、こういった周辺機能をキチンと書くのが今の課題です。
#Ｃ言語 #[Art-Net]
プロセス間の共有メモリの読み書き管理はフローチャートレベルではまとまりました。デフォルトでは読み書きを禁止しておき、認証プロセス(スレッド)へ要求を出し読み書きの許可を得るものです。どちらかがアクセスしている間は他方の処理を待たせます。いわゆるセマフォです。
この方法で本当にいいのか、タイムアウトなどの例外処理は必要か、その辺りは今後吟味です。
主処理の実験は以前の試作で済んでいますので、こういった周辺機能をキチンと書くのが今の課題です。
#Ｃ言語 #[Art-Net]
共有メモリの読み書きのタイミングを考えています。
Art-Netを受信して現在値を得る部分とそれを読みだしてパッチなりの加工をする部分はプロセスを分けようと思います。C言語では手続き型で書いても関数型で書いても基本は１プロセスで動作します。RaspberryPiでも１プロセスですべての処理を行っても間に合うと言えば間に合うのですが、プロセスを分けておいた方が処理に余裕が出来て後々いいかなと。
プロセスを分けることのメリットはあるのですが、問題はプロセス間のデータ共有、共有メモリへのアクセスのタイミングです。受信プロセスが共有メモリに書いている最中に次処理のプロセスが読み出すとデータに不整合が起こります。一つのプロセスやスレッドで読み書きを行うなら手続きの順番的に起こらないことですが、それぞれが平行して勝手に動いていれば起こりうることです。書き込んでいる最中は読み出しを待たせ、読み出している最中には書き込みを待たせる仕組みが必要です。
共有メモリは単純な機構のために速度が期待できる反面この様なマネージはされていません。書き込んでもいいぞ読み出してもいいぞとタイミングをジャッジする仕組みは自作しないといけないのです。
機構は単純ですが、吟味しないと潜在的なバグ要因になりそうです。
#Ｃ言語
Art-Netを受信して現在値を得る部分とそれを読みだしてパッチなりの加工をする部分はプロセスを分けようと思います。C言語では手続き型で書いても関数型で書いても基本は１プロセスで動作します。RaspberryPiでも１プロセスですべての処理を行っても間に合うと言えば間に合うのですが、プロセスを分けておいた方が処理に余裕が出来て後々いいかなと。
プロセスを分けることのメリットはあるのですが、問題はプロセス間のデータ共有、共有メモリへのアクセスのタイミングです。受信プロセスが共有メモリに書いている最中に次処理のプロセスが読み出すとデータに不整合が起こります。一つのプロセスやスレッドで読み書きを行うなら手続きの順番的に起こらないことですが、それぞれが平行して勝手に動いていれば起こりうることです。書き込んでいる最中は読み出しを待たせ、読み出している最中には書き込みを待たせる仕組みが必要です。
共有メモリは単純な機構のために速度が期待できる反面この様なマネージはされていません。書き込んでもいいぞ読み出してもいいぞとタイミングをジャッジする仕組みは自作しないといけないのです。
機構は単純ですが、吟味しないと潜在的なバグ要因になりそうです。
#Ｃ言語
今週末はホール管理の増員です。これといってやる事のない置きダヌキです。
Art-Netパッチの処理構造を妄想。
C言語でドライバ部、Pythonでユーザーインターフェース部を作る棲み分けですが、今はドライバ部の構成を整理しています。
これまでの試行錯誤から処理フローを図式化。基本の流れは見えたと思います。
ただ、C言語の構造体を用いた配列処理をもっと突っ込んで覚える必要があります。Art-Netのデータは、レベル値だけでなくメタデータとも言えるインデックスが重要で、カード型データ構造と言ってもいいでしょう。これの追加、削除、抽出、修正を延々と繰り返すので構造体配列を自在に扱えることは必須技能です。
C言語での配列は少し不器用で、私の理解が間違っていなければ、配列をデータベースに見立てたとしてレコードの追加や削除は出来ません。出来ると言えば出来るのですが、特定のレコードを除いた配列全体を新たな配列としてコピーするような操作が必要です。追加も似た様な操作になります。
少しややこしいのですが、次のサイトでは面白い事を書いてます。
C言語 構造体を使ってリスト構造を作るプログラム
C言語の配列に頼らずリスト構造を構成してます。言うなれば手作業で配列操作をするのです。
また、変数名を使わずメモリ領域を確保してポインタで管理しています。一見不合理な使い方に見えますが合理的かも。アセンブラっぽいので私には違和感はありません。
オレメモ
C言語：構造体のメンバのアドレス
C言語 ポインタ同士の引き算
配列が格納されるアドレスとピッチがわかればポインタで配列にアクセス出来ます。処理の内容によってはこの方が速いかも。
この他にも、以前はどうも理解しきれなかったC言語のマルチプロセスや共有メモリ(mmap)のことが理解できた。
Linuxプロセスの生成と実行 fork／exec
C言語でmmap()を用いてプロセス間で変数を共有する
以前の試作でイマイチだったところが解決しそうな期待感。
#[Art-Net]
Art-Netパッチの処理構造を妄想。
C言語でドライバ部、Pythonでユーザーインターフェース部を作る棲み分けですが、今はドライバ部の構成を整理しています。
これまでの試行錯誤から処理フローを図式化。基本の流れは見えたと思います。
ただ、C言語の構造体を用いた配列処理をもっと突っ込んで覚える必要があります。Art-Netのデータは、レベル値だけでなくメタデータとも言えるインデックスが重要で、カード型データ構造と言ってもいいでしょう。これの追加、削除、抽出、修正を延々と繰り返すので構造体配列を自在に扱えることは必須技能です。
C言語での配列は少し不器用で、私の理解が間違っていなければ、配列をデータベースに見立てたとしてレコードの追加や削除は出来ません。出来ると言えば出来るのですが、特定のレコードを除いた配列全体を新たな配列としてコピーするような操作が必要です。追加も似た様な操作になります。
少しややこしいのですが、次のサイトでは面白い事を書いてます。
C言語 構造体を使ってリスト構造を作るプログラム
C言語の配列に頼らずリスト構造を構成してます。言うなれば手作業で配列操作をするのです。
また、変数名を使わずメモリ領域を確保してポインタで管理しています。一見不合理な使い方に見えますが合理的かも。アセンブラっぽいので私には違和感はありません。
オレメモ
C言語：構造体のメンバのアドレス
C言語 ポインタ同士の引き算
配列が格納されるアドレスとピッチがわかればポインタで配列にアクセス出来ます。処理の内容によってはこの方が速いかも。
この他にも、以前はどうも理解しきれなかったC言語のマルチプロセスや共有メモリ(mmap)のことが理解できた。
Linuxプロセスの生成と実行 fork／exec
C言語でmmap()を用いてプロセス間で変数を共有する
以前の試作でイマイチだったところが解決しそうな期待感。
#[Art-Net]
ロックタイト425はいい感じです。
手では全く回せませんが、モンキーレンチとプライヤで強めに回すと外せます。母材も痛みません。止まり具合はＭ６ボルトでスプリングワッシャを完全に潰してもう一息締めたくらい。素手では無理だけど工具なら外せるという正に願ったり叶ったりのコンディションです。
で、ロックタイト425自体はブチルゴムの様な状態になっています。それほどベタベタはしないけど、へばりついて取れない消しゴムのカスみたいな感じです。
ブチルゴムっぽいからと防水用途に使うには無理がありそうですが、ネジロックにはイイ感じです。
#工具と資材
手では全く回せませんが、モンキーレンチとプライヤで強めに回すと外せます。母材も痛みません。止まり具合はＭ６ボルトでスプリングワッシャを完全に潰してもう一息締めたくらい。素手では無理だけど工具なら外せるという正に願ったり叶ったりのコンディションです。
で、ロックタイト425自体はブチルゴムの様な状態になっています。それほどベタベタはしないけど、へばりついて取れない消しゴムのカスみたいな感じです。
ブチルゴムっぽいからと防水用途に使うには無理がありそうですが、ネジロックにはイイ感じです。
#工具と資材
2024年2月 この範囲を時系列順で読む(電装工芸の投稿に限定) この範囲をファイルに出力する
SP13 の筐体はPE(ポリエチレン)ぽい感じです。刻印が無いとPE(ポリエチレン)なのかPP(ポリプロピレン)なのかABSなのか判別し難いのですが、どれも難接着素材です。ホームセンターの選択肢で接着するならスーパーXハイバーくらいです。ただ、本気で接着されるので、最悪の場合に取り外したいニーズに合いません。
ロックタイト271と243を試しましたが硬化せず。これらは金属用であり、嫌気性(空気を遮断すると硬化する)だけでなく金属イオンにも反応して硬化するのは本当の様です。
気になる製品をすべて試すのは不可能ですから、ロックタイト425が良いのでしょうか。超強力な接着をするモノは沢山ありますが、ホドホドの接着をしてくれるものは少ない。手では回らないけど工具を使えば回るって具合いを求めたいのです。
明日入荷なのでお試しです。
追記
モノタロウさんからロックタイト425が入荷しました。
早速試したところいい感じ。求めているのは工具を使えば分解出来るけれど手では動かない固定ですが、正にそんな感じがします。完全硬化は常温で24時間とのことですので、後日あらためて分解テストをしてみます。
比較的高価な接着剤ですがコネクタ１個当たりの使用量はほんのわずかですし、代替品も見当たりませんので価格に疑問はありません。
#工具と資材
ロックタイト271と243を試しましたが硬化せず。これらは金属用であり、嫌気性(空気を遮断すると硬化する)だけでなく金属イオンにも反応して硬化するのは本当の様です。
気になる製品をすべて試すのは不可能ですから、ロックタイト425が良いのでしょうか。超強力な接着をするモノは沢山ありますが、ホドホドの接着をしてくれるものは少ない。手では回らないけど工具を使えば回るって具合いを求めたいのです。
明日入荷なのでお試しです。
追記
モノタロウさんからロックタイト425が入荷しました。
早速試したところいい感じ。求めているのは工具を使えば分解出来るけれど手では動かない固定ですが、正にそんな感じがします。完全硬化は常温で24時間とのことですので、後日あらためて分解テストをしてみます。
比較的高価な接着剤ですがコネクタ１個当たりの使用量はほんのわずかですし、代替品も見当たりませんので価格に疑問はありません。
#工具と資材