Hinweise zur Dokumentation

Diese Beschreibung wendet sich ausschließlich an ausgebildetes Fachpersonal der Steuerungs- und Automatisierungstechnik, das mit den geltenden nationalen Normen vertraut ist.
Zur Installation und Inbetriebnahme der Komponenten ist die Beachtung der Dokumentation und der nachfolgenden Hinweise und Erklärungen unbedingt notwendig.
Das Fachpersonal ist verpflichtet, für jede Installation und Inbetriebnahme die zu dem Zeitpunkt veröffentlichte Dokumentation zu verwenden.

Das Fachpersonal hat sicherzustellen, dass die Anwendung bzw. der Einsatz der beschriebenen Produkte alle Sicherheitsanforderungen, einschließlich sämtlicher anwendbaren Gesetze, Vorschriften, Bestimmungen und Normen erfüllt.

Disclaimer

Diese Dokumentation wurde sorgfältig erstellt. Die beschriebenen Produkte werden jedoch ständig weiter entwickelt.
Wir behalten uns das Recht vor, die Dokumentation jederzeit und ohne Ankündigung zu überarbeiten und zu ändern.
Aus den Angaben, Abbildungen und Beschreibungen in dieser Dokumentation können keine Ansprüche auf Änderung bereits gelieferter Produkte geltend gemacht werden.

Marken

Beckhoff®, TwinCAT®, EtherCAT®, EtherCAT G®, EtherCAT G10®, EtherCAT P®, Safety over EtherCAT®, TwinSAFE®, XFC®, XTS® und XPlanar® sind eingetragene und lizenzierte Marken der Beckhoff Automation GmbH.
Die Verwendung anderer in dieser Dokumentation enthaltenen Marken oder Kennzeichen durch Dritte kann zu einer Verletzung von Rechten der Inhaber der entsprechenden Bezeichnungen führen.

Patente

Die EtherCAT Technologie ist patentrechtlich geschützt, insbesondere durch folgende Anmeldungen und Patente:
EP1590927, EP1789857, EP1456722, EP2137893, DE102015105702
mit den entsprechenden Anmeldungen und Eintragungen in verschiedenen anderen Ländern.

EtherCAT® ist eine eingetragene Marke und patentierte Technologie lizenziert durch die Beckhoff Automation GmbH, Deutschland.

Copyright

© Beckhoff Automation GmbH & Co. KG, Deutschland.
Weitergabe sowie Vervielfältigung dieses Dokuments, Verwertung und Mitteilung seines Inhalts sind verboten, soweit nicht ausdrücklich gestattet.
Zuwiderhandlungen verpflichten zu Schadenersatz. Alle Rechte für den Fall der Patent-, Gebrauchsmuster- oder Geschmacksmustereintragung vorbehalten.


Übersicht

Die TwinCAT SPS Bibliothek COMlib bietet Funktionsbausteine und Datenstrukturen für die serielle Datenkommunikation. Die COMlib unterstützt die seriellen Beckhoff Busklemmen KL6xxx.

Die Kommunikationsbibliothek COMlib3964RBC realisiert aufbauend auf der COMlib ein fehlersicherndes Protokoll zur Übertragung beliebiger Daten. Zur Fehlersicherung dienen eine Prüfsumme und Wiederholungen der Datentelegramme im Fehlerfall.

Um Datenbausteine, wie sie z. B. in Siemens-Steuerungen verwendet werden, zu übertragen, wird das Protokoll RK512 benutzt. Die Kommunikationsbibliothek COMlibRK512BC nutzt dazu das 3964R-Protokoll und wickelt den notwendigen Telegrammverkehr ab. Der Anwender parametriert dazu nur den Funktionsbaustein RK512.

Das Kommunikationspaket "Serial Communication RK512" beinhaltet alle notwendigen Bibliotheken. Es unterstützt die Übertragung von Datenbausteinen bis zu einer Länge von 128 Datenwörtern.

Grundlage für das Verständnis des Kommunikationskonzeptes ist die Dokumentation zur PLC-Library Serial Communication BC COMlib.


Installation

Zur Installation werden die folgenden Bibliotheksdateien in das TwinCAT Verzeichnis TwinCAT\PLC\LIB kopiert.

  • COMlibBC5B.LB6
  • COMlib3964RBC.LB6
  • COMlibRK512BC.LB6

