Hi Zen,
I really don't know what is going on, and I don't have a way to reproduce it or test it.
I suggest you find the locations where the VXI11 I/O is being done in the VXI11 driver and add some print statements to see what is happening.
Sorry I can't be of more help.
Mark
-----Original Message-----
From: Zenon Szalata [mailto:[email protected]]
Sent: Saturday, October 12, 2013 8:14 PM
To: Mark Rivers
Cc: [email protected]
Subject: Re: VXI11 - GPIB
Hi Mark,
Yes, 0x0c is the correct response. It is the status byte from the
device and the two bits set signify that it is on-line and that the
transfer count register is at 0.
Here is rather lengthy output of the IOC starting up. Part of it is a
table of operations that is read in from file ios.txt which is echoed.
zms@esaanal2 $ ./st.cmd
#!../../bin/linux-x86_64/camac
< envPaths
epicsEnvSet("ARCH","linux-x86_64")
epicsEnvSet("IOC","sioc-esa-cam01")
epicsEnvSet("TOP","/afs/slac.stanford.edu/g/testfac/vol1/rhel6/epics/R3.14.12.2/iocTop/camtest/devel")
epicsEnvSet("ROOT","/afs/slac/g/testfac")
epicsEnvSet("EPICS_SITE_TOP","/afs/slac/g/testfac/rhel6/epics/R3.14.12.2")
epicsEnvSet("EPICS_MODULES","/afs/slac/g/testfac/rhel6/epics/R3.14.12.2/modules")
epicsEnvSet("ASYN","/afs/slac/g/testfac/rhel6/epics/R3.14.12.2/modules/asyn/R4.21")
epicsEnvSet("CAMAC","/afs/slac/g/testfac/rhel6/epics/R3.14.12.2/modules/camac/devel")
epicsEnvSet("EPICS_BASE","/afs/slac/g/testfac/rhel6/epics/R3.14.12.2/base")
epicsEnvSet( ETHER,"192.168.1.79")
cd
/afs/slac.stanford.edu/g/testfac/vol1/rhel6/epics/R3.14.12.2/iocTop/camtest/devel
dbLoadDatabase "dbd/camac.dbd"
camac_registerRecordDeviceDriver pdbbase
vxi11Configure( "L0x","192.168.1.79",0,0.0,"gpib0",0,0)
asynSetTraceIOMask( "L0x",12,4)
asynSetTraceMask( "L0x",12,0x9)
drvKS3988Config("L0x",12)
drvKS3988::drvKS3988:connect: succeeded, stat=0
drvKS3988::drvKS3988: _ioPort=L0x, addr=12 configured
drvCamCCConfig( "CC0")
drvCamCC::drvCamCC: _port=CC0 configured
drvCamCC::camCVConfig: object created pthis=0x15517b0
camCVConfig( "CV0")
drvCamCV::drvCamCV: messageQueue created, id=0x1565e30
drvCamCV::drvCamCV: _port=CV0 configured
drvCamCV::camCVConfig: object created pthis=0x15601b0
#camADCConfig( "ADC0",50)
#magPSCConfig( "MAGS",2)
drvSy403CamConfig( "CHV",4,8)
drvCamCV::IOThread: started on 2013/10/11 21:55:30
drvSy403Base::drvSy403Base: messageQueue created, id=0x15f00f0
drvSy403Base::drvSy403Base: _locPort=CHV configured
drvSy403Cam::drvSy403Cam: configured
dbLoadRecords("db/camcc.db","P=ESA:CC,PORT=CC0,IOC=sioc-esa-cam01")
drvSy403Cam::taskThread: started on 2013/10/11 21:55:30
dbLoadRecords("db/camcv.db","P=ESA:CV,PORT=CV0,IOC=sioc-esa-cam01")
#dbLoadRecords("db/camadc.db","P=ESA:ADC0,PORT=ADC0,IOC=$(IOC)")
#dbLoadRecords("db/mags.db","P=ESA:MAG,PORT=MAGS,IOC=$(IOC)")
dbLoadRecords("db/sy403Ch.db","P=ESA:HV,PORT=CHV,IOC=sioc-esa-cam01")
cd
/afs/slac.stanford.edu/g/testfac/vol1/rhel6/epics/R3.14.12.2/iocTop/camtest/devel/iocBoot/sioc-esa-cam01
drvKS3988Setup( "ios.txt")
CamSetup::CamSetup:initOne succeded from ios.txt
tag=1, cc, cnafl=( 0, 0, 0, 0,0), nw= 0 sm=0,dma=0,init=0,d=0x0
tag=2, cc-rd-TCR, cnafl=(12,30, 0, 0,0), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=3, cc-rd-CSR, cnafl=(12,30, 0, 1,0), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=4, cc-rd-LAM, cnafl=(12,30,12, 1,0), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=5, cc-wt-TCR, cnafl=(12,30, 0,16,0), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=6, cc-wt-SRQ, cnafl=(12,30, 1,16,0), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=7, cc-wt-CSR, cnafl=(12,30, 0,17,0), nw= 1 sm=0,dma=0,init=0,d=0x4c0
tag=8, cc-wt-LAM, cnafl=(12,30,13,17,0), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=9, cv, cnafl=( 0, 0, 0, 0,0), nw= 0 sm=0,dma=0,init=0,d=0x0
tag=10, cv-rd-CMD, cnafl=(12, 1, 0, 3,0), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=11, cv-rd-DAT, cnafl=(12, 1, 0, 4,0), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=12, cv-rd-ROT, cnafl=(12, 1, 1, 4,0), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=13, cv-rd-RTN, cnafl=(12, 1, 2, 4,0), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=14, cv-rd-IDS, cnafl=(12, 1, 3, 4,0), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=15, cv-rd-P24, cnafl=(12, 1, 0, 5,2), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=16, cv-rd-P12, cnafl=(12, 1, 1, 5,2), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=17, cv-rd-P6V, cnafl=(12, 1, 2, 5,2), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=18, cv-rd-GND, cnafl=(12, 1, 3, 5,2), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=19, cv-rd-N6V, cnafl=(12, 1, 4, 5,2), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=20, cv-rd-N12, cnafl=(12, 1, 5, 5,2), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=21, cv-rd-N24, cnafl=(12, 1, 6, 5,2), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=22, cv-rd-TEM, cnafl=(12, 1, 7, 5,2), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=23, cv-rd-ANLG, cnafl=(12, 1, 0, 5,2), nw= 8 sm=1,dma=1,init=0,d=0x0
tag=24, cv-wt-DAT, cnafl=(12, 1, 0,20,0), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=25, dtm, cnafl=( 0, 0, 0, 0,0), nw= 0 sm=0,dma=0,init=0,d=0x0
tag=26, dtm-rd-ID, cnafl=(12, 2, 1, 1,0), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=27, dtm-rd-ST, cnafl=(12, 2, 0, 1,0), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=40, psc01, cnafl=( 0, 0, 0, 0,0), nw= 0 sm=0,dma=0,init=0,d=0x0
tag=41, psc01-rd-SP, cnafl=(12, 5, 0, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=42, psc01-rd-RP, cnafl=(12, 5, 0, 1,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=43, psc01-rd-ADC, cnafl=(12, 5, 1, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=44, psc01-rd-IM, cnafl=(12, 5, 1, 1,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=45, psc01-rd-DIO, cnafl=(12, 5, 2, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=46, psc01-wt-SP, cnafl=(12, 5, 0,16,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=47, psc01-wt-RP, cnafl=(12, 5, 0,17,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=48, psc01-wt-IM, cnafl=(12, 5, 1,17,1), nw= 1 sm=0,dma=0,init=0,d=0x2
tag=49, psc01-wt-DIO, cnafl=(12, 5, 2,16,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=50, psc01-tt-RP, cnafl=(12, 5, 0,27,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=51, psc02, cnafl=( 0, 0, 0, 0,0), nw= 0 sm=0,dma=0,init=0,d=0x0
tag=52, psc02-rd-SP, cnafl=(12, 7, 0, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=53, psc02-rd-RP, cnafl=(12, 7, 0, 1,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=54, psc02-rd-ADC, cnafl=(12, 7, 1, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=55, psc02-rd-IM, cnafl=(12, 7, 1, 1,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=56, psc02-rd-DIO, cnafl=(12, 7, 2, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=57, psc02-wt-SP, cnafl=(12, 7, 0,16,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=58, psc02-wt-RP, cnafl=(12, 7, 0,17,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=59, psc02-wt-IM, cnafl=(12, 7, 1,17,1), nw= 1 sm=0,dma=0,init=0,d=0x2
tag=60, psc02-wt-DIO, cnafl=(12, 7, 2,16,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=61, psc02-tt-RP, cnafl=(12, 7, 0,27,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=62, psc03, cnafl=( 0, 0, 0, 0,0), nw= 0 sm=0,dma=0,init=0,d=0x0
tag=63, psc03-rd-SP, cnafl=(12, 9, 0, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=64, psc03-rd-RP, cnafl=(12, 9, 0, 1,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=65, psc03-rd-ADC, cnafl=(12, 9, 1, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=66, psc03-rd-IM, cnafl=(12, 9, 1, 1,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=67, psc03-rd-DIO, cnafl=(12, 9, 2, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=68, psc03-wt-SP, cnafl=(12, 9, 0,16,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=69, psc03-wt-RP, cnafl=(12, 9, 0,17,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=70, psc03-wt-IM, cnafl=(12, 9, 1,17,1), nw= 1 sm=0,dma=0,init=0,d=0x2
tag=71, psc03-wt-DIO, cnafl=(12, 9, 2,16,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=72, psc03-tt-RP, cnafl=(12, 9, 0,27,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=80, adc01, cnafl=( 0, 0, 0, 0,0), nw= 0 sm=0,dma=0,init=0,d=0x0
tag=81, adc0100-F0, cnafl=(12,15, 0, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=82, adc0101-F0, cnafl=(12,15, 1, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=83, adc0102-F0, cnafl=(12,15, 2, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=84, adc0103-F0, cnafl=(12,15, 3, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=85, adc0104-F0, cnafl=(12,15, 4, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=86, adc0105-F0, cnafl=(12,15, 5, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=87, adc0106-F0, cnafl=(12,15, 6, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=88, adc0107-F0, cnafl=(12,15, 7, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=89, adc0108-F0, cnafl=(12,15, 8, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=91, adc0109-F0, cnafl=(12,15, 9, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=92, adc0110-F0, cnafl=(12,15,10, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=93, adc0111-F0, cnafl=(12,15,11, 0,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=94, adc01-DMAR, cnafl=(12,15, 0, 0,1), nw=12 sm=1,dma=1,init=0,d=0x0
tag=95, adc01-F8, cnafl=(12,15, 0, 8,1), nw= 0 sm=0,dma=0,init=0,d=0x0
tag=96, adc01-F9, cnafl=(12,15, 0, 9,1), nw= 0 sm=0,dma=0,init=0,d=0x0
tag=97, adc01-F24, cnafl=(12,15, 0,24,1), nw= 0 sm=0,dma=0,init=0,d=0x0
tag=98, adc01-F26, cnafl=(12,15, 0,26,1), nw= 0 sm=0,dma=0,init=0,d=0x0
tag=110, caenhv, cnafl=( 0, 0, 0, 0,0), nw= 0 sm=0,dma=0,init=0,d=0x0
tag=111, caenhv-F0, cnafl=(12,18, 0, 0,1), nw=64 sm=0,dma=0,init=0,d=0x0
tag=112, caenhv-F8, cnafl=(12,18, 0, 8,1), nw= 0 sm=0,dma=0,init=0,d=0x0
tag=113, caenhv-F9, cnafl=(12,18, 0, 9,1), nw= 0 sm=0,dma=0,init=0,d=0x0
tag=114, caenhv-F16, cnafl=(12,18, 0,16,1), nw=64 sm=0,dma=0,init=0,d=0x0
tag=115, caenhv-F17, cnafl=(12,18, 0,17,1), nw= 1 sm=0,dma=0,init=0,d=0x0
tag=116, caenhv-F24, cnafl=(12,18, 0,24,1), nw= 0 sm=0,dma=0,init=0,d=0x0
tag=117, caenhv-F26, cnafl=(12,18, 0,26,1), nw= 0 sm=0,dma=0,init=0,d=0x0
iocInit
Starting iocInit
######################################################
## EPICS R3.14.12.2 $Date: Mon 2011-12-12 14:09:32 -0600$
## EPICS Base built Jul 17 2012
######################################################
cas warning: Configured TCP port was unavailable.
cas warning: Using dynamically assigned TCP port 51037,
cas warning: but now two or more servers share the same UDP port.
cas warning: Depending on your IP kernel this server may not be
cas warning: reachable with UDP unicast (a host's IP in EPICS_CA_ADDR_LIST)
drvKS3988::afterInit:==== Done ====
drvCamCC::getPTag: name=cc,ptag=1
drvCamCC::afterInit: all done
drvCamCV::getPTag: name=cv,ptag=9
drvCamCV::afterInit: all done
drvSy403Cam::afterInit: nItems=9
iocRun: All initialization complete
#dbpf "ESA:CV:BO:UPDATE:STAT.SCAN",6
drvCamCV::_initialized: all done
drvSy403Base::_putInMsgQ: tag=117,ch=0,opc=0x0,nw=0
drvSy403Cam::getPTag: name=caenhv,ptag=110
drvSy403Cam::_initialized: all done
drvSy403Cam::_doIO: tag=117,ch=0,opc=0,nw=0
drvKS3988::_doIO:rw=0,nbt=9,*p=0
drvKS3988::_doIO:pb=(30,0,17,0,4,0,18,0,26)
2013/10/11 21:55:31.124 L0x 12 vxiWrite
1e 00 11 00 04 00 12 00 1a
2013/10/11 21:55:31.125 L0x 12 vxiRead
0c
drvKS3988::_writeRead: stat=0,l=1,nw=1,bln=4,nbi=1
drvKS3988::_writeRead: ncb=9,pcs=(30,0,17,0,4,0,18,0,26)
drvKS3988::_writeRead:sb=0xc
drvSy403Cam::_doIO:stat=0,tag=117,sb=0xc
...
I have left only one operation that is performed right after IOC init on
the CAMAC modules and that is to enable LAM in a module at N=18. This
is done by sending the binary string (in hex):
1e 00 11 00 04 00 12 00 1a
to it and the crate controller is instructed to respond by sending the
status byte, which it does and which is 0xc. I do this for each IO
request so that I can always use writeRead, since the controller always
responds by sending at least a status byte even if no data are expected
to be read back. In this case the read buffer length was specified as
less than 32.
Mark, thanks for looking at this,
Zen
On 10/12/13 05:59, Mark Rivers wrote:
Hi Zen,
Please send the complete output when the IOC boots.
Do you know if the 0x0c response when you use the 32-byte buffer is the correct response?
Mark
________________________________________
From: Zenon Szalata [[email protected]]
Sent: Friday, October 11, 2013 5:59 PM
To: Mark Rivers
Cc: [email protected]
Subject: Re: VXI11 - GPIB
Hi Mark and Matt,
First Mark's questions:
With read buffer length of greater than 32, writeRead fails with status 1,
which I think means that it is timing out on the read part.
Trace back gives:
2013/10/11 13:40:20.234 L0x 12 vxiWrite
1e 00 11 00 04 00 12 00 1a
epics> drvKS3988::_writeRead: stat=1,l=1,nw=1,bln=4,nbi=0
Stat in the print statement in my driver is the return code and nbi is
the number of bytes returned, both from the asynOctetSyncIO->wrteRead()
function. So, it failed to read.
On the other hand, with read buffer length of 32 or less:
trace back gives:
2013/10/11 13:08:48.636 L0x 12 vxiWrite
1e 00 11 00 04 00 12 00 1a
2013/10/11 13:08:48.638 L0x 12 vxiRead
0c
drvKS3988::_writeRead: stat=0,l=1,nw=1,bln=4,nbi=1
Matt,
I have not defined either the input nor output EOS characters. The code
worked with small read buffer size. It stopped working when I increased
the buffer size and it did not occur to me that this might be needed.
In each case, the device replies with one byte of data.
The hardware set up is:
Agilent Ethernet - GPIB <--> Kinetic Systems GPIB CAMAC crate controller.
I wonder if I could use IP Port driver instead of VXI11 driver?
I will look at the document for the KS3988 to see how it terminated its
reply data; it might help understand what is going on.
Thank you both,
Zen
On 10/11/13 13:58, Mark Rivers wrote:
Something does not seem right here, I don't understand why it is failing if nbt > 32.
Unfortunately I have no experience with VXI11, and I don't have any VXI11 devices to test with. Hopefully someone else on tech-talk can help you with this.
When the writeRead fails, what is the error return?
What do you see if you set asynTraceMask=255 in the underlying VXI11 port (L0x)?
Mark
-----Original Message-----
From: Zenon Szalata [mailto:[email protected]]
Sent: Friday, October 11, 2013 3:34 PM
To: Mark Rivers; [email protected]
Subject: VXI11 - GPIB
Hi Mark,
I have written a device driver for a GPIB device that is using VXI11
protocol.
The device driver is sub-classed from the asynPortDriver class.
In the st.cmd file I configure the VXI11 object as follows:
vxi11Configure( "L0x","$(ETHER)",0,0.0,"gpib0",0,0)
Then in the constructor I connect:
stat=pasynOctetSyncIO->connect( _ioPort,_addr,&_apvt,0);
finally in IO routine I call:
stat=pasynOctetSyncIO->writeRead(
_apvt,pcs,ncb,_buf,nbt,1,(size_t*)nio,&nbi,&eom);
_buf is defined as char _buf[2048]
I have discovered by trial and error that the writeRead succeeds for nbt
<= 32 and fails otherwise.
I do not understand this. I think that nbt is supposed to be the size
of the read buffer (in my case _buf) simply telling the routine, which
ultimately does the device IO, to put up to nbt bytes of data into the
read buffer. Now, it happens that in my test case the device returns
only one byte of data, that is the status byte. So, why should it fail
when I give the writeRead a ridiculously large buffer to read into?
Then what if I poke the device and it chooses to reply by sending 1024
bytes of data? Do I need to worry about that and issue the writeRead
number of times with 32 byte long read buffer until all bytes of data
are read in? Since I don't know before hand how much data will be
returned, it is not obvious to me how this could be done efficiently.
Thanks Mark,
Zen
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·