EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  <19961997  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  Index 1994  1995  <19961997  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 
<== Date ==> <== Thread ==>

Subject: Re: RTYP ?
From: [email protected] (Tim Mooney)
To: [email protected]
Date: Thu, 14 Nov 1996 14:07:12 -0600
re...

> While we feel that in general it is undesirable for high
> level general purpose tools to know what record they are 
> attached to, we also see that in many application specific
> situations it would be quite useful to have access to this 
> information. Perhaps we should add a new "record
> type name" data type to the database access level  (which
> I assume could only be fetched as a string). Client
> requests fetching this type against an old CA server 
> that does not support it would be refused.
> 
> Is there general interest in this change?

Reluctant yes.  Here's an actual case in favor:

Suppose I'm a client application talking to several types of things
that can all be regarded as "positioners" (actual motors, AO records
talking to peizos, BO's talking to solenoids, virtual motors that
control the combined effects of several actual motors, etc.).  I don't
want my users to have to remember which things really are motors, so I
need to catch any resulting errors (e.g., the user may try to set the
"speed" of an ADC) and decide whether those errors prevent me from
doing what the user wants.  (Let's assume the user either wants to
{move, read, move, read,...} or to {move, and while moving, read, read,
read...}.  In the first case, setting the speed might be nice; in the
second, it's essential.)

I could require the application developer to list *all* of the possible
PV's associated with each positioner (position, speed, done?, stop!,
etc.).  In the example above, the absence of a "speed" PV name would
tell me all I need to know.  But this solution is unnecessarily
restrictive (if the app developer didn't think of it, it can't be done)
and horribly maintenance-intensive.

A better solution would be to support *all* PV's minimally as
positioners, and to allow the setting of speeds, etc., if a positioner
really is associated with a motor, or if a "speed" PV name has been
named in that list I mentioned above.

I should also mention that, in this particular case, I could just check
for the existence of a ".DMOV" field to determine whether the record
I'm talking to is really a motor.  But this may not remain true as record
types evolve.

Tim Mooney


Navigate by Date:
Prev: Re: Training laurence lurio
Next: 3.12.2 patch Jeff Hill
Index: 1994  1995  <19961997  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: RTYP ? Gabor Csuka
Next: Re: RTYP ? Pete Jemian
Index: 1994  1995  <19961997  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, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·