Hi All.
I'm trying to do something that seems to have many moving pieces, but I think it should work, with a little guidance here. I have database and accompanying protocols that are attempting to use the I/O Intr methods documented
in the streamDevice docs, which say that I can have a series of records receive the input stream to attempt a matching scan. I'm doing this with an async port that is a TCP Server port. The port configuration seems to work; I can make a telnet connection to
it. I was hoping that I could type the text matching the streamDevice 'in' protocol, and that the record attached to the protocol would process the input. I don't seem to be getting any data through the asyn TCP server port. The record doesn't process (stays
UDF). Moreover, the asynReport data always stays at 0 bytes sent, and 0 bytes received.
I'm using the latest streamDevice from github (hard to figure out version numbers from there) and asyn4-22 with EPICS 3.14.12.2
Following are some excerpts from startup script, IOC DB and streamDevice protocol files.
-------------------------< IOC startup script >---------------------------
drvAsynIPServerPortConfigure("CYC", "localhost:9999",10,1,1)
dbLoadRecords( "/mnt/icfileserv/usr1/common/db/ccs2epics01.db", PORT="CYC" )
# asynSetTraceIOMask(FGC3,10,0x0005)
# asynSetTraceMask (FGC3,10,0x001f)
# var streamDebug 1
iocInit()
-------------------------< IOC start >---------------------------
asynSetTraceIOMask(CYC,0,0x0005)
asynSetTraceMask (CYC,0,0x001f)
# var streamDebug 1
iocInit()
Starting iocInit
############################################################################
## EPICS R3.14.12.2 $Date: Mon 2011-12-12 14:09:32 -0600$
## EPICS Base built Jan 18 2018
############################################################################
2018/01/23 15:17:06.452 CYC -1 registerInterruptUser
2018/01/23 15:17:06.452 CYC -1 registerInterruptUser
2018/01/23 15:17:06.452 CYC -1 registerInterruptUser
2018/01/23 15:17:06.452 CYC -1 registerInterruptUser
2018/01/23 15:17:06.452 CYC -1 registerInterruptUser
2018/01/23 15:17:06.452 CYC -1 registerInterruptUser
2018/01/23 15:17:06.452 CYC -1 registerInterruptUser
2018/01/23 15:17:06.452 CYC -1 registerInterruptUser
2018/01/23 15:17:06.452 CYC -1 registerInterruptUser
2018/01/23 15:17:06.452 CYC -1 registerInterruptUser
2018/01/23 15:17:06.452 CYC -1 registerInterruptUser
2018/01/23 15:17:06.452 CYC -1 registerInterruptUser
2018/01/23 15:17:06.452 CYC -1 registerInterruptUser
2018/01/23 15:17:06.452 CYC -1 registerInterruptUser
2018/01/23 15:17:06.452 CYC -1 registerInterruptUser
2018/01/23 15:17:06.452 CYC -1 registerInterruptUser
2018/01/23 15:17:06.452 CYC -1 registerInterruptUser
2018/01/23 15:17:06.452 CYC -1 registerInterruptUser
2018/01/23 15:17:06.452 CYC -1 registerInterruptUser
2018/01/23 15:17:06.452 CYC -1 registerInterruptUser
iocRun: All initialization complete
# exit
mmpsioc1>2018/01/23 15:17:31.110 drvAsynIPServerPort: new connection, socket=5 on localhost:9999
---------------------------------< IOC runtime DB >------------------------------------
record(ai,"CYC:START"){
field(DESC,"analog input record")
field(DTYP,"stream")
field(SCAN,"Passive")
field(INP,"@ccs2epics.proto WR_START $(PORT) 0")
}
record(ai,"ABC:01:DEVTYPE"){
field(DESC,"analog input record")
field(DTYP,"stream")
field(SCAN,"I/O Intr")
field(INP,"@ccs2epics.proto RD_ABC_01 $(PORT) 0")
}
record(ai,"ABC:23:DEVTYPE"){
field(DESC,"analog input record")
field(DTYP,"stream")
field(SCAN,"I/O Intr")
field(INP,"@ccs2epics.proto RD_ABC_23 $(PORT) 0")
}
(There are 18 more I/O Intr scanned records, which seems to match the reports from asyn registerInterruptUser)
---------------------------< protocol file >------------------------------------
One protocol per record. I added the 'out' commands as a diagnostic to see if I could make it respond.
WR_START {
out "START\n";
in "PLEASE %d";
}
RD_ABC_01 {
in "ABC,01,%d";
out "thanks\n";
}
RD_ABC_23 {
in "ABC,23,%d";
out "thanks\n";
}
RD_ABC_45 {
in "ABC,45,%d";
out "thanks\n";
}
Processing the Passive record 'CYC:START' by using dbtr in the IOC shell or by setting it to periodic scan causes streamDevice to emit:
2018/01/23 15:25:32.022206 _main_ CYC:START lockRequest: pasynManager->queueRequest: port CYC not connected
PV: CYC:START dbtr(dbProcess)
The connected telnet session doesn't complain, but characters typed don't seem to go anywhere that shows up in places I can inspect:
mmpsioc1>asynReport,3
CYC multiDevice:No canBlock:Yes autoConnect:No
enabled:Yes connected:No numberConnects 0
nDevices 0 nQueued 0 blocked:No
asynManagerLock:No synchronousLock:No
exceptionActive:No exceptionUsers 0 exceptionNotifys 0
traceMask:0x1f traceIOMask:0x5 traceInfoMask:0x1
interposeInterfaceList
asynOctet pinterface 0x760b40 drvPvt 0x247dc90
interfaceList
asynCommon pinterface 0x760b10 drvPvt 0x247a7b0
asynInt32 pinterface 0x767ce0 drvPvt 0x247a7b0
asynOctet pinterface 0x767c80 drvPvt 0x247a7b0
Port CYC: Connected
fd: 4
Max. clients: 10
Num. clients: 1
CYC:1 multiDevice:No canBlock:Yes autoConnect:No
enabled:Yes connected:Yes numberConnects 1
nDevices 0 nQueued 0 blocked:No
asynManagerLock:No synchronousLock:No
exceptionActive:No exceptionUsers 1 exceptionNotifys 0
traceMask:0x1f traceIOMask:0x5 traceInfoMask:0x1
interposeInterfaceList
asynOctet pinterface 0x760d00 drvPvt 0x7f9b00001790
interfaceList
asynCommon pinterface 0x757210 drvPvt 0x7f9b000008e0
asynOctet pinterface 0x7f9b000009c8 drvPvt 0x7f9b000008e0
Port localhost:9999: Connected
fd: 5
Characters written: 0
Characters read: 0
What is the meaning of the CYC:1 section in the above? Is there some kind of new pseudo port created by each client connection? Am I supposed to use that somehow? How? What is the meaning of 'autoConnect' in the context of a TCP server? It seems conceptually
meaningless to me.
Is this even supposed to work? At the end of the day, I want to have data that is uniquely tagged and sent spontaneously on an irregular basis by the client to be associated with particular EPICS records, according to the tags, which I'm attempting to
match in each streamDevice protocol. Any suggestions for alternative solutions are quite welcome.
Thanks.
Rod Nussbaumer
TRIUMF
Vancouver, Canada.