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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: synchronizing data to an event |
From: | "Pearson, MR \(Matthew\)" <[email protected]> |
To: | "Ralph Lange" <[email protected]>, <[email protected]> |
Cc: | EPICS Tech Talk <[email protected]> |
Date: | Wed, 7 Nov 2007 15:30:15 -0000 |
Hi,
There's been a lot of work at CERN in this area for the LHC
experiments. They are currently commissioning a fibre optic "timing, trigger and
control" system. It broadcasts timing information (bunch freq and orbit
freq) multiplexed with addressable trigger and control signals (like 'reset',
'flush buffer', etc.). The trigger/control signals can be addressed
to sub-systems of each main detector (like silicon tracker readout system,
muon chamber readout system, etc.).
It provides the means to tie each data structure
collected to an event number (collision, or bunch in synchrotron world), as
well as distributing a trigger to multiple systems.
There's more info at:
(lots of papers and references at the
bottom)
Cheers,
Matthew Pearson
DLS Controls From: [email protected] [mailto:[email protected]] On Behalf Of Ralph Lange Sent: 07 November 2007 14:57 To: [email protected] Cc: EPICS Tech Talk Subject: Re: synchronizing data to an event the latest publication on the LANSCE (Los Alamos, not SLAC) "flavored beam" issues is Jeff Hill's poster/paper at the ICALEPCS a few weeks ago. Hope this helps... Ralph Ron Rechenmacher wrote: Hi, I did a search of tech-talk for: timing event synchronization The results along with my experience to date leads to the conclusion that synchronization by 8 byte time stamp is the only synchronization that CA currently provides. (please correct if wrong) The question: I was wondering if there has ever been any (perhaps behind the scenes) discussion of adding additional synchronization information to the Channel Access protocol? Perhaps, in addition to the timestamp, a "synchronizing event" structure, which would be NULL if not used, but would otherwise have an event type and event count. At some linear accelerator facilities, there has been a move toward counting RF pulses and associating data collection triggered by the RF pulse with that pulse count. Of course there would be a pulse count to time correlation also, but many people seem to embrace the main data association (in archived data) being with an event count. I've heard that there has been work on "beam flavors" at SLAC. (sorry if this is bogus information). But if in addition to a timestamp, data also has "flavor" information, then this could be considered a start to additional synchronization information? Has there been work on this? and if so, has any progress reports been published? Thanks, Ron This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom |