某k電気株式会社殿製DCCTコントローラ用EPICS Device Supportの製作(Japanese)

• 1.はじめに
• 2.GP-IBファンクション
• 3.EPICS環境
• 4.コードの説明(GDL)
• 5.コードの説明(C)
• 6.EPICSデータベース
• 7.スタートアップファイル
• 8.MEDMによる制御
• 9.おわりに

1.はじめに

2.GP-IBファンクション

• MEAS
  ADCのトリガーモードをオートトリガーモードとします。
• MEAS?
  ADCのトリガーモードをオートトリガーモードとし、データを測った後この値を返します。
• TRIG
  ADCのトリガーモードをシングルトリガとし、１回トリガーします。データを測定した後、この値をメモリーに入れます。値を返すわけではありませんので、値を読むためにはREAD?コマンドを使う必要があります。
• READ?
  オートトリガー時は直前の測定データを返します。シングルトリガ時はメモリーに入っているデータを返します。
• RANGn(nは1〜6)
  測定レンジを切り替えます。初期値は6です。
  
  • 1:20mAレンジ
  • 2:50mAレンジ
  • 3:100mAレンジ
  • 4:200mAレンジ
  • 5:500mAレンジ
  • 6:1Aレンジ(但し、出力〜3V=3Aまでは問題なく測定可能)
• RANG?
  現在のレンジの値を(上のn)返します。例えば6レンジであれば、
  RANG=6
  といった形の答えが返ってきます。
• *IDN?
  装置のIDを返します。例えばK*d*s Beam DCCT 80051といった形です。

コマンドのエラーがあるときは、Syntax ErrorとかMissing Operandといった答えを返しますが、あまり統一性はありません。オーバーレンジの時は、Over Rangeを返すはずですが、Missing Operandを返す時もあるようです。

デリミタはCR+LFで、EOIも返します。一般的な使い方として、電源立ち上げ時は自動的にフリーランモードになっていますので、そのままレンジ設定したり読みとれば良いわけですが、安心のためには一番はじめにMEASを出しておけば良いでしょう。

全く意味不明で、有害無益なファンクションとして、応答のあるコマンドを出した後、すぐにデータを読まないとSRQを発効するというものがあります。何を考えてんだかとおもいますが、PET2001のべーしっくの世界でもあるまいし、どう考えても何の使い道もありません。

3.EPICS環境

4.コードの説明(GDL)

Device(DCCT)
%{
}%
TimeOut 60;

NameTable RangeName= "20mA","50mA","100mA","200mA","500mA","1A";

EfastTable RangeMode = "RANG1\r\n","RANG2\r\n","RANG3\r\n","RANG4\r\n","RANG5\r\n","RANG6\r\n";
EfastTable RangeRead ="RANG=1\r\n","RANG=2\r\n","RANG=3\r\n","RANG=4\r\n","RANG=5\r\n","RANG=6\r\n";

ParamTable{
	set_auto_trig	{rec=bo, command="MEAS\r\n"}
	read_auto_trig	{rec=ai, command="MEAS?\r\n",conv="%lf\r\n",leng=511}
	set_single_trig	{rec=bo, command="TRIG\r\n"}
	read_data	{rec=ai, command="READ?\r\n",conv="%lf\r\n",leng=511}
	set_range	{rec=mbbo,efast=RangeMode,name=RangeName}
	get_range	{rec=mbbi,command="RANG?\r\n",efast=RangeRead}
	get_name	{rec=si,command="*IDN?\r\n",
           conv="%[^\r\t\n]", leng=64}
	
}
%{
}%

LIBOBJS += devDCCTGpib.o

5.コードの説明(C)

本来、read?コマンドがでたとき、DCCT側の準備が出来ていない(データをregistorに用意していないとか、トリガーがかかっていない)場合は、GP-IBバス上のハンドシェイク信号でコマンドを拒否すれば良いのですが、実際には、read?が出てからデータをレジスタに用意するため、ハンドシェイクはOKを出しているのにデータがにゃあということになっています。これで読みとりが破綻する様です。とりあえずはread?コマンドと次のTA、LAを出すまでにwaitを入れてやれば問題は回避できます。

ウエイトを入れたところは、GP-IBアナライザで見ると、

M        Timestamp          Data             Control                        
      mi  s  ms  us  ns  A  H   87654321  E A S R I NR ND D                     
