なお、コマンドはSCPIだと言っていますが、SCPIで一般的なマルチコマンドは使えないようです(プログラム例にも入っているし、たまに使えることもある気もしたが、ほぼ動作しない)。なので、初期設定など、いっぱいのコマンドを送りたいときも諦めて1つずつ送るのが吉のようです(EPICSで別のデータベースにして、それを延々とFLNKで繋いでいく)。
コマンド | 機能 | タイプ | データベース番号 | 備考 |
---|---|---|---|---|
CHAN:TYPE SAMPEL | サンプルモード設定 | bo | 0 | |
FORMAT:DATA REAL,32 | データ転送REAL32指定 | bo | 1 | |
FORMAT:BORDER LSBF | LSBFirst指定 | bo | 2 | defaultはMSBFだが、今時MSBFで動くCPUあるの? |
CHAN:DATA:POIN DMAX | データ転送範囲 | bo | 3 | 表示エリアデータ全部転送 |
*RST | フルリセット | bo | 4 | 極めて危険。これ発行するくらいなら現場に走って行く |
ACQ:NSING:COUNT 1 | シングルショット回数1 | bo | 5 | 1を増やすとN回取得もできるらしい |
STOP | run停止 | bo | 6 | |
ACQ:STAT? | トリガー状態 | mbbi | 7 | 答えはRUN,STOP,COMP,BREのいずれか |
CHAN1:SCALE? | CH1のVスケール読み出し | ai | 8 | |
CHAN2:SCALE? | CH2のVスケール読み出し | ai | 9 | |
CHAN3:SCALE? | CH3のVスケール読み出し | ai | 10 | |
CHAN4:SCALE? | CH4のVスケール読み出し | ai | 11 | |
CHAN1:SCALE | CH1のVスケール設定 | ao | 12 | |
CHAN2:SCALE | CH2のVスケール設定 | ao | 13 | |
CHAN3:SCALE | CH3のVスケール設定 | ao | 14 | |
CHAN4:SCALE | CH4のVスケール設定 | ao | 15 | |
CHAN1:DATA? | CH1データ読みだし | waveform | 16 | |
CHAN2:DATA? | CH2データ読みだし | waveform | 17 | |
CHAN3:DATA? | CH3データ読みだし | waveform | 18 | |
CHAN4:DATA? | CH4データ読みだし | waveform | 19 | |
CHAN1:DATA:XINC? | CH1の水平方向時間差 | ai | 20 | チャンネル毎違うケースは考えにくいが |
CHAN2:DATA:XINC? | CH2の水平方向時間差 | ai | 21 | チャンネル毎違うケースは考えにくいが |
CHAN3:DATA:XINC? | CH3の水平方向時間差 | ai | 22 | チャンネル毎違うケースは考えにくいが |
CHAN4:DATA:XINC? | CH4の水平方向時間差 | ai | 23 | チャンネル毎違うケースは考えにくいが |
*TRG | Force trigger | bo | 24 | |
TIM:SCAL? | 水平スケール読み出し | ai | 24 | |
TIM:SCAL | 水平スケール設定 | ao | 25 | |
SING | シングルショット開始 | bo | 26 |
# データ長のバイト長 データバイト長 1つめのデータ 2つめのデータ..
標準状態では、IEEE 754 Floatingp-pointフォーマットです。但し、バイトオーダーは(神代の昔のCPUでない限り)FORM:BORD LSBFを指定して、データスワップを指定しないと変換が大変です。
なお、32ビットありますが、オシロスコープから出てくるデータは16ビット分は完全に0のデータしか入っていないので、無駄と言えば無駄が多いフォーマットです(ASCIIよりはマシですが)。
UINTegerだと、無駄なくデータを送ってきますが、その後変換するのがまだイヤだなぁ、という気もします。
トリガーがかかったかどうかは、ACQ:STAT?の結果で、シングルショットの場合、トリガー待ちの場合はSTOP, トリガーがかかった場合はCOMPになります。
EPICSそのものに対する入門出家入道については徳の高い専門家に帰依することをおすすめしますが、そうでない場合、古今東西の古文書、wikiなどを読破する努力が必要となります。
device(ai, GPIB_IO, devAiRTA4004, "RTA4004") device(ao, GPIB_IO, devAoRTA4004, "RTA4004") device(bi, GPIB_IO, devBiRTA4004, "RTA4004") device(bo, GPIB_IO, devBoRTA4004, "RTA4004") device(event, GPIB_IO, devEvRTA4004, "RTA4004") device(longin, GPIB_IO, devLiRTA4004, "RTA4004") device(longout, GPIB_IO, devLoRTA4004, "RTA4004") device(mbbi, GPIB_IO, devMbbiRTA4004 , "RTA4004") device(mbbiDirect,GPIB_IO, devMbbidRTA4004, "RTA4004") device(mbbo, GPIB_IO, devMbboRTA4004, "RTA4004") device(mbboDirect,GPIB_IO, devMbbodRTA4004, "RTA4004") device(stringin, GPIB_IO, devSiRTA4004, "RTA4004") device(stringout, GPIB_IO, devSoRTA4004, "RTA4004") device(waveform, GPIB_IO, devWfRTA4004, "RTA4004") include "asyn.dbd"です。
変換部などのコードは、キーサイトDMM 34465A用device supportを参考に作りました。当初、マルチコマンドが使えないことによる呪いを受けたり、怪しいsegmentation faultに悩まされましたが、一応安定に動く様になったと思います。segmentation faultについてはまだ完全に理解していないのですが、配列をやたらに大きく余裕をもって設定したりすると起きやすい傾向が見られました。これは、このEPICS IOCのメモリーサイズ上限が決まっていて、staticに配列などに食われているとdynamicに確保するときにくたばる、と疑っているのですが、間違っているでしょうか。
INIT1 ->INIT2 -> INIT4
をFLNKで繋いで実行するようにしてあります。また、データ読み込みは
GETDATA-> CH1:DATA:READ -> CH2:DATA:READ -> CH3:DATA:READ -> CH4:DATA:READ
もFLNKで繋いであります。全チャンネル読むのに2-3秒かかっていましたが、この試験を行っていた場所のネットワークが100baseであったのが影響していると思います。
!../../bin/linux-x86_64/fblinux ## You may have to change fblinux to something else ## everywhere it appears in this file < envPaths epicsEnvSet(EPICS_CA_MAX_ARRAY_BYTES, 1500000) cd ${TOP} ## Register all support components dbLoadDatabase("dbd/fblinux.dbd") fblinux_registerRecordDeviceDriver(pdbbase) ## Load record instances dbLoadRecords("db/FB_RTA.db","USER=FBL, PLACE=**,LNK=0,ADD=1") drvAsynIPPortConfigure("L0","172.19.***.***:5025",0,0,0) #asynSetTraceMask("L0",0,0x8) #asynSetTraceIOMask("L0",0,0x4) cd ${TOP}/iocBoot/${IOC} iocInit()簡単な操作と表示をするCSSパネルを作りました。