https://www.densokogei.jp/tegalog/tegalog.cgi ja Copyright 2026 Tue, 07 Apr 2026 17:05:05 +0900 Powered by てがろぐ Ver 3.4.0 ]]>
　LEDフットライトのLEDモジュール基板を発注しましたので、KiCADの3D画を揚げてみました。
　KiCADは回路図から基板を作れて3Dまで出るので便利です。
　LEDの3DキーはFusion360で描いたものをSTEP形式で出力してKiCADに読ませています。　
　逆に、KiCADで描いた基板の3DもSTEP形式で出力すればFusion360に読ませられます。配線パターンまでは表現されませんが、基板の外形に部品が乗った状態のものが出力されます。
　改めて描くことなく部品が乗った基板をFusion360の部品としても使えるので便利です。

　今回は最大4.0vのLEDをDC24v電源のCL6807で駆動させますので５発です。LEDを直列で使いますので、電源電圧はLEDの総電圧+3～5v程度になります。
　LED１発分くらいはドライバ回路で消費となります。

　価格は20枚で$81(USD・送料別)です。消費税は後請求か着払い扱いになるようです。
　為替レートを今日現在の135.5円/USDとすると10975.5円です。1枚あたり548.8円程度。アルミ基板がこの価格は安いと思います。
　ドライバ基板はLEDの動作や照度を確認してからにしますが、基板の価格はサイズよりも枚数に左右されるので１枚の基板に２回路入れましょう。電源モジュールも２回路で１台ですから丁度いい。

#電子工作 -- Posted by 電装工芸 〔602文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=346 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=346 tegalog Thu, 28 Jul 2022 18:10:09 +0900 　必ずしも芯に照度計を置ける訳ではないので５%くらいの違いはアリアリですが、最初の計測値が妙に低かったのは何故でしょう。
　原因はわかりませんが、大事な時にこの現象が起きないことを祈ります。

　基板を設計するにあたり照度をあたり直してみます。
　目指す製品は2.4m離れて1200～1500Lx出す物です。

　現在の計測条件は距離2.2mですので設定値より１割ほど近い。距離の差分で照度は85%くらいになりますので、現在値を260Lxとすると期待値は220Lxです。
　製品は幅1.2mにLEDが30発並んだ構成を想定しています。現在の有効照射面は直径1.0m程ですから照射面の１点には製品１台の83%が当たることになります。
　現在は５発で実験していますので１発あたり44Lx。30発の83%なら24.9発見当。単純計算では1097Lxになるハズです。

　設計値より低いので、仮に製品幅を1.0mにすると照射面の１点には100%当たることになり1320Lxです。
　この値なら十分ですが、現実には経年劣化等によりこの値よりも落ちると思います。10%減として1188Lxですが、この値ならかろうじて目標値。
　仮に製品幅を0.9mにすると1467Lxで10%減でも1319Lx。放熱はいけそうなので、部品類が収まるならこの幅かな？

　通風口やらケーブル口を考慮し、LEDを27.5mmピッチで取り付ければ30発でも0.9mに収まります。

#LED #照明器具 -- Posted by 電装工芸 〔665文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=345 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=345 tegalog Thu, 28 Jul 2022 10:41:57 +0900 　今回はφ8mmの単色3wLEDにφ13mmのレンズを被せています。出来るだけ薄い筐体で必要なナマ明かりを確保することが優先課題なので大柄になりがちなフルカラーLEDやリフレクタータイプのレンズを避けただけですが、この延長線でマーブルタイプのカラーミックスLEDバー作ったらLHQの代わりになるんぢゃないかと。発光部を見せないならマーブルタイプでも同じことだし、発熱点が集中しないので作りやすい。
　今回のレンズは収差によって半減角の周囲に色温度の低いエリアが出来てしまいますが、4in1などのフルカラーLEDでよくあるエッジの色ムラと比べたら特筆する支障でもありません。それに、LHQの代替にするにはどんなレンズを使っても拡散フィルタやバウンサーを使ってエッジの減光変化を柔らかくしなければなりませんので、発光部を細く作れる今回のφ13mmレンズは悪くないと思うのです。何と言っても安いし軽いし。
　また、薄く作れるならカマチに並べるフットライトとしても私好みです。
　まずは今の製品を完成させるべきですが、これらのことも考えながら進めるべきでしょう。

