Experimental Physics and
| |||||||||||||||||
|
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.
| ||||||||||||||||
ANJ, 10 Aug 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |