Experimental Physics and Industrial Control System
|
On 17.12.2012 15:35, Ralph Lange wrote:
On 17.12.2012 14:52, [email protected] wrote:
[...]
One or the other, I've not looked to see what would be involved (well, I have now...). I'd start by thinking of providing a simple socket interface which walks the database, or maybe just returns the results of dbgrep.
Actually, a glance at the implementation of dbgrep (src/db/dbTest.c) suggests that the existing code is close to what you need, but needs a tweak (rather than calling puts you'll want more control over where the strings go), but it looks to me as if all the functions called by dbgrep are exported by epics, so writing what you need should be exceptionally easy: just grab a copy of dbgrep, give it a file handle output, replace puts, wrap a socket interface around it, launch it as part of your IOC startup scripts.
If it were me, I'd dedicate a socket, read one line from the input, treat it as input to the modified dbgrep, send the results in response, close the socket. Then `echo \* | nc $IOC $PORT` would give you a list of all PVs exported by the IOC.
Of course, you'll need to add this code to every IOC...
You could also create a device support for the waveform record, that (at
boot time) creates an array (of char) containing all records' names.
Then a client can simply use CA to get the complete list from an IOC,
and there is no runtime overhead on the IOC. (Usually the client will be
faster at doing wildcard matches anyway.)
~Ralph
Not so easy for two reasons:
First the memory of a waveform record is allocated before the device
support is called. Thus the device support cannot create the array. The
user has to specify NELM large enough to keep all potential records. In
principle the device support could drop BPVT and assign it a new buffer.
But that is not save, because by this time any database link pointing to
the record has already read the address of the old buffer. Thus you will
have a record that you can only access with CA externally, but not with
links internally.
This can be solved by using an aai record. There the device support
allocates the memory. And in the current version, it even works
correctly, i.e. early enough.
Second an array of strings is limited to 40 char strings. Record names
may be longer now. But maybe getting only the fist 40 (or actually 39)
chars of the name is already something.
An array of char would need a defined separator character (e.g. '\n').
Thus each client would need to know how to interpret the data. Possible
but then we can as well start sending _everything_ as raw byte buffers.
What could work is a CA server that is not a record, very much like the
portable CAS. This server can actually create the list on the fly,
including pattern filtering. But I have not tried that so far.
Dirk
- References:
- How to get a list of all available PVs Carlos Pascual
- Re: How to get a list of all available PVs Carlos Pascual
- RE: How to get a list of all available PVs michael.abbott
- Re: How to get a list of all available PVs Carlos Pascual
- RE: How to get a list of all available PVs michael.abbott
- Re: How to get a list of all available PVs Ralph Lange
- Navigate by Date:
- Prev:
Re: How to get a list of all available PVs Carlos Pascual
- Next:
Re: How to get a list of all available PVs Rod Nussbaumer
- 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: How to get a list of all available PVs Tim Mooney
- Next:
Re: How to get a list of all available PVs Michael Davidsaver
- 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
|
ANJ, 18 Nov 2013 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|