#LED #照明器具 -- Posted by 電装工芸 〔528文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=344 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=344 tegalog Wed, 27 Jul 2022 23:32:28 +0900 　単色の3w品はかなり明るく、LEDの樹脂部品の変形もありませんので思ったよりも良好な照射をしています。

　30度のレンズを取り付けた５発が2m離れた位置で中心150Lx。期待値は200Lxだったので足りませんが、電流値を調整すれば180Lxくらいまで上げられそうな気もします。
　課題は明るさを増して個体ムラを軽減することです。実作業はLEDに送り込む電流値の調整となります。半導体は付加電圧に入力電流が単純比例しないために半導体と呼ばれますがLEDもその部類です。LEDの明るさは主に入力電流に比例しますが、電圧特性が個体によってバラつきがあるくせに入力電流は付加電圧によって増減します。制御回路は電流を計測してフィードバック制御してはいますが、電流の計測も結局は電圧の計測なので累積誤差は決して少なくありません。設計値のままの部品で回路を組んでもある程度の範囲には収まるのですが10%くらいの照度差は発生するようです(抵抗やコンデンサの誤差は5%程度あるので当たり前？)。なので、最後は人の手で計測して調整できるようにしなければなりません。
　さて、どうしよう！？

追記
　気になったので再計測。
　同条件で260Lx出ている・・・十分に期待値なのでホッとしましたが、なんで100Lxもアップ？
　考えられるのは温度。
　昨日のチェックはリフローの熱が完全に抜ける前に実施したと言ってもいい。アルミアングルをヒートシンクにしているけど冷却不足かも。制御回路には気になる発熱が無いので無関係だと思う。
　しばらく点灯して十分に熱を持たせて再計測します。

追記・・・30分後
　ヒートシンクが十分に温まったところで計測。
　照度258Lx。
　わずかに下がったけれど計測の誤差レベルでしょう。十分に期待値が出ているので細かい調整は考えないことにします。
　アルミアングルは温まっても素手で握っていられる程度なので、筐体放熱だけで足りそうな気がします。触った感じ、昨日よりも低い気がしなくもないけど・・・
　これなら実試作を始めてもいいので、基板を設計して中国に発注しますかね。
　LED基板も制御基板もアルミの片面基板にしましょう。短絡を避けるために基板の周囲にパターンの余白を大きめにとる必要がありますが、基板を筐体やヒートシンクに直付け出来るなど、クーリングの処理にメリットがあります。それに、国内でアルミ基板を作ると樹脂基板の数倍の価格になるのに対し中国ではほんの数割しか違いません。クーリングの機構が簡単になるならアルミ基板を用いた方が全体としては安く仕上がります。

#電子工作 #LED -- Posted by 電装工芸 〔1138文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=343 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=343 tegalog Wed, 27 Jul 2022 22:07:17 +0900 　これは表面実装部品を多用しているのでリフローの条件が整わないとどうにもならなかったのです。
　リフローでこれに付ける部品はチップ抵抗とチップコンデンサですから温度条件は比較的緩い。185度のソルダーペーストでも部品は持つと思いますので、138度のを使えば比較的簡単に出来そうです。

　このSPI-DMXはRaspberryPiからレガシーDMXを出力するためのインターフェースです。PICのファームウェアを書かなければなりませんし、トリッキーな処理の検証もあるので完成まで時間がかかりますが、最終的にはArt-Netデコーダになるので速やかに進めたいですね。LCDディスプレイモジュールをI2C化するのもこれに使いたいからだったりしますが・・・。

#電子工作 -- Posted by 電装工芸 〔380文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=342 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=342 tegalog Tue, 26 Jul 2022 23:42:25 +0900 　熱電対温度計で計測しながらの作業です。

　まず100度設定でオーブン自体の予熱。外装が暖かくなるまで行い、庫内温度が85度くらいになるようにする。
　物を入れてダイヤルを140度にし、庫内温度が100度になるまで待つ。
　庫内温度が100度になったらダイヤルを100度にし90秒計測開始。この間、庫内温度が100～110度を維持する様に操作する。
　90秒経ったらダイヤルを180度にし、ソルダーペーストを観察。
　庫内温度が150度近くになるとソルダーペーストが熔け始めるのがわかる。
　庫内温度が160度になったらダイヤルを100度まで下げ20秒計測開始。この時間ならヒーターの残熱で庫内温度が上がるくらいですが、160～170度を維持するように操作。180度は越えない方がいい。
　20秒経ったら(30秒を越えない様に注意)オーブンの電源を落としフタを開いて冷却。
　素手で触れるくらいに冷めたら完成。

　ハンダの溶ける様が分かりやすいので思ったより簡単で、前回の様にLEDの樹脂が変形することなく綺麗にハンダが付きました。
　185度のソルダーペーストと違い部品の耐熱温度に対して十分に余裕のある温度ですから、高すぎず長すぎずに注意しながらも十分に余熱をし、160～170度20秒間をキッチリやればよいようです。予熱後から最高温度までの過程はオーブンの成り行きに任せてＯＫ。部品を100度以上の環境にさらす時間は3分以内ってイメージも大事かもしれません。

#ガチ工作 #電子工作 -- Posted by 電装工芸 〔688文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=341 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=341 tegalog Tue, 26 Jul 2022 23:20:38 +0900 　BFで送受信の終了を監視し、SSPIF(ACKの終了)を監視してCKPをセットすれば良いっちゃ良いのだけど、不可能ではないけど面倒くさい処理の典型と化します。
　クロックストレッチングを使わなくても(ACKの直後に次の送受信が始まっても)動く様にしておけばよいのはわかっていますが、PICのI2Cはクロックストレッチングが前提の構成(特にスレーブ送信)だし、RaspberryPiに限った問題なのでi2c-gpioを使ってクロックストレッチングを用いた方が素直な気がします。i2c-gpioが凄い足かせになるワケでもないようですし。

