Feature #20111

Updated by Richard Neswold over 1 year ago

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 the default value for the clock type is specified, the front-end will use its clock. would be *@tclk@*.

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.