DE102016125128B3 - Datenübertragungsverfahren, Kommunikationsnetzwerk und Master-Teilnehmer - Google Patents

Datenübertragungsverfahren, Kommunikationsnetzwerk und Master-Teilnehmer Download PDF

Info

Publication number
DE102016125128B3
DE102016125128B3 DE102016125128.3A DE102016125128A DE102016125128B3 DE 102016125128 B3 DE102016125128 B3 DE 102016125128B3 DE 102016125128 A DE102016125128 A DE 102016125128A DE 102016125128 B3 DE102016125128 B3 DE 102016125128B3
Authority
DE
Germany
Prior art keywords
field
data
slave
datagram
data field
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE102016125128.3A
Other languages
English (en)
Inventor
Thorsten Bunte
Holger Büttner
Erik Vonnahme
Dirk Janssen
Thomas Rettig
Hans Beckhoff
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beckhoff Automation GmbH and Co KG
Original Assignee
Beckhoff Automation GmbH and Co KG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beckhoff Automation GmbH and Co KG filed Critical Beckhoff Automation GmbH and Co KG
Priority to DE102016125128.3A priority Critical patent/DE102016125128B3/de
Priority to US15/840,794 priority patent/US10848419B2/en
Application granted granted Critical
Publication of DE102016125128B3 publication Critical patent/DE102016125128B3/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/74Address processing for routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/42Loop networks
    • H04L12/423Loop networks with centralised control, e.g. polling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)

Abstract

Die Datenübertragung in einem Kommunikationsnetzwerk erfolgt über einen Übertragungsweg 1, über den ein Master-Teilnehmer 2 und zumindest ein Slave-Teilnehmer 3 miteinander in Verbindung stehen. Der Master-Teilnehmer 2 gibt dabei Telegramme auf dem Datenübertragungsweg 1 aus, mit denen die Slave-Teilnehmer 3 im Durchlauf Daten austauschen. Die vom Master-Teilnehmer 2 ausgegebenen Telegramme beinhalten Datagramme 220, die jeweils ein Steuerdatenfeld 221 und ein Nutzdatenfeld 222 umfassen, wobei das Steuerdatenfeld 221 ein Befehlsfeld und ein Adressfeld aufweist. Bei wenigstens einem Telegramm, das wenigstens ein Datagramm S220 aufweist, das ein Schreibdatagramm ist, bei dem das Befehlsfeld den von einem Slave-Teilnehmer 3 auszuführenden Datenübertragungsvorgang mit dem Nutzdatenfeld als Schreibvorgang festlegt, ist zwischen dem Steuerdatenfeld S221 des Schreibdatagramms und dem Nutzdatenfeld S222 des Schreibdatagramms wenigstens das Steuerdatenfeld eines weiteren Datagramms 220 angeordnet.