追記
　どうにもモヤモヤするのでクロックストレッチングを使わない方法を考え続けてみました。帰りの車中は考え事に最適です。
　条件を整理します。RaspberryPiのI2CがクロックストレッチングをしてくれないのですからPIC側の条件です。
　タイミングチャートを読みますと、ACKのクロック(ワードの９クロック目)の立下りで割り込みフラグSSPIFがアクティブになった後、次のワードの最初のクロックの立ち上がりまでに送受信のコンディションを整えられれば何事もなく次のワードが扱えるようです。これはSSPIFで割り込みが発生してから半クロック分の時間が使えるとも言えます。I2Cのビットレートは一意ではありませんが、標準的なビットレートである100kbpsに限って考えるなら半クロックは5usec。32MHz動作のPICなら40命令ステップに相当する時間です。
　PICは割り込みの入りと出にパイプラインロスが発生するのでそれぞれ１命令ステップが消費され、I2CのクロックとPICの動作クロックは同期していないし信号の立ち上がり立下り時間もあるので２命令ステップくらいの誤差は起こりえます。となると実処理のために使える命令ステップ数は最大で36程度です。
　ザックリと考えるならSSPIFで割り込みに入ってから30命令ステップ以内に送受信コンディションを整えて割り込みから抜ければよいのでは？となる。
　30命令ステップあれば書き込み(RaspberryPi→PIC)は間に合いそうです。
　I2Cは１フェーズ内では読み出しか書き込みかどちらかしか出来ませんので、Pythonの読み出しコマンド(PIC→RaspberryPi)はI2Cにおいて２フェーズ(１つ目のフェーズでコマンドや読み出すアドレスを書き込み、２つ目のフェーズでデータを読み出す)で実行されます。すなわち、PICが受け取ったワードをキーに処理して次のワードで即応する必要はありません。受け取るだけ受け取ってから処理をし、次の返信フェーズに備えればいいのです。もし鬼連続でコールされても２つ目の読み出しフェーズでデバイスアドレスを送受信する時間は返信データを作るのに使えます。１ワードは9bit分ですから100kbpsなら720usecです。足りる足りないではなくこの時間で済むように作ればいいのです。つか、PICにとっては5,760命令ステップに相当する時間です。私はPIC16をアセンブラで書きますが、5000ステップ以上の処理など書きたくもない・・・。
　割り込みベクタが一つしかないPIC16系で多重割り込みをするとI2Cのタイミングを外す可能性があります。他の処理はポーリングとなりますが、DMX512の送受信や位相制御のトリガー処理もポーリングで十分間に合っているので問題ないっしょ。むしろPIC１個にそんな沢山の仕事させるなってね(笑

　あれ？クロックストレッチングを使わないで組めそうな気がしてきた。

　なんのことやらオレメモ暴走独り言ですみません。

#RaspberryPi #電子工作 -- Posted by 電装工芸 〔1606文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=340 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=340 tegalog Tue, 26 Jul 2022 18:12:04 +0900 　2022年7月現在、Broadcom社製のBCMシリーズを使ったRaspberryPiは総じてダメなようで、ソフトウェアデバイスであるi2c-gpioを使うのが有効な対策だと思います。
　もちろん、ハードウェアデバイスに比べたらCPUに負担がかかるので、CPU負荷が多いシステムやI2Cメモリなどの扱うデータ量が多いデバイスでの使用は避けるべきかもしれません。
　あくまで、扱いデータ量が比較的少なく多少の遅延が発生しても支障がない機内通信で使うのがよいと思われます（I2Cはそもそもそういうモノらしいですけど）。

　今回はPICをインターフェースとして用い、パラレルバスのLCDキャラクタディスプレイ(SC1602やSC2004を用いた製品)をI2Cで接続しANSIエスケープシーケンスっぽいASCII文字列で制御できるシステムを目指します。
　もちろん、UART(シリアル)でも動く様に考えます。8PのDIPスイッチを取り付け、1PでI2C/UARTを選択し、残りの7PでI2CのアドレスやUARTのビットレートを設定できる様にすれば汎用性が高まるでしょう。

#RaspberryPi #電子工作 -- Posted by 電装工芸 〔560文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=339 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=339 tegalog Tue, 26 Jul 2022 10:58:55 +0900 　確かに、クロックストレッチングを多用すると噂のジャイロセンサBMX055を扱った時に数値が変だったりしたかも。
　i2c-gpioと呼ばれるソフトウェアI2Cを使えばクロックストレッチングが機能するとのことですが、こんな大事な機能にバグがあるとは困ります。
　クロックストレッチングを使わなくても機能する様にPIC側を作ればいいか。100kbpsならACKの間に10usecありますから、割り込みを使い5usec程度で処理すれば大丈夫と言えば大丈夫です。複雑な返信はしませんしね。

#電子工作 #RaspberryPi -- Posted by 電装工芸 〔326文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=338 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=338 tegalog Mon, 25 Jul 2022 18:35:47 +0900 　「Ｉ２Ｃのスレーブモードの使い方」
　サンプルソースはPIC18系っぽいですが、違いを読み変えればPIC16系のサンプルにもなります。

　SPIもそうですが、シフトレジスタ系の通信方法で重要なことは受信値を処理して次の受信コンディションが整うまで送信を一次停止させることです。
　I2Cではこの処理をハードウェア的に行うことが可能です。SSPCON2:SENをセット(フラグを1に)しておくと１バイトの受信が終わったところでクロックストレッチングと呼ばれる一時停止がハードウェア的に自動発生するモードになります。クロックストレッチングを解除し受信コンディションにするにはSSPCON1:CKPをセットするだけです。

　スレーブ受信処理の流れは、
１）SSPCON2:SENとSSPCON1:CKPをセットして受信コンディションにする（SSPCON2:SENのセットは初期化処理の時だけでいい）
２）バイトデータが受信されたらSSPBUFからデータを取り出す(この時点でSSPCON1:CKPはハードウェアでクリアされクロックストレッチングが発生している)
３）データを取り出したら(取り出したデータの処理が済んだら)SSPCON1:CKPをセットし次の受信コンディションにする
４）以下、ストップビットが検出されるまで(2)から繰り返し
　となります。

　スレーブ送信(返信)の場合も同様で、所定のレジスタにデータを入れた後、SSPCON1:CKPをセットするとマスターがクロックを刻み始めて送信となります。
　所定のレジスタにデータを入れると自動的にSSPCON1:CKPがセットされて送信が始まるモードもあるようです。

　ただ、SSPCON3:AHENとSSPCON3:DHENの意味がわかったようなわからないような状況です。両方ともクリア(=0)で良いような気もしますが、便利機能かもしれないのでデータシートを良く読んで整理しましょう。

　I2Cは敷居が高いイメージがありましたが、ハードウェアによる自動処理が多くソフトウェアで細かいタイミングを考える必要が無いため、この調子で整理していけば案外簡単に使えるかもしれません。
　PICでI2Cを扱うことが可能になれば、今回のパラレルバスLCDなどのI2Cに対応していないデバイスをI2C化することが容易になります。
　通信速度や即応性、RTOS的なリアルタイム性を求めるのは難しいと思われますが、7bitアドレスのノーマルモードでもI2Cバス上に126個のデバイスを置けますので、RaspberryPi、Arduino、ESP32などの製作の幅が広がるような気がします。

#電子工作 -- Posted by 電装工芸 〔1224文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=337 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=337 tegalog Sun, 24 Jul 2022 21:28:17 +0900 　数個のLEDで済む事もありますが、ガッツリモニタを組まないといけない事もあります。この中間が望ましいこともあります。
　案外必要にして十分なのが16字×2行や20字×4行くらいのLCDディスプレイモジュールです。ただ、制御は難しくありませんが、パラレル信号なので面倒が少なくありません。ならばエスケープシーケンスをシリアルやI2cで受けて動く様にしたらどうかと。PICでインターフェースを作るワケです。
　幸い16F1939が沢山あるのでコレを使えばI/Oピンに余裕を持って作れます。
　色んなアイデアを出しても製作が進まないのは補助的な周辺機器を作らんからかもしれません。

#ガチ工作 #電子工作 -- Posted by 電装工芸 〔337文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=336 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=336 tegalog Sun, 24 Jul 2022 16:41:06 +0900 「ESP32」について調べてみました。
　IoT向けの汎用マイコンです。安価な割に処理能力が高く、wi-fiでIPネットワークが組めて、私にとってはRaspberryPiとPICマイコンの間を埋められる製品だと思われます。
　Arduinoの使用も考えたことはあるのですが、私にとってはPICマイコンをアセンブラで書いた方が手っ取り早く、ケースバイケースのハードウェア製作ではArduinoだとパッケージの調整が面倒です。画期的で素晴らしい製品だと思いますが、私にとっては立ち位置が中途半端です。
　RaspberryPiも含め、この手のマイコン製品は開発環境が重要です。安価で高性能でも開発環境がボトルネックになってアマチュア界隈では普及しなかったマイコン製品は少なくありません。AVR対PICにおいても高性能なAVRよりも少し劣るPICなのは開発環境の影響です。AVRはArduinoの本体なので別な意味で普及はしていますけどね。ESP32はArduinoの開発環境が使えます。Arduinoではありませんが、ArduinoIDEに開発ライブラリを追加すればほぼ同じに使えるようです。間借りと言えば間借りで、関数ライブラリに違いはありますが、ほぼ同じ使用感。Arduionoを使える人ならわずかな違いを勉強すれば使えてします。これは画期的かもしれません。
　Arduino言語はANSI-Cがベースでフル実装でないもののC++っぽいオブジェクト指向な書き方も出来る言語です。基本書式と変数の考え方がANSI-Cと同じマクロ言語と思えばストレス無く使えそうです。

#電子工作 -- Posted by 電装工芸 〔700文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=335 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=335 tegalog Fri, 22 Jul 2022 12:24:31 +0900 　フリーな3D-CADには「FreeCAD」があります。私が3D-CADを使い始めた当時ではFusion360が実質無料で圧倒的に高性能だったので他に選択肢はありませんでしたが、Fusion360が実質有料化しFreeCADが高機能化したならば改めて比較評価してみる意味はありそうです。

#CAD -- Posted by 電装工芸 〔284文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=334 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=334 tegalog Wed, 20 Jul 2022 11:24:00 +0900 　今日の課題は小ホール(大練習室)です。約7.5間四方で天井も高いのでリハーサル室としてはかなり贅沢な寸法です。
　建築図面を整理することにも随分慣れましたし、線が少ないので、取り急ぎ必要な図面は１日で終わりました。
　ちなみにまだ建築中ですが、議員さんの後援者様は内部の見学が出来て、資料を作っている私は立ち入ることが出来ないのはアルアルですね。

#本業 -- Posted by 電装工芸 〔209文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=333 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=333 tegalog Tue, 19 Jul 2022 17:47:33 +0900
#電子工作 -- Posted by 電装工芸 〔71文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=332 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=332 tegalog Tue, 19 Jul 2022 09:36:02 +0900 　自宅は不在が多いので勤務先に送る様にしていますが、週末では現場かオフです。明日は現場がないのでオフです。
　仕方ないので勤務先で工作作業をしましょう。
　受け取ったら帰宅してリフローの条件出しです。

#電子工作 -- Posted by 電装工芸 〔154文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=331 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=331 tegalog Sat, 16 Jul 2022 19:25:30 +0900 　製作は急ぎじゃありませんが、早々にテストして次の課題に移りたい気持ちなのでちょっと不満。
　不思議なのは小売りで扱われる製品が少ない事です。趣味として日常的にハンダ付けをする人が少ない上にリフローハンダを使う人は更に少ないのですから仕方ないのでしょうけど、国内メーカーのハンダ付け関連品はとても優秀で品数も多いのにソルダーペーストの類を避けている感じがします。工場向けの製品は多いので尚更不思議です。
　とは言っても無いものは仕方ありません。

#電子工作 -- Posted by 電装工芸 〔259文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=330 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=330 tegalog Fri, 15 Jul 2022 15:18:02 +0900 　低融点ソルダーペーストを使えばピーク温度を160〜180度に抑えられますから大丈夫っしょ。

　※ 参考ページ
　おうちリフローやってみた

#電子工作 -- Posted by 電装工芸 〔148文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=329 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=329 tegalog Tue, 12 Jul 2022 12:29:16 +0900
　低融点ソルダーペーストを手配しました。入荷には１週間弱かかるとのことですが、手配ルートや在庫状況が微妙なので手に入るかは届いてみないとわかりません。
　TS391LT50
　50gでこのお値段はお高い感じもしますが、かなりの量を作らないと劣化するまでに使い切るのは難しい量ですし、低融点という特殊な性能を考えれば、１作あたりのコストは納得できる範囲だと思います。
　(たぶん、1g以上使うのはかなり大きな基板になると思います)
　この手の製品の消費期限は半年から１年間です。冷蔵庫等に入れて低温での保管が推奨されますが、使用の際には常温まで戻さなければなりません。この製品は常温保管も可とされているようですが、扱いや管理には注意が必要です。

#電子工作 -- Posted by 電装工芸 〔329文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=328 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=328 tegalog Tue, 12 Jul 2022 11:51:32 +0900
　以前購入した加熱台ではリフローハンダがうまくいきません。
　専用の機械を買おうかと思いましたが、ネットの書き込みを読むと「TESCOM TSF601」がイイ感じとのこと。庫内に熱風を回すタイプのコンベクションオーブンです。これで成功されている例が多いようです。
　温度の管理は、盤面の温度設定だけでは不十分で、熱電対などでの実測が必要みたいです。手持ちで試して具合がいいなら専用の温度計を買いましょう。
　懸念するのはハンダペーストです。溶解温度138度の低温タイプを使ったレポートが多いので購入を考えましたが今は品薄で手に入りません。185度の物は手元にあるので当面はこれで試してみましょう。

追記

　帰宅して試しました。
　ストップウォッチを片手にやってみましたが簡単でした。本体のリレーのカチカチ音とヒーターの発光を参考に計測します。
　テストピースは3wのLED素子を秋月さんの六角アルミ基板に取り付ける作業です。
　ソルダーペーストはXG-50。溶解温度185度の物です。
　基板にソルダーペーストを塗ってLEDを置きます。
　基板を庫内に入れ160度設定で起動します。時間管理はストップウォッチなので、TSF601のタイマは作業中に落ちない15～20分くらいの設定にします。
　リレーが切れる音が鳴ってヒーターが切れたところからストップウォッチで計測します。予熱です。
　90秒予熱したら温度設定ダイヤルを230度まで回します。ストップウォッチもリセットします。
　温度が上がってソルダーペーストが溶け始めたところから20秒後に電源を切って網ごと取り出し冷却。
　部品の耐熱限界を考えると230度に切り替えてから90秒たってもソルダーペーストが溶けない場合は失敗と思ってよさそう。この場合はハンダゴテで誤魔化すしかありません。
　上記のレシピでLEDは正常に点灯しました。これでいいのかまだわかりませんが、LED素子が大丈夫なら他の部品でも良いと思われます。

さらに追記

　上記のレシピではLEDの透明カバーが変形しました。低融点のソルダーペーストを使ってリフローの温度を下げる必要があると思われます。
　リフローでハンダ付けしたLEDを５灯直列ツナギにし、DC24v電源のCL6807ドライブで問題無く点灯しました。電流値も設計通りです。
　長時間点灯を試すにはヒートシンクを取り付けないといけません。
　今日のところはヨシとします。

#電子工作 -- Posted by 電装工芸 〔1038文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=327 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=327 tegalog Mon, 11 Jul 2022 17:53:39 +0900 　発光面のホクロは気になりません。売り物にするにはどうかと思いますが、手に取って使う物ではありせんので。
　電池は１次電池のアルカリを使ってみました。エネループが推奨ですが、アルカリも使えないと現場的には問題があるのでリハ時にテストです。忙しくて細かくチェックしていませんが、12時間以上使えたみたいです。
　今後カラーバリエーションを作る予定です。

#ガチ工作 #舞台の小物 -- Posted by 電装工芸 〔228文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=326 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=326 tegalog Sat, 09 Jul 2022 10:41:14 +0900 　オレメモです。

1) ライブラリをインポートします。
>>> import numpy as np
>>> import pickle

