なかのにっき

前はペンレコーダーでやっていたのだけど、 そいつ用の接続コネクタとケーブルがあった。 1kA 以下のところを 0〜10V で出力するようなので、 それを単にマルチメータで記録すればいいだけなのだが。 手元には Agilent の 34401A が余ってたので、これを使うことにする。

またか (笑)

短期間で VEE や Windows で GUI プログラムの勉強して組むのも辛いので、 作業は Linux がいいなあ。 とするといまは Linux GPIB を使うことになるらしい。

サポートされているカード で入手が楽そうなのは NI の PCI-GPIB と PCI-GPIB+ あたりか。 コンテックの ISA カード もあるけど、新しく買うのに ISA でもないだろな。

いま手元には Agilent (旧 HP) の 82350A が手元にあるのだが、こいつは FPGA ものなのでどうも望み薄っぽい。 インターフェースの ISA カードもあるけど、これもダメだろうなあ。

ちなみに http://www.interface.co.jp は、いまつながらない。

今回の用途にはあれだけど、 いずれにしても MgO の電流測定にいつか GPIB 触る必要があるから、 買う方向で動いてみるか。

とりあえずこっちでつないでしまおう。 シグマ光機のステージコントローラにつないでいるケーブルがそのまま使えそうなので、とりあえず接続。 うへ、ストレートケーブルだった…

ということで出かけて買ってきた。 吉祥寺はさすがに混み混み。 の割に食い物屋はあまりやっていない。

日本語マニュアルの p.156 から。 RS-232C, 9600 ボー, 8 bit non parity, SCPI 言語, にそれぞれ設定。

でテスト…と思ったが、反応せず。やっぱり LF が足されない せいか。うーん。

去年の m102 制御のプログラムを引っ張り出してきてテストしてみるが反応せず。 と思って調べたら、34401A は DTR/DSR 制御だったらしい… ということで普通のやり方だと 無理 らしい。 うーん。ケーブルの配線変えるのか。めんどくさいなあ。 買ってきたクロスケーブルは溶着式のやつで、 無理やり剥がしたら断線した。ありゃりゃ。

m102 についてたストレートケーブルは、 両側が AMP のコネクタになってて楽にばらせたので、 こっちの配線を変えることにするか。はあ。

• 34401A 側の TxD(3) を PC 側の RxD (2) に
• 34401A 側の RxD(2) を PC 側の TxD (3) に
• 34401A 側の DTR(4) を PC 側の CTS (8) に
• 34401A 側の DSR(6) を PC 側の RTS (7) に

接続するようにすればいいか。 まんま 2-8 までのピンがストレート接続されてたから、 片側で 2<->3, 4<->8, 6<->7 の swap をすればいいだけか。

ピン
 2 黒
 3 赤
 4 白
 5 黄
 6 青
 7 灰
 8 茶
 9 橙

こういうときにまた半田ごてのこて台がなかったりして 14 号館まで取りに行ったりとか。やれやれ。

うむ、通信もできた。

一応できた。返ってくる文字列は \r\n で終端されるので、

  nread = read(fd, buf, nbuf);
  delim = strchr(buf, '\r');
  *delim = '\0';
  if (nread > -1) {
    nread = strlen(buf);
  }
  return nread;

という非常に ad hoc な実装にした。いつもこんなんやなあ。 スタンダードなやり方をご存知の方はコメントいただけると幸いです。

安定動作させるには read()/write() のあと、 適当な usleep() をかますほうが良いかもしれない。 5 jiffies くらい? しかし FETCH かますタイミングがちょっとむつかしいな…

(1/4 追記) 結局 こんなかんじ にしたら、まっとうに動作するようになったようだ。

参考はこのへん？

コマンドのやり取りはできるようになったので、 後はタイミングを見つつ SCPI 言語のやり取りをすれば OK。 これは明日書くことにしよう。

*CLS
*RST
:SYST:REM

:VOLT:DC:RANG 10
:VOLT:DC:RES 0.0001
:VOLT:DC:NPLC 1
:TRIG:SOUR IMM
:TRIG:DEL MIN
:SAMP:COUN 1

無限ループ{
  (時刻取得)
  READ?
  read();
  printf(時刻・データ)
  fflush(stdout)
  usleep(9e5)
}

という感じで。

測定の無限ループを Ctrl-C で止めたときに 34401A とシリアル線の終了処理をするため、

void intHandler(int signum){
  xtc_send(":SYST:LOC");
  xtc_close();
  exit(0);
}

