MIL Event Telegram Format

Introduction

The 'old' GSI control system used a field bus that is an extension of the MIL STD 1553 field bus [1]. At GSI, this 'MIL bus' is used for two distinct use-cases.
  • MIL Event bus
    • used as a field bus for the old timing system
    • distribution of timing telegrams, so-called events, to the devices
    • one master
    • many fat long 'twinaxial' lines with distribution boxes
    • receivers, so-called Timing Interfaces 'TIF' connected via two-pin Lemo
    • only sending of telegrams by a bus-master
    • no limit on the numbers of receivers (in principle)
  • MIL Device bus
    • used as a field bus for communication
    • supplying devices with set-values and reading information from the devices
    • MIL device bus cable with 9-pin sub-D plug
    • one master
    • up to 127 (or 256?) devices
    • devices connected via daisy-chain
    • master sends information to devices
    • master may request 'read' information from devices

This page summarizes the format of telegrams used by the MIL Event bus. There is lots of information at many different places. As an introduction, the reader may have a look at [2,3]. However, some of the information given in [2,3] is out of date.

A telegram on the MIL event bus has 16 bits of payloads. Added Manchester code makes it 20 bits on the bus. The bus provides a rate of 1 MBit/s, thus a telegram takes 20us of time. However, there are no measures providing DC balance in transmission as it is done by the 8b/10b encoding used in telecommunication protocols such as Ethernet. Thus, a gap must be foreseen between transmission of telegrams.

The old GSI timing system ('Pulszentrale') used a minimum gap of 10us, thus at most one telegram can be sent every 30us.

Today it is assumed that a 5us gap is sufficient which allows sending one telegram every 25us.

As there is lots of 'old' equipment that still needs to be supplied with timing, the MIL event bus is still in use at GSI. Today and for the next years. So called 'White Rabbit to MIL Gateways' (wr-mil) are used as masters, sending event telegrams to the MIL event bus.

Format of a MIL Event Telegram

A telegram has 16 bits of data. The first 8 bits are used as 'Event Code'. Event code describes an activity: what to do. The second 8 bits contain data: how to do.

mil-event-format_general.png
Figure: General format of a timing message.

Remark: At GSI the 8 bit of event code provides a range of 0..255. The new White Rabbit based timing system provides 12 bit providing a range of 0..4095. These numbers are called 'event numbers' and a list is provided here. The range 0..255 provided by the MIL event bus is directly mapped into the first 256 event numbers. Thus the range
  • 0..255 is used for MIL timing (sent through the White Rabbit network)
  • 256..4095 is used for the new 'White Rabbit' timing

Usually, the 8 bit of data are split into two parts of 4 bit each.

mil-event-format_normal.png
Figure: Usual format of a timing message

The following sub-sections will present the formats used at GSI. The format depends on the event number. The event number is always coded into bits 0..7.

Normal Event

  • event numbers: all, except 0d200..208 (0xc8..d0) 0d224..228 (0xe0..e4), 0d255(0xff)
  • bits 8..11: virtual accelerator
  • bit 12: unused
  • bit 13: 'high-brho' (rigid beam)
  • bit 14: 'no beam'
  • bit 15: 'high current'
All data provided by timing schedule through UNIPZ or Data Master.

Remark: The value of bit 14 'no beam' is set during run-time depending on the setting of the chopper. Some mechanism should be implemented, that sets the value of this bit depending on the status of the chopper. This is important in the case of UNILAC, as profile grids are typically triggered with every virtual accelerator execution.

Why? When the 'Profilgitterschutztaste' is pressed, the schedule is changed (and chopper) and grids are measuring with each virtual accelerator execution. However, the chopper is not opened with every virtual accelerator execution, but only sometimes (maybe once per second). The 'no beam' flags marks virtual accelerator executions without beam, where data of profile grid shall not be processed.

See here on the mapping from White Rabbit timing message to MIL telegram.

UTC Event

  • events EVT_UTC1..5, 0d224..228, 0xe0..e4
  • bits 8..15: 8 out of 40 bits

