SSブログ

雑用に追われてた [日常のあれやこれや]

この2週間ほど、モグラ叩き的雑用に追われて、やらないといけないことが後回しになっていた。自分の頭の中の整理も兼ねて、おさらいしよう...

こないだのお客さんの工場見学では、組立装置のデモは結局スルーだった。まあ動かなかったのでしょうがない。その後から直接僕には誰も言わないけど「装置が信用できない」という空気が工場側で醸成されているような感じがなんとなくする。そのせいで判断の目を曇らせるようなことがないんだったら、なんとでも思ってもらっていいんだけど、やはり緊急の場合のために外から装置のホストに接続できるようにしたいなあ。いわゆるVPNが欲しいんだけどちゃんとしたサービスは結構値段が高い。手間がかからず、なるべく安く(できればロハで)、しかも効率がいいというのはないだろうか。それはあまりに身勝手というのは承知の上で。

ところで、この一年ちょっとで僕が作った組立装置や評価装置が増えてきた(外部のメカ屋さんに手伝ってもらってまともな見栄えにしたものから僕がレゴで外装してそのままになってるものまでいろいろある)。そういった装置は光学測定が中心的な仕事なので、無圧縮のモノクロカメラを使って、それなりの計算量がホスト側で必要になっている。計算や表示は僕がプログラミングするので自動的にホストはOS Xマシンになって、カメラはGigEになる。

そんな装置が今時点で工場に3台、横浜のオフィスに4台ある。全部がホストとしてMac miniを使っている(計算バックエンド専用のヘッドレスも何台かあるのでホストという言い方は正確ではないけど)。僕自身も普段持ちにMacBook Proと、仙台で使っていたiMacを計算用に、さらに10.6以前のOSがどうしても必要なときのために古いCoreSoloのMac miniをオフィスに持ち込んでいる。会社のみんなは誰一人認識してないと思うんだけど、いつの間にかMacだらけになっている。

CoreSolo Mac miniはしょうがないとして、これだけ台数があるとOSのバージョンもいろいろになってしまう。新しく買うと10.11が載っていてバージョンダウンできない。一方でMathematica6.0が動かなくなるので普段使いは10.10以前で止めないといけない。これがだんだん煩わしくなってきた。

また、GigEカメラのドライバも中途半端な状態のまま使い続けている。新しいカメラを買うごとにGEN<i>CAMのカメラ記述ファイルを読み出して、カメラごとにレジスタのアドレスなんかをハードコードしている。組立装置はカメラを2台使うのが普通になってきているので、Mac miniの台数の2倍近くカメラがあることになる。一方でカメラの新しい機種ほど記述ファイルが急速に大きくなってる。これはメーカ側でのカメラの機能競争の面と、GigEや1394やUSB3.0、CameraLinkといったインターフェイスの違いを吸収して製品仕様を直交化したいということだろうけど、そのおかげでこういう(レジスタアドレスをハードコードする)やり方も苦しくなってきた。

去年の春過ぎからずっとやってた機種(半導体レーザと専用レンズが2枚)が今回量産移行して、次の機種の企画が起きている。これにはまたこれまでと違った光学性能が期待されているので、設計そのものよりもどうやって評価するかが問題になる。それに、いろいろな光学部品の評価も自前で出来るようにならないといけない。自分たちの製品の光学特性に直接影響する部品仕様がいっぱいあるのに、その実際の値はベンダ側の統計的な値しかないという状態から少しでも脱却したい。この特性とこの特性から計算すると、部品のこの値はこうだと考えられる、というような辻褄合わせ的な理解の仕方しかしていないし、その辻褄も合わないところが結構あったりする(僕が入る前はどうしてたんだろう、と不思議になる)。

でも僕はまずGigEカメラのドライバを整備したいなあ。でないと破綻は目前という気がする。カメラごとのハードコードはやめてドライバがカメラ記述ファイルからカメラの機能をユーザに提示して、レジスタアドレスなんかはユーザから隠蔽するようにしたい。つまりそれはGEN<i>CAMのGenApi+GenTLと互換性のある実装をやるということで、ずっと前からやりたかった。個人的にはこれが最優先だなあ。

ただし、そういうのってみんなに説明してもわかってもらえない。「動いてるんならいいじゃん。余計なことはやめろよ。それよりも次のレンズ設計やれよ」と言われるに決まっている。レンズ設計のほうが仕様が決まってしまえばずっと簡単なんだけどなあ。



ところで、もっと原理的な問題として、今製品にしている光学系って非対称で、ある方向には絞られてフォーカスを持つけど、それに垂直な方向には広がりっぱなしになっている。このフォーカス位置付近の強度分布を1次元のFraunhofer回折や、フォーカス位置から遠いところでは1次元のFresnel回折とみなして計算している。でもそれでいいんだろうかとずっと気になっている。

どちらの回折計算も本来は、ある点の強度は瞳のすべての点から影響を受けるという前提になっている。でも一方の方向の広がり方が大きい場合には、実質的に瞳の狭い領域の寄与しかないはずなので 1次元で近似するのはおかしい。かといって極端に大きな非点収差があるとして2次元で計算しようとすると、瞳でのメッシュをすごく小さくしないと滑らかな位相分布にならなくて、計算がぜんぜんうまくいかない。そもそもどちらの計算もKirchhoffの回折積分の位相をベキ展開した近似なので、大きな収差を前提に計算するのは間違っている。

さっきも書いたけど、計算と現物とが合わないという光学現象が大きく分けてふたつある(残念ながらそれぞれを具体的にここには書けない)。部品固有のパラメータの値がわからないせいもあるし、また製品仕様として破綻するというところまでは行っていないので、それほど大きな問題にはなっていないんだけど、その合わない理由が計算のやり方の問題なのではないかと思って、ずっと心配している。今の会社には相談できる人もいないし(ちなみに、前の会社は従業員数で言えば二桁以上違うけど、僕が辞める頃には相談できる人はやっぱり周りにはいなかった。僕が入った頃はそうじゃなかったんだけどなあ。まあ、もうそれは置いといて)。

1次元の計算はしょせん近似なのではじめから合わないのは当然と言えば当然なんだけど、ならこういうのってどうすればいいんだろう?
nice!(0)  コメント(0)  トラックバック(0) 

nice! 0

コメント 0

コメントを書く

お名前:
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。

トラックバック 0

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。