---------------------------------------------------------------------
       0  0   2 162   0  R  52  01010010  0 0 0 1 0  0 1 1  DAB
       0  0   0  72 300  E  45  01000101  0 0 0 1 0  0 1 1  DAB
       0  0   1 260 450  A  41  01000001  0 0 0 1 0  0 1 1  DAB
       0  0   1  52 250  D  44  01000100  0 0 0 1 0  0 1 1  DAB
       0  0   1  52 250  ?  3f  00111111  0 0 0 1 0  0 1 1  DAB
       0  0   1  52 250     d   00001101  0 0 0 1 0  0 1 1  DAB
       0  0   1  52 250     a   00001010  0 0 0 1 0  0 1 1  DAB
       0  0   3 518 950  ?  3f  00111111  0 1 0 1 0  0 1 1  UNL
       0  0   0   6 800     20  00100000  0 1 0 1 0  0 1 1  LA0
       0  0   0   7   0  C  43  01000011  0 1 0 1 0  0 1 1  TA3

とりあえずは「ソフト的」にwaitを入れて、動かすことにします。

コントロールの山本さんに相談の結果、gp-ib drive supportに手を入れていもらい、コマンドと次のUNL、LA、TAまでの間にwaitを入れることが出来るようにしてもらいました。これを使うため、gmakeでmakeを行うのではなく、まずgdcでコンパイルをします。ここで、gdcは

/cont/epics/R313/epicsTest/base313/bin/hppa8k/gdc

static struct  devGpibParmBlock devSupParms = {
  &DCCTDebug,   /* debugging flag pointer */
  -1,   /* device does not respond to writes */
  TIME_WINDOW,  /* # of clock ticks to skip after a device times out */
  NULL, /* hwpvt list head */
  gpibCmds,     /* GPIB command array */
  NUMPARAMS,    /* number of supported parameters */
  -1,           /* magic SRQ param number (-1 if none) */
  "devDCCTGpib",        /* device support module type name */
  DMA_TIME,     /* # of clock ticks to wait for DMA completions */
  NULL, /* SRQ handler function (NULL if none) */
  NULL  /* secondary conversion routine (NULL if none) */
  ,(int) '\xff' /* End of String(eos) */
};

6.EPICSデータベース

/*** COMMAND LIST ***/

No.  0   BO      set_auto_trig 
No.  1   AI      read_auto_trig 
No.  2   BO      set_single_trig 
No.  3   AI      read_data 
No.  4   MBBO    set_range 
No.  5   MBBI    get_range 
No.  6   SI      get_name 

7.スタートアップファイル

# Example vxWorks startup file
#Following must be added for many board support packages
cd "/users/tobiyama/epics_r313/iocBoot/iocfeedback"
#ld < bin/enableA24_frc64.o
ld < /cont/epics/R313/epicsTest/base313/src/libCompat/O.frc40/enableA24_frc40.o
ld < bin/kekRouteSet_frc40.o
#ld < bin/kekRouteSet_frc64.o
ld < bin/iocCore
ld < bin/seq
ld < bin/feedbackLib

enableSlaveA24()
sysA24MallocInit(0x40000)

dbLoadDatabase("dbd/feedbackApp.dbd")
dbLoadDatabase("feedbackApp/Db/fb_ar_ktest.db","user=tobiyama")
#dbLoadRecords("feedbackApp/Db/dbExample.db","user=tobiyama")
iocInit
#seq &snctest

8.MEDMによる制御

9.おわりに

GP-IBは、太古の昔に(IEEEで規定されたのが1975年、HPが構想を始めたのが1960年代後半だからもう神代の昔と言って良いかも知れない)、当時の非常に貧弱なコンピュータ環境で測定器をコントロールするためにHP社殿が開発された物です。今から思えば、エラーリカバリ機能はありませんし、TTLレベル動作のおかげでノイズにも強くなく、スピードも決して速いわけではありませんが、IEEE-488で規定されている仕様をちゃんと理解し、正しく使うなら、妙な動作などしないと確信しております。しかしながら、世の中には特定の計算機でなければ動かないとか、組み合わせによっては動かないなど、いやな言葉ですが“相性がある”デバイスがあるのも事実です。これは、それらを作った人たちが、GP-IBの動作を理解しておらず、「自分の環境でとりあえず動けばいい」という考えで、規格外の製品を作っているからではないでしょうか。もっと想像力を働かせて、正しく規格にあった製品を作って欲しいと思います。また、そのようなデバイスを発注する側としても、正しく規格にあったものを、手を抜かずに作らせることが必要だと思います。