電装工芸日記
- 舞台照明機器の製作とか -
全年1月5日の投稿［3件］
2024年 この範囲を時系列順で読む この範囲をファイルに出力する
懸案だった殻割りは先述のオイルセパレーターですんなり出来ましたので、本格的に修理の検討を進めたいと思います。
製品は福岡のメモリーさんが扱われている「PegasysG10」です。高級品には見劣りしますが、この製品で問題になるお仕事は持っておりませんので、とてもコスパの良い製品です。
故障個所と思われるのは電源モジュールと操作スイッチです。
電源モジュールは電源の入り口から追いかけると故障個所を見つけることが可能で、大半はFETの破損ですので交換すれば治ることが多いのですが、とても時間がかかる作業なので当面は不可能です。今回は新品に交換し、そのウチ整備してリビルド品として予備に出来ればと思います。
操作スイッチは水濡れによる接点不良が大半です。全く同じスイッチが手に入ればいいのですがまだ見つかりませんし、基板の配線が腐っている物もありますので、今回は基板アッセンブリー交換がいいかなと。。
何にしても基板の供給をして頂けるかにかかっています。現在問合せ中です。
#器具の修理
製品は福岡のメモリーさんが扱われている「PegasysG10」です。高級品には見劣りしますが、この製品で問題になるお仕事は持っておりませんので、とてもコスパの良い製品です。
故障個所と思われるのは電源モジュールと操作スイッチです。
電源モジュールは電源の入り口から追いかけると故障個所を見つけることが可能で、大半はFETの破損ですので交換すれば治ることが多いのですが、とても時間がかかる作業なので当面は不可能です。今回は新品に交換し、そのウチ整備してリビルド品として予備に出来ればと思います。
操作スイッチは水濡れによる接点不良が大半です。全く同じスイッチが手に入ればいいのですがまだ見つかりませんし、基板の配線が腐っている物もありますので、今回は基板アッセンブリー交換がいいかなと。。
何にしても基板の供給をして頂けるかにかかっています。現在問合せ中です。
#器具の修理
少し前の書き込みに写真を揚げた品物は３点セットです。
写真の物はすでに納めていますが、主機なのでこれが無いと他の２点のチェックが出来ませんので中身だけ組んだ物です。
他の２品もほぼ組めました。部品の間違いやら組み上げミスなどが少しありましたが概ね良好です。ケースに組み付けて付属品を作れば終わりますので、ギリギリですが、最終納期には納められそうです。
この製品群は主機となるウェブカメラ、測定データを主機に送る出先機、専用のWi-fi中継器で構成されます。すべてバッテリー駆動が前提条件なのでWi-fi中継器も作ったワケです。
これが終われば昨年ずーっと追われていた感じから抜けられます。
防滴ＬＥＤスポットの殻割りは「オイルパンセパレーター」なる物を使ってみようと思います。
その名にある通り、自動車のエンジンの最下部にあるオイルパン(オイル受け)を取り外すための工具です。オイル漏れを防止するためにエンジンブロックとの間に入っているガスケットが貼り付いて外しにくくなることあるそうですが、隙間に打ち込んでコジ開けるために使います。
こういった工具は形を真似るのは簡単ですが、硬度のある材を使い焼き入れをしなければなりませんので同じ機能を持った物を作るのは簡単ではありません。
と、書いていたら現物が入荷。
早速試してみると楽だこと。差込の位置によっては筐体を割るので注意が必要です。
２つあった方が良さそうなので追加発注。
#器具の製作 #工具や資材
写真の物はすでに納めていますが、主機なのでこれが無いと他の２点のチェックが出来ませんので中身だけ組んだ物です。
他の２品もほぼ組めました。部品の間違いやら組み上げミスなどが少しありましたが概ね良好です。ケースに組み付けて付属品を作れば終わりますので、ギリギリですが、最終納期には納められそうです。
この製品群は主機となるウェブカメラ、測定データを主機に送る出先機、専用のWi-fi中継器で構成されます。すべてバッテリー駆動が前提条件なのでWi-fi中継器も作ったワケです。
これが終われば昨年ずーっと追われていた感じから抜けられます。
防滴ＬＥＤスポットの殻割りは「オイルパンセパレーター」なる物を使ってみようと思います。
その名にある通り、自動車のエンジンの最下部にあるオイルパン(オイル受け)を取り外すための工具です。オイル漏れを防止するためにエンジンブロックとの間に入っているガスケットが貼り付いて外しにくくなることあるそうですが、隙間に打ち込んでコジ開けるために使います。
こういった工具は形を真似るのは簡単ですが、硬度のある材を使い焼き入れをしなければなりませんので同じ機能を持った物を作るのは簡単ではありません。
と、書いていたら現物が入荷。
早速試してみると楽だこと。差込の位置によっては筐体を割るので注意が必要です。
２つあった方が良さそうなので追加発注。
#器具の製作 #工具や資材
2023年 この範囲を時系列順で読む この範囲をファイルに出力する
Ｃ言語はプロセスの管理方法を調査中です。
直近の課題はAr-Netパッチです。この機構は大きく分けて、(1)Art-Netエンジン(受信、パッチ、送信)、(2)DMXの状況モニタ表示、(3)ユーザーからのコマンド操作となります。
Ｃ言語で書けば主な機能をスレッドに分ければいいような気もしますが、スレッドを分けるのもプロセスを分けるのも手間は大差ないので、プロセスを分けておけばいいかなと。
先日も書きましたが、ランチャー的な親プロセスから各機能を子プロセスとして起動しようと思っています。これなら親プロセスで共有メモリを定義して子プロセスにポインタを渡すことが簡単だからです。また、子プロセスとして起動するなら親プロセスがプロセスIDを確実に把握出来ますので管理上のメリットもあります。
まだわからない調査中のことは、子プロセスの終了のさせ方です。killコマンドでプロセスを消す方法はありますが、後処理(設定の現在値の保存など)をしてから子プロセスを終了したいので、有無言わさずプロセスを消すkillコマンドはよろしくありません。望ましいのは、親プロセスからコマンドを送って子プロセス自身で終了させることです。Python的に考えるなら、親プロセスからの指示で子プロセスに何かしらの例外が発生してwhileをbreakで抜け出すような処理です。共有メモリでコマンドをやり取りするのが現実的だと思いますが、出来るだけシンプルで汎用的な方法を構築したいところです。
いずれにしても、親プロセスから子プロセスを起動し、プロセス間で通信(変数の共有)をし、親プロセスから子プロセスを終了させる方法の定型化です。
もう少し学習が進んでからになりますが、共有メモリの挙動も調査しないといけません。
共有メモリは複数のプロセスから読み書きできるメモリ空間ですが、マネジメントされていませんので衝突(読み書きの処理タイミングが被ること)による不整合が起きる可能性があります。これを回避する手段としてセマフォなどの機能があるのですが、出来るだけシンプルな方法を見つけたいと思っています。
調査したいのは、共有メモリに書き込み出来るプロセスを唯一とし、他のプロセスは読み出しのみとした場合にどうかという点です。機能的に共有メモリの読み書きは頻繁に行われますので出来るだけ手数を少なくしたいのですが、結果的に書き込みのタイミングをマネジメントしなくていいなら手数は最小だし、何かが必要だとしてもどこまでやるのかを知りたいワケです。
#Ｃ言語
直近の課題はAr-Netパッチです。この機構は大きく分けて、(1)Art-Netエンジン(受信、パッチ、送信)、(2)DMXの状況モニタ表示、(3)ユーザーからのコマンド操作となります。
Ｃ言語で書けば主な機能をスレッドに分ければいいような気もしますが、スレッドを分けるのもプロセスを分けるのも手間は大差ないので、プロセスを分けておけばいいかなと。
先日も書きましたが、ランチャー的な親プロセスから各機能を子プロセスとして起動しようと思っています。これなら親プロセスで共有メモリを定義して子プロセスにポインタを渡すことが簡単だからです。また、子プロセスとして起動するなら親プロセスがプロセスIDを確実に把握出来ますので管理上のメリットもあります。
まだわからない調査中のことは、子プロセスの終了のさせ方です。killコマンドでプロセスを消す方法はありますが、後処理(設定の現在値の保存など)をしてから子プロセスを終了したいので、有無言わさずプロセスを消すkillコマンドはよろしくありません。望ましいのは、親プロセスからコマンドを送って子プロセス自身で終了させることです。Python的に考えるなら、親プロセスからの指示で子プロセスに何かしらの例外が発生してwhileをbreakで抜け出すような処理です。共有メモリでコマンドをやり取りするのが現実的だと思いますが、出来るだけシンプルで汎用的な方法を構築したいところです。
いずれにしても、親プロセスから子プロセスを起動し、プロセス間で通信(変数の共有)をし、親プロセスから子プロセスを終了させる方法の定型化です。
もう少し学習が進んでからになりますが、共有メモリの挙動も調査しないといけません。
共有メモリは複数のプロセスから読み書きできるメモリ空間ですが、マネジメントされていませんので衝突(読み書きの処理タイミングが被ること)による不整合が起きる可能性があります。これを回避する手段としてセマフォなどの機能があるのですが、出来るだけシンプルな方法を見つけたいと思っています。
調査したいのは、共有メモリに書き込み出来るプロセスを唯一とし、他のプロセスは読み出しのみとした場合にどうかという点です。機能的に共有メモリの読み書きは頻繁に行われますので出来るだけ手数を少なくしたいのですが、結果的に書き込みのタイミングをマネジメントしなくていいなら手数は最小だし、何かが必要だとしてもどこまでやるのかを知りたいワケです。
#Ｃ言語