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 2025 | 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 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: synchronizing data to an event |
From: | Ralph Lange <[email protected]> |
To: | [email protected] |
Cc: | EPICS Tech Talk <[email protected]> |
Date: | Wed, 07 Nov 2007 15:56:44 +0100 |
Hi Ron, 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 |