EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: RTYP field through the PV Gateway
From: "Jeff Hill" <[email protected]>
To: "'Ralph Lange'" <[email protected]>, "'Ernest L. Williams Jr.'" <[email protected]>
Cc: "'EPICS Core Talk'" <[email protected]>
Date: Thu, 8 Jan 2009 09:25:54 -0700
As I recall, only db_access knows the behavior (mapping) associated with a DBR_CLASS_NAME request, and that the CA client and server only know that this is another DBR type which is stored as a string.

Perhaps the only issue is that the GW isn’t caching the DBR_CLASS_NAME PV attribute? Another possibility might be that the GDD to DBR conversion stuff was written before DBR_CLASS_NAME was added.

Jeff

> -----Original Message-----
> From: Ralph Lange [mailto:[email protected]]
> Sent: Thursday, January 08, 2009 6:57 AM
> To: 'Ernest L. Williams Jr.'
> Cc: Jeff Hill; 'Andrew Johnson'; EPICS Core Talk
> Subject: Re: RTYP field through the PV Gateway
> 
> 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", so that the data can be held in the usual cache structures.
> Then the Gateway's CA client side will properly recode the request to
> DBR_CLASS_NAME.
> 
> Actually I have no idea why "finding out the record type as a string"
> was implemented in that way, instead of adding support for an additional
> (maybe pseudo) field in the EPICS database. The pseudo field approach
> contradicts a number of well-accepted design ideas and concepts:
> 1. It bloats the protocol (by adding another DBR type).
> 2. It restricts (probably undocumented) the naming of EPICS database
> fields. (I refuse trying to imagine what creating a "real" field named
> RTYP would result in.)
> 3. For non-EPICS uses of CA (gateway through a CAS to something
> completely different) it imposes the EPICS-like naming ".RTYP" that
> might make no sense ore even create a conflict within the completely
> different naming scheme.
> 4. It forces an intermediate layer to add exception code (see above).
> 
> An implementation that just transparently forwards the read request to a
> PV "XXX.RTYP" like any other read request and lets the EPICS database
> code return that special record type name would IMHO be a much cleaner
> solution. Things like the gateway would just work without any added
> complexity.
> 
> Do I miss some important advantage of the pseudo field implementation? I
> can't think of one and (as I know this feature has been added later on)
> I guess there should be a few. Jeff, what am I missing here?
> 
> The only other case of CA-EPICSdb dependency (that I know of) is adding
> the ".VAL" extensionsto PVs without a field name. I don't know if this
> is done by the client or the server right now - it should be done on the
> server side for the same reasons.
> 
> Cheers,
> Ralph
> 
> 
> Jeff Hill wrote:
> > Summarizing the issue; this PV attribute, "DBR_CLASS_NAME", isn't
> currently
> > maintained in the gateway's cache. The symptom must be that its
> > communicating properly through both sides of CA, but not through the
> > gateway.
> >
> > I am not aware that anyone is working on this, but Ralph Lange would be
> the
> > best person to consult concerning current projects in progress with the
> > gateway.
> >
> > Jeff
> >
> >
> >> -----Original Message-----
> >> From: [email protected] [mailto:tech-talk-
> [email protected]]
> >> On Behalf Of Andrew Johnson
> >> Sent: Wednesday, January 07, 2009 8:29 AM
> >> To: [email protected]
> >> Cc: Ernest L. Williams Jr.
> >> Subject: Re: RTYP field through the PV Gateway
> >>
> >> Hi Ernest,
> >>
> >> On Wednesday 07 January 2009 00:15:17 Ernest L. Williams Jr. wrote:
> >>
> >>> Is anyone working to add the "DBR_CLASS_NAME" to the gateway so that it
> >>> handles the RTYP field in an EPICS record?
> >>>
> >> I'm not aware of anybody doing so.  Why can't you just ask for the .RTYP
> >> field
> >> name (which is really an automatically created record attribute)
> directly?
> >>
> >> - Andrew
> >> --
> >> The best FOSS code is written to be read by other humans -- Harold Welte
> >>
> >
> >
> >



References:
Re: RTYP field through the PV Gateway Ralph Lange

Navigate by Date:
Prev: Re: RTYP field through the PV Gateway Kasemir, Kay
Next: Re: RTYP field through the PV Gateway Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  <20092010  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 Kasemir, Kay
Next: Re: RTYP field through the PV Gateway Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·