Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: EPICS base V4
From: Benjamin Franksen <benjamin.franksen@bessy.de>
To: Andrew Johnson <anj@aps.anl.gov>
Cc: Marty Kraimer <mrk@aps.anl.gov>, Eric Norum <norume@aps.anl.gov>, Jeff Hill <johill@lanl.gov>, Ralph Lange <Ralph.Lange@mail.bessy.de>, Bob Dalesio <bdalesio1@comcast.net>, Ned Arnold <nda@aps.anl.gov>, Matej Sekoranja <matej.sekoranja@ijs.si>
Date: Thu, 24 Feb 2005 12:22:43 +0100
On Thursday 24 February 2005 00:52, Andrew Johnson wrote:
> Proposal for V4:
>
> Change the way in which records are executed, allowing the database
> designer to select which threads perform processing of particular
> sets of records.

General comment: very good idea.

> In V3 we create a thread for each scan period, plus a number of other
> threads for callbacks etc. so the thread that a record processes in
> is vaguely related to its SCAN and PRIO fields.  I propose changing
> menuScan so it only contains "Passive", "Event", "I/O Interrupt" and
> "Periodic".  We add another field which is a double called scanPeriod
> which can be set to any period in seconds (this two-field approach is
> analagous to "Event" and the old EVNT field). 

The data type of the new scan specification is quite naturally expressed 
as an algebraic data type (=tagged union). In Haskell I would write

data Scan = Passive | Event Int | Interrupt | Periodic Double

In dbd syntax this could look like:

union(scanSpec) {
    choice(scanPassive,"Passive")
    choice(scanEvent,"Event") {
        field(event,octet)
    }
    choice(scanInterrupt,"Interrupt",)
    choice(scanPeriodic,"Periodic") {
        field(rate,float)
    }
}

(I took the freedom to allow leaving out an empty pair of braces "{}". 
This makes the union notation compatible with the one for menus, which 
are a special case of unions where all choices are tags only without 
data.)

One more comment on event scanning. Currently events are specified by a 
number between 0 and 255. This has many obvious disadvantages. I think 
for V4 we should consider supporting event identification by name, 
rather than number. The above would then become

union(scanSpec) {
    ...
    choice(scanEvent,"Event") {
        field(event,string)
    }
    ...
}

Ben


References:
EPICS base V4 Marty Kraimer
Re: EPICS base V4 Andrew Johnson

Navigate by Date:
Prev: Re: EPICS base V4 Andrew Johnson
Next: memory management Jeff Hill
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: EPICS base V4 Andrew Johnson
Next: Re: EPICS base V4 Ralph Lange
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·