EA-IF-PB1 EA ELEKTRO-AUTOMATIK, EA-IF-PB1 Datasheet - Page 85

• Manufacturer Part Number: EA-IF-PB1
• Description: PSU, INTERFACE, PROFIBUS
• Manufacturer: EA ELEKTRO-AUTOMATIK

Specifications of EA-IF-PB1

• Accessory Type: Interface Cards
• 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

© 009, Elektro-Automatik GmbH & Co. KG
Programming
9. Communication without LabView
9.1 General
The following sections deal about the composition of the
communication telegrams, the dependency of the commu-
nication from the state of a device and the problems related
to that topic, without explaining how to use the USB driver
when using the USB card or how to build a complete CAN
message when using the CAN card. This has to be learned
and done by the user.
9.1.1 Note about the driver library
On the included CD, in the folder \manuals\other\ftdi, there
is a PDF, that describes the functions of the USB driver in
detail. In general it applies that a device, in this case the USB
hardware, has to be opened first (FT_Open or similiar), then
configured (FT_SetBaudRate, FT_SetDataCharacteristics
etc.) and then written (FT_Write) or read (FT_GetQueueSta-
tus, FT_Read). As soon as the device is not used anymore
it is advised to close it (FT_Close), while it is advised not to
open and close it for every read-write cycle. Configuration of
the USB hardware needs to be done only once as long as it
is powered. The functions FT_Write and FT_Read serve to
transport the actual telegram bytes of the object orientated
communication described in the following sections.
9.2 Guide to create telegrams
The programming of the various devices, in which the in-
terface cards are used, always follows the same scheme. It
only differs in number and functionality of the communication
objects that are supported by a specific device series.
Generally applies:
- Monitoring, i.e. only querying actual values and status,
- Setting of status and set values (controlling) requires the
- The remote mode can be blocked by certain circum-
In order to start controlling a device, for example by sending
a set value, you need to
1. activate the remote mode (object 54)
2. send the set value
3. set the output/input to on (if not already)
The remote mode should be left again, if not used any further.
As long as it is active, the device can not operated manually
or only restrictedly. The mode is indicated in the display.
is always possible. The devices don‘t require the remote
mode.
activation of the remote mode (remote in this case means
that the device is remotely controlled via a digital interface
card)
stances. For instance, the explicit local operation (only
PSI 9000) or a different mode the device is in and which
does not allow remote control. For further details refer to
the user manual of your device.
Example 1: Activating the remote via IF-R1/IF-U1
According to the telegram format (also see 7.5), the first byte
is the start delimiter, which depends on the type and direction
of the telegram. For this example the SD will be 0xD1, and
look like this in single bits :
11 01 00 01
Alternatively to the bitwise assembly, this can be simplified
by using hex values. Starting from bits 6 + 7 we get:
SD = Message type + Cast type + Direction + Length
whereas the message type is either
0xC0
0x40
and the cast type is either
0x00
0x20
and the direction is either
0x10
0x00
and the data length - 1 can be
0x00...0x0F up to 16 bytes of data (at CAN see „7.6.1
Splitted messages“)
The address (node) of the contacted device is 5, the object
to use is 54 (in hexadecimal 0x36), the mask for the remote
mode (also see table in section 9.3) is 0x10 and the control
byte for remote mode is also 0x10. Then we get this tele-
gram:
D1 05 36 10 10 01 2C
In order to reverse this command, means deactivation of the
remote mode, you need to send
mask stays the same, only the control byte changes.
Example 2: Querying actual values via CAN card
Using CAN, the start delimiter SD and the check sum CS,
are not used. So we only need the object, according to the
table it is 71 (hex = 0x47), the identifier ID (for calculation
example see section 7.6) and the length of the bytes to send.
In a CAN message, the object is included in the data length,
so this message would have a data length of 1, because
we only send the object that queries the actual values. The
device address (node) is 5, the RID is 8. According to the
formula from section 7.6 the identifier calculates as 8 * 64
+ 5 *  +1 = 53 (hex = 0x0B). The +1 is because it is a
message of type „query“.
Always note, that the data length is defined as number
of bytes to send -1!!!
Send data or
Query data
Singlecast or
Broadcast
from PC to the device or
from device to the PC
Bits 0...3: 1 = two bytes are sent
Bit 4: 1 = direction from PC
Bit 5: 0 = Singlecast
Bits 6+7: 11 = Send data
D1 05 36 10 00 01
1C. The
EN
85