Re: [Fwd: Re: Timing/Event Systems]

[Korhonen Timo <Timo.Korhonen@psi.ch>]

Andrew Johnson wrote:
> ILC-Controls folk: I'm forwarding Ron Rechenmacher's message to the 
> EPICS developers who are working on an enhanced timing/event API that 
> will be included in EPICS Base R3.14.10.
>
> EPICS Guys:
>
> The ILC community are discussing timing/event systems, see the 
> messages forwarded below.
>
> Do any of you have a network (probably UDP-based) driver pair for the 
> (old or new) Event system?  I don't see any particular difficulty with 
> creating one that would plug in to the Time Governor code, but I don't 
> remember hearing anyone talking about having created one.
Not at the moment (unless somebody has written such one and forgotten to 
tell :-) ). However, writing such a driver would not
be a big deal, for most of the functionality. I would need to take a 
close look at some of the issues. I would like to revise
some of the concepts with the drivers anyway (since many years...)


> That brings up another point for the Time Governor: should (do) we 
> have a standard API for event generators?  IIRC the Time Governor 
> stuff is currently just for event receivers, does it make sense to add 
> an API call for event system drivers that generates a particular event 
> number?  This obviously isn't going to be useful for high precision 
> timing, but it could be useful, including as a way to implement a 
> 'time distribution over event system' time driver in a generic manner 
> (although that would almost certainly break compatibility with 
> existing clients).
The Time Governor has also a part for event generators, at least in our 
(Babak's) version. We have a mixture of  (SLS) 'old' and 'new' (Diamond 
& later) event
cards and need to distribute some global time information over the 
network (and also keep the event time in sync with wall clock time with 
a servo loop.)
Adding an API call to generate an event number is simple, but it is not 
obvious for me at the moment how that could be used in time distribution 
(it is late Friday afternoon over here ...)

By the way, I could not resist to comment on this:
> The jitter and the drift with this system are several of 10ps

There must be something wrong with the setup (I am not sure whose 
comment this was...) we get a jitter well below 10 ps, measured with a 
LeCroy SDA6000 (and the 230-series EVG/EVR).  Long-term drift can of 
course depend on many issues, mainly (ambient) temperature change, but 
we have not seen any problems with this at SLS, and when the devices are 
operated in steady state.

best regards,

Timo

ps. And yes, the Micro-Research system is indeed the result of evolution 
from the Fermilab-APS line. We at SLS took the APS system
as a reference, redesigned it (with Micro-Research) so that we could use 
it for all timing including injection. For Diamond we then collaborated
and had a chance to implement many things which were not possible or 
feasible at the time we were building SLS.  Shanghai Light Source is
indeed using  them, as well as the Australian Light Source. All these 
places have contributed several good ideas along the way :-)