int main(int argc, char * argv[])
{
    :
  struct sigaction sa;
    :
  memset(&sa, 0, sizeof(sa));
  sa.sa_handler = intHandler;
  if (sigaction(SIGINT, &sa, NULL)) perror("sigaction");
    :

という感じで。 『プログラミング Linux』 の 13 章あたり。

    struct timeval tv;
    struct timezone tv;
       :
    gettimeofday(&tv, &tz);
    printf("%ld.%06ld %s\n", tv.tv_sec, tv.tv_usec, rbuf);

という感じで。

ここが一番はまった。 どうもタイミングによって "READ?" を送った後の read() コールで刺さることがある。 いろいろ試行錯誤していたのだが、 どうも制御文字関連ではまっているっぽい。 34401A は シーケンスの最後に \r\n を返してくる のだけど、 今回 m102 から引っぱってきたルーチンを叩き台にしてたので、 termios 構造体メンバの c_cc[VEOL] が '\r' になっており、 このせいで末尾の \n を 34401A 側のバッファに残しちゃってたようだ。あほだ。

DTR/DSR フローコントロールをしているので、EOL もろもろの制御文字は不要のような気もするのだが、 c_lflag ICANON フラグを落としちゃうと、 しょっぱなの read() 呼び出しの際に文字列が切れる。 ということで ICANON は立てておき、 c_cc[VEOL] を '\n' にしたらうまくいった…っぽい。うーむ。 '\r' は c_iflag に IGNCR を立てて捨ててしまうことにした。 んで昨日のやり方で \n を \0 にして返すことにした。

…それでも、どうしてもときどき刺さることがあるなあ。 つづけて何回か 起動-Ctrl-C を繰り返し、 一度回りだせば続けて回るのだが。

ん、*RST 送ると 34401A で「カッチン」というリレーっぽい音がしてたので、 そのあとに usleep(5e5) 噛ますと大丈夫になったっぽい。 うーむ、このへん 34401A の素性かな。どうも良くわからんな。

XTC のテストモード、こいつは 16.2Angstrom/sec で擬似的な積算膜厚に対応した 出力を出すことになっているのだけど、 実際に取ってみた電圧の増加率は 0.1574 V/s。 これはループ中の usleep() を変えても (=測定間隔を変えても) きっちり同じなので、どうやら XTC のタイマが 3% くらいずれている…のかな？ まあ表裏の ratio が重要なので、 これは覚えといて、とりあえずこのまま測ってしまうことにしよう。

学科のサーバは基本的に debian の kernel-image パッケージを入れることにした。 ただし proxy だけは debian の kernel-image だと なぜか VFS エラーになっちゃうので、仕方なく前の設定を引っぱってビルド。 11 号館 1F の各 GW のリブートは明日。

研究室のは一部 FreeS/WAN とか使ってるので自前で作らないとだめ。

#!/bin/sh
OLDVER=2.4.23
NEWVER=2.4.24
SRCDIR=linux-$NEWVER

for host in surf babagw tiger migrate
do
  cp config-$host-$OLDVER $SRCDIR/.config
  if [ $host == surf -o $host == babagw ]; then
    PK="YES"
  else
    PK="NO"
  fi
  (cd $SRCDIR; \
   make-kpkg clean;
   env LANG=C PATCH_THE_KERNEL=$PK make-kpkg configure)
  cp $SRCDIR/.config config-$host-$NEWVER
done

というのと

#!/bin/sh
NEWVER=2.4.24
SRCDIR=linux-$NEWVER
REVISION=1

for host in surf babagw tiger migrate
do
  cp config-$host-$NEWVER $SRCDIR/.config
  if [ $host == surf -o $host == babagw ]; then
    PK="YES"
  else
    PK="No"
  fi
  (cd $SRCDIR; \
   make-kpkg clean;
   env LANG=C PATCH_THE_KERNEL=$PK make-kpkg --revision $host.$REVISION \
	--rootcmd fakeroot kernel_image)
done

を順番に実行して、その場にいなくても良いようにした。 kernellab というパッケージもあるのだけど、 どうもパッチ周りはうまく処理してくれないようで。

みんな帰ったところで surf, proxy, babagw (NFS サーバ) なども再起動。 babagw のリブートで、一度 /dev/hda が lost interrupt で刺さった。 single user モードで入って hdparm を disable にしたら大丈夫になった。 とりあえず /dev/hda には hdparm を効かせない方向で。 そろそろやばいのかな > /dev/hda

うへ、surf に大量の 404 エラーが。すみません。 メールもあるし、 babagw のリブートは surf をシャットダウンしてからじゃないとだめだな…

133.220.125.0 が 12 号館 5F のネットワークで、 133.220.125.254 が上流への GW。

• 133.220.125.n, 133.220.125.m (n, m≠254)
• 133.220.11X.160 (11 号館のマシン)

というマシンで ping を試みると、

• 133.220.125.n <-> 133.220.125.m は通る。
• 133.220.125.n -> 133.220.125.254 は通らない。
• 133.220.11X.160 -> 133.220.125.254 は通る。
• 133.220.11X.160 -> 133.220.125.n は通らない。

ということで、GW が下流側のネットワークの経路を 正しく処理できていないのではないか。

というわけで 1 分おきに surf から gw へ ping を打ってみた 記録 。ときどきつながるところがまたいやらしい。ハードウェア障害かなあ。

前回の format を流用して 1st draft 完成。 しかし boss に見てもらうにも、メールでは送りにくいんだよな… 明日ノート持ってきてダイヤルインでつなぐかのう。