2) テスト用のnumpy.arrayを作ります。とりあえずはすべてゼロのuint8です。
>>> z = np.zeros(( 192, 8, 512 ), dtype=np.uint8 )
※ dtypeで変数の型を指定します。指定しないとOSのbit長のintになります。
※ 値の計算をするならuint16以上の型にしなければなりませんが、今のところArt-Netエンジン内では置き換えと比較しかしませんのでuint8で運用できそうです。

3) テスト用のtupleを作ります。
>>> y = ( 'tests', z )
※ 'tests'という文字列と(2)で作ったnumpy.arrayのtupleです。

4) シリアル化します。
>>> x = pickle.dumps( y )

　これでtuple:yが一列のバイナリとなり、scoketで通信できる状態になります。

5) 復号します。
>>> w = pickle.loads( x )
※ wはyと同じtupleです。正しく復号されました。

　numpy自体にもシリアル化/復号の方法があるようですが、型の違うデータを一括でやり取りしたいのでtupleをpickleで扱います。
　この処理の速度が十分かどうかはこれからの確認です。

#Python -- Posted by 電装工芸 〔658文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=325 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=325 tegalog Fri, 08 Jul 2022 09:49:21 +0900 　pickleというライブラリを使います。pickle.dumps()でシリアル化し、pickle.loads()で戻します。
　テキストと３次元のnumpy.arrayが混在するtupleが一発で処理出来ました。
　変換したデータのtypeはbytesですからsocketで送れるハズです。