This is rather special. Here, a time decoded into 40 bits in a special format is sent via 5 subsequent timing telegrams. This sequence is triggered by
  • SIS18, ESR: EVT_BEGIN_CMD_EXEC (0d246, 0xf6)
  • UNILAC: EVT_COMMAND (0d255, 0xff)
The White-Rabbit MIL gateways issue this series of 5 telegrams autonomously. These telegrams are neither scheduled nor is the value of the time stamp supplied by the settings management.

EVT_COMMAND

  • event number 255
  • bits 8..11: virtual accelerator
  • bits 12..15: 'Pulszentralenkennung'
    • 1, SIS18_RING
    • 2, ESR_RING
    • 9, PZU_QR
    • 10, PZU_QL
    • 11, PZU_QN
    • 12, PZU_UN
    • 13, PZU_UH
    • 14, PZU_AT
    • 15, PZU_TK
    • (see /common/usr/cscofe/opt/devacc/pro/include/dprsystem.h)

  • old control system (UNIPZ): The values are part of the schedule data
  • new control system (LSA): not clear

In case of event number 0d255 (0xff), all WR->MIL Gateways set the values for bit 12..15 to the 'Pulszentralenkennung'.

Deprecated

Special Command Events

  • event numbers 0d200..0d208, 0xc8..d0
  • bits 8..15: data
These event numbers are unsupported , since 8 bits are required but the settings management of the new control system just supplies 4 bits.

Remark: In case this event would be used, the WR->MIL gateways set the bits 8..15 to 0x00.

EVT Prep Next Acc

This old format for this event is no longer used. It has been replaced by the standard format of the other standard event numbers.

In old format [2] for this event has been:
  • event number EVT Prep Next Acc, 0d16, 0x10
  • bits 8..11: virtual accelerator
  • bit 12..14: virtual accelerator is executed
    • 0: normally
    • 1: without chopper
    • 2: with short chopper
  • bit 15: high-current

UNIPZ Internal Event Bus

UNIPZ has an internal MIL event bus. This is only relevant for UNIPZ and WR-UNIPZ but not relevant for the UNILAC Controls Upgrade (ICU). The following telegrams are used.

Synch Data'

Used to synchronize settings after fresh data supply

  • event number 0d32
  • bits 8..15: don't care

50 Hz Sync

Used to trigger the start of a new 20ms UNILAC cycle
  • event number 0d33
  • bits 8..15 don't care

Next Cycle

Used to announce which virtual accelerator shall be played in which MIL domain
  • event number PZ1..7, 0d1..7 (1: PZU_QR, 2: PZU_QL...)
  • bits 8..11: virtual accelerator
  • bit 12: channel number (this selects 'normal chopper' and 'short chopper' operation)
  • bit 13: no chopper ; the value of this bit is copied to bit 14 of a MIL timing telegram (= 'no beam')
  • bit 14: short chopper; I believe this is redundant
  • bit 15: 0 (if this bit is not '0', the other bits have a different meaning)

Service Event

Used to trigger the generation of so-called 'Service Events' that are not part of the pre-configured schedules.
  • event number PZ1..7, 0d1..7 (1: PZU_QR, 2: PZU_QL...)
  • bits 8..11: virtual accelerator
  • bits 12..14:
    • '111': triggers transmission of EVT_MAGN_DOWN after the end of the current cycle
    • '110': triggers transmission of EVT_AUX_PRP_NXT_ACC after the end of the current cycle
    • '101': triggers immediate transmission of EVT_AUX_PRP_NXT_ACC
    • '100': triggers immediate transmission of EVT_UNLOCK_ALVAREZ
  • bit 15: 1 (if this bit is not '1', the other bits have a different meaning)

Tables

Mapping between Settings and MIL Event Telegrams

A dedicated meeting has been executed [5]. However, not all aspects have been covered in this meeting. However, the actual status in the facility is more elaborated

MIL Telegram Type Message Source Event Code Bits 8..15 Bits 8..11 Bits 12..15 Remark
Normal Event UNIPZ bits 0..7 of Event Sequence N/A virt acc, bits 8..12 of Evt Seq beam status; bits 12, 13 and 15 of UNIPZ Evt Seq bit 14 'no beam' is copied from bit 13 of Super-PZ 'Next Cycle' telegram
  Data Master bits 0..7 of EvtNo of EvtId N/A virt acc, bits 0..3 of SID of EvtId beam status; bits 0..3 of WR EvtId ICU is expected to provide relevant and up-to-date information
