If you were going to do it that way you could use the PHAS
field to ensure that the calc records were processed later
in the scan than the inputs - thus processed up-to-date values.
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Heinrich du Toit
> Sent: 02 November 2007 14:02
> To: Eric Norum; EPICS tech-talk
> Subject: Re: lexical analyzer for .db?
>
>
> Hi
>
> Thanks for all your help
>
> Wonder why the FLNK isn't a direct DB link then if possible? (e.g.
> record inside same IOC)
> Does the fanout do it differently?
>
> What would you say about the idea of just putting all the
> inputs on SCAN
> = .2 second
> and then all the calc(out) rule records also on .2seconds SCAN ?
>
> The way I see it a calc record can then never work with a value older
> than .4 seconds... which is fine for the system I think.
>
> Can maybe just FLNK or fanout the critical stuff then
>
> -H
>
>
> Eric Norum wrote:
> > On Nov 2, 2007, at 8:30 AM, Ned Arnold wrote:
> >
> >>
> >> You may be able to eliminate the fanout records by careful
> design of
> >> forward links and/or input link flags (PP, CP, etc).
> >>
> >> For example, if the input record's forward link field
> referenced the
> >> calc record and the calc record's forward link field
> referenced the
> >> calcout record, all would process each time the input record
> >> processed ... without a fanout.
> >>
> >
> > Don't take this technique to extremes, though. I recall
> helping Steve
> > Shoaf diagnose problems with his database for a video switching
> > system. The database contained 128 records FLNK'd together. This
> > caused very weird IOC faults that we finally realized were
> caused by
> > stack overflow of the task processing the records -- 128 recursive
> > calls to the record processing routine forced the task
> stack pointer
> > past the end of the stack space.
> > --Eric Norum <[email protected]>
> > Advanced Photon Source
> > Argonne National Laboratory
> > (630) 252-4793
> >
> >
>
>
- References:
- Re: lexical analyzer for .db? Heinrich du Toit
- Navigate by Date:
- Prev:
Re: lexical analyzer for .db? Heinrich du Toit
- Next:
Re: lexical analyzer for .db? Emmanuel Mayssat
- 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:
Re: lexical analyzer for .db? Heinrich du Toit
- Next:
Re: lexical analyzer for .db? Ralph Lange
- 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
|