User manual
44
© 2007, Elektro-Automatik GmbH & Co. KG
EN
About the interface cards
ensure the proper transport of the communication data of
our system. These routines are not offered by us. Sample
code is available on the web site of the vendor FTDI, at www.
ftdichip.com. The USB chip is named FT232B
7.5 Structure of the communication
The communication with the controlled units is based on
these telegram types:
a) Simple message: an object is sent, which shall for instance
set the output voltage. As long as this action is permitted by
the current state of the device, the object is accepted and
executed. The device won’t send any answer. If it’s not per-
mitted it will send an answer, an error message.
b) Request: a request is sent by using a certain object, for
instance „get actual values“, and an answer is expected. If
the request is permitted for the current state of the device
it is executed and answered. The answer contains the re-
quested data. If not permitted it will send an error message
as answer.
c) Event: is an error message, which is sent by the device
without request, for example if the access to an object is not
permitted or if the previous message was not recognized by
any reason, like if it was crippled by external interferences.
Contains an error code.
7.6 Telegram structure IF-R1 and IF-U1
The interface cards IF-R1 and IF-U1 are using the same
telegram structure, the one of the CAN card IF-C1 is diffe-
rent. Read below if you‘re using a IF-C1 card. At the serial
transmission of one byte with the RS232 card following bits
are sent:
Start bit + 8 Data bits + Parity bit + Stop bit
The parity is checked for odd.
The USB card is internally working with the RS232 charac-
teristic For both card types it is required to set at least these
transmission parameters for the particular driver:
Baud rate: 57600kBd
Parity: odd
Stop bits: 1
The telegram is structured like this
SD+DN+OBJ+Data+CS
and is built by these bytes:
Byte 0: SD (start delimiter)
The start delimiter determines how to handle the telegram
furthermore. Meaning of the bits:
Bits 0-3
Denethedatalength-1ofthedatainthetelegram.
At an request the data length of the expected data is
given here.
Bit 4
0= Telegram from device to control unit
1= Telegram from control unit to device
Bit 5
0=
Singlecast, telegram to a certain device node
1= Broadcast/Multicast, telegram to all device nodes
Bits 6+7
00 = Reserved
01 = Request for data
10 = Answer to a request
11 = Send data (without previous request)*
* can also occur from the device
Byte 1: DN (device node)
The device node identifies and adresses devices inside a
bus system. Each node number must only be assigned once.
This is used to address a particular device.
Value range: 1...30, others are invalid.
Byte 2: OBJ
The communication objects for a device are addressed by
this byte. In the communications object list (see section 9)
the objects and its function(s) are explained in detail.
Byte 3 - 18: Data field
The data field can be 1-16 bytes long, hence the length of
the telegram varies. If a request 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 at byte 3. 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 (Big Endian Order).
Example of a telegram:
Object no. 71 (request 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 2400W 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.