EA-IF-C2 EA ELEKTRO-AUTOMATIK, EA-IF-C2 Datasheet - Page 33

• Manufacturer Part Number: EA-IF-C2
• Description: INTERFACE CAN (EA-PSI/BCI 800 R)
• Manufacturer: EA ELEKTRO-AUTOMATIK

Specifications of EA-IF-C2

• Accessory Type: Interface Card
• 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
Irrtümer und Änderungen vorbehalten
Ü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.
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
sendeten Daten nicht mit der Angabe DL überein, wird ein
Fehler zurückgegeben.
in Bytes ist. Stimmt die Länge der tatsächlich ge-
DATEN
ist nur erforderlich, wenn ein
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