Description

  • Die Erfindung betrifft ein Verfahren zur Datenübertragung in einem Kommunikationsnetzwerk, mit einem Datenübertragungsweg, über den ein Master-Teilnehmer und Slave-Teilnehmer miteinander in Verbindung stehen, und einen Master-Teilnehmer.
  • In der Fertigungs- und Prozessautomatisierung werden Feldbussysteme eingesetzt, bei denen dezentral angeordnete Geräte einer Maschinenperipherie wie Eingangs- und/oder Ausgangs-Module, Antriebe und Bedienerterminals über ein Echtzeit-Kommunikationssystem mit Steuereinheiten verbunden sind. Der Datenaustausch auf dem Feldbus erfolgt dabei meistens auf der Grundlage des Master-Slave-Prinzips. Die Steuereinheiten am Feldbus sind die aktiven Busteilnehmer, im Weiteren auch als Master-Teilnehmer bezeichnet. Sie sind im Besitz der Buszugriffsberechtigung und bestimmen den Datentransfer auf dem Feldbus. Die passiven Teilnehmer, im Weiteren auch als Slave-Teilnehmer bezeichnet, sind in der Regel die Maschinenperipheriegeräte. Sie haben keine Buszugriffsberechtigung und können empfangene Daten nur quittieren beziehungsweise auf Anfrage eines Master-Teilnehmers Daten übermitteln.
  • Feldbusse nutzen in der Regel den Ethernet-Standard für die Vernetzung der Teilnehmer im Kommunikationssystem, bei dem der Datenaustausch in Form von Datenpaketen erfolgt. Um die Echtzeitanforderungen bei der Fertigungs- und Prozessautomatisierung gewährleisten zu können, sind für industrielle Ethernet-Netze spezielle Protokolle definiert, mit denen sich gegenwärtig Datenaustauschraten von 100 Mbit/s erreichen lassen. Im Konsumerbereich werden jedoch bereits Ethernet-Netzwerke eingesetzt, deren Datenübertragungsrate bei 1 Gbit/s und mehr liegt.
  • Zielsetzung beim industriellen Ethernet ist es, ähnlich hohe Datenübertragungsraten zu erreichen. Die Anforderungen in der Fertigungs- und Prozessautomatisierung unterscheiden sich aber von denen der Bürodatenkommunikation. So wird im Gegensatz zum Konsumerbereich, bei dem in Kommunikationsnetzwerken in der Regel große Datenmengen von wenigen Teilnehmern übertragen werden, bei Kommunikationsnetzwerken in der Fertigungs- und Prozessautomatisierung in der Regel eine Datenkommunikation zwischen vielen Teilnehmern ausgeführt, bei der die Teilnehmer jeweils nur wenige Daten austauschen.
  • Um ein schnelles industrielles Ethernet-System bereitzustellen, bei dem die Telegramme einen hohen Nutzanteil aufweisen, werden Ethernet-Protokolle wie beispielsweise das EtherCAT-Protokoll eingesetzt, bei dem die Datenpakete, im Weiteren auch als Telegramme bezeichnet, in den Slave-Teilnehmern im Durchlauf verarbeitet werden. In das Ethernet-Telegramm sind dabei Datagramme eingebettet, die jeweils ein Steuerdatenfeld und ein Nutzdatenfeld umfassen. Im Steuerdatenfeld ist ein Befehlsfeld enthalten, das den von dem Slave-Teilnehmer mit dem Nutzdatenfeld auszuführenden Datenübertragungsvorgang anzeigt, das heißt, ob ein Lesevorgang ausgeführt werden soll, bei dem der Teilnehmer Daten aus dem Nutzdatenfeld entnehmen soll, oder ein Schreibvorgang, bei dem der Slave-Teilnehmer Daten in das Nutzdatenfeld einfügen soll. Im Adressfeld des Steuerdatenfeldes ist dann der Slave-Teilnehmer bzw. der Datenbereich im Slave-Teilnehmer festgelegt, mit dem der Slave-Teilnehmer beim Durchlauf des Nutzdatenfeldes Daten austauschen soll.
  • Der Slave-Teilnehmer beginnt mit der Datenverarbeitung sofort nach dem Empfang des Steuerdatenfeldes eines Datagramms im Ethernet-Telegramm und wertet das Befehlsfeld und das Adressfeld aus. Wenn der Slave-Teilnehmer adressiert ist, entnimmt der Slave-Teilnehmer bei einem Lesedatagramm dann die für den Teilnehmer bestimmten Ausgangsdaten aus dem Nutzdatenfeld während das Datagramm im Ethernet-Telegramm durch den Slave-Teilnehmer hindurch läuft. Bei einem Schreibdatagramm werden vom Slave-Teilnehmer Eingangsdaten im Durchlauf in das Nutzdatenfeld im Datagramm eingefügt. Die Ethernet-Telegramme werden bei der Verarbeitung der Datagramme im Durchlauf vom Slave-Teilnehmer nur kurz verzögert.
  • Wenn beim industriellen Ethernet ähnlich wie im Konsumerbereich statt der bisherigen Standardübertragungsrate von 100 Mbit/s eine Datenübertragungsrate von 1 Gbit/s eingesetzt werden soll, wird die Übertragungszeit zwischen den Teilnehmern auf ein Zehntel der bisherigen Übertragungszeit reduziert. Die Laufzeit von Ethernet-Telegrammen bei der Standard-Gbit-Technik zwischen zwei Teilnehmern beträgt ca. 1 µs. Um das Ethernet-Telegramme in den Slave-Teilnehmern im Durchlauf mit einer weiterhin geringeren Verzögerung verarbeiten zu können, ist es dann aber erforderlich, insbesondere bei Schreibdatagrammen, die Verarbeitungsgeschwindigkeit der Slave-Teilnehmer zu erhöhen. Es muss nämlich gewährleistet werden, dass, wenn der Slave-Teilnehmer bei Verarbeitung des Steuerdatenfeldes im Datagramm feststellt, dass er adressiert ist und ein Schreibdatagramm vorliegt, in das Daten eingefügt werden sollen, der Slave-Teilnehmer dann die Eingabedaten ausreichend schnell bereitstellt, wenn das Nutzdatenfeld des Schreibdatagramms durch den Slave-Teilnehmer hindurch läuft, um eine Verzögerung beim Durchlauf zu vermeiden. Um eine höhere Datenübertragungsrate zu ermöglichen, kann der Slave-Teilnehmer die Taktrate bei der internen Datenverarbeitung zur schnelleren Bereitstellung der Eingangsdaten erhöhen. Dies macht jedoch den Einsatz von Hochleistungsprozessoren notwendig, was zu steigenden Hardwarekosten und einer größeren Verlustleistung beim Slave-Teilnehmer führt.
  • Aus der DE 10 2014 109 060 B3 ist bekannt, EtherCAT-Datentelegramme, die dazu dienen, Prozessdaten eines Steuerzyklus vom Steuerknoten auf die Netzwerk-Teilnehmer der Sensor-/Aktorebene zu übertragen, nicht mehr auf den Steuerknoten rückzukoppeln. Nach dem Durchlauf auf dem Hinweg des Datenpfads werden die Datentelegramme anhand ihrer Kennung vom Kopf-Teilnehmer ausgefiltert. Anstelle der vom Steuerknoten versandten Datentelegramme werden zum Einsammeln der Prozessdaten der Netzwerk-Teilnehmer auf dem Rückweg des Datenpfads eigenständige, vom Kopf-Teilnehmer auf den Rückweg ausgegebene Datentelegramme genutzt.
  • Aus der DE 10 2005 120 242 B3 ist bekannt, bei den von den Slave-Teilnehmern zu beschreibenden Datagrammen zwischen den Header und den Datenbereich ein Zwischenfeld einzufügen, um einen Abstand zwischen dem Header und dem Datenfeld zu schaffen, um es einem Teilnehmer auch bei einer sehr kurzen Laufzeit des Datagramms durch den betreffenden Teilnehmer zu ermöglichen, Eingabedaten in Abhängigkeit vom Inhalt des Headers zu bestimmen und die so bestimmten Eingabedaten rechtzeitig in das Datenfeld zu schreiben. Das Zwischenfeld kann dabei Füllbits in Form von Leerbits enthalten. Alternativ kann das Zwischenfeld Statusinformationen aufnehmen oder genutzt werden, um nicht adressierte Daten an den Teilnehmer ähnlich einem Broadcast-Telegramm zu verteilen.
  • Aufgabe der Erfindung ist es, ein Verfahren zur Datenübertragung in einem Kommunikationsnetzwerk, ein Kommunikationsnetzwerk und einen Master-Teilnehmer bereitzustellen, die es ermöglichen, die Datenübertragungsraten auf dem Datenübertragungsweg auch bei einer Verarbeitung von Telegrammen durch die Slave-Teilnehmer im Durchlauf energieeffizient und kostengünstig steigern zu können.
  • Diese Aufgabe wird mit den Merkmalen der unabhängigen Ansprüche gelöst. Die abhängigen Ansprüche beschreiben vorteilhafte Ausführungsformen.
  • Die Datenübertragung in einem Kommunikationsnetzwerk erfolgt über einen Übertragungsweg, über den ein Master-Teilnehmer und zumindest ein Slave-Teilnehmer miteinander in Verbindung stehen. Der Master-Teilnehmer gibt dabei Telegramme auf dem Datenübertragungsweg aus, mit denen der Slave-Teilnehmer im Durchlauf Daten austauschen. Die vom Master-Teilnehmer ausgegebenen Telegramme beinhalten Datagramme, die jeweils ein Steuerdatenfeld und ein Nutzdatenfeld umfassen, wobei das Steuerdatenfeld ein Befehlsfeld und ein Adressfeld aufweist. Das Befehlsfeld legt den von einem Slave-Teilnehmer auszuführenden Datenübertragungsvorgang mit dem Nutzdatenfeld und das Adressfeld den Datenbereich in dem Slave-Teilnehmer, mit dem der Slave-Teilnehmer beim Durchlauf des Nutzdatenfeldes Daten austauschen soll, fest. Bei wenigstens einem Telegramm, das wenigstens ein Datagramm aufweist, das ein Schreibdatagramm ist, bei dem das Befehlsfeld den von einem Slave-Teilnehmer auszuführenden Datenübertragungsvorgang mit dem Nutzdatenfeld als Schreibvorgang festlegt, ist zwischen dem Steuerdatenfeld des Schreibdatagramms und dem Nutzdatenfeld des Schreibdatagramms wenigstens das Steuerdatenfeld eines weiteren Datagramms angeordnet.
  • Als Schreibdatagramm wird im Weiteren auch ein gemischtes Datagramm gekennzeichnet, bei dem neben einem Einschreiben von Daten in das Nutzdatenfeld zusätzliche auch ein Auslesen von Daten aus dem Nutzdatenfeld durch den Slave-Teilnehmer ausgeführt werden soll.
  • Ein Datenübertragungsverfahren, ein Kommunikationssystem und ein Master-Teilnehmer mit der erfindungsgemäßen Ausgestaltung geben einem Slave-Teilnehmer in einem Kommunikationsnetzwerk mehr Zeit zur Verarbeitung eines an den Slave-Teilnehmer adressierenden Schreibdatagramms. Bei Schreibdatagrammen, die im Durchlauf vom Slave-Teilnehmer verarbeitet werden, muss der Slave-Teilnehmer, um eine Verzögerung beim Durchlauf des Telegramms zu vermeiden, die in das Schreibdatagramm einzuschreibenden Eingabedaten nämlich bereits bereitgestellt haben, wenn das Nutzdatenfeld des Schreibdatagramms vom Slave-Teilnehmer empfangen wird. Durch die Aufspaltung des Schreibdatagramms in ein Steuerdatenfeld und ein Nutzdatenfeld und deren getrennten Anordnung im Telegramm, bei der zwischen dem Steuerdatenfeld und dem Nutzdatenfeld des Schreibdatagramms wenigstens das Steuerdatenfeld eines weiteren Datagramms angeordnet ist, verlängert sich die dem Slave-Teilnehmer zur Verfügung stehende Zeit, die er nach dem Empfang des Steuerdatenfeldes des Schreibdatagramms hat, wenn er bei der Auswertung des Steuerdatenfeldes feststellt, dass es sich um ein Schreibdatagramm handelt und ein Datenbereich im Slave-Teilnehmer adressiert ist, um Eingabedaten bereitzustellen. Durch die Beabstandung des Nutzdatenfeldes vom Steuerdatenfeld im Schreibdatagramm wird nämlich der Empfang des Nutzdatenfeldes des Schreibdatagramms durch den Slave-Teilnehmer zeitlich nach hinten verschoben, so dass der Slave-Teilnehmer diese zusätzliche Zeit nutzen kann, um die einzuschreibenden Eingabedaten in seinem Speicher zu ermitteln und auszulesen. Es besteht so die Möglichkeit, dass auch bei hohen Datenübertragungsraten auf dem Übertragungsweg im Slave-Teilnehmer „langsame“ Prozessoren zur Verarbeitung eingesetzt werden können, da dem Prozessor im Slave-Teilnehmer ausreichend Zeit für den Speicherzugriff gegeben wird, um die Eingabedaten zum Einschreiben in das Schreibdatagramm bereitzustellen.
  • Im Gegensatz zu den Schreibdatagrammen, worunter, wie vorstehend erläutert, auch gemischte Datagramme fallen, bei denen sowohl ein Einschreiben von Daten in das Nutzdatenfeld als auch ein Auslesen von Daten aus dem Nutzdatenfeld durch die Slave-Teilnehmer ausgeführt werden sollen, ist eine Aufteilung der Lesedatagramme, bei denen das Befehlsfeld im Steuerdatenfeld den von dem Slave-Teilnehmer auszuführenden Datenübertragungsvorgang mit dem Nutzdatenfeld als Lesevorgang festlegt, nicht erforderlich. Das Steuerdatenfeld und das Nutzdatenfeld beim Lesedatagramm können als einheitlicher Block vorliegen, da für den Lesevorgang aus dem Lesedatagramm beim Telegrammdurchlauf keine Datenverarbeitung durch den Prozessor im Slave-Teilnehmer erforderlich ist. Es kann somit auch zu keiner Verzögerung beim Telegrammdurchlauf im Slave-Teilnehmer bei Lesedatagrammen durch eine möglicherweise verzögerte Verarbeitung im Slave-Teilnehmer kommen. Es besteht natürlich die Möglichkeit auch bei Lesedatagrammen das Nutzdatenfeld getrennt vom Steuerdatenfeld im Telegramm zu positionieren, wenn beispielsweise eine einheitliche Datagrammstruktur im Telegramm hergestellt werden soll, bei der zuerst alle Steuerdatenfelder der Datagramme und dann alle Nutzdatenfelder der Datagramme angeordnet werden sollen.
  • Das Telegramm kann grundsätzlich so ausgestaltet sein, dass ein Kopfdatenfeld vorgesehen ist, in dem ein Kenndatenfeld angeordnet ist, dessen Datum angibt, ob bei den Datagrammen, insbesondere den Schreibdatagrammen im Telegramm das Steuerdatenfeld und das Nutzdatenfeld getrennt angeordnet sind. Mit dieser Ausgestaltung besteht die Möglichkeit, sowohl Telegramme, bei denen das Steuerdatenfeld und das Nutzdatenfeld der Schreibdatagramme im Telegramm getrennt angeordnet sind, zu verschicken als auch Telegramme, bei denen dies nicht der Fall ist. Die Telegrammstruktur lässt sich somit flexibel an die Auslegung der Hardware im Kommunikationsnetzwerk, insbesondere was die Slave-Teilnehmer betrifft, anpassen.
  • Die Verarbeitung von Telegrammen, bei denen das Steuerdatenfeld des Schreibdatagramms getrennt vom Nutzdatenfeld des Schreibdatagramms angeordnet ist, lässt sich Ressourcen-schonend im Slave-Teilnehmer implementieren, wenn die Telegramme so ausgelegt werden, dass das Steuerdatenfeld des Datagramms und das Nutzdatenfeld des Datagramms jeweils eine feste Datenlänge besitzen. Der Slave-Teilnehmer erfasst, wenn das Kenndatenfeld im Kopfdatenfeld des Telegramms anzeigt, dass bei den Schreibdatagrammen im Telegramm das Steuerdatenfeld und das Nutzdatenfeld getrennt angeordnet sind, die Anzahl der Schreibdatagramme im Telegramm. Wenn der Slave-Teilnehmer dann bei der Auswertung des Adressfeldes im Steuerdatenfeld eines Schreibdatagramms feststellt, dass ein Datenbereich im Slave-Teilnehmer adressiert ist, aus dem der Slave-Teilnehmer in das Nutzdatenfeld des Schreibdatagramms Daten einschreiben soll, kann der Slave-Teilnehmer dann auf einfache Weise aus der erfassten Anzahl der Schreibdatagramme sowie der bekannten festen Länge vom Steuerdatenfeld und Nutzdatenfeld die Position des an ihn adressierten Bereiches im Nutzdatenfeld des Schreibdatagramms feststellen, um dann an der richtigen Stelle die Daten in das Schreibdatagramm einzufügen.
  • Alternativ besteht auch die Möglichkeit, dass im Steuerdatenfeld des Schreibdatagramms im Telegramm ein Kenndatenfeld vorgesehen ist, dessen Datum als Wert oder Längenangabe die Position des zugeordneten Nutzdatenfeldes angibt. Der Slave-Teilnehmer kann dann durch Auswertung dieses Kenndatenfeldes, wenn das Schreibdatagramm an ihn adressiert ist, die Position des an ihn adressierten Bereichs im Nutzdatenfeld des Schreibdatagramms ermitteln.
  • Eine weitere Möglichkeit, bei einer getrennten Anordnung von Steuerdatenfeld und Nutzdatenfeld im Schreibdatagramm den Slave-Teilnehmer über die Datenlänge zwischen dem Steuerdatenfeld und dem Nutzdatenfeld zu informieren, besteht darin, dass der Bitabstand fest voreingestellt ist. Die Datenlänge zwischen dem Steuerdatenfeld und dem Nutzdatenfeld kann dabei vom Master-Teilnehmer den Slave-Teilnehmern beispielsweise im Rahmen der Initialisierung vorgegeben werden. Es besteht auch die Möglichkeit, dass im Kopfdatenfeld des Telegramms ein weiteres Kenndatenfeld vorgesehen ist, dessen Datum den Bitabstand angibt.
  • Die vom Master-Teilnehmer ausgegebenen Telegramme können so ausgelegt sein, dass zuerst die Steuerdatenfelder aller Schreibdatagramme im Telegramm angeordnet sind. Dies vereinfacht den Telegrammaufbau für den Master-Teilnehmer und vergrößert den Bitabstand zwischen den Steuerdatenfeldern der Schreibdatagramme und den Nutzdatenfeldern der Schreibdatagramme. Der Bitabstand kann zusätzlich noch verlängert werden, indem im Telegramm zwischen den Steuerdatenfeldern der Schreibdatagramme und den Nutzdatenfeldern der Schreibdatagramme die Lesedatagramme, bei denen das Steuerdatenfeld den von einem Slave-Teilnehmer auszuführenden Datenübertragungsvorgang mit dem Nutzdatenfeld als Lesevorgang festlegt, angeordnet sind.
  • Das Kommunikationsnetzwerk kann ferner so ausgelegt sein, dass die Datenübertragungsrate auf dem Übertragungsweg größer als die Datenübertragungsrate in wenigstens einem der Slave-Teilnehmer ist. Durch das Ausgestalten der Schreibdatagramme im Telegramm mit einem Bitabstand zwischen dem Steuerdatenfeld und dem Nutzdatenfeld, der zumindest der Länge des Steuerdatenfeldes eines weiteren Datagramms entspricht, können das Kommunikationsnetz und die Slave-Teilnehmer mit unterschiedlichen Datenübertragungsgeschwindigkeiten betrieben werden. Insbesondere besteht die Möglichkeit, eine schnelle Datenübertragung auf dem Datenübertragungsweg auszuführen, ohne Slave-Teilnehmer einzusetzen zu müssen, die dieselbe schnelle Datenübertragungsrate intern zur Datenverarbeitung nutzen. Die Feldbusprotokolle auf dem Datenübertragungsweg können so Datenübertragungsraten im 1-Gbit/s beziehungsweise 10 Gbit/s-Datenbereich nutzen, wobei die Slave-Teilnehmer gleichzeitig mit einer internen Datenrate von 100 Megabit/Sekunde arbeiten können.
  • Der Prozessor, der den Datenzugriff auf den Speicher im Slave-Teilnehmer ausführt, kann mit einer Taktrate betrieben werden, die um Größenordnungen geringer ist als die Datenübertragungsrate auf dem Übertragungsweg, ohne dass der Telegrammdurchlauf über die technisch vorgegebene Verzögerung beim Durchlauf im Nanosekundenbereich hinaus aufgehalten wird. Dem Prozessor wird nämlich durch die beabstandete Anordnung des Steuerdatenfeldes vom Nutzdatenfeld im Schreibdatagramm zusätzlich Zeit für den Zugriff auf den Speicher eingeräumt, um die adressierten Daten für das Einschreiben in das Nutzdatenfeld bereitzustellen. Der Verzicht auf Hochleistungsprozessoren reduziert die Hardwarekosten der Slave-Teilnehmer und hält gleichzeitig deren Verlustleistung, die sich bei einer höheren Prozessorleistung ergeben würde, niedrig.
  • Die Erfindung wird nachfolgend unter Bezugnahme auf die beigefügten Zeichnungen näher erläutert. Gleiche Bezugszeichen bezeichnen dabei gleiche oder äquivalente Komponenten.
  • 1 zeigt schematisch den Aufbau eines seriellen Bussystems, auf dem die Erfindung verwirklicht werden kann,
  • 2 zeigt schematisch den Aufbau eines Schreibdatagramms, wie es im Rahmen der Erfindung eingesetzt werden kann, und
  • 3 zeigt schematisch den Aufbau eines Telegramms, wie es im Rahmen der Erfindung eingesetzt werden kann.
  • In der Industrieautomation werden Kommunikationsnetzwerke in Form von seriellen Bussystemen eingesetzt, bei denen dezentral angeordnete Geräte mit Steuerungseinrichtungen kommunizieren. Die Teilnehmer sind dabei über einen Feldbus miteinander vernetzt. Der Datenaustausch zwischen den Teilnehmern erfolgt auf der Grundlage des Master-Slave-Prinzips. Die aktiven Busteilnehmer, auch als Master-Teilnehmer bezeichnet, sind die Steuereinrichtungen, die im Besitz der Buszugriffsberechtigung sind und den Datentransfer auf dem seriellen Bus bestimmen. Die Geräte der Maschinenperipherie, auch als Slave-Teilnehmer bezeichnet, bilden dagegen die passiven Busteilnehmer, die keine Buszugriffsberechtigung besitzen, das heißt nur empfangene Nachrichten quittieren oder auf Anfrage eines Master-Teilnehmers Nachrichten an diesen übermitteln dürfen.
  • Feldbussysteme mit Master-Slave-Architektur werden mit unterschiedlichen Übertragungsprotokollen betrieben, wobei bevorzugt Protokolle auf der Grundlage der Ethernet-Technologie eingesetzt werden. Bei der Ethernet-Technologie werden die Daten paketorientiert übertragen. Das Ethernet-Datenpaket ist standardmäßig 1518 Byte lang, wobei 18 Byte für einen Kopfabschnitt und einen Endabschnitt reserviert sind. Im Kopfabschnitt des Ethernet-Datenpaketes ist ein Datenfeld vorgesehen, in dem festgelegt ist, mit welchem Ethernet-Protokolltyp die Nutzdaten im Ethernet-Datenpaket interpretiert werden sollen.
  • In der Industrieautomation werden vorzugsweise Protokoll-Typen eingesetzt, die eine Echtzeitfähigkeit garantieren. Ein solcher Echtzeit-Standard ist das EtherCAT-Protokoll, bei dem die Verarbeitung der Nutzdaten im Ethernet-Datenpaket durch die Slave-Teilnehmer im Durchlauf erfolgt. Beim EtherCAT-Protokoll ist der Nutzdatenblock im Ethernet-Telegramm in ein EtherCAT-Kopfteil, im Weiteren auch als EtherCAT-Header bezeichnet, und ein oder mehrere EtherCAT-Datagramme aufgeteilt. Der EtherCAT-Header enthält Kenndatenfelder, die unter anderem die Länge der EtherCAT-Datagramme festlegen.
  • Die EtherCAT-Datagramme sind wiederum in einen Kopf- und einen Endabschnitt und einen dazwischen liegenden Nutzdatenabschnitt unterteilt. Im Kopfabschnitt des Datagramms, auch als Datagramm-Header bezeichnet, ist dabei ein Befehlsfeld, das den mit dem Slave-Teilnehmer auszuführenden Datenübertragungsvorgang festlegt, und ein Adressfeld, das den Datenbereich im Slave-Teilnehmer bezeichnet, mit dem der Slave-Teilnehmer beim Durchlauf des Nutzdatenabschnitts in Datagramm Daten austauschen soll, vorgesehen.
  • In der Automatisierungstechnik haben sich Ethernet-basierte Feldbusprotokolle mit einer Datenübertragungsrate 100 Mbit/s etabliert. Um schnellere Steuerungsvorgänge ausführen zu können, ist es Zielsetzung in der Industrieautomation zukünftig bei Ethernet-Systemen auch Übertragungsgeschwindigkeiten von 1 Gbit/s oder mehr verwenden zu können, wie sie bereits im Konsumerbereich für die Datenübertragung eingesetzt werden. Um solche schnellen Kommunikationsnetzwerke effektiv zur Steuerung nutzen zu können, müssen die Slave-Teilnehmer am Kommunikationsnetzwerk dann jedoch auch eine entsprechende schnelle Datenverarbeitung ausführen, um die Daten für die Datenübertragung rechtzeitig bereitzustellen und so eine Verzögerung im Telegrammverkehr zu vermeiden. Dies macht aber in den Slave-Teilnehmern Hochleistungsprozessoren und damit eine teure Hardware erforderlich. Außerdem führen schnellere Prozessoren zu einer höheren Verlustleistung.
  • Hinzu kommt, dass in der Automatisierungstechnik in der Regel eine Vielzahl von Slave-Teilnehmern über das serielle Bussystem miteinander kommunizieren, so dass bereits ein Slave-Teilnehmer im Verbund, der aufgrund mangelnder interner Verarbeitungsgeschwindigkeit seine Daten nicht ausreichend schnell für den Telegrammverkehr bereitstellt, die Datenübertragung entscheidend verzögern kann.
  • Bei einem Kommunikationsnetzwerk mit einer Master-Slave-Architektur, bei die Slave-Teilnehmer mit dem vom Master-Teilnehmer ausgegebenen Telegramm Daten im Durchlauf austauschen, kann eine ungewünschte Verzögerung beim Telegramm-Durchlauf insbesondere dann auftreten, wenn das Telegramm wenigstens ein Datagramm aufweist, das ein Schreibdatagramm ist, bei dem das Befehlsfeld den von einem Slave-Teilnehmer auszuführenden Datenübertragungsvorgang mit dem Nutzdatenfeld als Schreibvorgang festlegt. In diesem Fall muss nämlich der Slave-Teilnehmer, wenn er nach der Auswertung des Befehlsfeldes und des Adressfeldes im Steuerdatenfeld des Datagramms feststellt, dass das Datagramm ein Schreibdatagramm ist und ein Datenbereich im Slave-Teilnehmer adressiert ist, die Daten bereitstellen, bevor das Nutzdatenfeld des Datagramms vom Slave-Teilnehmer empfangen wird, um beim Durchlauf des Nutzdatenfeldes Daten verzögerungsfrei in das Datagramm einschreiben zu können.
  • Der Slave-Teilnehmer hat, um eine Verzögerung des Telegramm-Durchlaufs zu verhindern, dann nur die Zeit zum Bereitstellen der Daten zur Verfügung, die benötigt wird, um die Daten im Telegramm zu übertragen, die sich zwischen dem Steuerdatenfeld des Schreibdatagramms und dem Nutzdatenfeld des Schreibdatagramms befinden. Diese zwischen dem Steuerdatenfeld und dem Nutzdatenfeld im Schreibdatagramm angeordneten Daten beschränken sich standardmäßig auf wenige Bytes.
  • Als Schreibdatagramm wird im Weiteren auch ein gemischtes Datagramm gekennzeichnet, bei dem neben einem Einschreiben von Daten in das Nutzdatenfeld zusätzliche auch ein Auslesen von Daten aus dem Nutzdatenfeld durch den Slave-Teilnehmer ausgeführt werden sollen.
  • Bei Lesedatagrammen, bei denen das Befehlsfeld den vom Slave-Teilnehmer auszuführenden Datenvorgang mit dem Nutzdatenfeld als Lesevorgang festlegt, muss der Slave-Teilnehmer dem Nutzdatenfeld des Lesedatagramms nur Daten entnehmen, wobei die weitergehende Verarbeitung der entnommenen Daten im Slave-Teilnehmer dann zu einem späteren Zeitpunkt nach Durchlauf des Telegramms durchgeführt werden kann. Die interne Datenverarbeitungsgeschwindigkeit im Slave-Teilnehmer ist deshalb in Bezug auf den Telegramm-Durchlauf unkritisch bei Lesedatagrammen.
  • Um bei Schreibdatagrammen die Datenlänge zwischen dem Steuerdatenfeld des Schreibdatagramms und dem Datenbereich im Nutzdatenfeld des Schreibdatagramms, in das der Slave-Teilnehmer Daten einfügen soll, zu vergrößern und damit dem Slave-Teilnehmer mehr Zeit zum Bereitstellen der Daten zu geben, wird erfindungsgemäß die Telegrammstruktur so ausgeführt, dass im Telegramm zwischen dem Steuerdatenfeld des Schreibdatagramms und dem Nutzdatenfeld des Schreibdatagramms wenigstens ein Steuerdatenfeld eines weiteren Datagramms eingefügt ist. Mit der Aufteilung der Schreibdatagramme und der getrennten Anordnung von Steuerdatenfeld und Nutzdatenfeld des Schreibdatagramms mit zwischengeschobenem Steuerdatenfeld eines weiteren Datagramms wird die Zeit, die sich zwischen dem Empfang des Steuerdatenfeldes des Schreibdatagramms und dem Empfang des adressierten Nutzdatenbereiches im Nutzdatenfeld für den Slave-Teilnehmer ergibt, die Daten von der geforderten physikalischen Adresse im Slave-Teilnehmer zu holen und für das Einschreiben in den adressierten Nutzdatenbereich im Nutzdatenfeld des Lesedatagramms bereitzustellen, verlängert. Der Slave-Teilnehmer kann so mit einer internen Taktrate betrieben werden, die wesentlich geringer ist als die Datenübertragungsrate auf dem Übertragungsweg. Auf dem Übertragungsweg kann dann beispielsweise ein schnelles 1- bzw. 10-Gbit-Ethernetprotokoll eingesetzt werden, wohingegen der Slave-Teilnehmer intern den Speicherzugriff mit einer Taktrate von 100 Mbit/s ausführt.
  • Die Aufteilung und Anordnung der Schreibdatagramme im Telegramm durch den Master-Teilnehmer erfolgt dabei vorzugsweise so, dass zuerst die Steuerdatenfelder aller Schreibdatagramme angeordnet sind und dann erst die zugehörigen Nutzdatenfelder aller Schreibdatagramme, wodurch sich der Bitbestand zwischen Steuerdatenfeld und Nutzdatenfeld auf einfache Weise weiter vergrößern lässt. Um dem Slave-Teilnehmer noch mehr Zeit nach dem Auswerten des Steuerdatenfeldes im Schreibdatagramm für das Bereitstellen der Nutzdaten zum Einschreiben in das Nutzdatenfeld des Schreibdatagramms zu geben, werden auch die Lesedatagramme zwischen den Steuerdatenfeldern der Schreibdatagramme und den Nutzdatenfeldern der Schreibdatagramme angeordnet.
  • Ferner besteht die Möglichkeit, um das Kommunikationsnetzwerk flexibel auslegen zu können, dass der Master-Teilnehmer sowohl Telegramme ausgeben kann, in denen das Steuerdatenfeld und das Nutzdatenfeld der Schreibdatagramme verteilt angeordnet sind, und Telegramme, bei denen eine solche Aufteilung der Schreibdatagramme nicht erfolgt. Der Master-Teilnehmer kann dann jeweils individuell auf die Auslegung der Slave-Teilnehmer im Kommunikationsnetzwerk reagieren und Telegramme mit aufgeteilten Schreibdatagrammen beispielweise nur dann versenden, wenn die Slave-Teilnehmer aufgrund einer gegenüber der Datenübertragungsrate auf dem Datenübertragungsweg reduzierten internen Taktrate einen verlängerten Bitabstand zwischen dem Empfang des Steuerdatenfeldes im Schreibdatagramm und dem Empfang des entsprechend adressierten Nutzdatenfeldbereiches im Schreibdatagramm benötigen, um die einzuschreibenden Daten bereitzustellen.
  • Auch kann der Slave-Teilnehmer so ausgelegt werden, dass zwei Betriebsarten unterstützt werden. In einer ersten Betriebsart werden die Schreibdaten aufgrund einer ausreichend hohen Verzögerung rechtzeitig bereitgestellt, weshalb die Schreibdatagramme nicht aufgeteilt werden. In der zweiten Betriebsart werden die Schreibdatagramme aufgeteilt, und der Slave-Teilnehmer arbeitet mit geringerer Latenz. Das Umschalten zwischen den beiden Betriebsarten kann vorzugsweise durch den Master-Teilnehmer erfolgen. Beim Einschalten ist zunächst die erste Betriebsart mit höherer Latenz aktiv, wodurch sichergestellt ist, dass der Master-Teilnehmer auch mit Slave-Teilnehmern kommunizieren kann, die keine Aufteilung der Schreibdatagramme beherrschen. Der Master-Teilnehmer prüft dann die Slave-Teilnehmer im Netzwerk auf Kompatibilität mit aufgeteilten Schreibdatagrammen und schaltet anschließend die Slave-Teilnehmer, die die Aufteilung der Schreibdatagramme ausführen können, in die zweite Betriebsart mit geringer Latenz um.
  • Die Erfindung wird im Folgenden am Beispiel eines Ethernetbasierten Feldbussystems erläutert, bei dem zur Datenübertragung das EtherCAT-Protokoll verwendet wird. Die Erfindung ist jedoch nicht auf das EtherCAT-Protokoll beschränkt. Die Erfindung lässt sich grundsätzlich bei allen Kommunikationsnetzwerken einsetzen, bei der die Teilnehmer die Telegramme im Durchlauf verarbeiten.
  • 1 zeigt schematisch eine mögliche Auslegung eines Feldbussystems. Das Feldbussystem weist einen Datenübertragungsweg 1 auf, beispielsweise eine elektrische Leitung oder ein Lichtleiter. An dem Übertragungsweg 1 sind die Busteilnehmer angeschlossen, wobei zwischen den aktiven Busteilnehmern, das heißt den Master-Teilnehmern, und den passiven Busteilnehmern, das heißt den Slave-Teilnehmern, unterschieden wird. In 1 ist eine Ausgestaltung mit einem Master-Teilnehmer 2 und vier Slave-Teilnehmern 3 gezeigt.
  • Bei der EtherCAT-Technologie besteht die Möglichkeit, einen Master-Teilnehmer mit bis zu 65534 Slave zu vernetzen. Der Master-Teilnehmer 2 und die Slave-Teilnehmer 3 können dabei direkt an den Übertragungsweg 1 angeschlossen oder über einen eigenständigen Interface-Baustein mit dem Übertragungsweg 1 verbunden sein. Zur Verdeutlichung der Erweiterungsmöglichkeit des Netzwerkes sind zwischen dem zweiten und dem dritten Slave-Teilnehmer 3 Kreise als Platzhalter eingezeichnet.
  • Die Ausführung der Datenübertragung auf den Übertragungsweg 1 wird durch das Kommunikationsprotokoll, in vorliegenden Fall das EtherCAT-Protokoll, festgelegt. Das EtherCAT-Protokoll ist im Master-Teilnehmer 2 in einer Feldbusanschaltung 23 implementiert. Die für die Slave-Teilnehmer 3 notwendigen Kommunikationsprotokollteile sind in einer Slave-Anschaltung 33 abgespeichert.
  • Das EtherCAT-Netzwerk stellt logisch einen offenen Ringbus dar, bei dem der Master-Teilnehmer 2 an einem Ende Telegramme auf den Übertragungsweg 1 ausgibt und diese am anderen Ende, von den Slave-Teilnehmern 3 verarbeitet zurückerhält. Wie 1 zeigt, weisen der Master-Teilnehmer 2 und jeder Slave-Teilnehmer 3 jeweils einen Sender 22, 32 zum Verschicken der Telegramme auf dem Übertragungsweg 1 und einen Empfänger 21, 31, zum Empfang der Telegramme auf dem Übertragungsweg 1 auf.
  • Die Telegrammübertragung erfolgt dabei so, dass die Feldbusanschaltung 23 des Master-Teilnehmers 2 über seinen Sender 22 das Telegramm 1 an den vom Sender 22 im Master-Teilnehmer 2 ausgesehen ersten Slave-Teilnehmer 3 am Übertragungsweg 1 ausgibt. Der erste Slave-Teilnehmer 3 empfängt das Telegramm über seinen Empfänger 31, verarbeitet das Telegramm im Durchlauf durch seine Slave-Anschaltung 33 und leitet das verarbeitete Telegramm dann, nur um einige Bits verzögert, über seinen Sender 32 zum nächsten Slave-Teilnehmer am Übertragungsweg 1 weiter. Der letzte Slave-Teilnehmer am Übertragungsweg 1 schickt das von allen Slave-Teilnehmer am Übertragungsweg 1 verarbeitete Telegramm dann an den Empfänger 21 des Master-Teilnehmers 2 zurück.
  • Beim EtherCAT-Netzwerk ist der Übertragungsweg in der Regel direktional ausgebildet, wobei das Netzwerk vom Master-Teilnehmer aus gesehen einen physikalischen Strang bildet und die Telegramme von alle Slave-Teilnehmer zweimal durchlaufen werden und zwar auf dem Hinweg und auf dem Rückweg. Die Telegrammbearbeitung durch die Slave-Teilnehmer im Durchlauf erfolgt beim EtherCAT-Netzwerk vorzugsweise auf dem Hinweg. Der Rückweg dient zur Signalverstärkung und zum Lokalisieren und dem Schließen von Unterbrechungen auf dem Übertragungsweg. Beim EtherCAT-Netzwerk kann die Strangstruktur dabei durch Abzweigungen an beliebigen Slave-Teilnehmern auch zu einer flexiblen Baumstruktur ausgebaut sein.
  • Die Telegrammerzeugung erfolgt in der Feldbusanschaltung 23 des Master-Teilnehmers 2. Beim EtherCAT-Protokoll erzeugt die Feldbusanschaltung 23 im Master-Teilnehmer 2 dabei ein Ethernet-Telegramm, wie es in 3 gezeigt ist, das sich aus einem Kopfdatenfeld 100, im Weiteren auch als Ethernet-Header bezeichnet, einem Nutzdatenfeld 200 und einem Prüfzeichenfeld 300 am Ende zusammensetzt. Im Ethernet-Header 100 sind die Ziel- und Quelladresse festgelegt. Weiterhin ist im Ethernet-Header 100 angegeben, mit welchem Protokoll die Daten im Nutzdatenfeld 200 zu interpretieren sind. Beim EtherCAT-Netzwerk, dem dargestellten Ausführungsbeispiel, wird hier das EtherCAT-Protokoll angezeigt. Das Prüfzeichenfeld 300 am Ende Ethernet-Telegramm gibt eine so genannte FCS (Frame Check Sequence) an, um Fehler bei der Datenübertragung erkennen zu können.
  • Das Nutzdatenfeld 200 in der Mitte des Ethernet-Telegramms enthält dann das eigentliche EtherCAT-Datenpaket, das beim Standard-Ethernet-Telegrammrahmen eine Länge von bis zu 1500 Bytes aufweisen kann. Das EtherCAT-Datenpaket setzt sich wiederum aus einem Kopfteil 210, auch als EtherCAT-Header bezeichnet, und mehreren Datagrammen 220 zusammen. Die Datagramme 220 weisen jeweils ein Steuerdatenfeld 221 und ein Nutzdatenfeld 222 auf. 2 zeigt beispielhaft den Datagrammaufbau. Das Steuerdatenfeld 221 des Datagramms 220 umfasst ein Befehlsfeld Cmd, ein Identifikationsfeld Idx, ein Adressfeld Address, ein Längenfeld Length und ein Interrupt-Feld IRQ. Das Nutzdatenfeld 222 umfasst ein Datenfeld Data und ein Endfeld WKC.
  • Das Befehlsfeld Cmd gibt unter anderem an, auf welche Weise das Datagramm vom Slave-Teilnehmer verarbeitet werden soll. Das Befehlsfeld Cmd kann dabei mit einem ersten Wert ein Lesedatagramm kennzeichnen, das heißt ein Datagramm, bei dem der Inhalt des Nutzdatenfeldes Data im Datagramm von den Slave-Teilnehmern 3 ausgelesen werden soll. Mit einem zweiten Wert kann das Befehlsfeld CMD das Datagramm alternativ als Schreibdatagramm kennzeichnen, das heißt also ein Datagramm, in dessen Nutzdatenfeld Data Daten von den Slave-Teilnehmern 3 geschrieben werden sollen. Gemäß eines dritten Werts kann das Befehlsfeld CMD das Datagramm auch als Schreiblesedatagramm kennzeichnen, bei dem sowohl ein Auslesen von Daten aus dem Nutzdatenfeld Data als auch ein Einschreiben von Daten in das Nutzdatenfeld Data durch die Slave-Teilnehmer 3 ausgeführt werden sollen. Solche gemischten Datagramme werden im Weiteren wie Schreibdatagramme behandelt. Mit einem vierten Wert kann das Befehlsfeld CMD das Datagramm als Leerdatagramm kennzeichnen, so dass die Slave-Teilnehmer 3 das Nutzdatenfeld Data unverändert lassen.
  • Mit dem Identifikationsfeld Idx kennzeichnet der Master-Teilnehmer 2 das Datagramm 220, um es nach dem Empfang wieder einfach zuordnen zu können. Das Adressfeld Address gibt an, welcher oder welche Slave-Teilnehmer 3 ausgewählt werden, um den im Befehlsfeld Cmd vorgegebenen Datenaustauschvorgang auszuführen. Die Adressierung kann dabei auf verschiedene Weise angepasst an die Netzwerkanforderungen erfolgen. Es besteht die Möglichkeit einer physikalischen Adressierung eines einzelnen Slave-Teilnehmers 3, einer Mehrzahl von Slave-Teilnehmern 3 oder auch aller Slave-Teilnehmer 3 im Rahmen von Broadcast-Telegrammen. Alternativ kann jedoch auch eine logische Adressierung durchgeführt werden. Bei der logischen Adressierung erfolgt vorab eine Zuordnung der physikalischen Adressen der Slave-Teilnehmer 3 zu logischen Adressen, wobei die Zuordnung in FMMU-Einheiten (Fieldbus Memory Management Unit), die Teil der Slave-Anschaltungen 33 der Slave-Teilnehmer 3 sind, voreingespeichert ist.
  • Die Slave-Anschaltung 33 im Slave-Teilnehmer 3 überprüft dann bei Empfang eines Datagramms 220 mit logischer Adressierung, ob eine Adressenübereinstimmung mit den eingespeicherten logischen Adressen vorliegt und bestimmt dann die entsprechende zugeordnete physikalische Adresse im Slave-Teilnehmer 3. Mit der logischen Adressierung ist es möglich, beliebige Speicherbereiche im Slave-Teilnehmer 3 auch Bit-weise auf beliebige logische Adressen abzubilden und damit eine Vielzahl von Slave-Teilnehmern 3 gleichzeitig beispielsweise mit einem Datagramm 220 anzusprechen. Die logische Adressierung eignet sich insbesondere zur Übertragung von Prozessdaten zwischen dem Master-Teilnehmer 2 und den Slave-Teilnehmern 3. Die physikalische Adressierung wird vorzugsweise zur Übertragung von Parameterdaten genutzt.
  • Das Längenfeld Length im Steuerdatenfeld 221 des Datagramms 220 zeigt die Länge des Datenfeldes Data im Nutzdatenfeld 222 an. Das Interruptfeld IRQ definiert einen vom Slave-Teilnehmer 3 an den Master-Teilnehmer 2 anzuzeigenden Interrupt.
  • Mit dem Datenfeld Data im Nutzdatenfeld 222 des Datagramms 220 werden die zwischen dem Master-Teilnehmer 2 und den Slave-Teilnehmern 3 auszutauschenden Daten übermittelt. Das Endfeld WKC im Nutzdatenfeld 222 des Datagramms 220 ist ein Working Counter, der von jedem Slave-Teilnehmer 3 inkrementiert wird, der adressiert ist, und das Datagramm 220 erfolgreich bearbeitet hat.
  • Wie in 1 dargestellt, ist die Feldbusanschaltung 23 im Master-Teilnehmer 2 mit einem Prozessor 24 im Master-Teilnehmer 2 verbunden, der wiederum mit einem Speicher 25 kommuniziert. Der Prozessor 24 des Master-Teilnehmers 2 führt die Steuerungsaufgaben durch, wobei der Prozessor 24 für einzelne Steueraufgaben Eingangsprozessabbilder nutzt, um daraus Ausgangsprozessabbilder zu bestimmen. Den Eingangs- und Ausgangsprozessabbildern der einzelnen Steuerungsaufgaben ist dabei in der Regel jeweils wenigstens ein Datagramm zugeordnet. Die Schreibdatagramme dienen dabei dazu, die Eingangsprozessabbilder für die Steuerungsaufgabe zu liefern, wobei die Slave-Teilnehmer die entsprechenden Nutzdaten in die Schreibdatagramme einschreiben. Die Ausgangsprozessabbilder werden mit den Lesedatagrammen auf die Slave-Teilnehmer übertragen, die die zugeordneten Nutzdaten dann übernehmen.
  • Die Bearbeitung der Datagramme 220 in den Slave-Teilnehmern 3 findet im Durchlauf durch die Slave-Anschaltung 33 statt. Das Telegramm wird dann um wenige Bits verzögert vom Sender 32 im Slave-Teilnehmer 3 zum nächsten Slave-Teilnehmer 3 übertragen. Die Slave-Anschaltung 33 im Slave-Teilnehmer 3 wertet das Steuerdatenfeld 221 des Datagramms 220 aus, um anhand des Befehlsfeldes Cmd festzustellen, welcher Datenübertragungsvorgang mit dem Nutzdatenfeld des Datagramms 220 ausgeführt werden soll. Anhand des Adressfeldes Address ermittelt die Slave-Anschaltung 33 im Slave-Teilnehmer 3 dann, ob ein Datenbereich in dem Slave-Teilnehmer 3 adressiert ist, mit dem der Slave-Teilnehmer 3 beim Durchlauf des Nutzdatenfeldes 222 Data Daten austauschen soll.
  • Die Slave-Anschaltung 33 des Slave-Teilnehmers 3 ist, wie in 1 gezeigt, mit einem Prozessor 34 verbunden, der wiederum mit einem Speicher 35 kommuniziert, um die für den Slave-Teilnehmer vorgesehenen Nutzdaten zu verarbeiten. Bei einem Lesedatagramm liest die Slave-Anschaltung 33 beim Durchlauf des Datenfeldes Data im Datagramm 220 des Telegramms die dem Slave-Teilnehmer 3 zugeordneten Nutzdaten aus und reicht die Nutzdaten an den Prozessor 34 weiter. Der Prozessor 34 speichert die Nutzdaten dann in die adressierten Speicherbereiche im Slave-Teilnehmer 3. Bei einem Schreibdatagramm entnimmt der Prozessor 34 den adressierten Speicherbereichen im Slave-Teilnehmer 3 die Nutzdaten und stellt die Nutzdaten der Slave-Anschaltung 33 im Slave-Teilnehmer 3 zur Verfügung, damit die Slave-Anschaltung 33 die Nutzdaten, wenn der zugeordnete Bereich im Datenfeld Data des Datagramms im Slave-Teilnehmer durchläuft, einschreiben kann.
  • Für das Bereitstellen der Nutzdaten beim Durchlauf des Schreibdatagramms steht dem Prozessor 34 im Slave-Teilnehmer 3 dabei die Zeit zur Verfügung, die die Daten im Schreibdatagramm des Telegramms für den Durchlauf durch den Slave-Teilnehmer 3 benötigen, erhöht um die Zeit, die zwischen dem Steuerdatenfeld im Schreibdatagramm und dem adressierten Datenbereich im Nutzdatenfeld des Schreibdatagramms, in das der Slave-Teilnehmer 3 die Nutzdaten einschreiben soll, vergeht.
  • Um einen vergrößerten zeitlichen Abstand zwischen dem Empfang des Steuerdatenfeldes 221 und dem Empfang des Nutzdatenfeldes 222 im Schreibdatagramm zu erreichen, verwendet der Master-Teilnehmer 2 eine spezielle Telegrammstruktur, wobei in 3 eine mögliche Ausführungsform gezeigt ist. Das Ethernet-Telegramm wird von der Feldbusanschaltung 23 im Master-Teilnehmer 2 grundsätzlich so zusammengestellt und auf den Übertragungsweg 1 ausgegeben, dass das Schreibdatagramm unterteilt im Telegramm angeordnet ist, wobei zwischen dem Steuerdatenfeld und dem Nutzdatenfeld des Schreibdatagramms wenigstens das Steuerdatenfeld eines weiteren Datagramms angeordnet ist.
  • Bei der in 3 gezeigten Telegrammauslegung sind im Ethernet-Telegramm nach dem Ethernet-Header 100 und dem EtherCAT-Header 210 die Schreibdatagramm-Steuerdatenfelder S221a bis S221n aller Schreibdatagramme angeordnet, anschließend die Lesedatagramme L220a bis L220n und dann die Nutzdatenfelder S222a bis S222n der Schreibdatagramme sowie am Telegrammende das Prüffeld FCS 300. Um eine zusätzliche Verlängerung zu bewirken, besteht die Möglichkeit, neben den Lesedatagrammen L220a bis L220n zwischen dem Schreibdatagramm-Steuerdatenfeldern S221a bis S221n und den Schreibdatagramm-Nutzdatenfeldern S222a bis S222n weitere Datagramme (nicht gezeigt), die beispielsweise Parametern oder Diagnosedaten enthalten, einzufügen. Auch können Zusatzdatagramme (nicht gezeigt) in Form von Leerdatagrammen ohne besondere Funktion zur Bitabstand-Verlängerung zwischen den Schreibdatagramm-Steuerdatenfeldern S221a bis S221n und den Schreibdatagramm-Nutzdatenfeldern S222a bis S222n angeordnet werden.
  • Damit der Slave-Teilnehmer 3 erkennen kann, dass die Schreibdatagramme unterteilt sind, wobei zwischen dem Steuerdatenfeld des Schreibdatagramms und dem Nutzdatenfeld des Schreibdatagramms weitere Daten eingefügt sind, bestehen mehrere Möglichkeiten.
  • So kann der Master-Teilnehmer 2 die entsprechende Information beispielsweise mit einem Broadcast-Telegramm an die Slave-Teilnehmer 3 übermitteln. Es kann dabei auch vorab festgelegt werden, wie groß die Datenlänge im Telegramm zwischen dem Steuerdatenfeld des Schreibdatagramms und dem Nutzdatenfeld des Schreibdatagramms ist. Alternativ besteht die Möglichkeit, dass der Master-Teilnehmer 2 mit jedem Telegramm vorzugsweise im Ethernet-Header 100 oder im EtherCAT-Header 210 festlegt, dass im Telegramm die Schreibdatagramme unterteilt sind, wobei das Steuerdatenfeld und das Nutzdatenfeld getrennt, mit Datagrammen dazwischen angeordnet sind. Hierfür kann ein Kommandofeld im Ethernet-Header 100 oder im Ether-CAT-Header 210 als Kenndatenfeld genutzt werden. Für die Festlegung der Datenlänge im Telegramm zwischen dem Steuerdatenfeld des Schreibdatagramms und dem Nutzdatenfeld des Schreibdatagramms kann dann ein weiteres Kenndatenfeld im Ethernet-Header 100 oder im EtherCAT-Header 210 vorgesehen sein, das das entsprechende Datum angibt.
  • Alternativ besteht auch die Möglichkeit, dass im Steuerdatenfeld S221a bis S221n des Schreibdatagramms im Telegramm ein Kenndatenfeld vorgesehen ist, dessen Datum als Wert oder Längenangabe die Position des zugeordneten Nutzdatenfeldes S222a bis S222n angibt. Der Slave-Teilnehmer 3 kann dann durch Auswertung dieses Kenndatenfeldes, wenn das Schreibdatagramm an ihn adressiert ist, die Position des an ihn adressierten Bereichs im Nutzdatenfeld des Schreibdatagramms ermitteln.
  • Eine einfache Vorgehensweise, bei der außer der Angabe, dass die Schreibdatagramme jeweils aufgeteilt in ein Steuerdatenfeld und ein Nutzdatenfeld im Telegramm angeordnet sind, keine zusätzlichen Kennfelder erforderlich sind, kann erreicht werden, in dem das Steuerdatenfeld des Datagramms und das Nutzdatenfeld des Datagramms jeweils eine feste Datenlänge besitzen, wobei der Slave-Teilnehmer 3 dann, wenn das Kenndatenfeld des Telegramms anzeigt, dass bei den Schreibdatagrammen im Telegramm das Steuerdatenfeld und das Nutzdatenfeld getrennt angeordnet sind, die Anzahl der Schreibdatagramme erfasst werden. Der Slave-Teilnehmer 3 zählt die Schreibdatagramme beim Durchlauf des Telegramms mit, um, wenn ein Datenbereich im Slave-Teilnehmer 3 adressiert ist, durch Auswertung der Anzahl unter gleichzeitiger Kenntnis der festen Datagrammlänge nach Auswertung des Adressfeldes im Schreibdatagramm die entsprechende Position des zugehörigen Nutzdatenfeldes im Telegramm zu ermitteln.

