電装工芸日記
- 舞台照明機器の製作とか -
全年全月8日の投稿(時系列順)［27件］（2ページ目）
2022年8月 この範囲を新しい順で読む この範囲をファイルに出力する
コロナの反動で５月から７月の中旬まで忙しくさせて頂きましたが、例年なら夏祭りが続く８月上旬が中止の多発で少し空きました。
このところ基板を書きまくっているのは時間が取れたのと秋の現場に向けて作っておかねばならない案件だからです。
それにしてもKiCADは慣れると素晴らしく使いやすいです。基板CAD全般が持つ独特の風味に違和感を感じるところはありますが、CADLUS-Xは覚えるのに数か月かかったのに対して数時間です。CADLUS-Xで基板CADの流儀を覚えたからかもしれませんけどね。
KiCADの良い所は、回路図と基板がリンクしていることです。自動ではありませんが回路図の修正がワンクリックで基板に反映されます。やったことはありませんが、基板を修正して回路図に反映することも出来るようです。CADLUS-Xではこれが出来なかったので大きな変更が出ると大変でした。
また、3Dビューもいいですね。単にそれを見て楽しむのもいいですが、シルクの仕上がり具合いと部品の干渉を確認出来るのがいい。ガーバーデータのビュワーもシームレスに使えますので、入稿データを２つの手段で確認出来るのは校正手段としてとてもありがたい。
ver6になって「シュミレーター」というメニュー項目を見つけました。以前からあったのかもしれませんし、まだ試していませんが、回路シュミレーターのSpiceなどを当てられるとしたらこれは凄いです。Spiceは少し扱いが面倒ですが、条件を整えてあげるとどの端子にどういう波形が出るかを確認出来るので、特にアナログ回路を作る際には初期確認として便利です。もっとも、私が組むアナログ回路ならSpiceをセッティングするよりブレッドボードで仮組みしてオシロを眺めた方が短時間で済むのですけどね。
漠然とした気持ちを汲んで作ってくれるほど優しくありませんが、回路図からガーバーデータまで一貫した作業環境を提供してくれるKiCADは素晴らしいの一言です。
ちなみに基板とは層を成した板切れです。ガーバーデータはどの層にどんな形を描くかを指示するデータですので、基板の層の構成とそれに対応したレイヤーの名前の関係性を理解すればイラストレーターに馴染んだ人なら描くことは難しくないと思います。実際の層とデータレイヤーの関係には暗黙の縛りがあり、作者が勝手に決めることはまず無いってだけです。この辺りを丁寧に説明してくれている情報が皆無なので取っ付き難いのはあります。
工程としては、回路図作成、基板デザイン、ガーバーデータ作成、入稿となりますが、基板製作を学ぶには逆順で理解していくといいのかもしれません。
#CAD #電子工作
このところ基板を書きまくっているのは時間が取れたのと秋の現場に向けて作っておかねばならない案件だからです。
それにしてもKiCADは慣れると素晴らしく使いやすいです。基板CAD全般が持つ独特の風味に違和感を感じるところはありますが、CADLUS-Xは覚えるのに数か月かかったのに対して数時間です。CADLUS-Xで基板CADの流儀を覚えたからかもしれませんけどね。
KiCADの良い所は、回路図と基板がリンクしていることです。自動ではありませんが回路図の修正がワンクリックで基板に反映されます。やったことはありませんが、基板を修正して回路図に反映することも出来るようです。CADLUS-Xではこれが出来なかったので大きな変更が出ると大変でした。
また、3Dビューもいいですね。単にそれを見て楽しむのもいいですが、シルクの仕上がり具合いと部品の干渉を確認出来るのがいい。ガーバーデータのビュワーもシームレスに使えますので、入稿データを２つの手段で確認出来るのは校正手段としてとてもありがたい。
ver6になって「シュミレーター」というメニュー項目を見つけました。以前からあったのかもしれませんし、まだ試していませんが、回路シュミレーターのSpiceなどを当てられるとしたらこれは凄いです。Spiceは少し扱いが面倒ですが、条件を整えてあげるとどの端子にどういう波形が出るかを確認出来るので、特にアナログ回路を作る際には初期確認として便利です。もっとも、私が組むアナログ回路ならSpiceをセッティングするよりブレッドボードで仮組みしてオシロを眺めた方が短時間で済むのですけどね。
漠然とした気持ちを汲んで作ってくれるほど優しくありませんが、回路図からガーバーデータまで一貫した作業環境を提供してくれるKiCADは素晴らしいの一言です。
ちなみに基板とは層を成した板切れです。ガーバーデータはどの層にどんな形を描くかを指示するデータですので、基板の層の構成とそれに対応したレイヤーの名前の関係性を理解すればイラストレーターに馴染んだ人なら描くことは難しくないと思います。実際の層とデータレイヤーの関係には暗黙の縛りがあり、作者が勝手に決めることはまず無いってだけです。この辺りを丁寧に説明してくれている情報が皆無なので取っ付き難いのはあります。
工程としては、回路図作成、基板デザイン、ガーバーデータ作成、入稿となりますが、基板製作を学ぶには逆順で理解していくといいのかもしれません。
#CAD #電子工作
LCD Monitor Controller の基板を中国に発注しました。
試してもいない回路を発注するのはどうかって話もありますが、感光基板で自作するには密度があり過ぎますし、間違いがあっても許せる金額だからいいかなと。
そんな品物、PICに与えるクロックを内蔵のRC発振子か外付け発振子で8MHzにしようかと思っていたのですが7.3728MHzにしようかと。
一見半端な数値ですが、PICでRS232系のシリアル通信でありがちなボーレート(例えば9600bps)などを扱うならキリがいいのです。計算上ですがエラー率が0%になります。
目的のLCDモニタは単純なパラレルなので厳密な時間管理は不要だし、I2Cはクロック同期式のスレーブなのでタイミングはマスター任せです。しかし、シリアル通信は非同期なので受信側もボーレートを合わせなければなりません。PICはシステムクロックでボーレートを起こしますので、他に支障を来さない範囲でシリアル通信に都合の良いシステムクロックを使った方がいいのです。
これまでは国内の販売店で7.3728MHzの水晶発振子を見つけられなかったので使っていませんでしたが、試しに中国で探したら普通にあります。1個59円と安いので買っておきました。例によって送料の方が高い。。。
シリアル通信に都合が良いクロックは他にもありますが、この値を使うのはPICの都合です。16系PICのクロックは32MHzが上限で、そのままのクロックを与えてもいいのですが、内蔵の4倍PLLを使えば8MHzを与えることで32MHzで動作します。PLLを使った方が外部ノイズに強いのもありますから、8MHz以下でシリアル通信に都合が良い最大値である7.3728MHzはよろしいのです。
同じ理由で、PICでDMXを扱うなら250kHzの二乗数倍がよろしいのです。
#電子工作
試してもいない回路を発注するのはどうかって話もありますが、感光基板で自作するには密度があり過ぎますし、間違いがあっても許せる金額だからいいかなと。
そんな品物、PICに与えるクロックを内蔵のRC発振子か外付け発振子で8MHzにしようかと思っていたのですが7.3728MHzにしようかと。
一見半端な数値ですが、PICでRS232系のシリアル通信でありがちなボーレート(例えば9600bps)などを扱うならキリがいいのです。計算上ですがエラー率が0%になります。
目的のLCDモニタは単純なパラレルなので厳密な時間管理は不要だし、I2Cはクロック同期式のスレーブなのでタイミングはマスター任せです。しかし、シリアル通信は非同期なので受信側もボーレートを合わせなければなりません。PICはシステムクロックでボーレートを起こしますので、他に支障を来さない範囲でシリアル通信に都合の良いシステムクロックを使った方がいいのです。
これまでは国内の販売店で7.3728MHzの水晶発振子を見つけられなかったので使っていませんでしたが、試しに中国で探したら普通にあります。1個59円と安いので買っておきました。例によって送料の方が高い。。。
シリアル通信に都合が良いクロックは他にもありますが、この値を使うのはPICの都合です。16系PICのクロックは32MHzが上限で、そのままのクロックを与えてもいいのですが、内蔵の4倍PLLを使えば8MHzを与えることで32MHzで動作します。PLLを使った方が外部ノイズに強いのもありますから、8MHz以下でシリアル通信に都合が良い最大値である7.3728MHzはよろしいのです。
同じ理由で、PICでDMXを扱うなら250kHzの二乗数倍がよろしいのです。
#電子工作
2022年9月 この範囲を新しい順で読む この範囲をファイルに出力する
舞台仕事の先輩から譲ってもらったLED星球が不調です。
どうも電源モジュールがおかしい。DC12vのモノですが電圧が出ていません。スイッチング素子の前の平滑コンデンサには電圧が出ているので、スイッチング素子が飛んだか、センシング回路が誤作動している感じです。
そもそもの原因が電源モジュール単体の故障なのか、他の部位の不調によって電源モジュールが故障したのかは不明ですが、正常な別電源に繋いでみないとわかりません。
幸い主回路の基板には破損や焼損は見受けられませんので電源モジュール単体の不調だと思います。
帰宅してチェックです。
こういう故障は原因の特定が難しいことがあります。
部品を交換して動いても現場で使ったらやっぱりダメってことが少なくありません。本丸が別なところにあって微妙な関係性で故障に至っている場合です。
精神的にも辛い修理のパターンですが、こういった事例から学ぶことは多いので、まぁいいかなと。
追記
電源モジュールを交換して治りました。
中華電器から電源モジュールをまとめ買いしておいたのが役に立ったようです。
#照明器具
どうも電源モジュールがおかしい。DC12vのモノですが電圧が出ていません。スイッチング素子の前の平滑コンデンサには電圧が出ているので、スイッチング素子が飛んだか、センシング回路が誤作動している感じです。
そもそもの原因が電源モジュール単体の故障なのか、他の部位の不調によって電源モジュールが故障したのかは不明ですが、正常な別電源に繋いでみないとわかりません。
幸い主回路の基板には破損や焼損は見受けられませんので電源モジュール単体の不調だと思います。
帰宅してチェックです。
こういう故障は原因の特定が難しいことがあります。
部品を交換して動いても現場で使ったらやっぱりダメってことが少なくありません。本丸が別なところにあって微妙な関係性で故障に至っている場合です。
精神的にも辛い修理のパターンですが、こういった事例から学ぶことは多いので、まぁいいかなと。
追記
電源モジュールを交換して治りました。
中華電器から電源モジュールをまとめ買いしておいたのが役に立ったようです。
#照明器具
2023年1月 この範囲を新しい順で読む この範囲をファイルに出力する
屋外で開催される成人式関連のイベントで電源出しです。
起動してしまえばやることはありません。
本日の課題は共有メモリのテストです。
次のページにあるソースをそのまま使って挙動を確認です。
プロセス間でのメモリ共有
親プロセス「ShareMemTest1」を起動した後、待機時間(20秒)のうちにコンソールで「ShareMemTest2」に共有メモリのIDを与えて起動するというもの。一貫したプログラムではありませんが、やりたいことはプロセス間でのメモリ共有ですからむしろわかりやすい。
ちなみに、コンソールでプログラムを起動する際、末尾に「&」を付けると新規プロセスで実行します。
ここサンプルを使うなら、
＜親プロセスを起動＞
$ ./ShareMemTest1 &
＜起動後表示＞
nShareMemID = 23 /* IDは都度変わります */
process1 : nVar1 = 1, nVar2 = 2
・・・ここで20秒Sleepしてます・・・
＜子プロセスを起動＞
$ ./ShareMemTest2 23 &
＜起動後表示＞
nShareMemID = 23
process2 : nVar1 = 1, nVar2 = 2
process2 : nVar1 = 2, nVar2 = 2
・・・子プロセスはここで終了・・・
・・・20秒後、親プロセスが再開・・・
process2 : nVar1 = 2, nVar2 = 2
・・・親プロセスも終了・・・
となります。
正に記述にある通り。
$ ipcs -m
や
$ free
を用いるとSharedメモリの状況がわかります。
実際のテストではgetpid()を用いてプロセスIDも表示しながら確認しましたが、確かに別プロセスでした。
共有メモリの容量は、無意味に8MBくらい設定してみましたが何の問題も無し。
親側の設定は、typedefで構造体を定義し、構造体のポインタ変数を作り、構造体のメモリサイズ(sizeof()で取得)をもとに共有メモリを作り、構造体のポインタ変数に共有メモリを割り当てる、といった流れでしょうか。
子側は、typedefで構造体を定義し、構造体のポインタ変数を作り、親から取得したIDから構造体のポインタ変数に共有メモリを割り当てる、といった流れ？
共有メモリ上に変数(構造体)を構築した後は共有メモリを意識する必要は無いと思います。もちろん、衝突回避は常に考えないといけませんけど。
勘違いしていた点ですが、共有メモリのIDは管理用の通し番号であってポインタに設定するアドレスではないことです。Ｃ言語では何かにつけてポインタ渡しなのでこれもそうかと思ってしまいました。
共有メモリに構造体を配置することが次の課題ですが、構造体についてもう少し勉強してからです。
#Ｃ言語
起動してしまえばやることはありません。
本日の課題は共有メモリのテストです。
次のページにあるソースをそのまま使って挙動を確認です。
プロセス間でのメモリ共有
親プロセス「ShareMemTest1」を起動した後、待機時間(20秒)のうちにコンソールで「ShareMemTest2」に共有メモリのIDを与えて起動するというもの。一貫したプログラムではありませんが、やりたいことはプロセス間でのメモリ共有ですからむしろわかりやすい。
ちなみに、コンソールでプログラムを起動する際、末尾に「&」を付けると新規プロセスで実行します。
ここサンプルを使うなら、
＜親プロセスを起動＞
$ ./ShareMemTest1 &
＜起動後表示＞
nShareMemID = 23 /* IDは都度変わります */
process1 : nVar1 = 1, nVar2 = 2
・・・ここで20秒Sleepしてます・・・
＜子プロセスを起動＞
$ ./ShareMemTest2 23 &
＜起動後表示＞
nShareMemID = 23
process2 : nVar1 = 1, nVar2 = 2
process2 : nVar1 = 2, nVar2 = 2
・・・子プロセスはここで終了・・・
・・・20秒後、親プロセスが再開・・・
process2 : nVar1 = 2, nVar2 = 2
・・・親プロセスも終了・・・
となります。
正に記述にある通り。
$ ipcs -m
や
$ free
を用いるとSharedメモリの状況がわかります。
実際のテストではgetpid()を用いてプロセスIDも表示しながら確認しましたが、確かに別プロセスでした。
共有メモリの容量は、無意味に8MBくらい設定してみましたが何の問題も無し。
親側の設定は、typedefで構造体を定義し、構造体のポインタ変数を作り、構造体のメモリサイズ(sizeof()で取得)をもとに共有メモリを作り、構造体のポインタ変数に共有メモリを割り当てる、といった流れでしょうか。
子側は、typedefで構造体を定義し、構造体のポインタ変数を作り、親から取得したIDから構造体のポインタ変数に共有メモリを割り当てる、といった流れ？
共有メモリ上に変数(構造体)を構築した後は共有メモリを意識する必要は無いと思います。もちろん、衝突回避は常に考えないといけませんけど。
勘違いしていた点ですが、共有メモリのIDは管理用の通し番号であってポインタに設定するアドレスではないことです。Ｃ言語では何かにつけてポインタ渡しなのでこれもそうかと思ってしまいました。
共有メモリに構造体を配置することが次の課題ですが、構造体についてもう少し勉強してからです。
#Ｃ言語
共有メモリに構造体を配置してみましたが、割と簡単でした。
構造体のタグ(ひな形)をヘッダーファイルに作り、親プロセスと子プロセスにinclude。共有メモリのサイズは構造体のタグから得て設定。共有メモリ上に置く変数を独立したポインタにするとオフセットをそれぞれ計算して与えないといけませんが、構造体なら一括設定出来て便利です。
構造体をポインタにすると表記が独特になりますが、意味合いが明示的となって読みやすいかもしれません。
この辺りには、本文中に出来るだけ定数を直書きしないという方針にも繋がってきます。
次は共有メモリの衝突回避を調べないといけません。
#Ｃ言語
構造体のタグ(ひな形)をヘッダーファイルに作り、親プロセスと子プロセスにinclude。共有メモリのサイズは構造体のタグから得て設定。共有メモリ上に置く変数を独立したポインタにするとオフセットをそれぞれ計算して与えないといけませんが、構造体なら一括設定出来て便利です。
構造体をポインタにすると表記が独特になりますが、意味合いが明示的となって読みやすいかもしれません。
この辺りには、本文中に出来るだけ定数を直書きしないという方針にも繋がってきます。
次は共有メモリの衝突回避を調べないといけません。
#Ｃ言語
共有メモリの衝突回避ですが、共有メモリの中にハンドシェイク表すフラグを入れたらそれでいいんじゃないかと。
そのフラグが立っていれば極々わずかな時間sleepを繰り返す処理です。
while(flag1 == 1)
{
sleep(0.001);
}
flag2 = 1;
/* 共有メモリ処理 */
flag2 = 0;
みたいなものです。
別プロセスがフラグを0にすればwhileを抜けます。
簡易的なモノですが、フラグを書き換えられるプロセスを一つにしておけばイイんじゃないかと。最も簡単なセマフォはこういうことですし。
子プロセスの停止制御も同様の考え方が使えます。
動作し続けるってことは繰り返し処理です。単なる繰り返しはwhile(1)とかで無限ループすることが多いので、while(flag==1)とかにすればいい。共有メモリ上のフラグが1ならwhileでループし0になったら抜ければいいのです。抜けたら終了処理をしてプロセスを落とすと。子プロセスが完全に終わったことはスタックしておいたプロセスIDを見ればわかります。
この辺りまで決まれば次はランチャーです。
#Ｃ言語
そのフラグが立っていれば極々わずかな時間sleepを繰り返す処理です。
while(flag1 == 1)
{
sleep(0.001);
}
flag2 = 1;
/* 共有メモリ処理 */
flag2 = 0;
みたいなものです。
別プロセスがフラグを0にすればwhileを抜けます。
簡易的なモノですが、フラグを書き換えられるプロセスを一つにしておけばイイんじゃないかと。最も簡単なセマフォはこういうことですし。
子プロセスの停止制御も同様の考え方が使えます。
動作し続けるってことは繰り返し処理です。単なる繰り返しはwhile(1)とかで無限ループすることが多いので、while(flag==1)とかにすればいい。共有メモリ上のフラグが1ならwhileでループし0になったら抜ければいいのです。抜けたら終了処理をしてプロセスを落とすと。子プロセスが完全に終わったことはスタックしておいたプロセスIDを見ればわかります。
この辺りまで決まれば次はランチャーです。
#Ｃ言語
ランチャーに行く前にscoketの基本動作の確認かな？
受信したArt-Netパケットをそのまま送信する実験。
これが求める機能の基本ですから確認せんといかん。
#[Art-Net] #Ｃ言語
受信したArt-Netパケットをそのまま送信する実験。
これが求める機能の基本ですから確認せんといかん。
#[Art-Net] #Ｃ言語
2023年4月 この範囲を新しい順で読む この範囲をファイルに出力する
ホール管理の増員で操作盤の置物になっているだけなので調べモノをし放題です。
PythonのライブラリをＣ言語で作る方法の基本はわかりました。このサイトだけでほぼ解決。
製作手順を大まかに書き出すと、
１）関数ライブラリを用意する。
Ｃ言語で#includeして使える関数なら汎用でも自作でも何でもいい。
２）「ラッパー関数」を用意する。
Ｃ言語の関数をPythonへ引き渡す定義をするソースファイル。Pythonからの呼び出し方と変数の変換方法をＣ言語で記述します。
３）セットアップファイルを用意する。
セットアップファイルはgccで言うところのMakeFileです。Pythonで記述され、ファイル名はsetup.pyにすることが多いそうです。
４）ビルドする。
セットアップファイルを使ってビルドする。
５）インストールする。
セットアップファイルを使ってインストールする（動作の実際はPythonパッケージ管理のpipへの登録）。
と、なります。
ラッパー関数はＣ言語とPythonの両方を知らないと記述出来ないので少し難しいですが、セットアップファイルは定型の通り記述するだけです。
#Ｃ言語 #Python
PythonのライブラリをＣ言語で作る方法の基本はわかりました。このサイトだけでほぼ解決。
製作手順を大まかに書き出すと、
１）関数ライブラリを用意する。
Ｃ言語で#includeして使える関数なら汎用でも自作でも何でもいい。
２）「ラッパー関数」を用意する。
Ｃ言語の関数をPythonへ引き渡す定義をするソースファイル。Pythonからの呼び出し方と変数の変換方法をＣ言語で記述します。
３）セットアップファイルを用意する。
セットアップファイルはgccで言うところのMakeFileです。Pythonで記述され、ファイル名はsetup.pyにすることが多いそうです。
４）ビルドする。
セットアップファイルを使ってビルドする。
５）インストールする。
セットアップファイルを使ってインストールする（動作の実際はPythonパッケージ管理のpipへの登録）。
と、なります。
ラッパー関数はＣ言語とPythonの両方を知らないと記述出来ないので少し難しいですが、セットアップファイルは定型の通り記述するだけです。
#Ｃ言語 #Python
Linux上のＣ言語でLTCの波形を起こせたらと思ったのですが、処理能力の総量は余裕タップリなものの、Art-Netエンジンを作った際に感じた挙動ムラから想像するに許容範囲を越える波形ムラが起こりそうです。LinuxはOSそのものや他のモジュールに引っ張られて100～300usecくらい待たされることがあるのですが、LTCの波形を起こすのにこの条件はよろしくありません。RTOSを使わないなら普通のことですけどね。
ならばLTCを起こすところにはPICを使ったらいいかな？適材適所？
LinuxからUARTなどでフレーム情報を送ってPICでLTCを生成するのです。２～４フレーム分くらいPICにバッファすればLinux側に動作ムラがあっても安定した波形を出すと思われます。
差動バイフェーズで信号を反転する時間ピッチは25fpsで250usecです。29.97fpsではなく25fpsとしているのは、PALのレートなのでLTC対応の演出機器は100%対応するし、何よりも計算がしやすく誤差も出にくいために当面の試作には良いかなと。250usecは32MHzのPICで2,000命令相当の時間です。これだけあれば大概ことは１フェーズ分実行出来ます。実行周期はTMR1やTMR2による周期割込みを使えばPICのクロック素子相当の精度を得られます。
求める精度は、周期が0.001%未満、差動バイフェーズの立ち上がり立下り精度が5%未満です。無理は無さそうです。
書いてて思ったのですが、こんなLTCジェネレーターをこれまでに作らなかった自分が不思議。
#タイムコード #PIC #電子工作
ならばLTCを起こすところにはPICを使ったらいいかな？適材適所？
LinuxからUARTなどでフレーム情報を送ってPICでLTCを生成するのです。２～４フレーム分くらいPICにバッファすればLinux側に動作ムラがあっても安定した波形を出すと思われます。
差動バイフェーズで信号を反転する時間ピッチは25fpsで250usecです。29.97fpsではなく25fpsとしているのは、PALのレートなのでLTC対応の演出機器は100%対応するし、何よりも計算がしやすく誤差も出にくいために当面の試作には良いかなと。250usecは32MHzのPICで2,000命令相当の時間です。これだけあれば大概ことは１フェーズ分実行出来ます。実行周期はTMR1やTMR2による周期割込みを使えばPICのクロック素子相当の精度を得られます。
求める精度は、周期が0.001%未満、差動バイフェーズの立ち上がり立下り精度が5%未満です。無理は無さそうです。
書いてて思ったのですが、こんなLTCジェネレーターをこれまでに作らなかった自分が不思議。
#タイムコード #PIC #電子工作