Feature #20111

Add clock type to event specification

Added by Richard Neswold 9 months ago. Updated 9 months ago.

Work in progress
Start date:
Due date:
% Done:


Estimated time:
(Total: 0.00 h)


There have been discussions that it would be useful to specify which clock system to use for data acquisition. We have several clock systems in different areas of the Lab so a given clock event could have different meanings (because we only have 256 events per clock.) The proposal is to add an optional field to the DRF2 clock event specification specifying which clock is to be used for data collection.

e,{event},{hard/either},{delay},{clock type}

Where "clock type" could be tclk, lclk, pclk, or nclk. To preserve backward-compatibility, if no clock type is specified, the front-end will use its clock.

A front-end would only be expected to support one clock system. A MOOC front-end is usually installed near its equipment and would only have access to the clock system available there. If a different clock was requested, the front-end can return the (new) status, MOOC_CLOCK_NOT_SUPPORTED. Theoretically, a MOOC front-end could use the multicast clock to collect data for events on a non-local clock system. However, because different clock systems aren't correlated with each other, it's not clear if adding this flexibility would be worth the effort..

Erlang front-ends, on the other hand, are mostly located in the Computer Room and communicate with hardware over the network. There may be valid situation where, on a given Erlang front-end, one driver is communicating with hardware on one clock system and another driver uses hardware on a different clock. The Front-end Group will have to decide how to configure drivers to only use a particular clock system. The Erlang sync library will also need to be upgraded to listen to all multicast clocks.

This issue will track the subtasks needed to complete this project.


MOOC Framework - Feature #20112: MOOC needs to support the enhanced clock event specificationNew

TCLK Infrastructure - Feature #20113: Support the extended clock specificationAssignedRichard Neswold


#1 Updated by Richard Neswold 9 months ago

  • Due date set to 06/07/2018

due to changes in a related task: #20112

#2 Updated by Richard Neswold 9 months ago

  • Description updated (diff)

Changed the meaning when no clock type is specified.

#3 Updated by Richard Neswold 9 months ago

  • Due date set to 06/07/2018

due to changes in a related task: #20113

Also available in: Atom PDF