Das beiliegende Testprogramm kopieren Sie in ein beliebiges Projektverzeichnis, z. B. nach TwinCAT\PLC.

  • COMlibRK512BCTest.pr6


Datenbausteinkonfiguration

Der Funktionsbaustein RK512 arbeitet in zwei Betriebsarten. In der passiven Betriebsart empfängt er Daten und Anforderungstelegramme von einem Kommunikationspartner, der Datenbausteine über ihre Datenbausteinnummer adressiert. Nummerierte Datenbausteine sind in der IEC-1131 und damit auch in TwinCAT zunächst unbekannt. Datenbausteine sind in TwinCAT Variablen verschiedenen Typs, z. B. Arrays oder Datenstrukturen (STRUCT).

Zur Definition eines nummerierten Datenbausteins wird in einer Initialisierungsphase die Methode DBconfig des Funktionsbausteins RK512 mit allen notwendigen Parametern aufgerufen. Der Aufruf der Methode wird einmalig für jeden Datenbaustein durchgeführt, der vom Kommunikationspartner adressiert werden soll. Für die aktive Betriebsart (Send und Fetch) ist diese Konfiguration nicht notwendig.

In der aktiven Betriebsart können unabhängig von dieser Datenbausteinkonfiguration Variableninhalte zum Kommunikationspartner gesendet bzw. von diesem geholt werden. Die Datenbausteinnummer bezieht sich in der aktiven Betriebsart auf die Gegenstelle und muss nur dort bekannt sein.

Parameter

DbAdr

DbAdr ist die Speicheradresse einer SPS-Variablen, die als Datenbaustein definiert werden soll. Die Adresse wird mit der ADR-Funktion ermittelt.

z. B.: DbAdr := ADR( PLCvar );

Die SPS-Variable kann beliebigen Typs sein. Beispielsweise ist ein ARRAY OF WORD oder eine Datenstruktur STRUCT geeignet.

DbSize

DbSize ist die Größe der SPS-Variablen an DbAdr in Byte, die mit der SIZEOF-Funktion ermittelt wird.

z. B. DbSize := SIZEOF( PLCvar );

RemoteDbNr

RemoteDbNr enthält die Nummer des Datenbausteins beim Kommunikationspartner.

TxBuffer

Der Sendedatenpuffer TxBuffer ist vom Typ COMbuffer. Dieser Parameter wird für die Konfiguration nicht benötigt, muss aber als IN_OUT-Parameter übergeben werden.

RxBuffer

Der Empfangsdatenpuffer RxBuffer ist vom Typ COMbuffer. Dieser Parameter wird für die Konfiguration nicht benötigt, muss aber als IN_OUT-Parameter übergeben werden.

Beispiel

