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
Page 31
32
Page 32
33
Page 33
34
Page 34
35
Page 35
36
Page 36
37
Page 37
38
Page 38
39
Page 39
40
Page 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
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
Page 33/102

Download datasheet (2Mb)Embed
PrevNext
Über die Schnittstellenkarten
7.9.2 Timing von Telegrammen
Singlecast:
Nach jeder Anfrage benötigt das Gerät typisch 5ms und
maximal 50ms für eine Antwort. Grundsätzlich darf unmit-
telbar nach der Antwort wieder gesendet werden. Nach dem
Empfangen eines Ereignisses (Antworten ohne Anfrage)
muss mindestens 50 ms gewartet werden. Empfohlen wird
eine Zeit von 100 ms, damit das Gerät nicht zu sehr durch
die Kommunikation ausgebremst wird.
Bei der Gateway-Funktion (nur PSI9000) muß zudem die
Übermittlung der Telegramme von einem Bussystem auf das
andere Bussystem berücksichtigt werden. Hier kann sich die
Antwort bis zu 00 ms verzögern.
Nach dem Empfangen einer Fehlermeldung sollte minde-
stens 100ms gewartet werden.
Broadcast:
Nach jeder Rundumanfrage können die Busteilnehmer nur
nacheinander antworten. Abhängig vom Bussystem, der
Baudrate und der Anzahl der angesprochenen Busteilneh-
mer, sowie dem zusätzlichen anderen Datenverkehr wird
sich die Antwort mehr oder weniger verzögern. Da die Zeit
nur individuell zu spezifizieren ist, kann sie in erster Annä-
herung mit Busteilnehmeranzahl * Antwortzeit beim Single-
cast angenommen werden. In den meisten Fällen wird die
Antwortzeit aber wesentlich kürzer sein.
7.10 Telegrammaufbau IF-G1
Der Telegrammaufbau für die textbasierende Kommunikation
über eine IEEE-Karte ist im Abschnitt 4.5.7 beschrieben.
7.11 Telegrammaufbau IF-E1
Die Netzwerkkarte arbeitet über den Ethernetport mit SCPI-
Befehlen, die mit VXI11-Protokoll transportiert werden und im
Abschnitt 4.5.8 beschrieben sind. Besonderheit ist hier, daß
es zwei zusätzliche SCPI-Befehle gibt, die ein Telegramm,
aufgebaut nach dem objektorientierten Kommunikationspro-
tokoll, transportieren können. Der Sinn dieses Befehls ist
es, Kommandos an das Gerät zu senden für die es keinen
entsprechenden SCPI-Befehl gibt. So kann man über das
binäre Protokoll z. B. den Funktionsmanager der Gerätese-
rien PSI 9000 und PSI 8000 steuern, laden und abfragen,
was mit SCPI-Befehlen nicht möglich wäre. Um dies zu tun
ist ein hexadezimales Telegramm mit dem Aufbau
DL, ON, DATEN
zu erstellen und mittels des SYST:DATA and das Gerät zu
senden. Wichtig! Alle Bytes müssen durch Kommas getrennt
angegeben werden.
DATEN
ist nur erforderlich, wenn ein
Werte oder mehrere an das Gerät gesendet werden.
Wir unterscheiden hier grundsätzlich zwischen Telegram-
men, die nur etwas senden (SYST:DATA:SET) und welche,
die etwas abfragen (SYST:DATA:REQ). Siehe Befehlsliste
im Abschnitt 4.5.8.
Bei einer Sendung gibt die Datenlänge DL an, wie lang
DATEN
in Bytes ist. Stimmt die Länge der tatsächlich ge-
sendeten Daten nicht mit der Angabe DL überein, wird ein
Fehler zurückgegeben.
© 009, Elektro-Automatik GmbH & Co. KG
Irrtümer und Änderungen vorbehalten
Bei einer Anfrage gibt die Datenlänge DL an, wieviele Bytes
erwartet werden. Dies ist nötig, weil unterschiedliche Gerä-
teserien unterschiedliche Objekte (Befehle) besitzen können
und der Anwender für das angesprochene Gerät und das
verwendete Objekt die Datenlänge aus der Objekttabelle
herauszusuchen und hier anzugeben hat. Objektlisten siehe
Abschnitt 9.3.
Eine falsch angegebene Datenlänge führt zu einem Fehler.
Beispiel zur Datenlänge bei einer Anfrage: es soll Objekt 0
angefragt werden (Gerätetyp). Die Antwort wäre ein String
mit der maximalen Länge von 16 Bytes (inlusive EOL-Zei-
chen). Also wird als Datenlänge 16 angegeben.
Der zweite Wert, ON, ist die Objektnummer. Diese stellt ein
Ziel dar für die nachfolgenden Daten. Objektnummer und
Daten bilden zusammen einen Stell-Befehl.
Über den USB-Port können Befehle nur mit dem binären
Protokoll (siehe Abschnitte 7.4 bis 7.8 und 9.) transportiert
werden, wie bei anderen digitalen Karten IF-U1 und IF-R1.
7.11.1 Telegrammbeispiele
Beispiel 1:
Es soll die Bytefolge 0x4700 als Spannungssollwert trans-
portiert werden. Laut der Objektliste für z. B. ein PSI 9000
Gerät ist der Spannungssollwert Objekt 50.
Der sich dann ergebende SCPI-Befehl könnte so aussehen:
SYST:DATA:SET,50,71,0
Alternativ kann die Angabe in Hexadezimalform erfolgen:
SYST:DATA:SET#H0,#H3,#H47,#H00
Beispiel 2:
Es sollen die Istwerte angefragt werden. Dazu wird eine
Anfrage (Request) gestellt. Laut Objektliste ist Objekt 71 zu
nehmen, die Anzahl der angefragten Bytes ist 6. Die Anfrage
sieht dann also so aus:
SYST:DATA:REQ6,71
Das Gerät antwortet dann z. B. 6 Bytes in dezimaler Form:
67,37,1,17,4,16
Zwei Bytes ergeben jeweils einen 16Bit-Wert, der einen
Istwert in Prozent darstellt. Die sechs Bytes ergeben in he-
xadezimaler Form und jeweils zusammengefaßt:
0x435, 0x157F, 0x1810
In der festgelegten Reihenfolge ist der erste der Spannungs-
istwert, der zweite der Stromistwert und der dritte der Lei-
stungsistwert. Umrechnung der Prozentwerte in Realwerte
siehe Abschnitt 7.7.
DE
33