Ian,
Here is a little 'hack' that might be of use to you ...
>From your passive record, forward link to a subroutine record using the
attached subroutine. e.g. ...
record(bo,"MY:passiveBO") {
field(ZNAM,"Zero")
field(ONAM,"One")
field(FLNK,"MY:tidLkup.VAL PP NMS")
}
record(sub,"MY:tidLkup") {
field(INAM,"caHostIdI")
field(SNAM,"caHostId")
}
When the subroutine record processes, it will place the taskId in the
.DESC field of the record. If the task was created by the channel access
server, it will also show you the client name and user name.
If your record already is using the .FLNK, use the .SIML to process the
subroutine record.
You will need the following statment in the Makefile.Vx to find
the .h files ...
caHostIdSub_CFLAGS = -I $(EPICS_BASE)/src/rsrv -I $(EPICS_BASE)/src/ca
Have fun ...
Ned
>
> Hi Ian,
>
> > confused, yes! :-)
>
> That's what I thought ... the point is:
>
> The EPICS database records are just lying around like a large heap of
> sh...eep that are sleeping. Nebulously wavering on top of them there is
> an interface layer called Runtime Database Access that allows tasks to
> do things with (to?) these records, such as find one by name, put values
> to one of its fields or process it. (All the details are as always in
> the Application Developer's Guide.)
>
> So any task that wishes to access the database may use this interface to
> do so.
>
> (Compare your question to someone debugging the IO system asking "Which
> process is opening a file on this computer?" - Got the idea?)
>
> > In this case, it's DM poking a value into the record,
> > CA Put presumably.
>
> Right.
>
> This case is a bit difficult, since the tasks handling CA requests are
> generated on demand by the CA server.
>
> Issue an "i" command to the vxWorks shell after you boot your IOC, then
> take a deep breath and look at all the stuff that is helplessly idling
> around.
>
> Fire up the CA client (DM in this case) that accesses your channel.
>
> Issue another "i" command. Now you should be able to identify the pair
> of tasks that was created for this client. One of them, the CA event
> task, is handling the events (outgoing from IOC to client), the other
> one, called CA client task, handles the incoming requests (client to
> database). It is that task you should connect your debugger to.
>
> The names of these tasks have been undergoing a couple of changes
> lately, so what you see in your "i" output may differ depending on your
> base release.
>
> Now this should get you started ... good luck!
>
> Ralph
>
> ps: You may also look at the "IOC Test Facilities" chapter of the
> Developer's Guide to see what else is there to help you.
/* subroutine for determining host/uid of CA client
*
* DESC : String identifying Username & Host
*
*/
#include <vxWorks.h>
#include <taskLib.h>
#include <vme.h>
#include <types.h>
#include <stdioLib.h>
#include <stdio.h>
#include <string.h>
#include <ellLib.h>
#include <server.h>
#include <subRecord.h>
long caHostIdI(subRecord* pr)
{
return(0);
}
long caHostId(subRecord* pr)
{
int tid = taskIdSelf();
struct client* pclient;
LOCK_CLIENTQ;
for(pclient=(struct client*)ellFirst(&clientQ);
pclient && pclient->tid!=tid;
pclient=(struct client*)ellNext(&pclient->node)
);
if(pclient)
sprintf(pr->desc,"%s/%s/0x%x",
pclient->pUserName,pclient->pHostName,tid);
else
sprintf(pr->desc,"Internal: TID = 0x%x",tid);
db_post_events(pr, pr->desc, 1);
UNLOCK_CLIENTQ;
pr->val = 0; /* make sure val is 0 */
return(0);
}
- Replies:
- Re: process passive task Ralph Lange
- Navigate by Date:
- Prev:
Re: process passive task Ralph Lange
- Next:
Re: process passive task Ralph Lange
- 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: Device support for Berkeley Nucleonics B951 Benjamin Franksen
- Next:
Re: process passive task Ralph Lange
- 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
|