　ただ、pickleのシリアル化/復号には時間がかかる様子。
　先人の調査によると、scoket自体はとても速いけれどpickleの処理が案外遅くて総処理時間は他の方法と似たり寄ったりみたい。
　ただ、先人の比較方法はデータ量を起点にする比較が主で、都度のデータは少なくコネクションの回数が多いケースの比較ではありません。multiprocessingのQueueはコネクション毎のマネージ処理が重い感じがするので、コネクション自体は軽いsocketに分があるかもしれません。
　また、DMXのスロットデータを格納するnumpy.arrayは何も指定しないとint32やint64になりますが、uint8やuint16を指定すれば１スロット当たりのデータ長は小さくなります。つまり、データ総量が小さくなります。
　試さないとわからんですけど、オーバーヘッドが大きい通信処理でデータ量を減らせば十分な速度を確保できる期待感があります。DMXの1スロットは1バイトですから、Art-Netエンジンではスロットに対する計算処理をせずにuint8で運用するのがいいのかもしれません。今のところ、比較抽出のnumpy.maxはあってもスロットデータに計算らしい計算は当てないのでuint8で運用しても問題無さそう。
　つか、通信自体はsocketが凄く軽いことに驚いた。PythonというよりOS本体に依存するので当然かもしれませんが。

