[KEKB Bunch Feedback Group]

株式会社デジテックス研究所社製12ビット4チャンネルAD変換ボード17K76用EPICS Device Supportの製作(Japanese)


by とびやま まこと(Makoto Tobiyama)/KEKB ビームモニターグループ

警告
以下の記述に関しては、意図する、しないに関わらず多くの誤り、誤解が含まれていると思われますので、決して信用してはいけません。これを信じて起きた損害に関しては、当方は一切責任を持ちません。


If you need contact with the author, please E-mail makoto.tobiyama@kek.jp.
目次

1.はじめに

17K76はシングルターンBPM読み出しなどに適した、4チャンネル同時サンプルの 12ビットADCモジュールです。メモリー長は各チャンネル最大256kワードですが、 内部スイッチ切り替えにより128k/64k/32kワードに設定することもできます。 仕様上の最大サンプリングスピードは2MHzですが、10MHz程度までも問題なく動作 するようです。

2.VMEバスレジスタ

17K76ボードのI/Oマップは以下の通りです。
アドレスWrite/Readデータ
313029282726252423222120191817161514131211109876543210
0x**(**00)00000(R/W)****CH3:ADデータ(最古)****CH1:ADデータ(最古)
****Ch3****CH1
0x**(**00)1FFFC****CH3:ここまで(32kワード時)****CH1:32k
****Ch3****CH1
0x**(**00)3FFFC****CH3:ここまで(32kワード時)****CH1:64k
****Ch3****CH1
0x**(**00)7FFFC****CH3:ここまで(128kワード時)****CH1:128k
****Ch3****CH1
0x**(**00)FFFFC****CH3:ここまで(256kワード時)****CH1:256k
0x**(**01)00000(R/W)****CH4:ADデータ(最古)****CH2:ADデータ(最古)
****CH4****CH2
0x**(**01)1FFFC****CH4:ここまで(32kワード時)****CH2:32k
****CH4****CH2
0x**(**01)3FFFC****CH4:ここまで(32kワード時)****CH2:64k
****CH4****CH2
0x**(**01)7FFFC****CH4:ここまで(128kワード時)****CH2:128k
****CH4****CH2
0x**(**01)FFFFC****CH4:ここまで(256kワード時)****CH2:256k
0x**(**1*)*****R/W*コントロール(W)/ステータス(R)

ADCのデータフォーマットは、
入力電圧ディジタル出力
(MSB)(LSB)
+2V0000111111111111
0V0000100000000000
-2V0000000000000000

です。コントロール・ステータスレジスタのフォーマットは

3.EPICS環境

本デバイスサポートは、EPICS R313改訂版で開発したものです。EPICSそのものに対する説明、入門出家入道遁世については専門家に帰依するなり、コントロールグループのページをご参照なさるなりお気の向くままになさってください。動作はPPC750でのみ確認しています。A32/D32アクセスなのでPPC603ではきっと動作しません。

4.コードの概要

コードを以下に示します。 ADCデータの読み込みは、waveformレコードで要素数524228、データタイプが shortのものを2つ用意し、CH1、CH3を同時に 1つめのwaveform(signal 0)に(前半CH1、後半CH3)で 記録します。なお、データ長が256kワード より小さい時はその途中までしか記録しませんが、CH1とCH3の区切りは同じ場所です。
最初にメモリー書き込みが終了しているか(bit2が1か)、あるいは読み取り状態になっているか(bit0が0)かを判断します。どちらも満たされない場合はエラーで読み取りは行いません。
なお、リセットの都合上、必ずCH1CH3を先に読んで、次にCH2CH4(signal 1)を読みます。これは 次の入力用のリセットをCH2CH4を読んだときにしか出さないようにしているからです。 具体的には、データベース上でCH1CH3のレコードのFLNKをCH2CH4に入れておくか、 シーケンサー等で管理すべきです。
いずれにしてもwaveformレコードのレコード長が長大でこのままでは今のところchannel accessに 支障がありますので、データベース上では読みとれる長さ(4095以下)のsubarray あるいはcompact subarrayに分割する必要があります。compact subarrayについては データベースの所をご参照ください。
dbdファイルの中で次のように定義します。
device(bo,VME_IO,devBo17k76,"V17K76")
device(mbbiDirect,VME_IO,devMbbi17k76,"V17K76")
device(waveform,VME_IO,devWf17k76,"V17K76")

初期化ファイルはdev17k76Cnfigで、ベースアドレスが0x22000000で1枚使うとすると、

dev17k76Config(1,0x22000000)

の様に指定します。なお、このボードは1枚で2Mバイトもの領域を占有しますので、 他のボードと干渉しないよう特段の注意が必要です。

5.EPICSデータベースサンプル

サンプルファイルは以下を参照してください。 ここで、CH1CH3のwaveformレコードは10秒に1回スキャンしていますが、実際に使用する 時はscanではなく、sequencer等でstatusのbit2を見て1になったら CH1CH3→CH2CH4の順でプロセスすることになります。

compact subarrayについて

現行EPICSR313ではとても間抜けなことに 長いwaveformをcaput、cagetすることがでけまへん。長いwaveform 自体を作ることは可能ですが、applicationにそのままではもってこれません。そこで、 いくつかの部分arrayに分けてえっちらほっちら持ってくることになりますが、 今まではsubarrayレコードを使用していました。ところが、噂によるとこのsubarray レコードはとても間抜けなことにもとのwaveformと同じだけのメモリーを食うそうです。 このデバイスサポートで使うようにとても長いwaveformのsubarrayを作ると思うと、 身の毛もよだつようなことに(256k/4k=64、64×0.5M=32MB!!!!)なります。そこで小田切さんが開発されたいう compact subarray レコードを使えば、必要なだけしかメモリーを食わないので安心です。この新しい レコードを使うためには ということで出来るそうです(私は色々うまくいかなくてあちこちいじってしまったので 果たして今になって上の手順でうまくいくかどうか自信ない)。データベース自身は subarrayレコードからレコードタイプを
subArray→compactSAとし、MALMフィールドを除去したものです。

6.スタートアップファイルサンプル

1枚の17K76ボードを使用する時のスタートアップファイル(の関係部分)は次のようになります。
dbLoadRecords("fbppcApp/Db/FB_ADC.db","USER=FBH:TEST , chan=C0")

dev17k76Config(1,0x22000000)

iocInit

7.おわりに

4チャンネル同時サンプルの 12ビットADCモジュール、17K76ボードの のEPICSデバイスサポートおよびデータベースについて紹介しました。本ボードについてご興味のある方はより詳しい資料がありますので、飛山までご連絡ください。
Makoto Tobiyama
6/Jan/2002

Return to FB Home Page...