Experimental Physics and
Industrial Control System

>A little excursion into a strawperson design:
>...

Sounds like the right approach to me.  But lets be careful about what we
do here because it COULD be a nice general purpose parameter-name &
value database system that could be used for other things as well. 
Especially in the areas of hardware configuration.

It would be rather depressing to have to do this all over again for yet
another system that requires a parameterized database for configuration
information.  I mean, we ALREADY have a database system that allows
access to the fields of records... perhaps what is needed is to build a
library or new functionality into CA to get to it in a manner that suits
this problem.

A possible strawperson direction:

I see this as a need to get a database to run on a workstation that can
provide this type of information (though it can reside on an IOC just
the same... just seems like a waste.)  And two function calls that can
be called on an IOC or workstation that require NO INITIALIZATION to
use: 

GetSymbolValue(char *SymbolName, enum DataType ReturnType, void *pReturnValue);
PutSymbolValue(char *SymbolName, enum DataType ValueType, void *pValue);

Obviously these would not be able to 'get' or 'put' anything other than
a single instance of what is decided to be put into the 'DataType'
enumerator.

I suspect that is this type of system was used, a heirarchical nameing
convention would be useful such that each device parameter on a given
IOC would have the IOC name and link number incorporated into the
parameter name.  This way, if a 'get' should fail to a fully qualified
name, another one could be made without the IOC name.  This would allow
for global initializations to be done with the ability to override them
for specific IOCs.

Keepalives, births, deaths, etc. could be done for symbols, if desired,
with a function like this:

PutSymbolStatus(char *SymbolName, enum OperationType, op);

Where OperationType could be things like OP_MASTER_ALIVE,
OP_MASTER_DYING, OP_MASTER_KEEPALIVE,...


--John

Navigate by Date:

Prev: Reflections on a Reflective Memory Device Interface Bob Dalesio

Next: PV names Bill Brown

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: Reflections on a Reflective Memory Device Interface Bob Dalesio

Next: Re: Reflections on a Reflective Memory Device Interface Bill Brown

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