Darkside（リンクエラー修正しました）

　ダミー負荷と接続するためのコネクターを外す。

　いよいよ、励起ＬＤとの本配線を行う。
　暫くの間、これでダミー負荷は使えなくなる。

　数ヶ月前の構想で、一応組み立て後のイメージは作った。
　しかし遥か記憶の彼方なので、再度計画を練り直す。

　このコネクターの配線２本は、筐体に元から存在する穴を通すには太過ぎる。だが、これより細いコネクターだと細くなり過ぎる。ドンピシャに手頃な製品がない。
　そうすると、穴のプラスチック壁を除去するのが最も早い。ところがこのプラスチック壁が、なかなか除去できない。

　配線が占有する空間は小さいが、このエリアにはポンプコンバイナーも設置せねばならない。

　もう一方のコネクターは、筐体の細長い穴を活用可能。そのため、配線は楽勝で通せる。だが、コネクターを丸ごと穴に格納せざるを得なくなりそうで、空間的な余裕はほとんどない。

　さて、無事に実装できるか？
　システム一式を扱い易いパッケージにまとめることは、地味で技術的レベルも低い作業というイメージがある。だが実際は、非常に面倒で難易度の高い作業である。

　小さなコネクターの抜き差しは、どう頑張っても配線と内部ピンの接合部に機械的なストレスを加えるため、できるだけ避けたい。理論上は、配線の耐久値を削っているはずなのだ。
　迷った末に、今回は主ＰＩＣ基板を外すことにした。

　コネクターが硬いと、抜き差しでも配線ストレスが増大する。柔らかいと、勝手に抜けたり接触不良を起こす可能性が高まる。
　メンテナンス性の向上と引き換えに、コネクター化で失われるものも多い。どこをコネクターにし、どこは直接ハンダ付けしてしまうか。その判断が悩ましい。

　電源線が基板に接続される部分にパスコンがあるが、その隣に１０ＫΩの抵抗１本だけ追加。
　ポートＢの４番と、ＧＮＤを接続する。
　作業は単純だが、基板を外して作業してまた基板を戻すという一連の流れは手間隙かなり掛かる。

　パーツ代５円、工賃５０００円というのは、こういう状況から生まれる。

　これで停止信号の入力ピンがプルダウンされ、信号線が外れたり切断されるとＬになり主電源停止とみなされる。トラブル発生により状態が安全側に固定されるフェイルセーフが実現される。
　コネクター配線の疲労蓄積を、この安全対策と引き換えにした。

　抵抗１本だけで済ませるには全体の作業が多くて腹が立つので、ついでに基板裏側をアラルダイトで固める。要するに、ハードの正常動作がほぼ確認できたってこと。
　レーザー電源は完成度が高まったものの、埃対策は頭が痛い。現在電源は実験テーブルに水平に設置されていて、使用しないときは厚紙を被せて埃避けしている。しかし、実運用時は移動可能なので、空気の流れが生じる。より汚れた外気や砂埃に襲われる可能性もある。

　しかし、電源回路が汚れた場合の対策が難しい。
　最大の発熱源である DC-DCコンバーターはしっかり放熱されるが、細かなパーツの中には微妙なレベルの発熱をするものも多い。すなわち、自然空冷で充分だがアラルダイトなどで密封してもいいかどうか悩ましい。

　密封しまくっても、とにかく配線だらけ。こういう場所は埃が溜まり易い。
　いったん完成品のレーザー銃になってしまうと、電源部分にアクセスするための分解は極めて面倒になる。おいそれと掃除できないのだ。

　最近ようやく真夏の空気が去り、秋っぽくなって来た。
　前回充電しようとした頃に比べると、室温は６〜７度低くなっている。更に、体感湿度もかなり低い。温湿度計だとＨＩ表示が８７％とかに変わっただけだが、どうもこの湿度計は実感よりかなり高めに表示される。

　ラジコン充電器を使って、休憩抜きぶっ通し３本連続充電やったが、液晶表示がバグったりすることもなく正常に完了。
　１日１本しか充電できないのは、やはり夏場だけの限界のようだ。
　８０８ｎｍよりは高温に強い励起ＬＤだが、そっちにも夏場の環境はやさしくない。固体レーザーの運用は、２５度以下だな。

　充電器の積算充電量表示は、４４０６・４４１９・４４１７、だった。公称４５００のリポバッテリーを、相変わらず良い感じに使い切れている。ローバッテリー停止のタイミング、警告のタイミング、いずれも適切な閾値に設定できたようだ。

　停止信号は引き続き認識されているが、試験を続行した意味はあった。問題は、PORTB.4
への入力がオープンになった場合。

　これとっくに確認してあって、オープンでは発振停止しなかった。だが、そのときは数秒様子を見ただけ。
　ここにＧＮＤを接続したり外したりしているうちに、信号自体は認識されていてもオープンでは挙動不安定になることが分かって来た。もちろん通常は副ＰＩＣ出力と接続されており、安定している。

　暫く試しているうちに、電流５Ａで安定するはずが２．３Ａあたりで安定。
　あれっ？と思いつつ１０秒ほど経過すると、回路が燃えるとき独特の異臭が！
　この期に及んでどこが燃えた？！と焦って電源を切る。幸い、一番怪しい部分が犯人だった。主ＰＩＣが激しく過熱していた。

