Experimental Physics and Industrial Control System
Pete R Jemian wrote:
[1] A tracing mechanism in to find
out which host/user last modified this PV.
Yes, that will take additional memory.
When trying to locate some aberrant client,
this is most valuable. Also, useful when
trying to identify which user thought
we had a new d-spacing in our monochromator
(for example).
APS have a technique for tracking down who modified a specific PV
(actually a specific processing chain) via CA, but it does involve adding
some code and a subroutine record to the IOC. We actually configure
several 'spare' subroutine records for this in all of our IOCs; the magic
of runtime modification of link fields allows us to configure which
records we actually want to monitor later on when the need arises.
Another way to do this would be to write some simple logging code for the
Access Security write trapping hook. Check the Access Security chapter of
the Application Developers' Guide for details.
[2] An EPICS "ping" command or something that
a sysAdmin could use to identify all the EPICS
IOCs within a subnet. Maybe there is already
documentation on how to do this by probing
a certain port or some other elegant method.
The Channel Access client library knows this information because it has to
track server beacons, and in fact there is a program in base/src/ca called
casw.cpp which would easily be modifiable into a tool that prints out the
names of all known servers. Jeff wrote it as a diagnostic to print out
only server beacon anomalies, but it could be given a command-line option
to list all the servers when it first it sees them instead/as well.
[3] Building upon [2] above, a client request
for a list of all the PVs offered by a
chosen EPICS IOC. This would be a list
just like the "dbl" command from the IOC shell.
Why is this useful? It could be used to answer
the question "Where is this PV?" (Maybe this, too,
is already available from the low level C calls.
Maybe I should take the EPICS course.)
As has already been mentioned the answer to "Where is this PV" can be
discovered using a very simple CA client application:
#include <stdio.h>
#include <stdlib.h>
#include "cadef.h"
int main(int argc,char **argv)
{
chid mychid;
if(argc != 2) {
fprintf(stderr,"usage: caHost pvname\n");
exit(1);
}
SEVCHK(ca_context_create(ca_disable_preemptive_callback),
"ca_context_create failure");
SEVCHK(ca_create_channel(argv[1],NULL,NULL,10,&mychid),
"ca_create_channel failure");
SEVCHK(ca_pend_io(5.0),"ca_pend_io failure");
puts(ca_host_name(mychid));
return(0);
}
Grabbing the whole list of records on an IOC is not currently possible
through CA, but it would probably be relatively straightforward to write
some device support for the Waveform record that would make the IOC's list
of record names available as an array of strings. Of course this would
take up extra RAM and has to be added to the IOC in advance, and for large
databases it's only feasible on R3.14 where the 16KB array limit is no
longer an issue.
- Andrew
--
There are 10 types of people in the world:
Those who understand binary, and those who don't.
- Replies:
- Re: Among the things for which I wish... Rolf Keitel
- References:
- Among the things for which I wish... Pete R Jemian
- Navigate by Date:
- Prev:
Re: Among the things for which I wish... Till Straumann
- Next:
Re: Among the things for which I wish... Rolf Keitel
- 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: Among the things for which I wish... Till Straumann
- Next:
Re: Among the things for which I wish... Rolf Keitel
- 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