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[eV] = TICE/1000000 |
|
TICG |
any positive integer |
gap[mm] = TICG/1000000 |
|
TICS |
any integer |
shift[mm] = 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 |
|
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 |
2 |
gap 2 [mm] * 1.E6 |
100 ms or 50 ms |
CICS |
3 |
shift 1 [mm] * 1.E6 |
100 ms or 50 ms |
CICS2 |
4 |
shift 2 [mm] * 1.E6 |
100 ms or 50 ms |
CICE |
6 |
energy [eV] * 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”.