g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  Index 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014 
<== Date ==> <== Thread ==>

Subject: Re: RTYP field through the PV Gateway
From: Ralph Lange <Ralph.Lange@bessy.de>
To: "'Ernest L. Williams Jr.'" <ernesto@slac.stanford.edu>
Cc: EPICS Core Talk <core-talk@aps.anl.gov>
Date: Thu, 08 Jan 2009 14:56:53 +0100
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: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov]
On Behalf Of Andrew Johnson
Sent: Wednesday, January 07, 2009 8:29 AM
To: tech-talk@aps.anl.gov
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



Replies:
Re: RTYP field through the PV Gateway Kasemir, Kay
RE: RTYP field through the PV Gateway Jeff Hill
Re: RTYP field through the PV Gateway Andrew Johnson

Navigate by Date:
Next: Re: RTYP field through the PV Gateway Kasemir, Kay
Index: 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014 
Navigate by Thread:
Next: Re: RTYP field through the PV Gateway Kasemir, Kay
Index: 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·