'UTC Events' WR-MIL Gateway bits 0..7: 0xe0..0xe4 time data N/A N/A automatic generation by WR-MIL gateways; SIS18, ESR: triggered by EvtNo 0xf6; PZU_..: trigger by EvtNo 0xff
EVT_COMMNAND UNIPZ bits 0..7 of Event Sequence N/A virt acc, bits 8..12 of Evt Seq 'PZ Kennung', bits 12..15 of UNIPZ Evt Seq  
  Data Master bits 0..7 of EvtNo of EvtId N/A virt acc, bits 0..3 of SID of EvtId 'PZ Kennung' value of 'PZ Kennung' filled autonomously by WR-MIL gateways
0d200..0d208 N/A bits 0..7 of EvtNo of EvtId 0x0 N/A N/A unsupported, as EvtId just provides four bits [5]
Table: Mapping between Settings and MIL Event Telegrams.

Communication on the Internal MIL Event Bus of UNIPZ

This table shows the MIL Telegrams on the internal MIL Event bus of UNIPZ. The telegrams are received by the seven (MIL) Unterpulszentralen and the (virtually) seven WR-UNIPZ Unterpulszentralen. The MIL Unterpulszentralen push the MIL telegrams to the seven MIL Event bus directly. The WR-UNIPZ Unterpulszentralen send the data coded into White Rabbit timing messages ahead of time. The WR-UNIPZ provides White Rabbit timing to the UNILAC network as long as UNIPZ is in use. Optionally: physically seven White Rabbit -> MIL Gateways (WR-MIL) push the MIL telegrams to the seven MIL Event buses at UNILAC. Once UNIPZ will be replaced within the ICU, the usage of the seven WR-MIL gateways is mandatory.

Bits Sync Data 50 Hz Sync Next Cycle Service Remark
0..7 0d33 0d33 0d1..7 0d1..7 'Next Cycle', 'Service': bits decode number of 'Unterpulszentrale' (PZU_QR, ...)
8..11 unused unused virt acc virt acc  
12 unused unused Kanalnummer    
13 unused unused no chopper   the value of this bit must be copied on-the-fly to bit 14 of 'normal' MIL Event telegrams
14 unused unused short chopper    
15 unused unused 0 1 bit 15 is used to decode the message type 'Next Cycle' or 'Service'
12..14 unused unused   0b111: EVT_MAGN_DOWN after the end of the current cycle  
        0b110: EVT_AUX_PRP_NXT_ACC after the end of the current cycle  
        0b101: EVT_AUX_PRP_NXT_ACC now (!)  
        0b100: EVT_UNLOCK_ALVAREZ now (!)  
12..15 unused unused 0x1: 2nd channel 0xf: magn down bits 12..15 can be ORed for 'Next Cycle'
      0x2: no chopper 0xe: prep next bits 12..15 can be ORed for 'Next Cycle'
      0x4: short chopper 0xd: prep next now (!) bits 12..15 can be ORed for 'Next Cycle'
        0xc: unlock A4 now (!) bits 12..15 can be ORed for 'Next Cycle'
Table: MIL Telegrams used on the internal MIL Event bus of UNIPZ.

Further Reading

[1] https://de.wikipedia.org/wiki/MIL-STD-1553

[2] https://www-acc.gsi.de/data/documentation/eq-models/pzus/gm-pzus.pdf

[3] https://www-acc.gsi.de/wiki/pub/Timing/TimingSystemHowWRUniPZ/090119TimingGSI.pdf

[4] P. Kainberger, private communication

[5] https://www-acc.gsi.de/wiki/ProjectMgmt/MappingWrMilSisEsrUnilac

-- DietrichBeck - 15 Jul 2024
Topic revision: r8 - 2024-11-05, dbeck - This page was cached on 2024-12-15 - 13:23.

This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding GSI Wiki? Send feedback | Legal notice | Privacy Policy (german)