Details zum IEC Treiber
Dieses Kapitel wendet sich an fortgeschrittene WinCC OA Anwender, die Details zu den Übertragungsarten der Telegramme und deren Abbildung auf WinCC OA erfahren möchten.
Folgende Abbildung soll veranschaulichen wie eine ASDU (application service data unit, Dienstdateneinheit = Datenpaket) laut Norm aufgebaut ist. Die einzelnen Oktette der Adressen und Kennungen sind durch die Rechtecke dargestellt.
Gemäß den Normen besteht die Dienstdateneinheit (ASDU, application service data unit) aus dem Idenifikationsfeld der Dateneinheit mit:
-
Typkennung entspricht Art
-
Variable Strukturkennung erfolgt durch Treiber
-
Übertragungsursache (Cause of transmission)
-
Gemeinsame Adresse der ASDU entspricht der Common Address
-
Informationsobjekte: Die Oktetts der Adresse des Informationsobjektes entsprechen HB, MB und LB der Information Object Address. Die Informationselemente sind die eigentlichen Messwerte.
Insgesamt stellen sich die einzelnen Oktette der Telegramme wie in der Abbildung zusammen (ein Oktett entspricht einem Rechteck). Eine detaillierte Beschreibung der Oktette entnehmen Sie den Normen.
Im folgenden bedeutet UI[1..8] immer ein Byte mit einem Wertebereich 0 bis 255, UI[1] ist 2^0, UI[8] ist 2^7. BS[1], bedeutet genau ein Bit kann gesetzt sein an der ersten Stelle des Oktetts.
Typkennung = Art
Das Oktett der Typkennung legt Struktur, Typ und Format des folgenden Informationsobjekts fest.
Typkennung UI[1...8]<1..255>
| 2^7 | 2^0 |
<1..127>: kompatibler Bereich für Normfestlegungen
<128..135>: reserviert für Wegevermittlung von Nachrichten ("privater" Bereich)
<136..255>: für besondere Anwendungen ("privater" Bereich)
Welche Typkennungen in WinCC OA im Detail verwendet werden, entnehmen Sie dem Kapitel Kompatibilität.
Variable Strukturkennung
Die variable Strukturkennung enthält die Anzahl der Informationsobjekte oder -elemente und das SQ bit ("Single"/"Sequence"), das über die Adressierungsart der nachfolgenden Informationsobjekte oder -elemente informiert.
Oktett der Strukturkennung:
| SQ | 2^0 |
-
Anzahl: UI7[1..7]<0..127>: 0 bedeutet es ist kein Informationsobjekt enthalten, <1..127> die Anzahl der Informationsobjekte.
-
SQ: BS1[8]<0..1> Einzel/Folge
<0>: Adressierung eines individuellen Elements oder einer Kombination von Elementen aus einer Anzahl von Informationsobjekten gleichen Typs
<1>: Adressierung einer Folge von Informationselementen in einem einzelnen Objekt einer ASDU.
SQ<0> und N<0..127>: Anzahl der Informationsobjekte
SQ<1> und N<0..127>: Anzahl der Informationselemente in einem einzelnen Objekt einer ASDU
Die variable Strukturkennung wird vom Treiber gesetzt bzw. interpretiert. Das bedeutet, dass sie nicht parametriert werden muss und ist somit für den Anwender irrelevant.
Übertragungsursache (COT)
Die Übertragungsursache (spontan, periodisch etc.) leitet die ASDU zur Weiterbearbeitung an eine bestimme Anwendungsaufgabe (Programm). Das Oktett enthält Ursache, Bestätigung des Auftrages (positiv, negativ), ein Testbit (zur Prüfung der Übertragung ohne den Prozess zu beeinflussen) und die Herkunftsadresse:
| T | P/N | 2^5 | 2^0 | ||||
| Herkunftsadresse | |||||||
-
Ursache: UI6 [1..6]<0..63>; 0 nicht definiert, <1..63> Kennung der Ursache, <1..47> für den kompatiblen Bereich (gemäß der Norm), <48..63> privater Bereich für den besonderen Gebrauch
-
P/N: BS[7]<0..1>; 0 positive Bestätigung, 1 negative Bestätigung
-
T: BS[8]<0..1>; 0 keine Prüfung, 1 Prüfung
-
Herkunftsadresse: UI8[9..16]><0..255>; <0> nicht festgelegt, <1..255> Nummer der Herkunftsadresse
Die Definition für den kompatiblen Bereich entnehmen Sie dem Kapitel Kompatibilität. Weitere Details zu den Übertragungsursachen entnehmen Sie der Norm.
Die Übertragungsursache wird entweder vom Treiber automatisch definiert oder kann vom Anwender vorgegeben werden. Das automatische Verhalten wird wie folgt implementiert:
Bei Kommandos (C_* Telegramme), die der Treiber schickt, wird eine Übertragungsursache 6 (Aktivierung) eingesetzt. Wenn der Treiber Meldungen (M_* Telegramme) schickt, so ist die Übertragungsursache 3 (Spontan).
Die eingangsseitige Abbildung der Übertragungsursache ist folgendermaßen implementiert:
20 <= COT <= 36 ... Meldung aufgrund einer GA (GA Bit im PARA Panel ist gesetzt).
COT == 5 ... Meldung aufgrund einer Einzelabfrage (EA Bit im PARA Panel ist gesetzt).
andere COT ... Meldung spontan oder andere Ursache (kein Bit gesetzt).
Um zu unterscheiden, ob Meldungen (M_* Telegramme) normal von WinCC OA gesendet werden (d.h. Übertragungsursache spontan = 3) oder als Folge einer IGQ (Inverse General Query), gibt es den Config-Eintrag useCOTGQ (siehe auch Mögliche Config-Einträge des IEC Treibers). Wenn Wert des Config-Eintrags "Yes" ist (Default ist "No"), dann wird als COT (= Cause of Transmission) bei allen Meldungen, die aufgrund einer IGQ gesendet werden die Übertragungsursache 20 (abgefragt durch GA), bei Zählermeldungen 37 (abgefragt durch allgemeine Zählerabfrage) eingesetzt. Im Normalfall ist die Übertragungsursache 3.
Für die manuelle Abbildung der COT gibt es zwei Möglichkeiten:
Die Verwendung von Userbytes
Die Verwendung einer COT Adresse hat den Nachteil eines zusätzlich notwendigen DPEs inklusive spezieller COT Peripherieadresse (siehe Addresstyp in Panel zur Definition der Peripherieadresse).
Die COT Adresse
Ab WinCC OA Version 3.8 gibt es die Möglichkeit die "Cause Of Transmission" (COT) auf Userbytes abzubilden. Diese Methode sollte in Zukunft gegenüber der COT Adresse bevorzugt werden.
Um die COT und auch die Herkunftsadresse eingangsseitig auf WinCC OA abzubilden, müssen die Config Einträge UserByteCOT und UserByteOrigin auf die Nummer des zu verwendenden Userbytes gesetzt werden. Standardmäßig ist der Wert 0 und es erfolgt keine Abbildung. Mit den folgenden Config Einträgen wird die COT auf das Userbyte 3 und die Herkunftsadresse auf Userbyte 4 abgebildet.
UserByteCOT = 3
UserByteOrigin = 4
Damit Werte von Userbytes ausgangsseitig in das Telegramm eingebaut werden, sind die Config Einträge ConnUserByteCOT und ConnUserByteOrigin auf die Nummer des zu verwendenden Userbytes zu setzen. Es gilt wie bei der Abbildung der Quality mittels ConnUserByteQ, dass jede Änderungen des entsprechenden Userbytes (oder eines darin enthaltenen Userbit)s einen Hotlink auslöst und damit auch der Wert an die Peripherie verschickt wird. Um mehrfache Telegramme zu vermeiden, muss in einer Anwendung der _original.._value und das entsprechende _original.._userbyte<x> in einem dpSet() gesetzt werden. D.h. wenn z.B. der Wert, COT und die Herkunftsadresse im gleichem Moment geändert werden sollen, muss das in einem dpSet() geschehen, um Telegramme mit unerwünschten Zwischenzuständen zu vermeiden.
Kompatibilität COT Adressen Userbyte-Variante
Eingangsseitig:
Bisher war es möglich für die COT und Herkunftsadresse eine „COT Peripherieadresse“ zu parametrieren. Dies funktioniert weiterhin, auch wenn UserByteCOT bzw. UserByteOrigin ungleich 0 sind. Allerdings ist es nicht sinnvoll in einem neuen Projekt die Verfahren zu vermischen.
Ausgangsseitig:
Auch ausgangsseitig gab es bisher „COT Peripherieadressen“. Diese Adressen funktionieren nur noch, wenn ConnUserByteCOT und ConnUserByteOrigin auf 0 gesetzt sind. Ist ein Eintrag davon ungleich 0, so werden nur die Informationen aus den „user bytes“ in das Telegramm eingebaut.
Ist das Userbyte für die COT auf 0 gesetzt, so wird die Default COT vom Treiber verwenden.
Gemeinsame Adresse der ASDU = Region, Komponente
Die gemeinsame Adresse wird für alle Objekte innerhalb einer ASDU gemeinsam genutzt. Die globale Adresse ist eine an alle Stationen eines bestimmten Systems gerichtete Adresse.
Gemeinsame Adresse: UI8[1..16]<0...65535>
| 2^7 | 2^0 | ||||||
| 2^15 | 2^8 |
<0>: nicht benutzt
<1...65534>: Stationsadresse
<65535>: globale Adresse
ASDU mit einer "Adresse an alle" in Steuerungsrichtung müssen in Überwachungsrichtung mit ASDU beantwortet werden, welche die spezifisch festgelegte gemeinsame Adresse (Stationsadresse) enthalten.
Informationsobjekte = Information Object Address
Die Adresse des Informationsobjektes (1, 2 oder 3 Oktette) wird als Zieladresse in Steuerungsrichtung und als Quelladresse in Überwachungsrichtung benutzt. Je nach Zahl der Oktette ist die Adresse der Informationsobjekte:
| 2^7 | 2^0 | ||||||
| 2^15 | 2°8 | ||||||
| 2^23 | 2^16 |
UI [1...8]<1...255>: HB
UI [1-16]<1...65535>: MB
UI [1-24]<1...16777215>: LB
Einer detaillierte Beschreibung entnehmen Sie der Norm IEC 60870-5-104.
Anzahl an Ports und Wiederaufbau der Verbindung
Die theoretische Anzahl der Ports (seriellen Schnittstellen), die mit einem IEC 101 Treiber behandelt werden können, hängt von der Anzahl der möglichen seriellen Schnittstellen des betreffenden Betriebssystem zusammen. Für Windows ist die Anzahl auf 255 limitiert.
Die theoretische Anzahl der Slaves im unsymmetrischen Betrieb ist durch den maximalen Wert der Linkadresse vorgegeben.
Die Angaben sind deshalb "theoretisch“, da meistens aus Performance- oder anderen Gründen die maximale Anzahl nicht sinnvoll ist.
Im Falle einer unterbrochenen Verbindung zur Peripherie, versucht der Treiber periodisch die Verbindung zur Peripherie wiederherzustellen.
Generalabfrage
Automatische Generalabfrage beim Treiberstart bzw. bei Redundanzumschaltung IEC
Die Eigenschaften der automatischen Generalabfrage können mit dem Config Eintrag autoGQ bestimmt werden (Details siehe im Kapitel Mögliche Config-Einträge des IEC Treibers). Der 104 Treiber und der 101 Treiber verhalten sich bezüglich automatischer Generalabfrage identisch. Für die Funktion der Generalabfrage ist es notwendig, dass die Common Objekt-Adressen in der Lokalen/Globalen Liste explizit definiert sind, d.h. keine Wildcards vorhanden sind.
Zugriff auf verschiedene Telegrammtypen mittels Subindex
Die unten nachfolgende Tabelle enthält die Informationen, wie bei den unterschiedlichen Telegrammtypen mittels Subindex auf die, im Telegramm vorhandenen Felder zugegriffen werden kann. Dabei sind noch folgende Punkte zu beachten:
Quality Information
In Befehlsrichtung (sowohl C_* als auch M_* Telegrammtypen können in Befehlsrichtung geschickt werden) wird die Quality Information bei manchen Telegrammen als ODER-Verknüpfung des über Subindex angegebenen Wertes mit dem Wert aus der Adresse gebildet (z.B. M_SP_NA_1 oder C_SC_NA_1). Das ist in der Regel dann der Fall, wenn die Daten, oder ein Teil der Daten) und die Quality Information im selben Byte enthalten sind). Bei den anderen Telegrammen kann der Wert nur über die Quality Information aus der Adresse gebildet werden (z.B. M_BO_NA_1 oder C_SE_NA_1).
Wenn die Qualitätsinformation eingangseitig auf Userbits abgebildet wird, so werden die Userbits bei allen betroffenen Subindizes gesetzt.
DPE Typ
Der DPE Typ ist nicht notwendigerweise so wie in der Tabelle angegeben zu setzen, da auch eine Typkonvertierung stattfindet. So kann z.B. statt eines bool Typs auch ein int verwendet werden, der dann die Werte 0 oder 1 annimmt. Bei inkompatiblen Typen gibt es eine Fehlermeldung während der Transformation. Sinnvollerweise sollte man aber, wenn es keine anderen Gründe gibt, die Typen der Tabelle verwenden.
Spezielle Subindizes
Für manche Telegrammtypen gibt es spezielle Subindizes, die den Zugriff auf die Daten erleichtern. So ist es z.B. beim M_DP_NA_1 Telegramm möglich mit dem Subindex 8 auf das DPI Feld als "unsigned int zuzugreifen. D.h. man braucht nicht zwei DPEs für DPI bit 0 und DPI bit 1 zu definieren.
Ausgangsseitig wird der Wert des Userbytes aus einem Datenpunktelement mit niedrigstem Subindex auf die Datenpunktelemente mit höheren Subindizes geschrieben.
Bei der Definition der Peripherieadresse muss für die in folgender Tabelle aufgelisteten Telegrammtypen die Richtung mit "Ausgang (Gruppe)" parametriert werden!
| Telegramm | Transf. | Item | SI | DPE Type | Hinweis |
|
M_SB_NA_1 (1) M_SB_TA_1 (2) M_SB_TB_1 (30) |
SIQ | SPI | 0 | bool |
Eingangsseitig können BL, SB, NT und IV auch auf die entsprechenden Userbits abgebildet werden. Ausgangsseitig kann man die Qualitätsbits im Userbyte ConnUserByteQ setzen. |
| BL | 4 | bool | |||
| SB | 5 | bool | |||
| NT | 6 | bool | |||
| IV | 7 | bool | |||
|
M_DP_NA_1 (3) M_DP_TA_1 (4) M_DP_TB_1 (31) |
DIQ | DPI bit 0 | 0 | bool | |
| DPI bit 1 | 1 | bool | |||
| BL | 4 | bool |
Eingangsseitig können BL, SB, NT und IV auch auf die entsprechenden Userbits abgebildet werden. Ausgangsseitig kann man die Qualitätsbits im Userbyte ConnUserByteQ setzen. |
||
| SB | 5 | bool | |||
| NT | 6 | bool | |||
| IV | 7 | bool | |||
| DPI as uint | 8 | uint | DPI as unsigned integer, values from 0-3 | ||
|
M_ST_NA_1 (5) M_ST_TA_1 (6) M_ST_TB_1 (32) |
VTI | value | 0 | int |
Value Eingangsseitig können BL, SB, NT und IV auch auf die entsprechenden Userbits abgebildet werden. Ausgangsseitig kann man die Qualitätsbits im Userbyte ConnUserByteQ setzen. |
| T | 1 | bool | Display of Intermediate position | ||
|
M_BO_NA_1 (7) M_BO_TA_1 (8) M_BO_TB_1 (33) |
BSI |
bit[i]
|
0-31
|
bool |
Eingangsseitig können BL, SB, NT und IV auch auf die entsprechenden Userbits abgebildet werden. Ausgangsseitig kann man die Qualitätsbits im Userbyte ConnUserByteQ setzen. |
| OV | 32 | bool | |||
| BL | 36 | bool | |||
| SB | 37 | bool | |||
| NT | 38 | bool | |||
| IV | 39 | bool | |||
|
bit pattern
|
40 | bit32 | complete bit pattern | ||
|
M_ME_NA_1 (9) M_ME_TA_1 (10) M_ME_ND_1 (21) M_ME_TD_1 (34) |
NVA | value | 0 | float |
Eingangsseitig können BL, SB, NT und IV auch auf die entsprechenden Userbits abgebildet werden. Ausgangsseitig kann man die Qualitätsbits im Userbyte ConnUserByteQ setzen. |
| OV | 1 | bool | |||
| BL | 5 | bool | |||
| SB | 6 | bool | |||
| NT | 7 | bool | |||
| IV | 8 | bool | |||
| M_ME_ND_1 (21) | NVA | value | 0 | float | Bei Typ 21 gibt es keine Qualitätsinformation |
|
M_ME_NB_1 (11) M_ME_TB_1 (12) M_ME_TE_1 (35) |
SVA | value | 0 | int |
Eingangsseitig können BL, SB, NT und IV auch auf die entsprechenden Userbits abgebildet werden. Ausgangsseitig kann man die Qualitätsbits im Userbyte ConnUserByteQ setzen. |
| OV | 1 | bool | |||
| BL | 5 | bool | |||
| SB | 6 | bool | |||
| NT | 7 | bool | |||
| IV | 8 | bool | |||
|
M_ME_NC_1 (13) M_ME_TC_1 (14) M_ME_TF_1 (36) |
R32 | value | 0 | float |
Eingangsseitig können BL, SB, NT und IV auch auf die entsprechenden Userbits abgebildet werden. Ausgangsseitig kann man die Qualitätsbits im Userbyte ConnUserByteQ setzen. |
| OV | 1 | bool | |||
| BL | 5 | bool | |||
| SB | 6 | bool | |||
| NT | 7 | bool | |||
| IV | 8 | bool | |||
|
M_IT_NA_1 (15) M_IT_TA_1 (16) M_IT_TB_1 (37) |
BCR | counter value | 0 | int |
Eingangsseitig können CY, CA, und IV auf die entsprechenden Userbits abgebildet werden. Ausgangsseitig kann man die Qualitätsbits inklusive SQ im Userbyte ConnUserByteQ setzen.
SQ kann eingangsseitig nicht auf Userbits abgebildet werden, da es sich um einen Integerwert handelt. |
| SQ | 1 | uint | |||
| CY | 2 | bool | |||
| CA | 3 | bool | |||
| IV | 4 | bool | |||
|
M_EP_TA_1 (17) M_EP_TD_1 (38) |
SEP | ES bit 0 | 0 | bool | You cannot access ES as int at the moment. There is no implementation. |
| ES bit 1 | 1 | bool | |||
| EI | 3 | bool |
Eingangsseitig können EI, BL, SB, NT und IV auf die entsprechenden Userbits abgebildet werden. Ausgangsseitig kann man die Qualitätsbits im Userbyte ConnUserByteQ setzen. |
||
| BL | 4 | bool | |||
| SB | 5 | bool | |||
| NT | 6 | bool | |||
| IV | 7 | bool | |||
| elapsed time | 8 | time | |||
|
M_EP_TB_1 (18) M_EP_TE_1 (39) |
SPE | GS | 0 | bool | |
| SL1 | 1 | bool |
Eingangsseitig können SL1, SL2, SL3, SIE und SRD auf die entsprechenden Userbits abgebildet werden. Ausgangsseitig kann man die Qualitätsbits im Userbyte ConnUserByteQ setzen. |
||
| SL2 | 2 | bool | |||
| SL3 | 3 | bool | |||
| SIE | 4 | bool | |||
| SRD | 5 | bool | |||
| relay time | 8 | time | |||
|
M_EP_TC_1 (19) M_EP_TF_1 (40) |
OCI | GC | 0 | bool | |
| CL1 | 1 | bool |
Eingangsseitig können CL1, CL2 und CL3 auf die entsprechenden Userbits abgebildet werden. Ausgangsseitig kann man die Qualitätsbits im Userbyte ConnUserByteQ setzen. |
||
| CL2 | 2 | bool | |||
| CL3 | 3 | bool | |||
| relay opening time | 8 | time | |||
| M_PS_NA_1 (20) | BSI | bit[i] | 0-31 | bool | single bits |
| bit pattern | 40 | bit32 | complete bit pattern | ||
|
C_SC_NA_1 (45) C_SC_TA_1 (58) |
SCO | SCS | 0 | bool | |
| QU bit 0 | 2 | bool |
Ausgangsseitig kann man QU und S/E im Userbyte ConnUserByteQ setzen. Eingangsseitig muss man die Subindizes verwenden. |
||
| QU bit 1 | 3 | bool | |||
| QU bit 2 | 4 | bool | |||
| QU bit 3 | 5 | bool | |||
| QU bit 4 | 6 | bool | |||
| S/E | 7 | bool | |||
|
C_DC_NA_1 (46) C_DC_TA_1 (59) |
DCO | DCS bit 0 | 0 | bool | |
| DCS bit 1 | 1 | bool | |||
| QU bit 0 | 2 | bool |
Ausgangsseitig kann man QU und S/E im Userbyte ConnUserByteQ setzen. Eingangsseitig muss man die Subindizes verwenden. |
||
| QU bit 1 | 3 | bool | |||
| QU bit 2 | 4 | bool | |||
| QU bit 3 | 5 | bool | |||
| QU bit 4 | 6 | bool | |||
| S/E | 7 | bool | |||
| DCS | 8 | uint | DCS as unsigned integer, values from 0-3 | ||
|
C_RC_NA_1 (47) C_RC_TA_1 (60) |
RCO | RCS bit 0 | 0 | bool | |
| RCS bit 1 | 1 | bool | |||
| QU bit 0 | 2 | bool |
Ausgangsseitig kann man die QU und S/E im Userbyte ConnUserByteQ setzen. Eingangsseitig muss man die Subindizes verwenden. |
||
| QU bit 1 | 3 | bool | |||
| QU bit 2 | 4 | bool | |||
| QU bit 3 | 5 | bool | |||
| QU bit 4 | 6 | bool | |||
| S/E | 7 | bool | |||
| RCS | 8 | uint | RCS as unsigned integer, values from 0-3 | ||
|
C_SE_NA_1 (48) C_SE_TA_1 (61) |
NVA | value | 0 | float |
QL1-7 -> Subindex 1-7 S/E -> Subindex 8 |
|
C_SE_NB_1 (49) C_SE_TB_1 (62) |
SVA | value | 0 | int |
QL1-7 -> Subindex 1-7 S/E -> Subindex 8
Ausgangsseitig kann man die QL und S/E im Userbyte ConnUserByteQ setzen. Eingangsseitig muss man die Subindizes verwenden. |
|
C_SE_NC_1 (50) C_SE_TC_1 (63) |
R32 | value | 0 | float |
QL1-7 -> Subindex 1-7 S/E -> Subindex 8
Ausgangsseitig kann man die QL und S/E im Userbyte ConnUserByteQ setzen. Eingangsseitig muss man die Subindizes verwenden. |
|
C_BO_NA_1 (51) C_BO_TA_1 (64) |
BSI | bit[i] | 0-31 | bool |
single bits Bei diesem Typ gibt es keine Qualitätsinformation. |
| bit pattern | 40 | bit32 | complete bit pattern | ||
| C_IC_NA_1 (100) | Interrogation | QOI | 0 | uint | |
| C_CI_NA_1 (101) | Interrogation | QCC | 0 | uint | |
| C_RD_NA_1 (102) | Empty | - | - | bool | The data in the frame are fix coded. If you receive that kind of frame the value 1 is set on the datapoint. |
| C_CS_NA_1 (103) | CP56 | CP56 time | 0 | time | |
|
C_TS_NA_1 (104) C_TS_TA_1 (107) |
FBP | - | - | bool | The data in the frame are fix coded. If you receive that kind of frame the value 1 is set on the datapoint. |
| C_RP_NA_1 (105) | Interrogation | QRP | 0 | uint | |
| P_ME_NA_1 (110) | NVA | value | 0 | float | Ausgangsseitig kann man die Parameterqualifier KPA, LPC und POP im Userbyte ConnUserByteQ setzen |
| P_ME_NB_1 (111) | SVA | value | 0 | int | Ausgangsseitig kann man die Parameterqualifier KPA,LPC und POP im Userbyte ConnUserByteQ setzen |
| P_ME_NC_1 (112) | R32 | value | 0 | float | Ausgangsseitig kann man die Parameterqualifier KPA,LPC und POP im Userbyte ConnUserByteQ setzen |
| P_AC_NA_1 (113) | Empty | - | - | bool | The data in the frame are fix coded. If you receive that kind of frame the value 1 is set on the datapoint. |
|
M_IT_ND_1 (230) M_IT_TD_1 (231) |
eight byte floating point counter value | counter value | 0 | float | |
| SQ | 1 | uint |
Sequenznummer SQ kann eingangseitig nicht auf Userbits abgebildet werden, da es sich um einen Integerwert handelt. |
||
| CY | 2 | bool |
Eingangsseitig können CY, CA, und IV auf die entsprechenden Userbits abgebildet werden. Ausgangsseitig kann man die Qualitätsbits inklusive SQ im Userbyte ConnUserByteQ setzen. |
||
| CA | 3 | bool | |||
| IV | 4 | bool | |||
|
M_IT_NC_1 (240) M_IT_TC_1 (241) |
6 octet BCD | 0 | double | 6 octet counter value | |
| 6 octet BCD | 1 | uint |
Sequenznummer SQ kann eingangseitig nicht auf Userbits abgebildet werden, da es sich um einen Integerwert handelt. |
||
| 6 octet BCD | CY | 2 | bool |
Eingangsseitig können CY, CA, und IV auf die entsprechenden Userbits abgebildet werden. Ausgangsseitig kann man die Qualitätsbits inklusive SQ im Userbyte ConnUserByteQ setzen. |
|
| 6 octet BCD | CA | 3 | bool | ||
| 6 octet BCD | IV | 4 | bool | ||
| C_SE_NZ_1 (242) | 6 octet BCD | 0 | double | 6 octet counter value | |
| 6 octet BCD | 1 | uint | not used | ||
| 6 octet BCD | 2 | bool | not used | ||
| 6 octet BCD | 3 | bool | not used | ||
| 6 octet BCD | 4 | bool | S/E |
Private Telegrammtypen
Der Telegrammtyp 135 gehört zu den privaten Typen. D.h. es wird der Inhalt eines BLOB DPEs übertragen und es findet keine Interpretation der Daten statt. Das gilt für den IEC 101 und 104 Treiber.
Dieser Telegrammtyp funktioniert daher nur bei DPEs vom Typ blob. Zusätzlich muss die Information Object Address auf 0.0.135 gesetzt werden.
Konsistenzprüfungen der Telegramme
IEC 101
Geprüft wird:
-
Konsistenter Telegrammkopf
-
Prüfsumme
Bei Fehler ist die Konsequenz der Wiederaufbau der Verbindung.
IEC 104
Geprüft wird:
-
Konsistenter Telegrammkopf
Bei Fehler ist die Konsequenz der Wiederaufbau der Verbindung.
Wenn die Prüfsummenberechnung schief geht wird die Verbindung neu initialisiert. Es kommt dabei nur eine Fehlermeldung, dass die Verbindung unterbrochen wurde. Mit dem Debug-Level "-dbg 27" kann man sich näher anschauen ob die Prüfsumme die Ursache ist.
Optimierung vom Datendurchsatz
Nach Möglichkeit werden Telegramme beim Versenden in ein Telegramm gepackt.
Es wird geprüft ob TYP, COT (= Cause of Transmission) und COA (Common Object Address) vom letzten Telegramm in der Queue mit dem aktuellen Telegramm übereinstimmen. Wenn ja, wird das Informationobjekt an das letzte Telegramm in der Queue angehängt, wenn das von der Länge her möglich ist. Es wird nur versucht das IOA an das letzte Telegramm in der Queue anzuhängen damit sicher gestellt ist, dass kein Telegramm ein anderes überholt.
Mögliche Fehlermeldungen bei der Verwendung vom IEC-Treiber
WCCOAiec (1), 2005.02.26 17:27:25.622, PARAM,SEVERE, 54, Unexpected
state, IecResources, DP-Element does not exist , _Iec_1.FileTransfer.Command:_original.._value
WCCOAiec (1), 2005.02.26 17:27:25.623, PARAM,SEVERE, 54, Unexpected state, IecResources, DP-Element does not exist , _Iec_1.FileTransfer.Status:_original.._value
Diese Meldungen deuten daraufhin, dass eine Inkonsistenz zwischen der Treiber-Version und den internen Datenpunkten bzw. deren Typen besteht.
WCCOAiec (1), 2005.02.27 16:27:19.990, PARAM,WARNING, 54, Unexpected state, IecTgLayer, generalQuery, Check format of local/global list entry, COA not correctly specified *.*.*.*.*
In der globalen/lokalen IEC-Liste ist *.*.*.*.* definiert. Die Log-Meldung ist eine Warnung, eine GA über den internen Datenpunkt bzw. den Config-Eintrag autoGQ > 0 ist damit nicht möglich. Damit dies möglich ist müssen die beiden ersten Einträge (Region + Komponente) ungleich "*" sein.
