One disadvantage of this method is that if you ever want to change the scan
rate, the change needs to be coordinated between different records. Having
a process chain with only 1 record setting the scan rate makes it easier if
you ever foresee someone else wanting to change the scan rate.
--
Rodney R. Porter
X-Ray Nanoprobe Software Engineer
Advanced Photon Source Sector 26
Center for Nanoscale Materials
Argonne National Laboratory
On 11/2/07 9:01 AM, "Heinrich du Toit" <[email protected]> wrote:
> 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
>>
>>
>
- Replies:
- Re: lexical analyzer for .db? Ralph Lange
- References:
- Re: lexical analyzer for .db? Heinrich du Toit
- Navigate by Date:
- Prev:
Re: question about iocConsole Ralph Lange
- 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
- Navigate by Thread:
- Prev:
Re: lexical analyzer for .db? Ralph Lange
- 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
|