電装工芸日記
- 舞台照明機器の製作とか -
2022年7月 この範囲を時系列順で読む この範囲をファイルに出力する
低融点ソルダーペーストは入荷までしばらくかかりそう・・・なんて書いたのに出荷されたとか。
自宅は不在が多いので勤務先に送る様にしていますが、週末では現場かオフです。明日は現場がないのでオフです。
仕方ないので勤務先で工作作業をしましょう。
受け取ったら帰宅してリフローの条件出しです。
#電子工作
自宅は不在が多いので勤務先に送る様にしていますが、週末では現場かオフです。明日は現場がないのでオフです。
仕方ないので勤務先で工作作業をしましょう。
受け取ったら帰宅してリフローの条件出しです。
#電子工作
低融点ソルダーペーストの入荷は２－３週間先のようです。
製作は急ぎじゃありませんが、早々にテストして次の課題に移りたい気持ちなのでちょっと不満。
不思議なのは小売りで扱われる製品が少ない事です。趣味として日常的にハンダ付けをする人が少ない上にリフローハンダを使う人は更に少ないのですから仕方ないのでしょうけど、国内メーカーのハンダ付け関連品はとても優秀で品数も多いのにソルダーペーストの類を避けている感じがします。工場向けの製品は多いので尚更不思議です。
とは言っても無いものは仕方ありません。
#電子工作
製作は急ぎじゃありませんが、早々にテストして次の課題に移りたい気持ちなのでちょっと不満。
不思議なのは小売りで扱われる製品が少ない事です。趣味として日常的にハンダ付けをする人が少ない上にリフローハンダを使う人は更に少ないのですから仕方ないのでしょうけど、国内メーカーのハンダ付け関連品はとても優秀で品数も多いのにソルダーペーストの類を避けている感じがします。工場向けの製品は多いので尚更不思議です。
とは言っても無いものは仕方ありません。
#電子工作
LEDのデータシートを見直したところ、リフローのピーク温度は220度だそうな。最初からよく見ろって話ですが、完全にオーバーしてました。
低融点ソルダーペーストを使えばピーク温度を160〜180度に抑えられますから大丈夫っしょ。
※ 参考ページ
おうちリフローやってみた
#電子工作
低融点ソルダーペーストを使えばピーク温度を160〜180度に抑えられますから大丈夫っしょ。
※ 参考ページ
おうちリフローやってみた
#電子工作
低融点ソルダーペーストを手配しました。入荷には１週間弱かかるとのことですが、手配ルートや在庫状況が微妙なので手に入るかは届いてみないとわかりません。
TS391LT50
50gでこのお値段はお高い感じもしますが、かなりの量を作らないと劣化するまでに使い切るのは難しい量ですし、低融点という特殊な性能を考えれば、１作あたりのコストは納得できる範囲だと思います。
(たぶん、1g以上使うのはかなり大きな基板になると思います)
この手の製品の消費期限は半年から１年間です。冷蔵庫等に入れて低温での保管が推奨されますが、使用の際には常温まで戻さなければなりません。この製品は常温保管も可とされているようですが、扱いや管理には注意が必要です。
#電子工作
以前購入した加熱台ではリフローハンダがうまくいきません。
専用の機械を買おうかと思いましたが、ネットの書き込みを読むと「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ドライブで問題無く点灯しました。電流値も設計通りです。
長時間点灯を試すにはヒートシンクを取り付けないといけません。
今日のところはヨシとします。
#電子工作
シリアル化の手順は次の通りです。
オレメモです。
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
オレメモです。
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
numpy.arrayを含むtupleをsocketで送るにはシリアル化ってのをすればいいらしい。pythonのオブジェクトをバイナリ化する方法とのこと。
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
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
Art-Netエンジンの構成を整理していますが、そういやプロセス間通信はどうしましょう。
PythonではmultiprocessingのQueueが予想以上に遅くて使い物になりません。便利なんですけどね。
ネットの情報ではPipeや共有メモリが速いとあります。ですが、socketもQueueより速そうなレポートが多く見受けられます。
実験してみないとわかりませんが、速度が足りるならsocketにした方が将来性があります。なぜなら、内部でのプロセス間通信も別プロセッサとの協調動作も設定するIPアドレスとポートが違うだけで全く同じプログラムで実現可能だからです。Pipeや共有メモリよりもsocketはシンプルで扱いやすいので速度が十分なら尚更です。
Art-NetとEtherNetを共用するのは避けた方が良さそうですが、ローレベルのハードウェアを扱いやすいRaspberryPiと計算能力が高いPCを組合せば得意分野を活かして良い結果を出せるような気がします。もし調光卓を考えるならこの方法は必須かもしれません。もちろん、Art-NetエンジンそのものをPCに実装するのもアリでですけど。
これまではQueueベースで書いてきましたが、タプルをバイナリ化してsocketで通信する方法から試してみましょう。
#Python #[Art-Net]
PythonではmultiprocessingのQueueが予想以上に遅くて使い物になりません。便利なんですけどね。
ネットの情報ではPipeや共有メモリが速いとあります。ですが、socketもQueueより速そうなレポートが多く見受けられます。
実験してみないとわかりませんが、速度が足りるならsocketにした方が将来性があります。なぜなら、内部でのプロセス間通信も別プロセッサとの協調動作も設定するIPアドレスとポートが違うだけで全く同じプログラムで実現可能だからです。Pipeや共有メモリよりもsocketはシンプルで扱いやすいので速度が十分なら尚更です。
Art-NetとEtherNetを共用するのは避けた方が良さそうですが、ローレベルのハードウェアを扱いやすいRaspberryPiと計算能力が高いPCを組合せば得意分野を活かして良い結果を出せるような気がします。もし調光卓を考えるならこの方法は必須かもしれません。もちろん、Art-NetエンジンそのものをPCに実装するのもアリでですけど。
これまではQueueベースで書いてきましたが、タプルをバイナリ化してsocketで通信する方法から試してみましょう。
#Python #[Art-Net]
現場もホール資料の作成も一息つきました。
終わっていませんが、自分の領分に区切りが付いて投げたところなのでしばらくは少しサボれます。
なので、Art-Netエンジンを再開しています。
基本的な機能の製作は済んでいるので最適化をします。常にそれなりの負荷で動くモジュールなので可能な限り動作負荷を軽減し例外エラーも出にくくしたいからです。
特に処理の順位とタイミングの精査が重要です。無駄な繰り返し処理を極力減らし、やるべきことは適切に実行させるのです。パッと見はスマートでも順位が最適じゃないとか、状況確認のIF文が無駄に実行されていたりするのはよくあることです。自然な流れで実際の処理量をどれだけ減らせるかが勝負です。
改めてフローを書いています。実験段階ではフローを書かず処理が成立するかコマンドを試しながら思いつきで書くことが多いのですが、最適化をするには分割した部分を並べ直して見直すのがいいようです。いわゆるフローチャートを書くのではなく、付箋に要素を書いてホワイトボードに並べるブレインストーミングみたいな作業です。一人作業なのでパソコンの中でやってますけど、LibreOfficeのドローがこの作業では使いやすいですね。
時間も開発費も乏しいところですが、出来るだけ多くの製品を作りたいものです。
#[Art-Net]
終わっていませんが、自分の領分に区切りが付いて投げたところなのでしばらくは少しサボれます。
なので、Art-Netエンジンを再開しています。
基本的な機能の製作は済んでいるので最適化をします。常にそれなりの負荷で動くモジュールなので可能な限り動作負荷を軽減し例外エラーも出にくくしたいからです。
特に処理の順位とタイミングの精査が重要です。無駄な繰り返し処理を極力減らし、やるべきことは適切に実行させるのです。パッと見はスマートでも順位が最適じゃないとか、状況確認のIF文が無駄に実行されていたりするのはよくあることです。自然な流れで実際の処理量をどれだけ減らせるかが勝負です。
改めてフローを書いています。実験段階ではフローを書かず処理が成立するかコマンドを試しながら思いつきで書くことが多いのですが、最適化をするには分割した部分を並べ直して見直すのがいいようです。いわゆるフローチャートを書くのではなく、付箋に要素を書いてホワイトボードに並べるブレインストーミングみたいな作業です。一人作業なのでパソコンの中でやってますけど、LibreOfficeのドローがこの作業では使いやすいですね。
時間も開発費も乏しいところですが、出来るだけ多くの製品を作りたいものです。
#[Art-Net]
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132