EA-IF-C2 EA ELEKTRO-AUTOMATIK, EA-IF-C2 Datasheet - Page 82

• Manufacturer Part Number: EA-IF-C2
• Description: INTERFACE CAN (EA-PSI/BCI 800 R)
• Manufacturer: EA ELEKTRO-AUTOMATIK

Specifications of EA-IF-C2

• Accessory Type: Interface Card
• Svhc: No SVHC (18-Jun-2010)
• Applications: Engineering Laboratory And Complex Industrial Application
• Approval Bodies: CE / EN
• Rohs Compliant: Yes
• For Use With: EA Elektro-Automatik PSU
• Lead Free Status / RoHS Status: Lead free / RoHS Compliant

About the interface cards
© 009, Elektro-Automatik GmbH & Co. KG
Byte 3 - 18: Data field
The data field can be 1-16 bytes long, hence the length of
the telegram varies. If a query is sent (PC -> device) and no
data is sent, the data range is not used and the checksum of
the telegram (see below) follows directly after byte . Only if
an answer (device -> PC)is sent, even if it is an event, there
will be data of a specific length.
Word x: CS (check sum)
The check sum is always located at the end of the telegram.
It is built by the simple addition of all bytes of the telegram.
It is two bytes long. The high byte is placed before the low
byte.
Example of a telegram:
Object no. 71 (query actual values) shall be sent to a de-
vice with device node 1. The telegram has to look like this
(hexadecimal values):
55 01 47 00 9D
The expected answer could look like this:
85 01 47 64 00 1E 00 50 00 01 9F
(this results in 80V, 30A and 400W at a 80V, 100A and
3000W power supply, like for example the PSI9080-100)
Also see next section for the conversion of set values and
actual values.
More examples in section 9.
7.9 Message structure for the IF-C1
The interface card IF-C1 supports the CAN V.0a standard.
The extended address format is not used.
The CAN driver chip requires the identifier, up to
bytes
is 11 bits long (CAN .0a) and specified by the
the relocatable identifier segment (RID) and the type of the
message. For every unit we define two identifiers (see also
section 4.3.1):
[RID*64 +
[RID*64 +
whereas the first identifier is used for „send only“ messages
and the second one (+1) for query messages.
A message can contain a maximum of 8 bytes. The first byte
is the number of the communication object. After this you can
put up to 7 data bytes (see communication object list).
In order to send an object with a 16 bytes long data field
it is thus required to send at least three message and the
data field has to be split up over those three messages. See
below for more.
The data length is only related to the telegram that is about
to be sent (or received) next. In a CAN telegram there are
basically up to 8 bytes transmittable. See also the section
about split telegrams.
and the
device node
device node
data length
* ] and
*  + 1],
for a transmission. The
device
identifier
8 data
node,
Two examples:
a) the device has to be set to remote mode. This is required
to control the device by a status command or to set values.
The
sage is of „send only“ type. The identifier calculates as 3
* 64 + 15 *  = 
According to the object list in section 9 we use object 54
(hex: 0x36) with the data bytes 0x10 (mask) and 0x10 (set
remote). The resulting data length is 3. The CAN message
requires these bytes:
ID DL
DE 03
In case you don‘t want to set the state, but query it, the
identifier 0xDF is used (query type= +1) and because it is
a query, the object alone is sufficient as data. The bytes for
the CAN message are like this:
DF 01 36
and the answer should be like this:
DF 01 36 10 10
7.9.1 Split messages
A split message is a message, which is split into multiple
messages (only possible for objects in „string“ format). After
the object number (=object address) an extra identifier is
inserted. The extra identifier of the first message is 0xFF,
for the second message it is 0xFE and 0xFD for the third
one. The order of these messages is not specified. The
telegram has to be composed again later from these mes-
sages. When using the gateway function the split telegrams
are not composed by the gateway. This has to be done by
a superior control unit.
7.9.2 Timing of messages
Singlecast :
After every query the device typically needs between 5ms
and maximum 50ms for the answer. Basically you are allowed
to send queries directly after another. But if an event was
received it is required to wait at least 50ms. A time of 100
ms is recommended in order to not slow down the device’s
operation by too heavy communication.
When using the gateway function you need to consider the
time that will be consumed by transferring the telegram from
one bus system to the other. The answer may be delayed
up to 00ms here.
After receiving an error message over this gateway you
should consider to wait at least 100ms until the next trans-
mission.
device node
DATA
36 10 10
was set to 15 and the
D
or 0xDE after to the above formula.
RID
to 3. The mes-
EN
8