EA-IF-E2

Manufacturer Part NumberEA-IF-E2
DescriptionINTERFACE ETHERNET (EA-PSI/BCI800R)
ManufacturerEA ELEKTRO-AUTOMATIK
EA-IF-E2 datasheet
 


Specifications of EA-IF-E2

SvhcNo SVHC (18-Jun-2010)Accessory TypeInterface Card
ApplicationsEngineering Laboratory And Complex Industrial ApplicationApproval BodiesCE / EN
Rohs CompliantYesFor Use WithEA Elektro-Automatik PSU
Lead Free Status / RoHS StatusLead free / RoHS Compliant  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
Page 81
82
Page 82
83
Page 83
84
Page 84
85
Page 85
86
Page 86
87
Page 87
88
Page 88
89
Page 89
90
Page 90
91
92
93
94
95
96
97
98
99
100
101
102
Page 85/102

Download datasheet (2Mb)Embed
PrevNext
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,
is always possible. The devices don‘t require the remote
mode.
- Setting of status and set values (controlling) requires the
activation of the remote mode (remote in this case means
that the device is remotely controlled via a digital interface
card)
- The remote mode can be blocked by certain circum-
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.
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.
© 009, Elektro-Automatik GmbH & Co. KG
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
Bits 0...3: 1 = two bytes are sent
Bit 4: 1 = direction from PC
Bit 5: 0 = Singlecast
Bits 6+7: 11 = Send data
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
Send data or
0x40
Query data
and the cast type is either
0x00
Singlecast or
0x20
Broadcast
and the direction is either
0x10
from PC to the device or
0x00
from device to the PC
and the data length - 1 can be
0x00...0x0F up to 16 bytes of data (at CAN see „7.6.1
Splitted messages“)
Always note, that the data length is defined as number
of bytes to send -1!!!
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
D1 05 36 10 00 01
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“.
EN
1C. The
85