電装工芸日記
- 舞台照明機器の製作とか -
全年7月27日の投稿(時系列順)［4件］
2022年 この範囲を新しい順で読む この範囲をファイルに出力する
パワーLEDをリフローして秋月さんのドライバ基板で点灯させました。
単色の3w品はかなり明るく、LEDの樹脂部品の変形もありませんので思ったよりも良好な照射をしています。
30度のレンズを取り付けた５発が2m離れた位置で中心150Lx。期待値は200Lxだったので足りませんが、電流値を調整すれば180Lxくらいまで上げられそうな気もします。
課題は明るさを増して個体ムラを軽減することです。実作業はLEDに送り込む電流値の調整となります。半導体は付加電圧に入力電流が単純比例しないために半導体と呼ばれますがLEDもその部類です。LEDの明るさは主に入力電流に比例しますが、電圧特性が個体によってバラつきがあるくせに入力電流は付加電圧によって増減します。制御回路は電流を計測してフィードバック制御してはいますが、電流の計測も結局は電圧の計測なので累積誤差は決して少なくありません。設計値のままの部品で回路を組んでもある程度の範囲には収まるのですが10%くらいの照度差は発生するようです(抵抗やコンデンサの誤差は5%程度あるので当たり前？)。なので、最後は人の手で計測して調整できるようにしなければなりません。
さて、どうしよう！？
追記
気になったので再計測。
同条件で260Lx出ている・・・十分に期待値なのでホッとしましたが、なんで100Lxもアップ？
考えられるのは温度。
昨日のチェックはリフローの熱が完全に抜ける前に実施したと言ってもいい。アルミアングルをヒートシンクにしているけど冷却不足かも。制御回路には気になる発熱が無いので無関係だと思う。
しばらく点灯して十分に熱を持たせて再計測します。
追記・・・30分後
ヒートシンクが十分に温まったところで計測。
照度258Lx。
わずかに下がったけれど計測の誤差レベルでしょう。十分に期待値が出ているので細かい調整は考えないことにします。
アルミアングルは温まっても素手で握っていられる程度なので、筐体放熱だけで足りそうな気がします。触った感じ、昨日よりも低い気がしなくもないけど・・・
これなら実試作を始めてもいいので、基板を設計して中国に発注しますかね。
LED基板も制御基板もアルミの片面基板にしましょう。短絡を避けるために基板の周囲にパターンの余白を大きめにとる必要がありますが、基板を筐体やヒートシンクに直付け出来るなど、クーリングの処理にメリットがあります。それに、国内でアルミ基板を作ると樹脂基板の数倍の価格になるのに対し中国ではほんの数割しか違いません。クーリングの機構が簡単になるならアルミ基板を用いた方が全体としては安く仕上がります。
#電子工作 #LED
単色の3w品はかなり明るく、LEDの樹脂部品の変形もありませんので思ったよりも良好な照射をしています。
30度のレンズを取り付けた５発が2m離れた位置で中心150Lx。期待値は200Lxだったので足りませんが、電流値を調整すれば180Lxくらいまで上げられそうな気もします。
課題は明るさを増して個体ムラを軽減することです。実作業はLEDに送り込む電流値の調整となります。半導体は付加電圧に入力電流が単純比例しないために半導体と呼ばれますがLEDもその部類です。LEDの明るさは主に入力電流に比例しますが、電圧特性が個体によってバラつきがあるくせに入力電流は付加電圧によって増減します。制御回路は電流を計測してフィードバック制御してはいますが、電流の計測も結局は電圧の計測なので累積誤差は決して少なくありません。設計値のままの部品で回路を組んでもある程度の範囲には収まるのですが10%くらいの照度差は発生するようです(抵抗やコンデンサの誤差は5%程度あるので当たり前？)。なので、最後は人の手で計測して調整できるようにしなければなりません。
さて、どうしよう！？
追記
気になったので再計測。
同条件で260Lx出ている・・・十分に期待値なのでホッとしましたが、なんで100Lxもアップ？
考えられるのは温度。
昨日のチェックはリフローの熱が完全に抜ける前に実施したと言ってもいい。アルミアングルをヒートシンクにしているけど冷却不足かも。制御回路には気になる発熱が無いので無関係だと思う。
しばらく点灯して十分に熱を持たせて再計測します。
追記・・・30分後
ヒートシンクが十分に温まったところで計測。
照度258Lx。
わずかに下がったけれど計測の誤差レベルでしょう。十分に期待値が出ているので細かい調整は考えないことにします。
アルミアングルは温まっても素手で握っていられる程度なので、筐体放熱だけで足りそうな気がします。触った感じ、昨日よりも低い気がしなくもないけど・・・
これなら実試作を始めてもいいので、基板を設計して中国に発注しますかね。
LED基板も制御基板もアルミの片面基板にしましょう。短絡を避けるために基板の周囲にパターンの余白を大きめにとる必要がありますが、基板を筐体やヒートシンクに直付け出来るなど、クーリングの処理にメリットがあります。それに、国内でアルミ基板を作ると樹脂基板の数倍の価格になるのに対し中国ではほんの数割しか違いません。クーリングの機構が簡単になるならアルミ基板を用いた方が全体としては安く仕上がります。
#電子工作 #LED
パワーLEDに先が見えてきたところですが、LHQの代替機材も作れんぢゃね？
今回はφ8mmの単色3wLEDにφ13mmのレンズを被せています。出来るだけ薄い筐体で必要なナマ明かりを確保することが優先課題なので大柄になりがちなフルカラーLEDやリフレクタータイプのレンズを避けただけですが、この延長線でマーブルタイプのカラーミックスLEDバー作ったらLHQの代わりになるんぢゃないかと。発光部を見せないならマーブルタイプでも同じことだし、発熱点が集中しないので作りやすい。
今回のレンズは収差によって半減角の周囲に色温度の低いエリアが出来てしまいますが、4in1などのフルカラーLEDでよくあるエッジの色ムラと比べたら特筆する支障でもありません。それに、LHQの代替にするにはどんなレンズを使っても拡散フィルタやバウンサーを使ってエッジの減光変化を柔らかくしなければなりませんので、発光部を細く作れる今回のφ13mmレンズは悪くないと思うのです。何と言っても安いし軽いし。
また、薄く作れるならカマチに並べるフットライトとしても私好みです。
まずは今の製品を完成させるべきですが、これらのことも考えながら進めるべきでしょう。
#LED #照明器具
今回はφ8mmの単色3wLEDにφ13mmのレンズを被せています。出来るだけ薄い筐体で必要なナマ明かりを確保することが優先課題なので大柄になりがちなフルカラーLEDやリフレクタータイプのレンズを避けただけですが、この延長線でマーブルタイプのカラーミックスLEDバー作ったらLHQの代わりになるんぢゃないかと。発光部を見せないならマーブルタイプでも同じことだし、発熱点が集中しないので作りやすい。
今回のレンズは収差によって半減角の周囲に色温度の低いエリアが出来てしまいますが、4in1などのフルカラーLEDでよくあるエッジの色ムラと比べたら特筆する支障でもありません。それに、LHQの代替にするにはどんなレンズを使っても拡散フィルタやバウンサーを使ってエッジの減光変化を柔らかくしなければなりませんので、発光部を細く作れる今回のφ13mmレンズは悪くないと思うのです。何と言っても安いし軽いし。
また、薄く作れるならカマチに並べるフットライトとしても私好みです。
まずは今の製品を完成させるべきですが、これらのことも考えながら進めるべきでしょう。
#LED #照明器具
2023年 この範囲を新しい順で読む この範囲をファイルに出力する
Table のカラム幅の自動調整で少し悩む。
初期サイズからウィンドウ枠をドラックするサイズ変更を１回でもやれば問題ないのですが、初期サイズからいきなり最大化(フルスクリーン)するとカラム幅が期待値にならない。一見良いのですが全体的に平均的な幅になろうとします。
ウィンドウサイズが初期値以下になると初期値に戻る機能を付けていたので、サイズ変更後にこの機能が１回余計に発動する騙しを入れたところ解決。上記のウィンドウ枠をドラックしてサイズ変更することが自動的に起こる様にしたワケ。ウィンドウサイズを変更をした後の画面復帰が少し遅くなりますが、頻繁に行われる操作ではないのでいいかなと。フラグを使えば起動後一回だけの動作に出来るので書き換えてみます。
PySimpleGUI はこういった騙しみないなのを入れないと期待値を得られないことがあるようです。
あと、列ごとに左寄せ、センタリング、右寄せの指定が出来ないのがシックリこない。
調べたところ次のバージョンのPySimpleGUIでは対応するとのこと。GitHubにあるバージョンを手動インストールすれば今でも出来るらしいですが、pipで入手するにはもう少し待たなければならないようです。
フォントの指定も列ごとに出来るといいのですけどね。
#Python
初期サイズからウィンドウ枠をドラックするサイズ変更を１回でもやれば問題ないのですが、初期サイズからいきなり最大化(フルスクリーン)するとカラム幅が期待値にならない。一見良いのですが全体的に平均的な幅になろうとします。
ウィンドウサイズが初期値以下になると初期値に戻る機能を付けていたので、サイズ変更後にこの機能が１回余計に発動する騙しを入れたところ解決。上記のウィンドウ枠をドラックしてサイズ変更することが自動的に起こる様にしたワケ。ウィンドウサイズを変更をした後の画面復帰が少し遅くなりますが、頻繁に行われる操作ではないのでいいかなと。フラグを使えば起動後一回だけの動作に出来るので書き換えてみます。
PySimpleGUI はこういった騙しみないなのを入れないと期待値を得られないことがあるようです。
あと、列ごとに左寄せ、センタリング、右寄せの指定が出来ないのがシックリこない。
調べたところ次のバージョンのPySimpleGUIでは対応するとのこと。GitHubにあるバージョンを手動インストールすれば今でも出来るらしいですが、pipで入手するにはもう少し待たなければならないようです。
フォントの指定も列ごとに出来るといいのですけどね。
#Python
まだまだ途中ではあるものの使えるっちゃ使える LTC_Player で本業の音源チェックをしています。
思いっきり自画自賛ですが、コレ、便利です。
作った本人だからってのが８１%くらいありそうですけど、こうやって実務で使うと完成イメージが具体的になります。
今は設定変更のロックを機能別にしていますが、Play_Mode という括りで良さそうです。本番モード、リハモード、机上作業モード、プレイリスト編集モードって感じです。各種設定のロックの組み合わせがモードの違いとなりますが、機能単位でロックを掛けられるようにしていますので変更するのは簡単です。
私のプログラムの書き方を整理しますと「状態を把握」「処理の振り分け」「パラメータとフラグの設定」「パラメータとフラグを見て最終処理」ってのを１フェーズ単位にして管理しています。バグが多く発生する書き方は処理を振り分ける際に一部の最終処理までしてしまう書き方だったので、幾重にも重なったふるいにかけて粉を落とすイメージでフラグを立て、最後に落ちて来たフラグを見て最終処理をするのです。その都度結果を求めると整合性を取るのが大変になり、それこぞバグの原因になるのでした・・・私の場合ですけどね。完全独学ですから王道の書き方なんて知りませんが、一本筋の処理フェーズしかないPICのアセンブラで染みついた構築の仕方です。ガチガチで汎用性が狭い感じがしますが、発展させると疑似的なマルチスレッドも構成出来ます。PICではタイマー１個でポーリングによる複数の時間分岐を得る書き方をレギュラー化していますが、これって精度は低いけどRTOSっぽくね？とか思いながら使っています。タイムスレッドと勝手に呼称している書式ですが、余程のレスポンスを求めないなら割込みを使わずタイムスレッドとモジュールの割込みフラグによるポーリング処理で複数の処理をPICの中で実現出来ています。特別なレスポンスを求める要素にだけ割込みを使い、高級言語で言うところの sleep を絶対に使わない方針です。
ソフトウェアは時間の管理が一番大事だと思う今日この頃。適切に時間が管理されていればインプットもアプトプットも整合性を持って管理出来ます。
#Python #PIC
思いっきり自画自賛ですが、コレ、便利です。
作った本人だからってのが８１%くらいありそうですけど、こうやって実務で使うと完成イメージが具体的になります。
今は設定変更のロックを機能別にしていますが、Play_Mode という括りで良さそうです。本番モード、リハモード、机上作業モード、プレイリスト編集モードって感じです。各種設定のロックの組み合わせがモードの違いとなりますが、機能単位でロックを掛けられるようにしていますので変更するのは簡単です。
私のプログラムの書き方を整理しますと「状態を把握」「処理の振り分け」「パラメータとフラグの設定」「パラメータとフラグを見て最終処理」ってのを１フェーズ単位にして管理しています。バグが多く発生する書き方は処理を振り分ける際に一部の最終処理までしてしまう書き方だったので、幾重にも重なったふるいにかけて粉を落とすイメージでフラグを立て、最後に落ちて来たフラグを見て最終処理をするのです。その都度結果を求めると整合性を取るのが大変になり、それこぞバグの原因になるのでした・・・私の場合ですけどね。完全独学ですから王道の書き方なんて知りませんが、一本筋の処理フェーズしかないPICのアセンブラで染みついた構築の仕方です。ガチガチで汎用性が狭い感じがしますが、発展させると疑似的なマルチスレッドも構成出来ます。PICではタイマー１個でポーリングによる複数の時間分岐を得る書き方をレギュラー化していますが、これって精度は低いけどRTOSっぽくね？とか思いながら使っています。タイムスレッドと勝手に呼称している書式ですが、余程のレスポンスを求めないなら割込みを使わずタイムスレッドとモジュールの割込みフラグによるポーリング処理で複数の処理をPICの中で実現出来ています。特別なレスポンスを求める要素にだけ割込みを使い、高級言語で言うところの sleep を絶対に使わない方針です。
ソフトウェアは時間の管理が一番大事だと思う今日この頃。適切に時間が管理されていればインプットもアプトプットも整合性を持って管理出来ます。
#Python #PIC