EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: enhanced seq record
From: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Tue, 31 Jan 2006 03:05:29 +0100
On Monday 30 January 2006 12:16, Luedeke Andreas wrote:
> Benjamin Franksen wrote:
> >[...] Other comments/ideas are welcome, too, of course.
>
> A simple but powerful enhancement would be a copy
> of the OOPT field of the "calcout" record:
> a field for each LNKn input, that specifies conditions
> under which the output link is processed.
> ("On Change", "When Zero", "Transition to ...")
> This would allow to specify conditional execution chains
> to simplify database design.

I find it an interesting idea. However...

What would you suppose should be done when the value has type string and 
OOPT is e.g. "When Zero"? Should the string be converted to a number? 
But then, what if the conversion fails? Zero?

BTW, I have some esthetical problems with OOPT. The selection of 
possible conditions seems arbitrary. I would rather have a field where  
can give a boolean expression. OTOH, that would mean to program yet 
another calc record and I am not inclined to do so. (Those of you who 
read core-talk, remember my proposal for re-usable record type building 
blocks?)

So many choices...sigh.

> Of course the same can be done already with "calcout" chains.
> But a single record to control a sequence would simplify matters.

One problem with calcout chains is that using many calcout records with 
CPP input links cause problems during startup. We have an application 
that heavily uses calcout records and which collects a large number of 
values from all over the facility. Due to not yet completely understood 
interactions some of the calcout records do not get processed properly 
when many of the IOCs that provide these values boot at the same time. 
SOmehow events get lost or s.l.t. I remain sceptical if someone asks me 
to use a whole bunch of calcouts just so that I can place conditions on 
processing output links. I'd rather use an SNL program, if only SNL 
were not that ugly and feel a little less heavy-weight (and did not 
need even more records to get working).

Ben

References:
enhanced seq record Benjamin Franksen
Re: enhanced seq record Luedeke Andreas

Navigate by Date:
Prev: Re: mallocMustSucceed( 0 ) non-portable Eric Norum
Next: Re: mallocMustSucceed( 0 ) non-portable Till Straumann
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: enhanced seq record Brian McAllister
Next: Re: enhanced seq record Brian McAllister
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·