Hi:
You just explained why the *RTYP request cannot work
through a gateway, but it does work when I try it here:
The CSS "EPICS PV Tree" gives a tree-view of data links.
It asks for a record's type via ..RTYP,
then follows an AI's INP or CALC's INPA,INPB,... or a BO's DOL etc.,
recursing down.
Obviously a very crummy way to do this because there's no good way
to determine what links of interest a record type might have
(would have to get the DBD file that the IOC used),
or to decide if a link is another record to decend into,
or hardware address that cannot be followed
(I look for '@...' or '#...' in the link text).
But in any case, it works through our PV Gateway Version 2.0.2.1
-Kay
On 1/8/09 08:56 , "Ralph Lange" <[email protected]> wrote:
> Hi - I moving this over to core-talk for the gory details....
>
> RTYP is a pseudo field: When a read request for a "*.RTYP" PV comes in,
> the CA client library strips the ".RTYP" and converts it to a
> DBR_CLASS_NAME request.
> When the CA server in the IOC (rsrv) gets that request, it finds out the
> record type of the EPICS record that the PV belongs to and returns the
> name of that record type as a string.
>
> So an intermediate layer like the Gateway will probably have to
> re-convert the DBR_CLASS_NAME request for "XXX" to a simple request for
> "XXX.RTYP", ...
- References:
- Re: RTYP field through the PV Gateway Ralph Lange
- Navigate by Date:
- Prev:
Re: RTYP field through the PV Gateway Ralph Lange
- Next:
RE: RTYP field through the PV Gateway Jeff Hill
- Index:
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: RTYP field through the PV Gateway Ralph Lange
- Next:
RE: RTYP field through the PV Gateway Jeff Hill
- Index:
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|