User manual

ManualsBrandsEA ELEKTRO-AUTOMATIK ManualsPower Supplies & Mains AdaptersEA-IF-R1 RS-232 Interface

About the interface cards

7.6.1 Translating set values and actual values

The set values and actual values (see communication object

list) are, with a few exceptions, transmitted as percentage

values, whereas 0x6400 corresponds to 100%. If a device

has a nominal voltage of 80V and the queried actual value

is 0x3200 (0x32 = 50 = 50%) then it corresponds to 40V

output voltage.

The high byte is the percentage number (0x64 = decimal

100) and the low byte is the decimal place of it. You need to

translate the outgoing set values and the incoming actual

values before they can be used.

Nom. value * Percentage act. value

Actual value =

25600

Example: Nom. value of the device is 80V, the percentage actual value

came in as 0x2454 = 9300. It results in: Actual value = (80 * 9300) /

25600 = 29.06V

25600 * Set value

Percentage set value =

Nom. value of the device

Example: the set value for voltage shall be 25.36V, the nom. value of the

device is 80V. With the formula it results in:

Percentage set value = (25600 * 25.36) / 80 = 8115 = 0x1FB3.

You need to, of course, round the decimal value for the hex value.

7.7 Message structure for the IF-C1

The interface card IF-C1 supports the CAN V2.0a standard.

The extended address format is not used.

The CAN driver chip requires the identifier, up to 8 data

bytes and the data length for a transmission. The identifier

is 11 bits long (CAN 2.0a) and specified by the device node,

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 + device node * 2] and

[RID*64 + device node * 2 + 1],

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.

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 device node was set to 15 and the RID to 3. The mes-

sage is of „send only“ type. The identifier calculates as 3

* 64 + 15 * 2 = 222

or 0xDE after to the above formula.

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 DATA

DE 03 36 10 10

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.7.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.7.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 200ms here.

After receiving an error message over this gateway you

should consider to wait at least 100ms until the next trans-

mission.