Claims (14)

  1. Verfahren zur Datenübertragung in einem Kommunikationsnetzwerk, mit einem Datenübertragungsweg (1), über den ein Master-Teilnehmer (2) und zumindest ein Slave-Teilnehmer (3) miteinander in Verbindung stehen, wobei der Master-Teilnehmer (2) Telegramme (100, 200, 300) auf dem Datenübertragungsweg (1) ausgibt, mit denen der bzw. die Slave-Teilnehmer (3) im Durchlauf Daten austauschen, wobei die vom Master-Teilnehmer (2) ausgegebenen Telegramme (100, 200, 300) Datagramme (220) beinhalten, die jeweils ein Steuerdatenfeld (221) und ein Nutzdatenfeld (222) umfassen, wobei das Steuerdatenfeld (221) ein Befehlsfeld und ein Adressfeld aufweist, wobei das Befehlsfeld den von einem Slave-Teilnehmer (3) auszuführenden Datenübertragungsvorgang mit dem Nutzdatenfeld (222) und das Adressfeld den Datenbereich in dem Slave-Teilnehmer (3), mit dem der Slave-Teilnehmer (3) beim Durchlauf des Nutzdatenfeldes (222) Daten austauschen soll, festlegt, wobei bei wenigstens einem Telegramm (100, 200, 300), das wenigstens ein Datagramm (220) aufweist, das ein Schreibdatagramm ist, bei dem das Befehlsfeld den von einem Slave-Teilnehmer (3) auszuführenden Datenübertragungsvorgang mit dem Nutzdatenfeld (S222) als Schreibvorgang festlegt, zwischen dem Steuerdatenfeld (S221) des Schreibdatagramms und dem Nutzdatenfeld (S222) des Schreibdatagramms wenigstens das Steuerdatenfeld eines weiteren Datagramms (220) angeordnet ist.
  2. Verfahren nach Anspruch 1, wobei das Telegramm ein Kopfdatenfeld aufweist, das ein Kenndatenfeld umfasst, dessen Datum angibt, ob bei den Schreibdatagrammen im Telegramm das Steuerdatenfeld und das Nutzdatenfeld getrennt angeordnet sind.
  3. Verfahren nach Anspruch 2, wobei das Steuerdatenfeld des Datagramms und das Nutzdatenfeld des Datagramms jeweils eine feste Datenlänge besitzen, wobei die Slave-Teilnehmer (3), wenn das Kenndatenfeld im Kopfdatenfeld (100, 210) des Telegramms anzeigt, dass bei den Schreibdatagrammen im Telegramm das Steuerdatenfeld (S221) und das Nutzdatenfeld (S222) getrennt angeordnet sind, die Anzahl der Schreibdatagramme erfassen.
  4. Verfahren nach Anspruch 1 oder 2, wobei das Steuerdatenfeld (S221) des Schreibdatagramms im Telegramm ein Kenndatenfeld umfasst, aus dem sich die Position des zugeordneten Nutzdatenfeldes (S222) ergibt.
  5. Verfahren nach Anspruch 1 oder 2, wobei die Datenlänge im Telegramm zwischen dem Steuerdatenfeld (S221) des Schreibdatagramms und dem Nutzdatenfeld (S222) des Schreibdatagramms fest eingestellt ist.
  6. Verfahren nach einem der Ansprüche 1 bis 5, wobei die vom Master-Teilnehmer (2) ausgegebenen Telegramme so ausgelegt sind, dass zuerst die Steuerdatenfelder (S221) aller Schreibdatagramme im Telegramm angeordnet sind.
  7. Verfahren nach Anspruch 6, wobei im Telegramm nach den Steuerdatenfeldern (S221) der Schreibdatagramme die Lesedatagramme (L220), bei denen das Befehlsfeld den von einem Slave-Teilnehmer (3) auszuführenden Datenübertragungsvorgang mit dem Nutzdatenfeld als Lesevorgang festlegt, angeordnet sind.
  8. Verfahren nach einem der Ansprüche 1 bis 7, wobei die Datenübertragungsrate auf dem Datenübertragungsweg (1) beim Übertragen des Telegramms zwischen den Teilnehmern größer als die Datenübertragungsrate in wenigstens einem Slave-Teilnehmer 3 beim Durchlauf des Telegramms ist.
  9. Kommunikationsnetzwerk mit einem Datenübertragungsweg (1), über den ein Master-Teilnehmer (2) und zumindest ein Slave-Teilnehmer (3) miteinander in Verbindung stehen, wobei der Master-Teilnehmer (2) ausgelegt ist, Telegramme auf den Datenübertragungsweg (1) auszugeben, mit denen der bzw. die Slave-Teilnehmer (3) im Durchlauf Daten austauschen können, wobei die vom Master-Teilnehmer (2) ausgegebenen Telegramme (100, 200, 300) Datagramme (220) beinhalten, die jeweils ein Steuerdatenfeld (221) und ein Nutzdatenfeld (222) umfassen, wobei das Steuerdatenfeld (221) ein Befehlsfeld und ein Adressfeld aufweist, wobei das Befehlsfeld den von einem Slave-Teilnehmer (3) auszuführenden Datenübertragungsvorgang mit dem Nutzdatenfeld (222) und das Adressfeld den Datenbereich in dem Slave-Teilnehmer, mit dem der Slave-Teilnehmer (3) beim Durchlauf des Nutzdatenfeldes Daten austauschen soll, festlegt, wobei bei wenigstens einem Telegramm, das wenigstens ein Datagramm (220) aufweist, das ein Schreibdatagramm ist, bei dem das Befehlsfeld den von einem Slave-Teilnehmer (3) auszuführenden Datenübertragungsvorgang mit dem Nutzdatenfeld (S222) als Schreibvorgang festlegt, zwischen dem Steuerdatenfeld (S221) des Schreibdatagramms und dem Nutzdatenfeld (S222) des Schreibdatagramms wenigstens das Steuerdatenfeld eines weiteren Datagramms (220) angeordnet ist.
  10. Kommunikationsnetzwerk nach Anspruch 9, wobei das Kommunikationsnetzwerk ausgebildet ist, ein Verfahren gemäß einem der Ansprüche 2 bis 8 auszuführen.
  11. Kommunikationsnetzwerk nach Anspruch 9 oder 10, wobei das Kommunikationsnetzwerk ein Ethernet basierendes Feldbussystem ist.
  12. Master-Teilnehmer (2) für ein Kommunikationsnetzwerk mit einem Datenübertragungsweg (1), über den der Master-Teilnehmer (2) und zumindest ein Slave-Teilnehmer (3) miteinander in Verbindung stehen, der ausgelegt ist, Telegramme auf den Datenübertragungsweg (1) auszugeben, mit denen der bzw. die Slave-Teilnehmer (3) im Durchlauf Daten austauschen können, wobei die Telegramme (100, 200, 300) jeweils Datagramme (220) beinhalten, die jeweils ein Steuerdatenfeld (221) und ein Nutzdatenfeld (222) umfassen, wobei das Steuerdatenfeld (221) ein Befehlsfeld und ein Adressfeld aufweist, wobei das Befehlsfeld den von einem Slave-Teilnehmer (3) auszuführenden Datenübertragungsvorgang mit dem Nutzdatenfeld (222) und das Adressfeld den Datenbereich in dem Slave-Teilnehmer (3), mit dem der Slave-Teilnehmer (3) beim Durchlauf des Nutzdatenfeldes (222) Daten austauschen soll, festlegt, wobei bei wenigstens einem Telegramm, das wenigstens ein Datagramm (220) aufweist, das ein Schreibdatagramm ist, bei dem das Befehlsfeld den von einem Slave-Teilnehmer (3) auszuführenden Datenübertragungsvorgang mit dem Nutzdatenfeld (S222) als Schreibvorgang festlegt, zwischen dem Steuerdatenfeld (S221) des Schreibdatagramms und dem Nutzdatenfeld (S222) des Schreibdatagramms wenigstens das Steuerdatenfeld eines weiteren Datagramms (220) angeordnet ist.
  13. Master-Teilnehmer nach Anspruch 12, der ausgelegt ist, die Telegramme so aufzubauen, dass im Telegramm zuerst die Steuerdatenfelder (S222) aller Schreibdatagramme angeordnet sind.
  14. Master-Teilnehmer nach Anspruch 12 oder 13, der ausgelegt ist, die Telegramme so aufzubauen, dass im Telegramm nach den Steuerdatenfeldern (S222) der Schreibdatagramme die Lesedatagramme (L220), bei denen das Befehlsfeld den von einem Slave-Teilnehmer (3) auszuführenden Datenübertragungsvorgang mit dem Nutzdatenfeld als Lesevorgang festlegt, angeordnet sind.
