lowCAL - Partial implementation of the CAN application layer

Introduction

lowCAL is one of the CAN Bus protocols that are implemented in MultiCAN.

It implements a part of the CAN Application Layer (CAL), specifically the CMS protocol for all types of integer variables. lowCAL also implements multiplex variables where the first byte of the data frame is an index for an array of variables.

CAN Application Layer (CAL) was superseded by CANOpen. This new communication standard for the CAN bus contains a part of the old CAL-CMS specification, so lowCAL is still needed when you communicate with newer CANOpen devices.

To use CANOpen. you need:

• for PDO variables: lowCAL with variables of type ‘basic write-only’

• for SDO variables: sdo - CANOpen SDO objects for MultiCAN

Defining lowCAL records

To use lowCAL in an EPICS record you have to set the following fields:

• DTYP : set this to “lowcal”

• INP / OUT : set this to a string that specifies the CAN bus link

• SCAN : for input records set this to “I/O Intr”

The CAN bus link definition

Note

A utility for encoding/decoding LowCAL links is part of bii_scripts. The utility is ‘canlink.pl’ and described here: canlink.pl.

For LowCAL that string has the following syntax. Like for all strings in these fields the first character is ‘@’. It is followed by the first character describing attributes of the LowCAL variable. These are the meanings of the several permissible characters:

Character	User type	Class	Access type
a	Client	Basic	Read-only
b	Client	Basic	Write-only
c	Client	Basic	Read-Write
d	Client	Multiplexed	Read-only
e	Client	Multiplexed	Write-only
f	Client	Multiplexed	Read-Write
g	Server	Basic	Read-only
h	Server	Basic	Write-only
i	Server	Basic	Read-Write
j	Server	Multiplexed	Read-only
k	Server	Multiplexed	Write-only
l	Server	Multiplexed	Read-Write

The next character, separated with <space> from the first, specify the data type of the LowCAL variable as shown in the next table

Character	LowCAL Data Type
a	String
b	String being encoded or decoded by the device support
s	Signed Short
S	Unsigned Short
t	Array of Signed Short
T	Array of Unsigned Short
u	Raw Signed Short
U	Raw Unsigned Short
v	Array of Raw Signed Short
V	Array of Raw Unsigned Short
e	Signed Middle (24 Bit)
E	Unsigned Middle (24 Bit)
f	Array of Signed Middle (24 Bit)
F	Array of Unsigned Middle (24 Bit)
g	Raw Signed Middle (24 Bit)
G	Raw Unsigned Middle (24 Bit)
h	Array of Raw Signed Middle (24 Bit)
H	Array of Raw Unsigned Middle (24 Bit)
l	Signed Long
L	Unsigned Long
m	Array of Signed Long
M	Array of Unsigned Long
n	Raw Signed Long
N	Raw Unsigned Long
o	Array of Raw Signed Long
O	Array of Raw Unsigned Long
c	Signed Character
C	Unsigned Character
d	Array of Signed Character
D	Array of Unsigned Character

The different arrays of long can only be used with basic variables because 8 is the maximum number of bytes you can transmit with one CAN data frame.

The succeeding 10 hexadecimal integers are separated with <space> and have the meaning as shown in that table:

• Maximum length of data in byte to transmit with that object id (COB) on the CAN bus. If you use multiplexed variables, one byte for the multiplexor is to be added to the size of the chosen data type. All multiplexed variables using the same CAN object id (COB) must have the same maximum length.

• The port number on the CAN card depending on the jumper settings of that card

• CAN object id (COB) of the outgoing object

• CAN object id (COB) of the incoming object

• The multiplexor

• The inhibit time is the minimum time to elapse between the sending of CAN objects with the same CAN object id. The time t results from the input value multiplied with a constant of 100μs.

• The timeout value refers to confirmed or remote LowCAL services and can be adjusted in a resolution of 1ms.

• The meaning of that integer depends on the record type and the LowCAL data type. For mbbiDirect and mbboDirect record it represents a shift value which is explained in MultiCAN design If the LowCAL data type is an array it represents the size of the array.

Not for all LowCAL variable types all parameters are necessary but the device support for LowCAL expects all above mentioned entries in the string. Not needed parameters should be set to ‘0’.

Here is an example of an hardware link to LowCAL with the following attributes:

“@f S 3 2 101 c1 a 5 1f4 0”

• Client / Multiplexed / Read-Write

• Multiplexor 10

• Unsigned Short

• Maximum length of 3

• Port 2 / Out-id 257 / In-id 193

• Inhibit time of 500μs

• Timeout value of 500ms