Anhang. Schneider Electric 140NOE771.. TCP/IP Modbus Ethernet-Module, 140NOE771.. Modules Ethernet TCP/IP Modbus
বিজ্ঞাপন
বিজ্ঞাপন
31002922 10/2009
Anhang
Übersicht
Weiteres Referenzmaterial zur Quantum-Modulserie NOE 771 •• finden Sie in den
Anhängen.
Inhalt dieses Anhangs
Dieser Anhang enthält die folgenden Kapitel:
Kapitel
A
B
C
D
Kapitelname
Technische Daten
Ethernet-Entwicklerhandbuch
Quantum Ethernet TCP/IP Modbus Anwendungs-Protokoll
Leistungsstatistik des E/A-Verwalters für die Module NOE 771
-00, -01 und -11
Seite
31002922 10/2009
245
246
31002922 10/2009
Technische Daten
31002922 10/2009
Technische Daten
A
Technische Daten
Tabelle der technischen Daten
Kommunikationsports
Programmiersoftware
Typ und Version
Ein Port, selbstabtastend, 10/100Base-T, geschirmt, twistedpair (RJ-45-Stecker) und ein Port, 100Base-FX (MT-RJ-
Stecker). Beide Ports senden und empfangen in einem TCP/IP-
Protokoll gekapselte Modbus-Befehle.
Maximale Stromaufnahme 750 mA
Verlustleistung 3,8 W
Sicherung Keine
Concept, Ver. 2.2 oder höher
Modlink, Ver. 2.0 oder höher
Modsoft, Ver. 2.6 oder höher
ProWORX NxT, Ver. 2.1 oder höher
Firmware
CPU-Typ und Version
NOE ausbaufähig
Betriebsbedingungen
Quantum-Executive, Ver. 2.0 oder höher
Kundenseitig ausbaufähig über FTP oder Programmiergerät
Temperatur
Rel. Luftfeuchtigkeit
Höhe
Schwingung
0 bis +60
°
C
0 bis 95 % rel. Luftfeuchtigkeit nicht kondensierend bei 60
°
C
4.500 m
10-57 Hz bei 0,0075 mm D.A
57-150 Hz bei 1 g
Lagerbedingungen
Temperatur
Rel. Luftfeuchtigkeit
Freier Fall
Stoß
-40 bis +85
°
C
0 bis 95 % rel. Luftfeuchtigkeit nicht kondensierend bei 60
°
C
1 m unverpackt
3 Stöße / Achse, 15 g, 11 ms
31002922 10/2009
247
Technische Daten
248
31002922 10/2009
Ethernet-Entwicklerhandbuch
31002922 10/2009
Ethernet-Entwicklerhandbuch
B
Einführung
Dieses Kapitel dient zur Unterstützung des Ethernet-Entwicklers.
Inhalt dieses Kapitels
Dieses Kapitel enthält die folgenden Themen:
Thema
Übersicht
Beschreibungen der Klassen
Klasse CSample_doc
Klasse CSample_View
Timer und Transaktionsverarbeitung
Sendezustandsmaschine
Empfangszustandsmaschine
Anzeige auf dem Bildschirm
Seite
249
31002922 10/2009
Ethernet-Entwicklerhandbuch
Übersicht
Einführung
In diesem Anhang wird der Aufbau der TCP/IP-Beispielanwendung beschrieben, die
Netzwerk-Options-Ethernet-Tester (NOET) genannt wird. Die NOET-Anwendung ist eine Multi-Dokument-Schnittstelle, die die Installation des Quantum Ethernet-
TCP/IP-Moduls prüft und auch als Beispielanwendung für Entwickler dient.
Die Portnummer 502 dse TCP/UDP-Systems wird mit ASA protocol_id 0 verwendet.
Referenzen
Inside Visual C++ , zweite Ausgabe, David J. Kruglinski
Window Sockets, An Open Interface for Network Programming under Microsoft®
Windows , Version 1.1
Funktion der Beispielanwendung z z z z
Die Beispielanwendung führt Folgendes durch:
Aufruf der Fenster-Socket-Funktion socket zum Erstellen eines Sockets
Aufruf der Fenster-Socket-Funktion setsockopt zum Einstellen der Socket-
Attribute z
Aufruf der Fenster-Socket-Funktion
Aufruf der Fenster-Socket-Funktion connect send
zum Aufbauen einer Verbindung
zum Senden des Requests an den dezentralen Teilnehmer
Aufruf der Fenster-Socket-Funktion recv zum Empfangen der Antwort des z dezentralen Teilnehmers
Aufruf der Fenster-Socket-Funktion closesocket zum Schließen der Verbindung und Freigeben des Sockets
Außerdem codiert die NOET den Request. Der Request besteht aus einem Header gefolgt von einer Modbus-Meldung.
Wie Sie in der folgenden Tabelle sehen, enthält der Header einen Aufruf-
Bezeichner, einen Protokolltyp, die Befehlslänge und eine Ziel-ID
Aufruf-Bezeichner Protokolltyp Befehlslänge Ziel-ID Modbus-Meldung
Die Import-Bibliothek winsock.lib, die von der Installation zur Verfügung gestellt wird, dient zum Verbinden der Fenster-Socket-Aufrufe.
Entwicklungsumgebung
Die Beispielanwendung wurde mit Microsoft Visual C++, Version 1.52 entwickelt.
Die Beispielanwendung nutzt Microsoft Foundation Class. Die ursprüngliche
Anwendung wurde vom Visual C++ Anwendungs-Assistent generiert.
250
31002922 10/2009
Ethernet-Entwicklerhandbuch
Beschreibungen der Klassen
Liste der Klassen z z z z z z z z z z z
CSample_app : Csample_app ist die Anwendungsklasse. Diese Anwedung wurde vom Anwendungs-Assistenten generiert. Die Quelle ist in der Datei sam_app.cpp. Die Klassendeklaration ist in sam_app.h.
CMainFrame : CMainFrame wird von der MFC-Klasse CMDIFrameWnd abgeleitet und ist der Hauptfensterrahmen der Anwendung. Die Quelle für
CMainFrame ist in mainfrm.cpp. Die Deklaration ist in mainfrm.h. Der Code für
CMainFrame wurde ursprünglich vom Anwendungs-Assistenten generiert. Er wurde geändert, um Fenster-Timer-Meldungen zu verarbeiten.
CSample_doc : CSample_doc ist die Dokumentklasse. Die Deklaration ist in sam_doc.h und die Implementierung ist in sam_doc.cpp.
CSample_View : CSample_View ist die Anzeige des Dokuments. Sie wird von der Klasse CScrollView abgeleitet. Die Deklaration ist in der Klasse sam_vw.h und ist implementiert in den Dateien sam_vw.cpp, disp.cpp, tcp_hlp.cpp und tx_rx.cpp.
CIP_dig : Die Klasse CIP_dlg class ist die Dialogklasse zum Abrufen der IP-
Adresse. Sie wird von der Klasse CDialog abgeleitet. Die Deklaration ist in der
Datei cip_dlg.h und die Implementierung ist in der Datei cip_dlg.cpp. Beide
Dateien wurden vom Visual C++ Klassen-Assistent generiert.
ClrStatsDlg : Die Klasse ClrStatsDlg ist die Dialogklasse zum Löschen der
Statistik. Sie wird von der Klasse CDialog abgeleitet. Die Deklaration ist in der
Datei cstatdlg.h und die Implementierung ist in der Datei cstatdlg.cpp. Beide
Dateien wurden vom Visual C++ Klassen-Assistent generiert.
GetStatsDlg : Die Klasse GetStatsDlg ist die Dialogklasse zum Abrufen der
Statistik. Sie wird von der Klasse CDialog abgeleitet. Die Deklaration ist in der
Datei gstatdlg.h und die Implementierung ist in der Datei gstatdlg.cpp. Beide
Dateien wurden vom Visual C++ Klassen-Assistent generiert.
CPollDlg : Die Klasse CPollDlg ist die Dialogklasse zum Ermitteln der
Abfrageperiode. Sie wird von der Klasse CDialog abgeleitet. Die Deklaration ist in der Datei polldlg.h und die Implementierung ist in der Datei polldlg.cpp. Beide
Dateien wurden vom Visual C++ Klassen-Assistent generiert.
CReadDlg : Die Klasse CReadDlg ist die Dialogklasse zum Ermitteln der zu lesenden Register. Sie wird von der Klasse CDialog abgeleitet. Die Deklaration ist in der Datei readdlg.h und die Implementierung ist in der Datei readdlg.cpp.
Beide Dateien wurden vom Visual C++ Klassen-Assistent generiert.
CWriteDlg : Die Klasse CWriteDlg ist die Dialogklasse zum Ermitteln der zu schreibenden Register und der Schreibdaten. Sie wird von der Klasse Cdialog abgeleitet. Die Deklaration ist in der Datei writedlg.h und die Implementierung ist in der Datei writedlg.cpp. Beide Dateien wurden vom Visual C++ Klassen-
Assistent generiert.
CAboutDlg : Die Klasse CAboutDlg ist die Dialogklasse für "Info". Die Deklaration und die Implementierung sind in der Datei sam_app.cpp.
31002922 10/2009
251
Ethernet-Entwicklerhandbuch
Klasse CSample_doc
Übersicht
CSample_doc (Dokumentklasse) enthält die von der Klasse CSample_View verwendeten Anwenderdaten. Die Anwenderdaten bestehen aus der IP-Adresse des dezentralen Teilnehmers, dem Transaktionstyp und den zugehörigen Werten.
Die verschiedenen Transaktionstypen sind Register lesen, Register schreiben,
Statistik löschen und Statistik abrufen. Neben dem Transaktionstyp und den zugehörigen Werten enthält die Dokumentklasse auch das Abfrageintervall.
Der Anwender ändert die Anwenderdaten über ein Menü oder eine Funktionsleiste.
CSample_doc verarbeitet die Befehlsmeldung im Fenster des Menüs bzw. der
Funktionsleiste durch Aufrufen des entsprechenden Dialogfensters. Der Zustand der verschiedenen Menüoptionen und Schaltflächen in der Funktionsleiste richtet sich nach dem Zustand der Verbindung zwischen der Anwendung und dem dezentralen Teilnehmer. Die Klasse CSample_View speichert den Verbindungszustand und stellt daher den Zustand der Menüoptionen und der Schaltflächen in der Funktionsleiste ein.
252
31002922 10/2009
Ethernet-Entwicklerhandbuch
Klasse CSample_View
Übersicht
Die Klasse CSample_View verwaltet die TCP/IP-Verbindung, sendet Requests an dezentrale Teilnehmer und zeigt entweder den Verbindungszustand oder die
Ergebnisse der Transaktion an. Außerdem stellt die Klasse die Zustände der
Schaltflächen in der Funktionsleiste und die Menüoptionen ein.
Aufrufen von TCP/IP
CSample_View hat über die Programmierschnittstelle der Anwendung und über
Meldungen, die von der Fenster-Sockets-DLL zum Fenster CSample_View gesendet wurden, eine Schnittstelle mit Fenster-Sockets. Die Referenz für die
Fenster-Socket-API ist oben angegeben. Der erste Aufruf an die Fenster-Sockets-
DLL muss WSAStartup sein. Dieser Aufruf wird von der Member-Funktion
InitInstance der Klasse CSample_app durchgeführt. Der letzte Aufruf an die
Fenster-Socket-DLL muss WSACleanup sein. Dieser Aufruf wird von der Member-
Funktion ExitInstance der Klasse Csample_app durchgeführt.
z z z
CSample_View ordnet die folgenden Socket-Attribute zu und stellt sie ein.
"Linger" setzen, um festes Schließen zu verursachen
Out-of-Band-Daten im normalen Datenstrom empfangen
Nagel-Algorithmus deaktivieren
Falls der Nagel-Algorithmus deaktiviert ist, wenn der Stack eine Anwendungsmeldung empfängt, wird die Meldung sofort an die Anwendung weitergegeben und es wird eine TCP/IP-Quittierungsmeldung gesendet. Dadurch kann zwar mehr
Verkehr entstehen, doch die Anwendung empfängt die Meldung früher als wenn der
Nagel-Algorithmus aktiviert würde. Die Member-Funktion tcpip_setsocket_options stellt die Socket-Attribute ein.
Die Fenster-Socket-Schnittstelle bietet die Funktion WSAAsyncSelect, die das
Fenster über Netzwerkereignisse informiert. Die Member-Funktion tcpip_setsocket_options ruft die Funktion WSAAsyncSelect auf.
Die folgende Tabelle beschreibt die verschiedenen Ereignisse.
Ereignis
FD_READ
FD_WRITE
FD_OOB
FD_CONNECT
FD_CLOSE
Beschreibung
Ein Socket kann Daten lesen.
Ein Socket kann Daten schreiben.
Ein Socket kann Out-of-Band-Daten lesen.
Eine Verbindungsantwort wurde empfangen.
Die Verbindung wurde geschlossen.
31002922 10/2009
253
Ethernet-Entwicklerhandbuch
Einer der Parameter von WSAAsyncSelect ist eine benutzerdefinierte Meldung, die die Fenster-Socket-DLL an das Fenster sendet. Die Benutzermeldung der Beispielanwendung ist WM_TCPIP_EVENT und ist in der Datei wn_msh.h definiert. Der
MFC-Architekturrahmen ruft die Member-Funktion tcpip_event der Klasse
CSample_View auf, um diese Meldung zu verarbeiten. Wie bei allen Funktionen, die
Meldungen verarbeiten, sind die Parameter tcpip_event ein Wort und ein Long-
Wort. Der Wort-Parameter ist der Socket. Der Long-Wort-Parameter enthält das
Netzwerkereignis und einen Fehlercode.
Tcpip_event prüft das Netzwerkereignis und ruft die Member-Funktion auf, die in der folgenden Tabelle angegeben wird.
Netzwerkereignis t
FD_READ
FD_WRITE
FD_OOB
FD_CONNECT
FD_CLOSE
Member-Funktion
OnTcpIpRead(
OnTcpIpWrite()
OnTcpIpOob(
/OnTcpIpConnect
OnTcpIpClose()
Format der Anwendungsmeldung
TCP/IP überträgt eine Meldung als Strom. Es gibt keine Anzeige für Beginn und
Ende einer Meldung. Das NOE-Optionsmodul fügt einen Header hinzu, um die
Grenzen der Meldung zu ermitteln. Die Meldung ist eine Modbus-Meldung.
z z
Der Header enthält die folgenden Felder.
z Aufruf-Bezeichner : Dieses 2-Byte-Feld ordnet Request und Antwort zu. Die
Client-Anwendung wählt den Aufruf-Bezeichner aus. Der Server meldet den z gleichen Aufruf-Bezeichner in der Antwort zurück.
Protokolltyp : Dieses 2-Byte-Feld gibt den Protokolltyp an. Derzeit wird nur das
Modbus-Protokoll unterstützt.
Befehlslänge : Dieses 2-Byte-Feld ist die Größe der übrigen Meldung.
Ziel-Bezeichner : Dieses 1-Byte-Feld ist für zukünftige Verwendung reserviert.
Die Modbus-Meldung folgt auf den Header. Die Meldung enthält kein Adressfeld.
Stattdessen ist das erste Byte der Modbus-Funktionscode.
Die Datenstruktur des Headers ist in der Datei modbus.h deklariert und die Funktion encode_header der Klasse CSample_View codiert den Header. Die Member-
Funktionen sind encode_clear_stats, encode_read_stats, encode.
254
31002922 10/2009
Ethernet-Entwicklerhandbuch
Timer und Transaktionsverarbeitung
Timer
CSample_View empfängt in regelmäßigen Abständen eine Timer-Meldung. Die
Meldung bewirkt, dass CSample_View eine Meldung überträgt. Weil Fenster-Timer eine begrenzte Ressource sind, empfängt das zur Klasse CmainFrame gehörige
Fenster die Timer-Meldungen. Die Member-Funktion AddTimerList der Klasse
CMainFrame platziert ein Fenster auf der Timer-Liste. Wenn CMainFrame die
Meldung WM_TIMER verarbeitet, sendet es jedem Fenster auf der Timer-Liste die benutzerdefinierte Meldung WM_POLL_INTERVAL.
MFC ruft beim ersten Erstellen die Member-Funktion OnInitalUpdate der Klasse
CSample_View auf. OnInitialUpdate ruft AddTimerList von CMainFrame auf, um die
Meldung WM_POLL_INTERVAL zu empfangen. Der MFC-Architekturrahmen ruft die Member-Funktion OnPollInterval der Klasse CSample_View auf, um diese
Meldung zu verarbeiten.
Transaktionsverarbeitung
Die Transaktionsverarbeitung von CSample_View besteht aus dem Aufbauen einer
Verbindung, dem Übertragen des Requests, dem Empfangen der Antwort und dem
Anzeigen der Antwort. CSample_View nutzt die Sende- und Empfangszustandsmaschinen, um eine Transaktion zu bearbeiten.
31002922 10/2009
255
Ethernet-Entwicklerhandbuch
Sendezustandsmaschine
Übersicht z z
Die folgende Liste enthält die verschiedenen Zustände der
Sendezustandsmaschine:
IDLE : Im Zustand IDLE ist keine Verbindung vorhanden.
RESOLVING_NAME : Im Zustand RESOLVING_NAME wartet CSample_View darauf, dass die Fenster-Socket-DLL den Namen eines Teilnehmers in eine IP-
Adresse umwandelt.
z CONNECTING : Im Zustand CONNECTING wartet CSample_View darauf, dass die Fenster-Socket-DLL das Ereignis FD_CONNECT generiert. Dieses Ereignis zeigt an, ob der Versuch, eine Verbindung aufzubauen, erfolgreich war oder fehlgeschlagen ist. z z z
CONNECTED : Der Zustand CONNECTED gibt an, dass eine Verbindung erfolgreich aufgebaut wurde.
WAIT_TO_TX : Im Zustand WAIT_TO_TX wartet CSample_View darauf, die
Meldung zu senden. Die Meldung wird gesendet, wenn die Zeit seit der letzten
Übertragung das angegebene Abfrageintervall überschreitet.
BLOCKED : Wenn CSample_View versucht, eine Meldung zu senden, kann die
Fenster-Socket-DLL möglicherweise nicht die komplette Meldung senden. Dies ist ein Fehler in der Flusskontrolle und CSample_View geht in den Zustand z
BLOCKED. Die Fenster-Socket-DLL generiert das Ereignis FD_WRITE, wenn weitere Daten gesendet werden können.
TX_DONE : CSample_View geht in den Zustand TX_DONE, wenn der Request vollständig übertragen wurde.
Wenn CSample_View im Zustand IDLE ist und Sie den Menübefehl bzw. die
Schaltfläche in der Funktionsleiste "Verbinden" wählen, versucht die Funktion
OnManagConnect der Klasse CSample_View, eine Verbindung zur Funktion tcpip_initate_connection herzustellen. Diese Funktion prüft das dezentrale Ziel und ermittelt, ob es sich um einen Namen oder um eine IP-Adresse handelt. Handelt es sich um einen Namen, ändert OnManagConnect den Sendezustand in
RESOLVING_NAME und ruft die Funktion WSAAsyncGetHostByName der
Fenster-Socket-DLL auf, um den Namen aufzulösen. Die Fenster-Socket-DLL erzeugt die benutzerdefinierte Meldung WM_TCPIP_NAME_RESOLVED, die angibt, ob der Name aufgelöst wurde. Die Member-Funktion OnTcpIpNameResolved verarbeitet die Meldung WM_TCPIP_NAME_RESOLVED. Wird der Name nicht aufgelöst, ändert OnTcpIpNameResolved den Sendezustand wieder in IDLE.
256
31002922 10/2009
31002922 10/2009
Ethernet-Entwicklerhandbuch
Handelt es sich bei dem dezentralen Teilnehmer um eine IP-Adresse oder um einen aufgelösten Namen, dann wird die Funktion tcpip_connect_rq der Klasse
CSample_View aufgerufen, um einen Verbindungs-Request für den dezentralen
Teilnehmer auszugeben. Der Listen-Port für den Verbindungs-Request ist 502 und wird von der Konstante MBAP_LISTEN_PORT in der Datei modbus.h definiert.
Wenn tcpip_connect_rq erfolgreich einen Verbindungs-Request ausgelöst hat,
ändert tcpip_connect_rq den Sendezustand in CONNECTING. Andernfalls wird der
Sendezustand in IDLE geändert.
Die Fenster-Socket-DLL generiert ein Ereignis FD_CONNECT, das anzeigt, ob der
Verbindungs-Request erfolgreich war oder fehlgeschlagen ist. Die Funktion
OnTcpIpConnect der Klasse CSample_View verarbeitet das Ereignis
FD_CONNECT. War der Verbindungs-Request erfolgreich, ändert
OnTcpIpConnect den Sendezustand in CONNECTED. Andernfalls wird der Zustand in IDLE geändert.
Denken Sie daran, dass der MFC-Architekturrahmen die Member-Funktion
OnPollInterval der Klasse CSample_View aufruft, um die Meldung
WM_POLL_INTERVAL zu verarbeiten, die als Ergebnis daraus gesendet wurde, dass die Klasse CMainFrame eine Meldung WM_TIMER verarbeitet. OnPollInterval prüft den Sendezustand. Ist der Sendezustand CONNECTED und der Anwender hat einen Transaktionstyp gewählt, dann ruft OnPollInterval die Funktion
TransmitUserRequest von CSample_View auf.
TransmitUserRequest codiert einen Request basierend auf dem Transaktionstyp, speichert die aktuelle Uhrzeit und ruft die Funktion TransmitMessage der Klasse
CSample_View auf. OnPollInterval ermittelt anhand der gespeicherten Uhrzeit, wann der nächste Request zu senden ist. TransmitMessage versucht, eine Meldung an die dezentrale Seite zu senden. Zum Senden der Meldung tritt TransmitMessage in eine Schleife ein. In der Schleife ruft TransmitMessage die Sendefunktion der
Fenster-Socket-DLL auf.
Die folgende Liste beschreibt das Resultat der Sendefunktion und die entsprechenden Maßnahmen.
z Die Meldung wurde erfolgreich gesendet.
TransmitMessage ändert den z
Sendezustand in TX_DONE und verlässt die Schleife.
Nur ein Teil der Meldung wurde gesendet.
TransmitMessage tritt erneut in die z
Schleife ein.
Die Sendefunktion gibt einen Fehler aus und zeigt an, dass im
Übertragungssystem nicht genügend Speicher vorhanden ist.
Transmit-
Message ändert den Sendezustand in BLOCKED und verlässt die Schleife. z Die Sendefunktion gibt einen anderen Fehler aus.
TransmitMessage schließt die Verbindung, ändert den Sendezustand in IDLE und verlässt die Schleife.
Wenn wieder Speicherplatz zum Senden von Meldungen im Übertragungssystem verfügbar ist, generiert die Fenster-Socket-DLL ein Ereignis FD_WRITE. Die
Funktion OnTcpWrite von CSample_View verarbeitet die Funktion FD_WRITE durch Aufrufen von TransmitMessage.
257
Ethernet-Entwicklerhandbuch
Die Emfangszustandsmaschine
verarbeitet die Antwort auf einen
Request. Wenn die Emfangszustandsmaschine die vollständige Antwort erhalten hat, wird der Zustand der Sendezustandsmaschine von TX_DONE in WAIT_TO_TX geänderet.
Wie bereits erläutert, speichert TransmitUserRequest die Uhrzeit. OnPollInterval von CSample_View nutzt die gespeicherte Uhrzeit, um zu ermitteln, ob ein neuer
Request gesendet werden muss. OnPollInterval wird vom MFC-Architekturrahmen aufgerufen, um das Ereignis WM_POLL_INTERVAL zu verabeiten, das gesendet wird, wenn die Klasse CMainFrame die Fenster-Timer-Meldung WM_TIMER verarbeitet. OnPollInterval prüft den Sendezustand. Ist der Sendezustand
WAIT_TO_TX und die seit dem vorherigen Sende-Request abgelaufene Zeit
überschreitet das Abfrageintervall, dann ruft OnPollInterval die Funktion
TransmitUserRequest auf, um eine weitere Transaktion zu starten.
258
31002922 10/2009
Ethernet-Entwicklerhandbuch
Empfangszustandsmaschine
Übersicht
Die folgende Liste enthält die verschiedenen Zustände der
Empfangszustandsmaschine: z RX_HEADER : Im Zustand RX_HEADER empfängt die Empfangsmaschine den
Meldungs-Header.
z z
RX_BODY : Im Zustand RX_BODY empfängt die Empfangsmaschine die
Antwortmeldung zu der angeforderten Transaktion.
DUMP_BODY : Im Zustand DUMP_BODY empfängt die Empfangsmaschine eine Meldung, doch es gibt keine zugehörige Transaktion in Bezug auf diese
Meldung.
Die Fenster-Socket-DLL generiert das Ereignis FD_READ, wenn Daten gelesen werden müssen. Wenn nur ein Teil der Daten gelesen werden, wird ein weiteres
Ereignis generiert. Die Funktion OnTcpIpRead der Klasse CSample_View verarbeitet das Ereignis FD_READ und steuert die Empfangszustandsmaschine.
Wenn ein Ereignis FD_READ generiert wird, ist es möglich, dass die vollständige
Meldung nicht vorhanden ist. Der dezentrale Teilnehmer hat möglicherweise versucht, eine 100-Byte-Antwort zu senden, doch das Übertragungssystem hat möglicherweise nur Speicherplatz zum Senden von drei Byte frei gehabt. Der
Empfänger erhält FD_READ für die drei Byte. OnTcpIpRead ruft CSample_View rx_msg auf, um die empfangenen Daten in den Puffer einzulesen. Es gibt drei
Parameter für rx_msg. Der erste Parameter ist ein Zeiger auf einen Empfangspuffer.
Der zweite Eingangsparameter ist die Empfangsgröße. Der dritte Parameter ist
Eingangs- und Ausgangsparameter. Bei beiden, Eingang und Ausgang, ist der dritte
Parameter die Anzahl der gelesenen Byte. Diese Parameter ermöglichen die
Verarbeitung von teilweise empfangenen Meldungen.
Die Empfangszustandsmaschine speichert eine Variable, die die Anzahl der empfangenen Byte enthält. Anfangs befindet sich die Empfangszustandsmaschine im Zustand RX_HEADER und die Anzahl der empfangenen Byte ist 0.
Wenn OnTcpIpRead aufgerufen wird und der Empfangszustand RX_HEADER ist, ruft OnTcpIpRead die Funktion rx_msg mit einer Empfangsgröße gleich der Header-
Größe auf. Bei der Rückkehr prüft OnTcpIpRead die Anzahl der empfangenen Byte.
Ist die Anzahl der empfangenen Byte nicht gleich der Header-Größe, bleibt die
Empfangszustandsmaschine im Zustand RX_HEADER und OnTcpIpRead kehrt zurück.
31002922 10/2009
259
Ethernet-Entwicklerhandbuch
Wenn bei der Rückkehr die Anzahl der empfangenen Byte gleich der Header-Größe ist, wurde der Header empfangen. OnTcpIpRead setzt die Anzahl der empfangenen
Byte auf 0 zurück und die Empfangsgröße wird vom Header übernommen. Diese beiden Werte werden beim nächsten Aufruf von rx_msg verwendet. OnTcpIpRead ruft auch die Transaktionskennung und den Protokolltyp aus dem Header ab. Wenn die Transaktionskennung dem Sende-Request-Bezeichner entspricht und der
Protokolltyp MODBUS ist, ändert OnTcpIpRead den Empfangszustand in
RX_BODY. Wenn jedoch entweder die Transaktionskennung nicht stimmt oder das
Protokoll nicht MODBUS ist, ändert OnTcpIpRead den Empfangszustand in
DUMP_BODY.
Wenn OnTcpIpRead aufgerufen wird und der Empfangszustand RX_BODY ist, ruft
OnTcpIpRead die Funktion rx_msg mit einer Empfangsgröße gleich dem Wert aus dem Header auf. Bei der Rückkehr prüft OnTcpIpRead die Anzahl der empfangenen
Byte. Ist die Anzahl der empfangenen Byte nicht gleich der Empfangsgröße, bleibt die Empfangszustandsmaschine im Zustand RX_HEADER und OnTcpIpRead kehrt zurück.
Wenn bei der Rückkehr die Anzahl der empfangenen Byte gleich der
Empfangsgröße ist, hat OnTcpIpRead die Antwort auf eine Transaktion gelesen.
OnTcpIpRead speichert die Ergebnisse und macht den Client-Bereich ungültig, wodurch die Ergebnisse angezeigt werden. OnTcpIpRead ändert auch den
Sendezustand in WAIT_TO_TX und setzt die Empfangszustandsmaschine zurück, indem der Zustand RX_HEADER eingestellt und die Anzahl der empfangenen Byte auf 0 gesetzt wird. Dann kehrt die Funktion zurück.
Wenn OnTcpIpRead aufgerufen wird und der Empfangszustand DUMP_BODY ist, ruft OnTcpIpRead die Funktion rx_msg mit einer Empfangsgröße gleich dem Wert aus dem Header auf. Bei der Rückkehr prüft OnTcpIpRead die Anzahl der empfangenen Byte. Ist die Anzahl der empfangenen Byte nicht gleich der
Empfangsgröße, bleibt die Empfangszustandsmaschine im Zustand RX_HEADER und OnTcpIpRead kehrt zurück.
Wenn bei der Rückkehr die Anzahl der empfangenen Byte gleich der
Empfangsgröße ist, hat OnTcpIpRead die Meldung vollständig gelesen. Weil diese
Meldung keiner Transaktion entspricht, ist die einzige Bearbeitung, die von
OnTcIpRead durchgeführt wird, das Zurücksetzen der
Empfangszustandsmaschine.
Die Member-Funktion rx_msg ruft die Funktion recv des Fenster-Sockets auf, um
Daten zu lesen. Die Funktion recv gibt entweder eine Nummer aus, die nicht negativ ist, wobei es sich um die Anzahl der gelesenen Byte handelt, oder die Funktion gibt einen Fehler aus. Ist die Anzahl der gelesenen Byte 0, ist keine Verbindung mehr vorhanden und rx_msg schließt den Socket und setzt den Sendezustand auf IDLE.
Wenn die Funktion recv einen Fehler ausgibt, der anzeigt, dass keine
Empfangsdaten verfügbar sind, kehrt rx_msg einfach zurück. Bei anderen Fehlern der Funktion recv schließt rx_msg den Socket und setzt den Sendezustand auf
IDLE.
260
31002922 10/2009
Ethernet-Entwicklerhandbuch
Anzeige auf dem Bildschirm
Übersicht
Das Member m_display der Klasse CSample_View gibt den Anzeigetyp an. Die folgende Liste beschreibt die verschiedenen Arten von Anzeigen und die
Memberfunktionen der Klasse CSample_View zum Einblenden der Anzeige.
z Anzeigen des Verbindungszustands : Die verschiedenen Verbindungszustände, die angezeigt werden, sind IDLE, RESOLVING NAME und
CONNECTING. Die Member-Funktion ConnPaint zeigt den Verbindungszustand z z z z an.
GetStatsPaint : Zeigt die Ergebnisse eines Requests zum Abrufen der Statistik an.
ClearStatsPaint : Zeigt die Ergebnisse eines Requests zum Löschen der
Statistik an.
ReadRegPaint : Zeigt die Ergebnisse eines Requests zum Lesen des Registers an.
WriteRegPaint : Zeigt die Ergebnisse eines Requests zum Schreiben des
Registers an.
Der MFC-Architekturrahmen ruft die Member-Funktion OnDraw der Klasse
CSample_View auf, um die Fenstermeldung WM_PAINT zu verarbeiten. OnDraw prüft die Member-Variable m_display und ruft die entsprechende Member-Funktion auf, die im Abschnitt oben beschrieben wurde. Wenn CSample_View ein Ergebnis anzeigen muss, wird die Funktion Cview Invalidate aufgerufen, die eine Meldung
WM_PAINT verursacht.
CSample_View wird aus der MFC-Klasse CScrollView abgeleitet. Diese Klasse ist für die Logik des Blätterns zuständig. Für die Durchführung der Blätterlogik benötigt
CScrollView die Größe des Dokuments. Die Dokumentgröße wird über die Member-
Funktion SetScrollSizes mitgeteilt.
Die Member-Funktion UpdateScrollSizes von CSample_View basiert auf dem
Anzeigetyp und berechnet die Dokumentgröße. Dann wird SetScrollSizes aufgerufen. CSample_View ruft UpdateScrollSizes auf, wenn sich der Anzeigetyp
ändert oder wenn der Anwender die Fenstergröße ändert.
31002922 10/2009
261
Ethernet-Entwicklerhandbuch
262
31002922 10/2009
Ethernet TCP/IP Modbus Anwendungs-Protokoll
31002922 10/2009
Quantum Ethernet TCP/IP Modbus
Anwendungs-Protokoll
C
Einführung
Dieses Kapitel beschreibt das Quantum Ethernet TCP/IP Modbus
Anwendungsprotokoll.
Inhalt dieses Kapitels
Dieses Kapitel enthält die folgenden Themen:
Thema
Übersicht
PDU des Modbus-Anwendungsprotokolls
Dienstklassen des Modbus-Anwendungsprotokolls
Analyse der Modbus-Anwendungsprotokoll-PDU
TCP/IP-spezifische Themen
Referenzdokumente
Seite
263
31002922 10/2009
Ethernet TCP/IP Modbus Anwendungs-Protokoll
Übersicht
Einführung
Im Folgenden ist das Modbus-Anwendungsprotokoll (MBAP) beschrieben.
Das MBAP ist ein Sieben-Schichten-Protokoll für die Peer-to-Peer-Kommunikation zwischen SPS und anderen hostbasierten Teilnehmern in einem LAN. Insgesamt implementieren diese Teilnehmer die gesamte oder einen Teil einer Steuerungsanwendung für die Industrieautomatisierung in der Automobil-, Reifen- und Gummi-,
Nahrungsmittel- und Getränke- und der Versorgungsindustrie, um nur einige zu nennen.
Bei den Transaktionen des Modbus-Protokolls handelt es sich üblicherweise um
Request/Antwort-Meldungspaare. Modbus-Requests enthalten Funktionscodes, die verschiedene Klassen von Diensten einschließlich der Klassen für Datenzugriff,
Online-Programmierung sowie Programm-Download- und -Upload darstellen.
Modbus-Antworten können ACKs mit und ohne Daten oder NACKs mit Fehlerinformationen sein.
Das MBAP kann über jedes beliebige Kommunikationssystem übertragen werden, das Nachrichtenübertragungsdienste unterstützt. Die aktuelle Quantum-Implementierung überträgt MBAP-PDUs jedoch über TCP/IP. Die Rahmen Ethernet II und
IEEE 802.3 werden beide unterstützt, doch der Rahmen Ethernet II ist der Standard.
Weitere Informationen finden Sie im Referenzhandbuch für Modbus-Protokolle (PI-
MBUS-300).
264
31002922 10/2009
Ethernet TCP/IP Modbus Anwendungs-Protokoll
PDU des Modbus-Anwendungsprotokolls
Übersicht
MBAP-PDU, mbap_pdu, wird an TCP-Portnummer 502 empfangen. Die aktuelle maximale Größe für mbap_pdu in dieser Dienstklasse beträgt 256 Byte. Struktur und Inhalt von mbap_pdu ist laut Definition: mbap_pdu::={inv_id[2], proto_id[2], len[2],dst_idx[1], data=mb_pdu}
Der Header umfasst 7 Byte und enthält die Felder, die in der folgenden Tabelle aufgeführt sind.
Feld inv_id proto_id len
Beschreibung
[2 Byte]: Aufruf-ID für Transaktionspaarbildung
[2 Byte]: Systeminternes Multiplexing, Standard ist 0 für Modbus-Dienste
[2 Byte]: Das Feld "len" ist ein Byte-Zählwert der übrigen Felder und es umfasst die dst_id und Datenfelder.
Der restliche Teil der PDU umfasst zwei Felder:
Feld dst_idx data
Beschreibung
[1 Byte]: Ziel-Index für das systeminterne Routing von Paketen (derzeit nicht implementiert)
[n Byte]: Dies ist der Dienstanteil der Modbus-PDU, mb_pdu, und ist im
Folgenden definiert.
Der Dienstanteil des MBAP, genannt mb_pdu, enthält zwei Felder.
mb_pdu::={func_code[1], data[n]}
Die folgende Tabelle beschreibt die Felder in mb_pdu.
Feld func_code{1 byte data
Beschreibung
Modbus-Funktionscode
[n Byte]: Dieses Feld ist abhängig vom Funktionscode und enthält
üblicherweise Informationen wie Variablenreferenzen,
Variablenzählwerte und Daten-Offsets.
Größe und Inhalt des Datenfelds sind abhängig vom Wert des Funktionscodes.
31002922 10/2009
265
Ethernet TCP/IP Modbus Anwendungs-Protokoll
Beispiel
Hier sind die Werte für ein Beispiel einer mbap_pdu zum Lesen eines Registers.
00 01 00 00 00 06 01 03 00 00 00 01
Die folgende Tabelle zeigt Struktur und Inhalt für dieses Beispiel.
inv_id 00 01 proto_id len dst_idx func_code data
00 00
00 00
01
03
00 00 00 01
266
31002922 10/2009
Ethernet TCP/IP Modbus Anwendungs-Protokoll
Dienstklassen des Modbus-Anwendungsprotokolls
Übersicht
Es gibt mehrere Klassen von Diensten, die Teil des MBAP sind. Jede dieser Klassen wird im Folgenden beschrieben.
Datenzugriff
Lesen/Schreiben von digitalen und analogen Datenwerten in SPS-Registerdateien.
Online-Programmierung
Dienste nehmen relativ kleine Änderungen an Ladder Logic-Programmen vor und die Einführung dieser Änderungen in das ausgeführte Programm wird stark gesteuert.
Image-Download/Upload
Image-Download-Dienste unterstützen den Download eines Ladder Logic-
Steuerungsprogramms in die SPS. Image-Upload-Dienste unterstützen den Upload eines Ladder Logic-Steuerungsprogramms von einer SPS in einen PC-Host zu
Archivierungs-/Sicherungszwecken.
Konfiguration
Mit Hilfe der Konfigurationsdienste können Sie Parameterwerte definieren, die sich auf SPS-Registerdateien, E/A-Bestückung, Konfiguration des Kommunikationsports und Zykluseigenschaften auswirken, um nur einige zu nennen.
Steuerung des Geräteausführungszustands
Mit Hilfe dieser Dienstklasse können Sie die Ausführung des SPS-Zyklus starten bzw. stoppen. Sie müssen sich im Anmeldungskontext der Anwendung befinden, den Sie über andere Modbus-Dienste erreichen.
31002922 10/2009
267
Ethernet TCP/IP Modbus Anwendungs-Protokoll
Analyse der Modbus-Anwendungsprotokoll-PDU
Analyse
Die MBAP PDU wird über einen TCP/IP-Ethernet-Stack übertragen. Es werden die
Rahmen Ethernet II und IEEE 802.3 unterstützt. Der Rahmen Ethernet II ist die
Standardeinstellung.
. . . von dem eingehenden Draht des Rahmens IEEE 802.3 ist . . .
. . . ist der Rahmen IEEE 802.3, wenn die Länge <=1500
. . .802.3_pdu ::= {dst_addr[6], src_addr[6], length[2], data=802.2_pdu} *eine IEEE 802.3 PDU hat eine max.
Rahmengröße von 1518 Byte
*eine IEEE 802.3 PDU hat eine minimale Rahmengröße von 64
Byte 802.2_pdu: {dsap[1], ssap[1], frm_cntrl[1], snap_hdr[5], data=ip_pdu} **die snap_hdr ist mit einem "gut bekannten"
802.2 sap snap_hdr verknüpft
::={org_code[3], ethertype[2] }
*die snap hdr (Subnetzzugangsprotokoll) ermöglicht den
älteren Stil
Ethernet-Protokolle müssen auf der neueren IEEE 802.2-
Schnittstelle ausgeführt werden. Der
ethertype-Parameter gibt den Dienst an, Bsp.: ip oder arp.
IP hat einen Wert
0x800. . . . von dem eingehenden Draht für den Rahmen
Ethernet II . . .
. . . ist der Rahmen Ethernet II, wenn die Länge >=1500
. . .802.3_pdu ::= {dst_addr[6], src_addr[6], length[2], data=ip_pdu} . . . Der allgemeine Teil des Pakets beginnt hier . . .ip_pdu ::= {ip_hdr[20], data=tcp_pdu}tcp_pdu ::=
{tcp_hdr[24], data=appl_pdu=mbap_pdu} mbap_pdu ist das MBAP, dessen Meldungen an einem bekannten Port empfangen werden. Die derzeit maximale Größe der mbap_pdu für diese Dienstklasse beträgt
256 Byte.
268
31002922 10/2009
Ethernet TCP/IP Modbus Anwendungs-Protokoll
Struktur und Inhalt
Struktur und Inhalt von mbap_pdu ist laut Definition: mbap_pdu ::={ inv_id[2], proto_id[2], len[2], dst_idx[1], data=mb_pdu }Der Header ist 7 Byte lang und enthält die folgenden Felder:
inv_id [2 Byte] Aufruf-ID, die für die
Transaktions-Paarbildung verwendet wird proto_id [2
Byte] wird für das systeminterne Multiplexing verwendet, der
Standardwert beträgt 0 für Modbus
Dienste len [2 Byte] Das Feld "len" ist ein Byte-Zählwert der verbleibenden Felder und
enthält die dst_id und die Datenfelder.
Der restliche Teil der pdu umfasst zwei Felder:
dst_idx [1 Byte] Ziel-Index für das systeminterne
Routing von
Paketen. (derzeit nicht implementiert) data [n
Byte] Dies ist der Dienstanteil der Modbus-PDU, mb_pdu, der nachfolgend
definiert ist.
Dieser Dienstanteil des Modbus-Anwendungsprotokolls, der als mb_pdu bezeichnet wird, enthält zwei Felder: mb_pdu ::= { func_code[1], data[n] }
func_code [1 Byte] MB-Funktionscode data [n
Byte] Dieses Feld ist abhängig vom Funktionscode und enthält
üblicherweise Informationen wie etwa Variablenreferenzen,
Variablenzählwerte und Daten-Offsets.
Größe und Inhalt des Datenfelds sind abhängig vom Wert des Funktionscodes.
31002922 10/2009
269
Ethernet TCP/IP Modbus Anwendungs-Protokoll
TCP/IP-spezifische Themen
Broadcast/Multicast
Broadcast- und/oder Multicast werden zwar von beiden Adressen, IP-Netzwerkadresse und IEEE 802.3 MAC-Adresse, unterstützt, doch MBAP unterstützt weder
Broadcast noch Multicast auf Anwendungsebene.
Die Quantum-SPS von Schneider Electric nutzt die Broadcast-Adressierung, weil sie den Zielteilnehmer mittels ARP ermittelt. Die Client-Schnittstelle zum MBAP-
Dienst auf der SPS, der MSTR-Block, erfordert, dass Sie die Ziel-IP-Adresse vorgeben. Auch der eingebettete Stack nutzt eine vorkonfigurierte Standard-
Gateway-IP-Adresse für den Fall, dass ARP nicht funktioniert.
TCP-Portnummer
Schneider Electric hat einen bekannten System-Port von einer Internet-Behörde erhalten. Die bekannte System-Portnummer von Schneider Electric ist 502. Die
Internet-Behörde hat asa-appl-proto die System-Portnummer 502 zugewiesen.
Dennis Dubé ist der Anprechpartner in der Firma.
Mit dieser Portnummer kann Schneider Electric mehrere Anwendungsprotokolle
über TCP oder UDP übertragen. Das jeweilige Protokoll wird von dem Wert des
Parameters proto_id in mbap_pdu angegeben.. Derzeit ist die einzige Zuweisung 0, mit der Bedeutung MBAP.
270
31002922 10/2009
Ethernet TCP/IP Modbus Anwendungs-Protokoll
Referenzdokumente
Übersicht z z
Im Folgenden finden Sie eine Liste mit Referenzdokumenten.
ANSI/IEEE Std 802.3-1985, ISO DIS 8802/3, ISBN - 0-471-82749-5, Mai 1988
ANSI/IEEE Std 802.2-1985, ISO DIS 8802/2, ISBN 0-471-82748-7, Februar 1988 z RFC793, TCP (Transmission Control Protocol) DARPA Internet Program z
Protocol Specification, September 1981
RFC 791, IP (Internet Protocol) DARPA Internet Protocol Specification, z
September 1981
RFC826, An Ethernet Address Resolution Protocol (ARP), David Plummer, NIC z
September 1982
RFC1042, A Standard for the Transmission of IP Datagrams over IEEE 802.2 z
Networks, Postel & Reynolds, ISI, Februar 1988
RFC 792, ICMP (Internet Control Message Protocol) DARPA Internet C Control z
Message Protocol Specification, Jon Postel, September 1981
RFC951, BOOTSTRAP PROTOCOL (BOOTP), Bill Croft and John Gilmore, z
September 1985
RFC783, The Trivial File Transfer Protocol (TFTP) rev 2, K.R. Solons MIT, Juni
1981
31002922 10/2009
271
Ethernet TCP/IP Modbus Anwendungs-Protokoll
272
31002922 10/2009
Leistungsstatistik des E/A-Verwalters
31002922 10/2009
Leistungsstatistik des E/A-
Verwalters für die Module
NOE 771 -00, -01 und -11
D
Leistung des E/A-Scanners der Module 140 NOE 771 -00, -01 und -11
Überblick
Das folgende Kapitel beschreibt die Leistung des E/A-Scanners der Module 140
NOE 771 -00, -01 und -11 mit verschiedenen Quantum-CPUs.
Quantum 113 CPU
Die folgende Abbildung zeigt die Leistung des E/A-Scanners der Module 140 NOE
771 -00, -01 und -11 mit einer Quantum 113 CPU.
31002922 10/2009
273
Leistungsstatistik des E/A-Verwalters
Quantum 213 CPU
Die folgende Abbildung zeigt die Leistung des E/A-Scanners der Module 140 NOE
771 -00, -01 und -11 mit einer Quantum 213 CPU.
Quantum 424 CPU
Die folgende Abbildung zeigt die Leistung des E/A-Scanners der Module 140 NOE
771 -00, -01 und -11 mit einer Quantum 424 CPU.
274
31002922 10/2009
Leistungsstatistik des E/A-Verwalters
Quantum 534 CPU
Die folgende Abbildung zeigt die Leistung des E/A-Scanners der Module 140 NOE
771 -00, -01 und -11 mit einer Quantum 534 CPU.
31002922 10/2009
275
Leistungsstatistik des E/A-Verwalters
276
31002922 10/2009
ডাউনলোড
পাবলিক লিঙ্ক আপডেট করা হয়েছে
আপনার চ্যাটের পাবলিক লিঙ্ক আপডেট করা হয়েছে। You may view and manage your chat links after registration here.
নথির পাবলিক লিঙ্ক
বিজ্ঞাপন