電装工芸日記
- 舞台照明機器の製作とか -
全年全月16日の投稿［47件］（5ページ目）
2022年3月 この範囲を時系列順で読む この範囲をファイルに出力する
基板の製造は「PCBgogo」さんにお願いしました。
他社と比較出来る程の知識も経験もありませんが、日本語対応が進んでいるのでやりとりが楽です。
まだ完全ではないと言っていますが、入稿したデータの完成予想画像をアカウント画面から見ることが出来ます。こちらの思惑通りにガーバーデータを受け取ってくれているか確認出来るのは凄い安心感です。
ちなみに他社さんですが、オーダー画面も設定パラメータもPCBgogoさんと大差ありません。言語が英語か日本語かの違いくらい。価格もほぼ同じ。
ここまでネットのシステムが似ていると製造システムも似ているのでは？と思います。仕上がりも大差ないのかもしれません。
ひょっとして、実際に作っているのは一社だったりして・・・
本業の忙しさが落ち着く頃に加熱台と共に入荷する見込みです。届いたら早速試験しましょう。
まずはリフローハンダからです。今回頼んだ基板５枚はリフローハンダの練習台でゴミになるかもしれませんが、大判のリフローの練習になれば御の字です。
リフローハンダに成功して動作チェックするところまで行ければ、確認と手直しをして本オーダーです。
さて、本業再開と・・・
#電子工作
本業がイキナリ忙しくなっています。
クライアント側から間近にならないと資料が来ないためですが、コロナが明けつつある現時点では全てのスタートが遅くなっているので仕方ありません。
数か月先の日程の問い合わせも多くなっています。ありがたいことですが、目先の現場に集中したい時に何故か多い不思議。
久しぶりに照明仕込み図を描きました。現場が少なかったですし、照明よりも舞監モドキをすることが多いので、これも仕方ありません。
裏方のために世の中が回っているワケじゃありませんから仕方ないは仕方ない。
照明の仕込み図が終わったら舞監仕事で別な現場の進行表をカキカキです。
終わる気がしねー。
#本業
KiCadはver6になっています。
以前インストールしたver5を使っていましたが、ver6はかなり使いやすい。
ただ、ネットの参考情報の大半がver5ベースなので、ver5で勉強してからver6にした方がいいかもしれません。ver6ベースの参考情報はまだ少ないようです。
ver5で書いたものをver6に持っていく場合はライブラリ周りで少し引っかかります。一見すんなり行けるのですが、ver5のライブラリはver6で編集出来ないよと言われてしまいます。実際は、ライブラリファイルを更新するのではなく、編集したオブジェクトのみを更新するとすれば問題なく完了します。
どちらかと言えば、ver5で作ったものをver6に持っていかないのがいいのかもしれません。
KiCadは私にとってCADLUS-Xの方言違い程度で使えたので案外楽でした。
基板屋さんもデータを正確に拾ってくれているので、今後基板を作る際にはKiCadです。
基板CADはレイヤーに当初から決められた製造上の役割りがあり、製作上の制約(パターン線間の隙間とか)を描く前に設定する必要があることだけ理解すればVecoterWorksやイラレと同じ感覚で使えます。
KiCadは、配線間違いを防止する観点からか、回路図を描いて部品同士の関係性を作ってからしか描けません。基板を描き始めるまでの儀式が多いかもしれません。
#電子工作
2022年2月 この範囲を時系列順で読む この範囲をファイルに出力する
空き時間が少なかったのですが、Art-Netのエンコードを試してみました。
受信したバイナリをデコードし、パラメータをそのままにエンコードして送信です。単純な動作ですが、これが出来なきゃパッチマシンなど絶対無理というテストです。
卓からの８ユニバースをすべて処理したのですが、負荷の増加は2.5%くらいでした。十分に許容範囲で収まったのは良いことです。
パッチマシンは8in8outくらいを想定していますが、16in16outも可能だったりして。16ユニバース出る卓が無いので試せないし作ってもオーバースペックなので私は不要かな。機能全体を組み込んでから悩むことですが・・・。
今のところ１日１課題。
あとどれくらいの課題があるのかわかりませんが、納期はありませんのでノンビリいきましょう。ここまで出来れば、丁寧にclassライブラリにまとめ上げ、コメントに使い方を明記して後々も使える様にしておきましょう。
そういう意味ではキー操作やモニタ表示もclassライブラリにして汎用性を高めるのがいいですね。
と言いますか、このまま書き増しを続けるとソースコードがグチャグチャになって後で後悔しそうです。
私のメインはPICのアセンブラなのでANSI-Cの関数タイプっぽい書き方をしがちですが、Pythonならオブジェクト指向な書き方をしたいものです。最近、クラス、インスタンス、継承を使う意味と感覚がわかってきましたので、出来るだけそういった書き方をしていこうと思います。
以前は「継承」ってのが感覚的にわからんかったのですが、関数を束ねて新しい関数を作るだけだと簡単に考えればいいみたいです。ただ、関数は実体なのであっちこっちの関数から同じ関数を同時に呼ぶと衝突が起こります。解決には親関数の中で使う関数を親関数にとって専用にすればいいのですが、同じ様な関数を使うだけ書くのは面倒だしやらたとソースが大きくなるので、ひな形であるクラスから実体のインスタンスを作るという発想になったのだと最近ようやく「感覚的に」理解出来ました。
その筋の解説書を読むと「継承はオブジェクト指向という高貴な峰の頂」みたいな奇妙に美化した記述が多いのですが、その実態は「楽して俺様関数書きてぇ〜」って俗っぽい発想でした。美化した手段を書くだけで目的を書かない解説書が多いので感覚的にわからんかったのです。
#Python #[Art-Net]
受信したバイナリをデコードし、パラメータをそのままにエンコードして送信です。単純な動作ですが、これが出来なきゃパッチマシンなど絶対無理というテストです。
卓からの８ユニバースをすべて処理したのですが、負荷の増加は2.5%くらいでした。十分に許容範囲で収まったのは良いことです。
パッチマシンは8in8outくらいを想定していますが、16in16outも可能だったりして。16ユニバース出る卓が無いので試せないし作ってもオーバースペックなので私は不要かな。機能全体を組み込んでから悩むことですが・・・。
今のところ１日１課題。
あとどれくらいの課題があるのかわかりませんが、納期はありませんのでノンビリいきましょう。ここまで出来れば、丁寧にclassライブラリにまとめ上げ、コメントに使い方を明記して後々も使える様にしておきましょう。
そういう意味ではキー操作やモニタ表示もclassライブラリにして汎用性を高めるのがいいですね。
と言いますか、このまま書き増しを続けるとソースコードがグチャグチャになって後で後悔しそうです。
私のメインはPICのアセンブラなのでANSI-Cの関数タイプっぽい書き方をしがちですが、Pythonならオブジェクト指向な書き方をしたいものです。最近、クラス、インスタンス、継承を使う意味と感覚がわかってきましたので、出来るだけそういった書き方をしていこうと思います。
以前は「継承」ってのが感覚的にわからんかったのですが、関数を束ねて新しい関数を作るだけだと簡単に考えればいいみたいです。ただ、関数は実体なのであっちこっちの関数から同じ関数を同時に呼ぶと衝突が起こります。解決には親関数の中で使う関数を親関数にとって専用にすればいいのですが、同じ様な関数を使うだけ書くのは面倒だしやらたとソースが大きくなるので、ひな形であるクラスから実体のインスタンスを作るという発想になったのだと最近ようやく「感覚的に」理解出来ました。
その筋の解説書を読むと「継承はオブジェクト指向という高貴な峰の頂」みたいな奇妙に美化した記述が多いのですが、その実態は「楽して俺様関数書きてぇ〜」って俗っぽい発想でした。美化した手段を書くだけで目的を書かない解説書が多いので感覚的にわからんかったのです。
#Python #[Art-Net]
2022年1月 この範囲を時系列順で読む この範囲をファイルに出力する
エポキシ樹脂を塗った合板はとても良い。
薄塗りをペーパーで均しましたから塗膜は薄いのですが、柔らかい木肌が半硬化と思われる段階で無垢なラワン材より硬くなっています。
上塗りは、足付けを兼ねてペーパーで均した上にミッチャクロンマルチを塗ってラッカーを吹きましたが、予想以上にガッツリ着いています。
エポキシ樹脂もラッカーも完全硬化は明日ですが、強度をシッカリ評価しましょう。
#ガチ工作
薄塗りをペーパーで均しましたから塗膜は薄いのですが、柔らかい木肌が半硬化と思われる段階で無垢なラワン材より硬くなっています。
上塗りは、足付けを兼ねてペーパーで均した上にミッチャクロンマルチを塗ってラッカーを吹きましたが、予想以上にガッツリ着いています。
エポキシ樹脂もラッカーも完全硬化は明日ですが、強度をシッカリ評価しましょう。
#ガチ工作
2021年12月 この範囲を時系列順で読む この範囲をファイルに出力する
現地設置は大物が無事終わりました。
残りは細かい電装です。１月中旬までに終わればいいので、ちょっとペースを落として下準備をし、正月明けに仕上げていこうと思います。
本音を言えば、防水を確認するための試行時間だったりします・・・
この様子なら年末年始は休めそうです。
客席テーブルver4.5の仕上げとArt-Netの実験が課題。
こんなことをして果たしてオフなのか？って正論は止めておきます。
Art-Netはwi-fiでの送受信も試そうと妄想しています。Linux系のOSは複数のネットワークデバイスをBridgeさせて有線LANだろうがwi-fiだろうが同じゾーンとして扱えるので、今考えている方法で繋がるならありえないくらい安価にワイヤレスDMXを実現出来ます。
よくわからんので実験したいことが「pythonのsocketはブリッジデバイスをバインド出来るのか？」という点。これが出来ないとワイヤレスDMXとして望む機能にはなりません。ブリッジデバイスは一種の仮想デバイスですが、socketにおいても仮想デバイスを実デバイスと同等に扱えるのか？ということです。Linuxは実デバイスだろうが仮想デバイスだろうがデバイスはデバイスとしてシンプルに扱うので出来そうなものです。Windowsでは実と仮想の間に奇妙な壁があるので私には出来ない芸当ですが・・・
#ガチ工作
残りは細かい電装です。１月中旬までに終わればいいので、ちょっとペースを落として下準備をし、正月明けに仕上げていこうと思います。
本音を言えば、防水を確認するための試行時間だったりします・・・
この様子なら年末年始は休めそうです。
客席テーブルver4.5の仕上げとArt-Netの実験が課題。
こんなことをして果たしてオフなのか？って正論は止めておきます。
Art-Netはwi-fiでの送受信も試そうと妄想しています。Linux系のOSは複数のネットワークデバイスをBridgeさせて有線LANだろうがwi-fiだろうが同じゾーンとして扱えるので、今考えている方法で繋がるならありえないくらい安価にワイヤレスDMXを実現出来ます。
よくわからんので実験したいことが「pythonのsocketはブリッジデバイスをバインド出来るのか？」という点。これが出来ないとワイヤレスDMXとして望む機能にはなりません。ブリッジデバイスは一種の仮想デバイスですが、socketにおいても仮想デバイスを実デバイスと同等に扱えるのか？ということです。Linuxは実デバイスだろうが仮想デバイスだろうがデバイスはデバイスとしてシンプルに扱うので出来そうなものです。Windowsでは実と仮想の間に奇妙な壁があるので私には出来ない芸当ですが・・・
#ガチ工作
技術を持つ人が本気で取り組むネタ工作いいすね。
鉄夫ではありませんが、タモリ電車クラブは大好きです。
実はスクローラーを作ったとき、当初はPWMの周期が低すぎてモーターから音が出てしまいました。
ドレミファインバーターの様に軽やかな音色ではありませんでしたが、正に電車の発車音を思い出し、設定を変えて遊んでいた思い出があります。
#ガチ工作
鉄夫ではありませんが、タモリ電車クラブは大好きです。
実はスクローラーを作ったとき、当初はPWMの周期が低すぎてモーターから音が出てしまいました。
ドレミファインバーターの様に軽やかな音色ではありませんでしたが、正に電車の発車音を思い出し、設定を変えて遊んでいた思い出があります。
#ガチ工作