The Monochromator CAN bus interface specification

Preface

WUP, the Wigggler/Undulator Protocol is a protocol based on a subset of CAL, the CAN application layer .

The implementation of a subset of this protocol at the HZB is called “lowCAL” which is part of MultiCAN, the CAN Bus device support for EPICS that was developed at the HZB.

lowCAL can use the first byte of a CAN data frame as a “multiplexor”. By this mechanism, a single CAN Object or a pair of CAN Objects can be used to transport many different parameters, each with it’s own multiplexor.

In particular, with respect to the monochromator undulator communication, all CAN variables are of type “multiplex read/write”. This means that the a CAN data frame has 5 bytes, where the first byte is the multiplexor, the following four bytes are an integer in little endian byte order.

For more details see CAN application layer chapter 4 “CMS Variable Protocols”, sub section 4.5 “Read/Write Access, Multiplexed Variables”.

Node-ID

The Node-ID together with the Channel-id determines the CAN Object IDs (COBs) that are used for the communication. How to calculate COBs from Node-IDs and Channel-IOs is described at CAN Object ID conventions at the HZB.

With the Wigggler/Undulator protocol, only two Node-IDs are defined, one for the undulator IOC (ID-IOC) and one for the monochromator IOC (MC-IOC).

Note

On most beamlines, there actually is more than one monochromator, but only one at a time should communicate with the undulator. All monochromators have an identical Node-ID, but all but one must remain strictly silent on the CAN Bus and not write any CAN messages. Currently, this is archived by disabling records in the monochromator control program dependent on the position of the split mirror unit.

NODE

Node-ID

Name

ID_IOC

10

Insertion Device (Undulator-) IOC

MC_IOC

20

Monochromator IOC

CONFMESSAGE

This is the confirmed message that is used to transport information from the insertion device to the monochromator. With respect to the lowCAL protocol, the server for this lowCAL read/write variable is the monochromator IOC. This means that the monochromator IOC doesn’t make requests but waits for the undulator IOC to provide the data.

The channel ID (CID) together with the Node-ID (NID) determines the CAN Object IDs of the read- and write object according to CAN Object ID conventions at the HZB.

The incoming COB and outgoing COB are just shown for convenience, they can be calculated from NID and CID. “incoming” and “outgoing” are terms that relate to the variable server, the monochromator IOC.

Basic properties:

property

value

lowCAL variable type

read/write, multiplexed

data type

signed long

NID (node ID)

MC_IOC

CID (channel ID)

5

incoming COB

724

outgoing COB

660

Fields:

FIELD

multiplexor

description

update

STAT

0

status (gap)

every 5s or on change

ERR

1

error (gap)

every 5s or on change

RES

2

reserved

SSTAT

3

status (shift)

every 5s or on change

SERR

4

error (shift)

every 5s or on change

CNT

6

run-counter (gap)

every 1s or on change

SCNT

7

run-counter (shift)

every 1s or on change

RM_SW

8

remote/local switch

every 5s or on change

RL_SW

9

R/L switch

every 1s or on change

DMODE

10

drivemode (gap)

every 5s or on change

SDMODE

11

drivemode (shift)

every 5s or on change

Field values:

Field

possible values

STAT

see status codes

ERR

see error codes

PARAMETER

This is the confirmed message that is used to transport information from the monochromator insertion device to the monochromator. With respect to the lowCAL protocol, the server for this lowCAL read/write variable is the undulator IOC. This means that the undulator IOC waits for the monochromator IOC to set parameters.

The channel ID (CID) together with the Node-ID (NID) determines the CAN Object IDs of the read- and write object according to CAN Object ID conventions at the HZB.

The incoming COB and outgoing COB are just shown for convenience, they can be calculated from NID and CID. “incoming” and “outgoing” are terms that relate to the variable server, the undulator IOC.

Basic properties:

property

value

lowCAL variable type

read/write, multiplexed

data type

signed long

NID (node ID)

ID_IOC

CID (channel ID)

4

incoming COB

586

outgoing COB

522

Fields:

FIELD

multiplexor

description

CMD

0

command

TICE

2

target energy

TICG

3

target gap

SCMD

4

shift command

TICS

5

target shift

RL_SW

6

R/L switch

VEL

11

velocity

SVEL

12

shift velocity

SPEED

15

dynamic speed

TABMD

16

table mode

COUPLE

17

couple

Field values and constants:

Field

name

value

description

CMD SCMD

STOP

10

stop movement

START

11

start movement

TICE

any positive integer

energy= TICE/1000000

TICG

any positive integer

gap= TICG/1000000

TICS

any integer

shift= TICS/1000000

RL_SW

L

1

select left undulator halve

R

2

select right undulator halve

RL

3

select both undulator halves

VEL SVEL

any positive integer

either an integer between 0 and 4000 or the velocity in mm/s * 1.E8. Which one depends on the configuration of the undulator.

SPEED

Usually two 16 bit numbers packed in a single 32 bit integer.

see dynamic speed

TABMD

OFF

0

see dynamic speed

ON

1

COUPLE

OFF

0

see dynamic speed

ON

1

Dynamic Speed

Here are the values for variables SPEED, TABMD and COUPLE:

name

multiplexor

type

description

SPEED

15

32 bit integer

bit 0-15: gap speed factor

0xFFFF is 1.0, 0x0000 is 0.0

bit 16-31: shift speed factor

0xFFFF is 1.0, 0x0000 is 0.0

TABMD

16

32 bit integer

0: Dynamic Velocity off 1: Dynamic Velocity on

COUPLE

17

32 bit integer

0: Couple Gap/Shift off 1: Couple Gap/Shift on

FASTMESSAGE

This is the confirmed message that is used to provide the monochromator IOC with the current position of the undulator. With respect to the lowCAL protocol, the server for this lowCAL write-only variable is the monochromator IOC.

The undulator IOC writes it’s positions with a rate of 10 or 20 Hz depending on the configuration of the undulator.

The channel ID (CID) together with the Node-ID (NID) determines the CAN Object IDs of the read- and write object according to CAN Object ID conventions at the HZB.

The incoming COB and outgoing COB are just shown for convenience, they can be calculated from NID and CID. “incoming” and “outgoing” are terms that relate to the variable server, the monochromator IOC.

Basic properties:

property

value

lowCAL variable type

write-only, multiplexed

data type

signed long

NID (node ID)

MC_IOC

CID (channel ID)

6

incoming COB

852

outgoing COB

788

Fields:

FIELD

multiplexor

description

update

CICG

1

gap 1 [mm] * 1.E6

100 ms or 50 ms

CICG2

1

gap 2 [mm] * 1.E6

100 ms or 50 ms

CICS

1

shift 1 [mm] * 1.E6

100 ms or 50 ms

CICS2

1

shift 2 [mm] * 1.E6

100 ms or 50 ms

Note

What “gap 1”, “gap 2”, “shift 1” and “shift 2” actually mean, depends on the configuration of the undulator. “gap 1” is always the current gap, “gap 2” is currently not used on any device. “shift 1” is on some devices the shift position. On other devices “shift 1” and “shift 2” are for example the “parallel shift” and the “antiparallel shift”.