DE102016125128.3A 2016-12-21 2016-12-21 Datenübertragungsverfahren, Kommunikationsnetzwerk und Master-Teilnehmer Active DE102016125128B3 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102016125128.3A DE102016125128B3 (de) 2016-12-21 2016-12-21 Datenübertragungsverfahren, Kommunikationsnetzwerk und Master-Teilnehmer
US15/840,794 US10848419B2 (en) 2016-12-21 2017-12-13 Data transmission method, communication network and master participant

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102016125128.3A DE102016125128B3 (de) 2016-12-21 2016-12-21 Datenübertragungsverfahren, Kommunikationsnetzwerk und Master-Teilnehmer

Publications (1)

Publication Number Publication Date
DE102016125128B3 true DE102016125128B3 (de) 2018-03-29

Family

ID=61564156

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102016125128.3A Active DE102016125128B3 (de) 2016-12-21 2016-12-21 Datenübertragungsverfahren, Kommunikationsnetzwerk und Master-Teilnehmer

Country Status (2)

Country Link
US (1) US10848419B2 (de)
DE (1) DE102016125128B3 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018215302A1 (de) * 2017-05-24 2018-11-29 Wago Verwaltungsgesellschaft Mbh Verarbeitung von prozessdaten

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3949284A1 (de) * 2019-03-26 2022-02-09 Lenovo (Singapore) Pte. Ltd. Extraktion von ethercat-datagrammen aus einem ethercat-frame
US11300936B2 (en) * 2019-03-26 2022-04-12 Lenovo (Singapore) Pte. Ltd. Extracting EtherCAT datagrams from an EtherCAT frame
CN112134771B (zh) * 2019-06-25 2022-03-29 青岛海尔电冰箱有限公司 用于冰箱的半双工通信方法与冰箱

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014109060B3 (de) 2014-06-27 2015-09-24 Beckhoff Automation Gmbh Netzwerk, Kopf-Teilnehmer und Datenübertragungsverfahren
DE102015120242B3 (de) 2015-11-23 2017-02-09 Beckhoff Automation Gmbh Verfahren zum Betreiben eines Kommunikationsnetzwerkes, Kommunikationsnetzwerk, Steuervorrichtung und Datenverarbeitungsvorrichtung

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7031904B1 (en) * 1999-01-26 2006-04-18 Adaptec, Inc. Methods for implementing an ethernet storage protocol in computer networks
JP5411725B2 (ja) * 2010-01-27 2014-02-12 株式会社日立産機システム 制御用ネットワークシステム、マスタ装置、制御用データ処理方法、および、制御用データ処理プログラム
EP2579513B1 (de) * 2010-05-27 2017-03-15 Panasonic Intellectual Property Management Co., Ltd. Knotenvorrichtung, integrierte schaltung und steuerverfahren in einem ringübertragungssystem
US8819170B2 (en) * 2011-07-14 2014-08-26 Schneider Electric It Corporation Communication protocols

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014109060B3 (de) 2014-06-27 2015-09-24 Beckhoff Automation Gmbh Netzwerk, Kopf-Teilnehmer und Datenübertragungsverfahren
DE102015120242B3 (de) 2015-11-23 2017-02-09 Beckhoff Automation Gmbh Verfahren zum Betreiben eines Kommunikationsnetzwerkes, Kommunikationsnetzwerk, Steuervorrichtung und Datenverarbeitungsvorrichtung

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018215302A1 (de) * 2017-05-24 2018-11-29 Wago Verwaltungsgesellschaft Mbh Verarbeitung von prozessdaten
CN110679118A (zh) * 2017-05-24 2020-01-10 Wago管理有限责任公司 处理过程数据
US11580040B2 (en) 2017-05-24 2023-02-14 Wago Verwaltungsgesellschaft Mbh Synchronized processing of process data and delayed transmission