#Python -- Posted by 電装工芸 〔850文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=324 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=324 tegalog Thu, 07 Jul 2022 21:08:52 +0900
　PythonではmultiprocessingのQueueが予想以上に遅くて使い物になりません。便利なんですけどね。
　ネットの情報ではPipeや共有メモリが速いとあります。ですが、socketもQueueより速そうなレポートが多く見受けられます。
　実験してみないとわかりませんが、速度が足りるならsocketにした方が将来性があります。なぜなら、内部でのプロセス間通信も別プロセッサとの協調動作も設定するIPアドレスとポートが違うだけで全く同じプログラムで実現可能だからです。Pipeや共有メモリよりもsocketはシンプルで扱いやすいので速度が十分なら尚更です。
　Art-NetとEtherNetを共用するのは避けた方が良さそうですが、ローレベルのハードウェアを扱いやすいRaspberryPiと計算能力が高いPCを組合せば得意分野を活かして良い結果を出せるような気がします。もし調光卓を考えるならこの方法は必須かもしれません。もちろん、Art-NetエンジンそのものをPCに実装するのもアリでですけど。

　これまではQueueベースで書いてきましたが、タプルをバイナリ化してsocketで通信する方法から試してみましょう。

#Python #[Art-Net] -- Posted by 電装工芸 〔586文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=323 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=323 tegalog Thu, 07 Jul 2022 19:06:20 +0900 　終わっていませんが、自分の領分に区切りが付いて投げたところなのでしばらくは少しサボれます。
　なので、Art-Netエンジンを再開しています。
　基本的な機能の製作は済んでいるので最適化をします。常にそれなりの負荷で動くモジュールなので可能な限り動作負荷を軽減し例外エラーも出にくくしたいからです。
　特に処理の順位とタイミングの精査が重要です。無駄な繰り返し処理を極力減らし、やるべきことは適切に実行させるのです。パッと見はスマートでも順位が最適じゃないとか、状況確認のIF文が無駄に実行されていたりするのはよくあることです。自然な流れで実際の処理量をどれだけ減らせるかが勝負です。
　改めてフローを書いています。実験段階ではフローを書かず処理が成立するかコマンドを試しながら思いつきで書くことが多いのですが、最適化をするには分割した部分を並べ直して見直すのがいいようです。いわゆるフローチャートを書くのではなく、付箋に要素を書いてホワイトボードに並べるブレインストーミングみたいな作業です。一人作業なのでパソコンの中でやってますけど、LibreOfficeのドローがこの作業では使いやすいですね。

　時間も開発費も乏しいところですが、出来るだけ多くの製品を作りたいものです。

#[Art-Net] -- Posted by 電装工芸 〔576文字〕 ]]> https://www.densokogei.jp/tegalog/tegalog.cgi?postid=322 https://www.densokogei.jp/tegalog/tegalog.cgi?postid=322 tegalog Thu, 07 Jul 2022 15:57:43 +0900