Hi Mark,
I looked at asynPortDriver and decided that I should look at it in some near future. For the time being, I have gone ahead trying to understand how various asyn components work. To this end I am staying with my attempt at a low level asyn driver, which I call drvMarx.c and which is based on Marty Kramer's echoDriver.c.
I now understand what is happening but as yet don't know what is the right solution.
I am now using asyn4.13.
When I process the epics records, the following action is triggered:
1. drvMarx:mxWrite() is called and it sends the string to my python "echo" program.
2. The python program, converts the string to upper case and sends it back.
3. drvMarx:mxRead() routine is called and it calls asynOctetSyncIO:readOnce().
4. asynOctetSyncIO:readOnce() calls asynOctetSyncIO:readIt(),
5. asynOctetSyncIO:readIt() calls pioPvt->pasynOctet->read(). This turns out to be:
6. asynInterposeEos:readIt(). As I see it, this is where trouble is. In this routine,
peosPvt->processEosIn is 1, therefore the execution goes into the for(;;) loop.
In this loop, peosPvt->poctet->read() is called twice. The first time it succeeds
but the second time it times out (not surprising since there is no more data to be
read from the port). In the for(;;) loop, there is some fancy handling of EOM stuff.
I don't understand that.
I tried the following in my st.cmd file:
asynInterposeEosConfig( "HM01",0,0,0)
This did not affect the value of peosPvt->processEosIn, it is still 1.
What is the correct solution to this?
It is clear to me that the read should be done only once. It seems to me that in my case processEosIn should be 0 and that would solve the problem that the read (recv) from the port is done a second time, which fails with time out. Or should the EOM parameters be configured somehow, such that the execution goes only once through the for(;;) loop?
I really need some straightening out on this.
Thanks in advance,
Zen
-----Original Message-----
From: Mark Rivers [mailto:[email protected]]
Sent: Saturday, April 17, 2010 11:18 AM
To: Szalata, Zenon M.; TECHTALK Tech-Talk
Subject: RE: asyn Driver questions
Hi Zen,
It looks like you must be using a pretty old version of asyn, R4-9 (October 2007) or earlier, because the asynOctetSyncIO->readRawOnce function was removed in R4-10. The release notes for R4-10 do say:
***
drvAsynIPPort
Cleaned up timeout handling.
***
I am not sure if going to a more recent release will fix your problems or not, but if possible I would try that first.
What type of device-specific asyn driver are you trying to write? The only documents are the ones in asyn. I have recently added a new C++ base class, asynPortDriver, that makes writing a device-specific driver very easy, particularly for complex devices with lots of parameters. I think it is well documented, and there is a well-commented example in asyn/testAsynPortDriver.
Mark
________________________________
From: [email protected] on behalf of Szalata, Zenon M.
Sent: Sat 4/17/2010 12:38 PM
To: TECHTALK Tech-Talk
Subject: asyn Driver questions
I am trying to learn how to write a driver module which is based on echoDriver.c written by Marty Kramer, which I renamed to drvMarx.c. I have a soft IOC, which includes the drvMarx.c module and which is intended to communicate with some Ethernet device. The network protocol is UDP. Presently the Ethernet device is simulated with a simple Python script which receives text message, converts the text to all upper case and sends this back. The script is working fine.
In drvMarx.c I am calling asynOctetSyncIO->readRawOnce, which fails with a timeout. Here is the code fragment from the read routine in drvMarx.c:
printf( "\n");
printf( "mxRead:before:readRawOnce: data=%s,nbts=%d,oemReason=0x%x\n",
data,*nbytesTransfered,*eomReason);
printf( "\n");
status=pasynOctetSyncIO->readRawOnce( pmxPvt->udpPort,0,data,maxchars,
5,nbytesTransfered,eomReason,"");
printf( "\n");
printf( "mxRead:after:readRawOnce: data=%s,nbts=%d,oemReason=0x%x\n",
data,*nbytesTransfered,*eomReason);
printf( "\n");
This is what I have in my db file:
record( stringout, "$(P):SO:SEND:IT"){
field( DESC, "Send msg")
field( FLNK, "$(P):SI:READ:IT")
}
record( stringin, "$(P):SI:READ:IT"){
field( DESC, "Read msg")
field( DTYP, "asynOctetWriteRead")
field( INP, "@asyn($(P),0,1) $(P):SO:SEND:IT")
}
When I put the string Hello in the stringout record, this is what gets output:
epics> 2010/04/17 10:02:25.337 HM01 queueRequest synchronous
2010/04/17 10:02:25.337 HM01 mxDriver:write addr 0
2010/04/17 10:02:25.337 HM01 lockPort autoConnectOK 1
2010/04/17 10:02:25.337 HM01 flush
drvMarx:mxFlush
2010/04/17 10:02:25.337 HM01 mxDriver:flush addr 0
2010/04/17 10:02:25.337 HM01 mxFlush
2010/04/17 10:02:25.337 asynOctetSyncIO flush
2010/04/17 10:02:25.337 HM01 unlockPort
2010/04/17 10:02:25.337 HM01 write
Hello
2010/04/17 10:02:25.337 HM01:SI:READ:IT devAsynOctet: writeIt
Hello
2010/04/17 10:02:25.337 HM01 mxDriver:read addr 0
mxRead:before:readRawOnce: data=,nbts=0,oemReason=0x0
2010/04/17 10:02:30.338 asynOctetSyncIO readRaw failed 134.79.64.51:9999 UDP timeout: Resource temporarily unavailable
mxRead:after:readRawOnce: data=HELLO,nbts=5,oemReason=0x0
2010/04/17 10:02:30.338 mxRead nbytesTransfered 5
2010/04/17 10:02:30.338 HM01:SI:READ:IT devAsynOctet: readIt failed
Note that some of the output is generated by printf statements I put in the code.
Also note that readRawOnce returns the correct value, which means that it received the data from the python script and yet it failed.
Here is the st.cmd file:
#!../../bin/linux-x86/marx
< envPaths
cd ${TOP}
dbLoadDatabase("dbd/marx.dbd")
marx_registerRecordDeviceDriver(pdbbase)
drvAsynIPPortConfigure("HMx01","134.79.64.51:9999 UDP",0,0,0)
mxDriverInit("HM01",0,0,0,"HMx01")
dbLoadRecords("db/marx.db","P=HM01")
cd ${TOP}/iocBoot/${IOC}
asynSetTraceMask("HM01",0,0xff)
asynSetTraceIOMask("HM01",0,0x2)
iocInit()
## Start any sequence programs
#seq sncExample,"user=whitegrHost"
The big question is why is readRawOnce timing out?
Is there a document describing how to write a device specific asyn device driver? I see examples in the asyn distribution, like the echoDriver.c, but I find it very difficult to decipher those examples. Therefore I am stumbling around, much of the time not knowing what is the correct approach.
Thanks in advance,
Zen
- Replies:
- Re: asyn Driver questions Eric Norum
- References:
- asyn Driver questions Szalata, Zenon M.
- RE: asyn Driver questions Mark Rivers
- Navigate by Date:
- Prev:
Re: How to compile the sysVmeMapShow() function to the MVME5500 BSP? Andrew Johnson
- Next:
Re: asyn Driver questions Eric Norum
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: asyn Driver questions Mark Rivers
- Next:
Re: asyn Driver questions Eric Norum
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|