How to use WhiteRabbit Timing @GSI

1. In the instantiation document: Select "WhiteRabbit" as timingDomain and choose a WhiteRabbit accelerator for your device (A number of test accelerators is available):

   <device-instance name="myDeviceNomenklatur">
      <configuration>
         <description value="This is a WhiteRabbitDevice" />
         <accelerator value="WhiteRabbit-pLinac#123" />
         <timingDomain value="WhiteRabbit" />
         <mainMuxCriterion value="USER" />
      </configuration>
      ...

2. Choose one (or more) of the WhiteRabbit-events in the events-mapping (currently there are 10 different test-events provided to choose from)

         <events-mapping>
           <myLogicalEvent>
             <event-configuration name="MyEventConfig">
                <Timing>
                   <hardware-event name="WhiteRabbit-CycleStart#44" />
                           <hardware-event name="WhiteRabbit-SomeOtherTestEvent#2" />
                </Timing>
             </event-configuration>
             <event-configuration name="MyEventConfig2">
                <Timing>
                   <hardware-event name="WhiteRabbit-SomeOtherTestEvent#2" />
                </Timing>
             </event-configuration>
             ...

3. Work with the payload of the WR-event in the RT-Action
   • Please refer to the according code snippets
4. (optional) Add a trigger to the ECA to directly trigger hardware on an incoming event:

   void RTDeviceClass::specificInit()
   {
       GSI_ECA::Event eventFilter = 123;   // filter to specify for which event(s) to listen
       GSI_ECA::Time offset = 0;           // offset for the event, max 8ns
       GSI_ECA::Channel channel = 0;       // PCI_EXPRESS = 1 (software-interrupts are reserved for FESA) .. ask the Timing-Team for possible other channels
       uint8_t relevantFilterBits = 12;    // Bits which will be used for filtering in "eventFilter" (fesa uses first 32bits for eventID) maschineID-filtering is not used yet.
       fesaGSI::TimingEventSourceWR::registerHardwareTrigger( eventFilter, offset, channel, relevantFilterBits );
   }

5. Start FESA-class with application-argument "-WR" to use the TimingEventSourceWR

   from FESA3 1.2.2 on: start_<deply-unit name>_<X>.sh -f "-usrArgs -WR"

6. Trigger local-event on the ECA for testing purposes:

   [root@scul022]$ eca-ctl dev/wbm0 send 0x0000002c00000042 0x12343456 0xabd +1
   This would configure the ECA to launch event 44(2c) with the payload 0x12343456 0xabd in 1sec ( you can as well put absolute timestamps here! Ask Wesley for details)
   "42" could e.g. be a BeamProcessID. FESA assumes to find the EventNo in the first 32bits.

7. Trigger local event on the ECA for testing purposes:

   [root@scul022]$ eca-ctl dev/wbm0 send 0x1ec0b0400000002 0x12343456 0xabd +0.1
   
   0x1ec0b04000000002 translates to: trigger event Timing::WhiteRabbit-CycleStart#44 with sequence ID 1024, beam process ID 0, group ID 492, format  ID 0, sequence counter 2  

8. What does not work currently:
   • multiple fesa-binaries on the same maschine. FESA has to be the one and only user of the ECA ! It will stay like that, until there is a timing-daemom and a SAFT-lib, provided by the Timing-group.
   • meaningful machine-names and event-names in the Instantiation-file (TimingConfigurationWR.xml). Can be added as soon as CCT/LSA provides info about it.