WR-MIL Gateway

Introduction

The White Rabbit to MIL gateway can work in one GID only. Its main features are.

• listen to so-called legacy event numbers, Evtno 0..255
• convert received timing messages to MIL telegrams following a defined mapping
• on-time, send the converted MIL telegrams to the MIL Eventbus
• generate so-called UTC telegrams; this is triggered via a special timing message
• deprecated: if required, generate so-called 'fill events'

Presently (2024) nine MIL Event bus domains exist at GSI. The corresponding timing group IDs are

• PZU_QR, UNILAC Timing - Source Right
• PZU_QL, UNILAC Timing - Source Left
• PZU_QN, UNILAC Timing - Source High Charge State Injector (HLI)
• PZU_UN, UNILAC Timing - High Charge State Injector (HLI)
• PZU_UH, UNILAC Timing - High Current Injector (HSI)
• PZU_AT, UNILAC Timing - Alvarez Cavities
• PZU_TK, UNILAC Timing - Transfer Line
• SIS18_RING, SIS18 Ring, includes some timing messages for HEST
• ESR_RING, ESR Ring

More background on MIL telegrams is available here.

A dedicated How-To can be found here.

The MILbus is a single master bus. Here, the master is an SCU. The cable from the SCUs connects to hardware driver modules. Each module drives one MIL strand. A MIL strand is mainly one big cable with a driver at the start and a terminator at the end. Converter boxes (aka 'Blechdose') are inserted into the MIL strand, the whole strand is basically a daisy chain. Each converter box has multiple outputs (differential LEMO) to which clients - TIF, SEs ... - are connected.

A test setup consists of an SCUs, a MILbus cable, a converter box and a MIL slave.

A very simple test setup consists of an SCU, to which a MIL slave is connected via a special cable.

Figure: Connections between SCU and converter box.

Some remarks

MIL telegrams have 20 bits in total, 16 data bits plus 4 bits for manchester encoding. Bus speed is 1 MHz. Thus sending a MIL telegram takes 20 us. However, MIL protocol has no built-in 'balancing' such as the 8b/10b encoding done with Ethernet. To be on the safe side, it is assumed that a 5us pause is required between MIL telegrams. Thus, it takes 25us for transmitting one MIL telegram.

Figure: Typical MIL telegrams have a jitter (max,min) of about 3us.

Setup

An SCU is used as target platform. To guarantee on-time generation of MIL event telegrams, shared resources (MIL task ram, SCU bus, Wishbone bus, ...) are avoided by using one SCU per MIL event bus (= MIL timing domain).

Bugs

During the beamtime 2021, several reports of missing MIL events appeared. For example, the electron cooler in ESR was sometimes not switched off because of a missing event. The reason for the missing events is not found yet. This is a collection of observations related to the missing events. It may help in finding the cause of the probelm.

• The WR-event that corresponds to a missing MIL-event is definitely there. The events are not missing in the schedule of the Data Master.
• The conversion of a WR-event into MIL-event happens in an LM32 program. The LM32 sends MIL-events with the correct deadline into the ECA, these events have the ID=0xffffffff0000MMMM, where M represents the bits of the MIL-event. The ECA-WB-Master output channel writes the MIL-event into the MIL-Piggy. By configuring the ECA-IO channel to pulse one of the SCU-IOs at the same event, it can be seen that the firmware indeed injects the event into the ECA. However sometimes the MIL-Piggy doesn't send anything. The Missing Events can be observed on the oscilloscope.
• 
• It is unclear why this happens. Speculation: the MIL-Piggy doesn't accept that WB-Write from the EAC-WB-Master output channel for some reason, or the WB-Master output channel has a bug and doesn't execute the WB-write, or the MIL-Piggy accepts the WB-write but has a bug and doesn't send the MIL-Event. => Make a SignalTap that targets the WB-interfaces of ECA-WB-Master output channel and the WB-interface of the MIL-Piggy
• The MIL-Events of the prduction systems (SIS18 and ESR) in BG2.009 have glitches after the last Manchester-bit. This doesn't seem to be a problem because it always happens after the last bit (the parity bit). These glitches do not appear on a similar setup in my office. The reason/source of the glitches is not located yet.
• 
• The rate of missing events depends on the schedule, but approximately every 30-60 minutes a MIL event is lost. Often the missing MIL-events are not essential for machine control (e.g. missing UTC timestamp bits). Missing MIL events that are important appear a few times per day.

-- DietrichBeck - 14 Nov 2024