> From [email protected] Fri Oct 27 17:21 CDT 1995
> Date: Fri, 27 Oct 1995 22:20:50 +0000 (GMT)
> From: Andy Foster <[email protected]>
> X-Sender: ajf@orc
> To: Epics Questions <[email protected]>
> Subject: New Subroutine Record
> Mime-Version: 1.0
> Content-Type> : > TEXT/PLAIN> ; > charset=US-ASCII>
> Content-Length: 1297
>
> I liked the idea put forward by Gordon Uchenick, i.e. taking the user
> code out of the context of the standard scan tasks.
> See Marty's message of Fri, 27 Oct 1995.
>
We have to trade off usefulness vs number of tasks. Dont know how to
decide this. Note that incorrecty written device/driver support can also
crash tasks. Is subroutine really that much worse?
> I also think it would be good to allow the user to choose the type of
> the output, so that they can specify DOUBLE, STRING etc.
>
> What about choosing the type of the input as well?
>
> How many inputs and outputs?
>
> "mosub" currently has 6 string outs, 6 double outs and allows
> for 12 double in's and 1 string in. We have to be a bit careful
> here as the Capfast symbols can become enormous.
This is still throwing out ideas to think about.
How about having 6 inputs and 6 outputs. Record support does nothing
with these links but lets subroutine do everything. Each associated
input/output value field is marked as SPC_DBADDR. The record support
routine cvt_dbaddr just passes the call on to the subroutine (as
an aside a subroutine should be accessed via a DSET and the DSET name
is what the application developer sets in the record).
This allows the following:
Thye subroutine support can turn each field into any standard type
(DBF_STRING, ...., DBF_DOUBLE). In addition it can support arrays for any
input or output. It can even use fields as inp/out or have all inputs
or all outputs (This will confuse database config tools however and should
be discouraged).
Thus means that the subroutine package has to do more work then existing
subroutines but it sure does make for a very general subroutine record.
Marty Kraimer
- Navigate by Date:
- Prev:
Re: ezcaIDL vs CaIDL Ben-chin K. Cha
- Next:
Monitoring and Archiving more than 1 value Andy Foster
- 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:
New Subroutine Record Andy Foster
- Next:
Has anyone integrated the Heurikon "NITRO 60" 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
|