Also Published As

Publication number Publication date
US10848419B2 (en) 2020-11-24
US20180176132A1 (en) 2018-06-21

Similar Documents

Publication Publication Date Title
DE102016125128B3 (de) Datenübertragungsverfahren, Kommunikationsnetzwerk und Master-Teilnehmer
DE102007004044B4 (de) Verfahren und Anlage zur optimierten Übertragung von Daten zwischen einer Steuereinrichtung und mehreren Feldgeräten
EP2109259B1 (de) Verfahren, Buskomponenten und Steuerungssystem zur Ethernet-basierten Steuerung eines Automatisierungssystems
EP3679691B1 (de) Datenübertragungsverfahren und kommunikationsnetzwerk
DE19934514C1 (de) Verfahren zum Konfigurieren eines an einen Feldbus angeschlossenen Busteilnehmers
EP1456722A2 (de) Datenübertragungsverfahren, serielles bussystem und anschalteinheit für einen passiven busteilnehmer
EP2961106B1 (de) Netzwerk, kopf-teilnehmer und datenübertragungsverfahren
DE102014108457B3 (de) Netzwerkverteiler
DE102014108455A1 (de) Verfahren zum Betreiben eines Netzwerks
EP3759871B1 (de) Master-slave bussystem und verfahren zum betrieb eines bussystems
EP3854035B1 (de) Datenübertragungsverfahren und automatisierungskommunikationsnetzwerk
DE102014105207B4 (de) Verfahren zum Betreiben eines Kommunikationsnetzwerks und Kommunikationsnetzwerk
EP1436950B1 (de) Teilnehmergerät für ein hochperformantes kommunikationssystem
EP1642207B1 (de) Zuordnung von stationsadressen zu kommunikationsteilnehmern in einem bussystem
DE10329179A1 (de) Anordnung und Verfahren zur Verwaltung eines Speichers
EP1371184B1 (de) Elektronischer schaltkreis und verfahren für eine kommunikationsschnittstelle mit zwischenspeicherung
DE102018010209A1 (de) Master-Slave Bussystem und Verfahren zum Betrieb eines Bussystems
DE10141187B4 (de) Elektronischer Schaltkreis und Verfahren für eine Kommunikationsschnittstelle mit Zwischenspeicherung
EP4073983B1 (de) Verfahren zur datenkommunikation zwischen teilnehmern eines automatisierungssystems
EP3590235B1 (de) Datenübertragungsverfahren und automatisierungskommunikationsnetzwerk
EP1430657B1 (de) Verfahren zur erstellung einer dynamischen adresstabelle für einen koppelknoten in einem datennetz und verfahren zur übertragung eines datentelegramms
EP4070530B1 (de) Verfahren zum zyklischen übertragen von daten zwischen kommunikationsteilnehmern auf einem datenübertragungskanal und datenübertragungssystem
DE102005019105A1 (de) Kommunikationssystem
DE10228823A1 (de) Verfahren zum Betrieb eines isochronen, zyklischen Kommunikationssystems
DE10234148A1 (de) Teilnehmer für ein hochperformantes Kommunikationssystem

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final