Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 14 Dec 2007 10:26:06 -0600

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.

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).

- Andrew

-------- Original Message --------
Subject: Re: Timing/Event Systems
Date: Fri, 14 Dec 2007 09:58:51 -0600
From: Ron Rechenmacher <[email protected]>
Reply-To: [email protected]
To: Dalesio, Leo `Bob` <[email protected]>

CC: Kazuro FURUKAWA <[email protected]>, Andrew Johnson

<[email protected]>, Frank Lenkszus <[email protected]>, [email protected],

[email protected], [email protected]

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 ([email protected] and [email protected]) 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: [email protected] on behalf of Kazuro FURUKAWA
Sent: Fri 12/14/2007 5:45 AM
To: Andrew Johnson
Cc: Frank Lenkszus; [email protected]; [email protected]; [email protected]; 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 <[email protected]> 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 <[email protected]>
 Linac&KEKB,  High Energy Accelerator Research Organization (KEK), Japan
 Telephone: +81-29-864-5200 x4316,  Facsimile: +81-29-864-0321

--
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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System