　停止信号線を副ＰＩＣに接続戻し、新しいＰＩＣにプログラムを書き込んで交換。
　回路は再び正常に動作するようになったし、どこも燃えない。
　これでひとまずは一見落着だが、問題は停止信号線が外れるトラブルに対策を施すかどうか。運用を開始したら、幾ら振動や衝撃があってもこのピンヘッドが外れることは考え難い。一方で対策は、10KΩでプルダウンするだけで充分効果的と思われるが、作業はそれなりに面倒。コネクター類は出来るだけ抜き差し回数を増やしたくない。すっかりハード的に落ち着いているのを、外してまた取り付けて・・・とやるのはペイするかどうか。

　久しぶりにハンダゴテを使う。
　ジャンク箱の金属クリップとピンヘッドを接続し、ＧＮＤに落とすための実験配線を作る。

　目的は、副ＰＩＣが主電源停止しようとしたときに主ＰＩＣが適切にレーザーのドライブを停止してくれるかどうかの確認。
　主電源が停止されると DC-DCコンバーターの電源が供給されなくなり、どのみちレーザーはドライブされなくなる。しかしそれを主ＰＩＣが認識できていないと、制御ループはそのまま動き続けてしまう。現在では故障判定が働くが、それは本来監視している現象とは異なる。
　正規ルートで電源が落ちたことを認識する機能が独立して働いてくれないと、多重保護になっていない。

　そのため、副ＰＩＣからの停止信号だけを別に入力してやる。

　写真左端に見えているのが主ＰＩＣで、副ＰＩＣからの停止信号をPORTBの４番で受け取る。灰色の配線だ。２本あるのは、接触不良リスクを減らすため。これは重要な信号である。それを外して、先の実験配線のピンヘッドに差し込む。
　写真右上に金属クリップが見えている。こっちはＧＮＤを食わせる。

　副ＰＩＣは主電源のスイッチ用ＦＥＴのゲートと同時に、主ＰＩＣのPORTB.４に同じ信号を送る。Ｌならば主電源停止中である。すなわち、ＧＮＤに落とせば主ＰＩＣは主電源が停止されたと判断する。実際には主電源はＯＮのままであり、主ＰＩＣが停止信号を認識したかどうかを確認できる。
　認識すれば、主電源がＯＮなのにレーザードライブが停止する。認識していないなら、停止しない。

　トリガーをＯＮにしても、ドライブされなかった。
　金属クリップをＧＮＤから外すと、普通にドライブされた。そのままＧＮＤに接触させると、停止。想定通りに動いていそうだ。

　更に確認を続行しようとしたが、合計数秒だけドライブされたところでローバッテリーになってしまった。
　警告音は既に鳴っていたが、遂に力尽きる。充電して念のためチェック続行せねばならない。それでも、恐らくは機能に問題ないと思われる。

　何ヶ月も少しずつ完成度を高め、ＰＩＣのプログラムも順調に仕上がっている。
　ソフトウェアではあるが、昔ならハードの回路を作り変えて調整していた部分が置換されただけで、気分的にはハードウエアをチップに焼き込んでいるようなもの。
　細部の処理ロジックを調整し、パラメータの最適値を追及し、手間を重ねた結果。そのソースコードを眺めていると、ハードウェアを顕微鏡で観察している気分になる。

　最近ハンダゴテは余り出番が無いが、工作ならずっとやって来ている。

　故障判定を行なった結果、
・ＯＫならカウンターを０にする。
・ＮＧならカウンターを＋１し、所定の回数に達していれば故障扱い。

　というように条件分岐を追加。
　１０回連続までは故障扱いしないようにしたところ、普通に５Ａに収束して使用できるようになった。だが、条件分岐がバグっていて絶対に故障扱いにならないという可能性もある。そこで、今度は１回連続にしてみた。一瞬で故障扱いになった。
　次の問題は、故障扱いまで連続何回と定義するのが適切かということ。
　回数を増やせば誤判定は減るが、故障検出に要する時間が長くなる。

　昨日の段階では、１分ぐらい照射してからＮＧの連続回数の最大値をフラッシュメモリーに書き込む・・・みたいな調査を考えていた。しかし、調査用プログラムコードが案外複雑になる。高級言語を使うなら何でもない処理だが、ＰＩＣアセンブラでは調査用コード自体に幾つのバグが紛れ込むかも分からない複雑な記述を要する。
　実際、ＰＩＣを使っていて最大の弱点はアセンブラのマクロが貧弱過ぎることだと思う。以前書いたが、中でもただ一点「マクロでローカルラベルが使える」ように改善されるだけで桁違いに生産性が上がると思う。

　そんな訳で、今度は連続２回で試す。３回、４回と連続ＮＧ許容回数を増やしながら、故障判定されるまでの時間を測る。時間の伸び具合から、事実上無限に判定されなくなるであろう回数を推測し、それを最終的に設定する。
　だが想定外にも、２回に増やしただけで何十秒経過しても故障判定されない。
　プログラムコードを確認すると、ＮＧでカウンターを＋１した後の飛び先でカウンターがクリアされていた。最後に飛ばす場所がＯＫ時と同じだった。これではカウンターは永久に２にならない。

　良くある馬鹿ミスだが、修正してもやはり２回連続のＮＧが発生しない。
　試しに敷居値を書き換えて、ほぼ常にＮＧと判定されるようにしてみた。２回はもちろん１０回許容にまで設定しても、一瞬で故障扱いになった。つまり、カウンター周りの追加コードはもうバグっていない。
　どうやら巨大ノイズは発生原因に周期性でもあるのか、頻度こそ高いものの２回連続で発生する確率は非常に低いようだ。
　そこで、許容回数を５回に決定した。