> - Andrew
>
> -------- Original Message --------
> Subject: Re: Timing/Event Systems
> Date: Fri, 14 Dec 2007 09:58:51 -0600
> From: Ron Rechenmacher <ron@fnapcf.fnal.gov>
> Reply-To: ron@fnal.gov
> To: Dalesio, Leo `Bob` <dalesio@slac.stanford.edu>
> CC: Kazuro FURUKAWA <kazuro.furukawa@kek.jp>, Andrew Johnson 
> <anj@aps.anl.gov>, Frank Lenkszus <frl@aps.anl.gov>, mcclure@fnal.gov, 
> kucera@fnal.gov, ilc-controls@fnal.gov
>
> Hi,
>
> I suggest to anyone on this list that can influence the development of 
> the
> interface software that the software be constructed in such a way as 
> to allow
> (either as a compile time config or a runtime config) a way to work 
> without
> the hardware (simulation mode -- perhaps allowing for stimulus via 
> network
> messages). CERN has recently added such capability to their front end 
> software
> environment - see 2nd dark bullet on the 3rd page of:
>    http://ics-web4.sns.ornl.gov/icalepcs07/WOPA04/WOPA04.PDF
> I've been thinking about this for several years and I thing such thinking
> ultimately can facilitate collaboration on such system.
>
> --Ron
>
>
> > LCLS is using this timing on RTEMS. Contact Dayle Koturi or Till 
> > Straumann (dayle@slac.stanford.edu and Strauman@slac.stanford.edu) It 
> > was installed and ported there with much help from Timo and Eric.
> >
> > At NSLS II we are considering a modification of this approach as we 
> > are looking to develop a standard data and timing distribution to 
> > embed into our FPGA based device controllers. We are working in 
> > concert with Larry Doolittle at LBL while inclulding Timo at SLS, 
> > Jukka at Micro Research, and Rok Ursic at I Tech (libera BPM folks).
> >
> > Bob
> >
> >
> > -----Original Message-----
> > From: owner-ilc-controls@listserv.fnal.gov on behalf of Kazuro FURUKAWA
> > Sent: Fri 12/14/2007 5:45 AM
> > To: Andrew Johnson
> > Cc: Frank Lenkszus; mcclure@fnal.gov; kucera@fnal.gov; 
> > ilc-controls@fnal.gov; Kazuro FURUKAWA
> > Subject: Re: Timing/Event Systems
> >  
> > Hello,
> >
> > Discussion with Ron Rechenmacher and other Fermilab people were very 
> > interesting.  Thank you Ron.
> > We have started some software evaluation based on the discussion. But 
> > is may take time.
> > For the Event system;
> >
> > As far as I understand, Timo at SLS (Swiss light source) took the 
> > idea of the event/timing system from APS/ANL and designed his event 
> > system for SLS, EVG/EVR-100 series.  Later for Diamond light source 
> > he designed the modules with newer technologies, EVG/EVR-200 series. 
> > It should have much potential, and Jukka at MRF reported on the 
> > possible embedded EPICS on RTEMS on PowerPC on EVG230.  (We normally 
> > don't use that PowerPC, yet.)
> >
> > The event rate is around 100MHz depending on the rf frequency, we can 
> > transfer 2kbyte of information at the rate of ~100MHz/2000, which is 
> > fast and large enough for most applications to provide additional 
> > beam information.
> > The system is used at Diamond and BEPCII at IHEP-Beijing.  We hope to 
> > utilize it at our running machine, KEK Linac, from the next summer.  
> > It is also planned to be used or is evaluated at many places 
> > including LCLS, LANL, Shanghai, SNS(?), BNL(?).  The current 
> > developer of the EPICS device support is Eric Bjorklund at LANL. 
> > The jitter and the drift with this system are several of 10ps, and we 
> > will keep some of the old but more precise system for some areas. 
> > However, most of the signals will be replaced with outputs from this
> > system.
> > This week, we are evaluating the new device support from Eric on 
> > VxWorks collaborating with people from IHEP, Ms. Lei and Mr. Xu.  
> > Hopefully, the next week we will evaluate its new functionality soon, 
> > and maybe with RTEMS as well.  (Although we didn't succeeded in 
> > building it on RTEMS.)
> >
> > Regards.
> > >>> On Thu, 13 Dec 2007 11:52:30 JST,  Andrew Johnson 
> > <anj@aps.anl.gov> wrote;
> > > Frank Lenkszus wrote:
> > > > > > I took a quick look at the Micro-Research web site. I'm not 
> > sure what > > the genesis of their event system is but it looks very 
> > familiar and > > interesting. What I can tell you is Fermi Lab 
> > published an event system > > several years ago. We at APS looked at 
> > what they had done and developed > > what we considered a higher 
> > performance system suitable for general > > timing at the APS in the 
> > very early 90's. Our implementation added > > features such as 
> > synchronized time stamping for record processing. > > Subsequently 
> > SLS took the APS design, updated it and increased the speed > > by 
> > ~x10 while maintaining the programming model. I believe the SLS > > 
> > version became commercially produced but I don't recall the firm name.
> > > > I'm not sure if they were the original, but Micro Research are 
> > the > current suppliers, so this is the great**N grand-son of the APS 
> > Event > System, versions of which have been used at various 
> > accelerators around > the world since we gave away the design.  EPICS 
> > support is pretty much > guaranteed with any version.
> > > > - Andrew
> > > -- > When a distinguished but elderly scientist states that 
> > something is
> > > possible, he is almost certainly right.  When he states that something
> > > is impossible, he is very probably wrong.  -- Arthur C. Clarke
> >
> > -----
> > Kazuro FURUKAWA <kazuro.furukawa@kek.jp>
> >  Linac&KEKB,  High Energy Accelerator Research Organization (KEK), Japan
> >  Telephone: +81-29-864-5200 x4316,  Facsimile: +81-29-864-0321


--
Timo Korhonen  PSI (Paul Scherrer Institut, http://www.psi.ch) 
              CH-5232 Villigen PSI 
              tel + 41- 56 3103262  fax + 41 - 56 310 3383 
e-mail:	       timo.korhonen@psi.ch