VAR
    (* declare some DB
    (* the type of data doen't matter but the
    (* size shouldn't be larger than 128 bytes
    (**)
    DB1 : ARRAY[1..64] OF WORD; (* exemplary type of db *)
    DB5 : ARRAY[1..64] OF WORD; (* exemplary type of db *)
    DB10 : ARRAY[1..64] OF WORD; (* exemplary type of db *)

    (* input and ouput data for the RK512 function block *)
    RK512com : RK512;

    initialized : BOOL;
END_VAR

IF NOT initialized THEN
    RK512com.DBconfig( RemoteDbNr:=5, DbAdr:=ADR(DB5), DbSize:=SIZEOF(DB5), TxBuffer:=TxBuffer, RxBuffer:=RxBuffer );
    RK512com.DBconfig( RemoteDbNr:=10, DbAdr:=ADR(DB10), DbSize:=SIZEOF(DB10), TxBuffer:=TxBuffer, RxBuffer:=RxBuffer );
    initialized := TRUE;
END_IF

Durch die Initialisierung im Beispiel wird erreicht, dass der Kommunikationspartner die Datenbausteine 5 und 10 beschreiben und lesen darf. Jeder Zugriff auf einen anderen Datenbaustein wird mit einem Fehler abgewiesen.


Funktionsbaustein RK512

VAR_INPUT
    Send : BOOL;                       (* SEND command *)
    Fetch : BOOL;                      (* FETCH command *)
    DbAdr : POINTER TO BYTE;           (* ADR(DB), SEND=source, FETCH=target *)
    DbSize : UINT;                     (* SIZEOF(DB), size in byte for Send or Fetch *)
    RemoteDbNr :BYTE;                  (* SEND=target, FETCH=source *)
    NrOfBytes : UINT;                  (* number of bytes to send or fetch *)
    ByteOffset : UINT;                 (* byte offset in remote DB *)
    HighPriority : BOOL;               (* 3964R priority *)
    SwapWords : BOOL;                  (* swaps every two bytes in the data stream before/after transmission *)
    TREA : TIME;                       (* Timeout for answer *)
END_VAR
VAR_OUTPUT
    Busy : BOOL;                       (* FB is busy *)
    (* send or fetch (active) mode *)
    BusySendFetch : BOOL;              (* FB is with SendFetchCommand busy *)
    SendFetchSuccess : BOOL;           (* Send or Fetch successfully finished *)
    Error : BOOL;                      (* RK512 error *)
    ErrorId : INT;                     (* RK512 error id *)
    (* receive (passive) mode only *)
    BusyReceive : BOOL;                (* FB is busy with remote request *)
    ReceiveSuccess : BOOL;             (* DB has been received from the remote PLC *)
    ReceivedDbNr : BYTE;               (* Number of the DB that has been received *)
    ErrorRx : BOOL;                    (* RK512 error. For receive mode only *)
    ErrorIdRx : INT;                   (* RK512 error id. For receive mode only *)
    Aux : RK512_Auxiliary_t;           (* Additional errors for debugging *)
END_VAR
VAR_IN_OUT
    TxBuffer : ComBuffer;
    RxBuffer : ComBuffer;
END_VAR

Betriebsarten

Der Funktionsbaustein RK512 unterscheidet grundsätzlich zwei Betriebsarten, den passiven Betrieb und den aktiven Betrieb.

In der passiven Betriebsart wartet der Baustein auf Datentelegramm vom Kommunikationspartner und antwortet darauf. Der Kommunikationspartner kann Datenbausteine in die lokale Steuerung senden oder Daten von ihr holen. Damit der Funktionsbaustein RK512 Datenbausteine entgegennehmen oder die angeforderten Daten zurücksenden kann, muss er vorher für die passive Betriebsart mit DBconfig konfiguriert werden.

In der aktiven Betriebsart sendet der Funktionsbaustein RK512 Datenbausteine an den Kommunikationspartner (SEND) oder holt Datenbausteine von ihm ab (FETCH).

Solange der Funktionsbaustein nicht über seine Eingänge Send oder Fetch in den aktiven Betrieb wechselt, wartet er auf Telegramme vom Kommunikationspartner und wechselt gegebenenfalls automatisch in den passiven Betrieb. Beide Betriebsarten können gemischt werden. In diesem Fall versucht der Funktionsbaustein RK512 den Telegrammverkehr zu synchronisieren. Da ein Mischbetrieb zu Verzögerungen im Datenverkehr führen kann, sollte er wenn möglich vermieden werden.

Eine Instanz des Funktionsbausteins RK512 bedient genau eine serielle Schnittstelle. Es können nicht mehrere Instanzen zur selben Zeit den Datenverkehr über dieselbe serielle Schnittstelle abwickeln.

Eingangs- und Ausgangsparameter

Send

Mit einer positiven Flanke am Eingang Send werden Daten aus der Variablen am Eingang DbAdr an den Kommunikationspartner übertragen und dort im Datenbaustein mit der Nummer RemoteDbNr abgelegt. Send und Fetch können nicht gleichzeitig ausgeführt werden.

Fetch

Mit einer positiven Flanke am Eingang Fetch werden Daten aus dem Datenbaustein RemoteDbNr vom Kommunikationspartner angefordert und in der Variablen am Eingang DbAdr gespeichert. Send und Fetch können nicht gleichzeitig ausgeführt werden.

DbAdr

DbAdr ist die Speicheradresse einer SPS-Variablen, die mit der ADR-Funktion ermittelt wird.

z. B.: DbAdr := ADR( PLCvar );

Die SPS-Variable kann beliebigen Typs sein. Beispielsweise ist ein ARRAY OF WORD oder eine Datenstruktur STRUCT geeignet.

Mit einem Send-Kommando werden die Daten aus dieser Variablen an den Kommunikationspartner übertragen, mit einem Fetch-Kommando werden Daten geholt und in der Variablen gespeichert.

DbSize

DbSize ist die Größe der SPS-Variablen an DbAdr in Byte, die mit der SIZEOF-Funktion ermittelt wird.

z. B. DbSize := SIZEOF( PLCvar );

RemoteDbNr

RemoteDbNr enthält die Nummer des Datenbausteins beim Kommunikationspartner zu dem Daten gesendet werden bzw. aus dem Daten geholt werden.

NrOfBytes

NrOfBytes enthält die Anzahl der zu übertragenden Datenbytes. Die Anzahl kann kleiner oder gleich der Variablengröße DbSize sein.

ByteOffset

Der ByteOffset gibt an, ab welchem Datenbyte die Daten im Datenbaustein des Kommunikationspartners gespeichert, bzw. geholt werden.

HighPriority

Die Priorität bezieht sich auf das 3964R-Protokoll. Beide Kommunikationspartner sollten unterschiedliche Priorität haben. In dem Fall, dass beide Partner zur gleichen Zeit senden, kommt es zu einer Kollision. Diese Kollision wird dadurch aufgelöst, dass der Partner mit niedriger Priorität in den Empfangsmodus schaltet und der Partner mit hoher Priorität erneut sendet.

SwapWords

Datenbausteine sind normalerweise Wortweise organisiert. Je nachdem, wie die Datenwörter im Speicher abgelegt werden, ist es notwendig die Datenbytes der übertragenen Wörter zu tauschen. Ist SwapWords TRUE, werden in allen Datentelegrammen die Datenbytes eines Wortes getauscht.

TREA

Jedes Telegramm eines Kommunkationspartners wird mit einem Antworttelegramm quittiert. Diese Quittierung wird mit dem Timeout TREA zeitlich überwacht. TREA liegt z. B. bei 15 Sekunden.

Busy

Busy wird TRUE, sobald der Baustein in den aktiven oder passiven Betrieb wechselt, also seinen Ruhezustand verlässt. Solange Busy TRUE ist, kann er keine neues Kommandos annehmen.

BusySendFetch

BusySendFetch wird TRUE, sobald der Baustein durch eine positive Flanke am Send- oder Fetch-Eingang in den aktiven Betrieb wechselt. Nachdem BusySendFetch FALSE wird, ist die Übertragung abgeschlossen und entweder der Ausgang SendFetchSuccess oder Error ist gesetzt.

SendFetchSuccess

SendFetchSuccess signalisiert, dass eine mit Send oder Fetch eingeleitete Datenübertragung erfolgreich abgeschlossen wurde.

Error

Error wird TRUE, wenn bei einer bei einer durch Send oder Fetch eingeleiteten Datenübertragung ein Fehler auftritt.

ErrorId

ErrorId zeigt im Fehlerfall eine Fehlernummer an.

BusyReceive

BusyReceive zeigt an, dass sich der Funktionsbaustein RK512 im Empfangsmodus, d. h. in der passiven Betriebsart befindet. Der Baustein wechselt automatisch in die passive Betriebsart, sobald im Ruhezustand (Busy gleich FALSE) ein Telegramm vom Kommunikationspartner empfangen wird. Mit fallender Flanke an BusyReceive wird entweder ReceiveSuccess oder ErrorRx gesetzt.

ReceiveSuccess

Nachdem ein Datenbaustein vom Kommunikationspartner erfolgreich empfangen wurde wird ReceiveSuccess TRUE. Dieses Signal betrifft nur den passiven Betrieb, ReceiveSuccess wird also nicht TRUE, wenn mit Fetch aktiv ein Datenbaustein vom Kommunikationspartner geholt wird.

ReceivedDbNr

Sobald ReceiveSuccess TRUE wird zeigt ReceivedDbNr die Nummer des empfangenen Datenbausteins an.

ErrorRx

Das Signal ErrorRx zeigt an, dass beim Datenempfang in der passiven Betriebsart ein Fehler aufgetreten ist

ErrorIdRx

ErrorIdRx zeigt im Fehlerfall im der passiven Betriebsart die Fehlernummer an.

Aux

Aux ist eine Datenstruktur, die zusätzliche Fehlermeldungen zur Diagnose enthält.

TxBuffer

Der Sendedatenpuffer TxBuffer ist vom Typ COMbuffer. Dieser Puffer wird vom Baustein RK512 verwendet und wird vom Benutzer nicht geändert.

RxBuffer

Der Empfangsdatenpuffer RxBuffer ist vom Typ COMbuffer. Dieser Puffer wird vom Baustein RK512 verwendet und wird vom Benutzer nicht geändert.


Fehlercodes

Nr. | Nr. (hex) | Fehlerkonstante | Beschreibung
4 16#04 RK512ERR_P3964ERR_ZVZ Die Zeichenverzugszeit wurde überschritten. ZVZ = 220 ms.

Die Zeichenverzugszeit ist der maximale Zeitabstand zwischen der Übertragung zweier aufeinanderfolgendender Zeichen.

5 16#05 RK512ERR_P3964ERR_QVZ Die Quittungsverzugszeit wurde überschritten.

Die Gegenstelle sendet während der Telegrammabwicklung zweimal ein Quittungszeichen (DLE = 10H). QVZ = 2 s.

Die erste Quittung wird am Anfang der Übertragung erwartet. Der Ausgang ErrorState ist im Fehlerfall "Wait_DLE_TXstart". Ursache können z. B. eine fehlerhafte physikalische Verbindung oder falsche Schnittstellenparameter sein.

Die zweite Quittung wird nach der Übertragung der Nutzdaten erwartet. Im Fehlerfall ist der ErrorState "Wait_DLE_TXend". Ursache können in diesem Fall z. B. Datenverlust, Datenverfälschung oder vertauschte Datenbytes eines Datenwortes (vergleiche Eingang SwapWords) sein.
6 16#06 RK512ERR_P3964ERR_WVZ Die Wiederholungsverzugszeit wurde überschritten. WVZ = 4 s.

Im Fehlerfall wird ein Telegramm wiederholt. Bleibt im Wiederholungsfall das Telegramm von der Gegenstelle aus, meldet der Funktionsbaustein 3964R diesen Fehler.
7 16#07 RK512ERR_P3964ERR_WRONGBCC Prüfsummenfehler beim Datenempfang.

Jedes Telegramm wird mit einer Prüfsumme versehen. Beim Datenempfang wird die berechnete Prüfsumme mit der empfangenen Prüfsumme verglichen.
9 | 16#09 | RK512ERR_P3964ERR_COMERRTX | Schnittstellenfehler beim Senden
10 | 16#0A | RK512ERR_P3964ERR_COMERRRX | Schnittstellenfehler beim Empfang
11 | 16#0B | RK512ERR_P3964ERR_NOTXDATA | Parametrierungsfehler. Die Anzahl der zu sendenden Datenbytes TxCount ist Null.
120 16#78 RK512ERR_P3964ERR_NAK Ein Telegramm wurde von der Gegenstelle mit einer Negativquittung (NAK) zurückgewiesen.

Der Fehler kann u. a. in folgenden Übertragungszuständen (ErrorState) auftreten:

Wait_DLE_TXstart: Die lokale SPS leitet ein Telegramm mit einem Startzeichen ein. Die Gegenstelle weist das Telegramm mit NAK ab.

Wait_DLE_TXend: Die Gegenstelle weist das Telegramm nach Nutzdatenübertragung mit NAK ab. Ursache kann in diesem Fall z. B. ein Prüfsummenfehler in der Gegenstelle sein.
12 16#0C RK512ERR_INVALIDDATATYPE Ungültiger Datentyp

Es wurde ein Telegramm mit einer nicht unterstützten Datentypkennung empfangen. Es können nur Datenbausteine mit der Kennung 'D' verarbeitet werden.
16 16#10 RK512ERR_ERRORPROTOCOLHEADER Fehlerhafter Protokoll-Header

Der Kopf eines Datentelegramms entspricht nicht der RK512-Spezifikation
20 16#14 RK512ERR_DBNOTAVAILIBLE Datenbaustein nicht verfügbar.

Es wurde ein Datenbaustein gesendet oder angefordert, der nicht verfügbar ist. Datenbausteine, auf die die Gegenstelle zugreift, müssen zunächst mit der DBconfig-Methode angemeldet werden.
22 16#16 RK512ERR_INVALIDCOMMAND Ungültiges Kommando

Es wurde ein Telegramm mit ungültiger Kommandokennung (SEND / FETCH) empfangen.
52 16#34 RK512ERR_INVALIDSIZE Ungültige Längenangabe

Einer der Parameter DbSize oder NrOfBytes ist ungültig oder es wurde ein zu langes Datentelegramm empfangen.
53 16#35 RK512ERR_INVALIDDBADR Ungültige Datenbausteinadresse

Die Datenbausteinadresse DbAdr ist ungültig.
54 16#36 RK512ERR_SYNCERROR Synchronisationsfehler

Ein Synchronisationsfehler kann auftreten, wenn beide Kommunikationspartner zur gleichen Zeit beginnen zu senden.

257 16#101 RK512ERR_TIMEOUT Timeout auf RK512 Telegrammebene

Ein erwartetes Reaktionstelegramm konnte nicht innerhalb der Wartezeit TREA empfangen werden.
258 16#102 RK512ERR_ERRORREMOTEREATEL Fehler im Reaktionstelegramm

Im Reaktionstelegramm des Kommunikationspartners wurde eine Fehlermeldung übermittelt. Diese Fehlernummer kann in der zusätzlichen Fehlerinformation AUX ausgelesen werden.
259 | 16#103 | RK512ERR_INVALIDSIZEREMOTEREATEL | Das Reaktionstelegramm des Kommunikationspartners hat eine falsche Länge
260 16#104 RK512ERR_TIMEOUTREAPEATSENDFETCH Timeout beim Senden

Trotz mehrfacher Wiederholung konnte ein Send- oder Fetch-Telegramm nicht gesendet werden
261 16#105 RK512ERR_3964ERROR Fehler auf der der 3964R-Protokollebene.

Vorhersehbare Fehler auf dieser Ebene werden nicht mit dem allgemeinen Fehler RK512ERR_3964ERROR, sondern mit einer detaillierten Fehlernummer ausgegeben.
262 | 16#106 | RK512ERR_3964NOTBUSYNOTREADY | Die Übertragung eines Telegramms wurde beendet aber nicht erfolgreich abgeschlossen.


Bilbiotheken einbinden

Legen Sie ein neues SPS-Projekt mit dem TwinCAT PLC Control an, um das Einbinden der Bibliothek nachzuvollziehen.

Wechseln Sie in die Bibliotheksverwaltung und fügen Sie die Bibliotheken ComLibBC5B.LIB, ComLib3964RBC.LIB und ComLibRK512BC.LIB ein.


Globale Variable

Um eine serielle Schnittstelle anzusprechen, sind vier globale Datenstrukturen notwendig. Zwei stellen die Verbindung zur Hardware in Sende- und Empfangsrichtung her. Zusätzlich werden zwei Datenpuffer als Zwischenspeicher benötigt.

Die Datenstrukturen vom Typ PcComInData bzw. PcComOutData werden im TwinCAT System Manager mit der Hardware verbunden. Lesen Sie dazu das entsprechende Kapitel in der Dokumentation zur COMlib.


Hintergrundkommunikation

Die Kommunikation zwischen der seriellen Hardware und den Datenpuffer vom Typ ComBuffer wird in einer separaten Funktionsbaustein abgewickelt. Grundlagen zum Thema werden in der Dokumentation zur Kommunikationsbibliothek COMlib vermittelt.


RK512 Protokoll

Das Beispielprogramm definiert drei WORD-Arrays, um sie als Datenbausteine zu verwenden. Die Datenbausteine 5 und 10 werden während der Initialisierung mit einem Aufruf der Methode DBconfig für den Zugriff durch den Kommunikationspartener bekannt gemacht. Der Funktionsbausteins RK512 verhält passiv und ist bereit Datentelegramme von der Gegenstelle anzunehmen und zu beantworten. Im Testprogramm kann das aktive Senden oder Holen von Daten durch beschreiben der Variablen Send bzw. Fetch gestartet werden.