Die Kommunikationsstrecken RS232 & TCP/IP

IPTRAIN
Senior
Beiträge: 202
Registriert: Di 15. Jan 2013, 20:20
[phpBB Debug] PHP Warning: in file [ROOT]/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1275: count(): Parameter must be an array or an object that implements Countable

Die Kommunikationsstrecken RS232 & TCP/IP

Beitrag von IPTRAIN » Sa 26. Jan 2013, 18:38

In diesem Thread werde ich die Grundlagen zu den verwendeten Kommunikationsstrecken in unserem Projekt WLANCROC behandeln:

Es sind die serielle Kommunikation (in der Lok) und die paketvermittelnde zwischen der Lok und ihrer Umgebung (hin zum Smartphone).

Wenn man ein Objekt (z.B. über Funk) ansteuern möchte, muss man ihm eine Codierung (eine Nachricht) zukommen lassen, die eine Information enthält, was das Objekt tun soll. Idealerweise meldet das Objekt auch noch zurück, dass es
  1. die Nachricht verstanden hat
  • und / oder den Befehl erfolgreich oder nicht erfolgreich ausgeführt hat
Fangen wir mit der seriellen Kommunikation an.
Wenn wir eine Nachricht transportieren möchten, machen wir das idealerweise über eine Kommunikationsverbindung, die aus einem Sender, einen Empfänger und der dazwischen liegenden Leitung.

Bei der Leitungsgebundenen Kommunikation ist die älteste, bekannteste (verbreitetste) die sogenannte Serielle Kommunikation, bestens vertreten durch die RS232 Schnittstelle http://de.wikipedia.org/wiki/RS_232 am Computer, die ein jeder irgendwie schon einmal gesehen haben dürfte. Hier http://www.elektronik-kompendium.de/sit ... 310301.htmkann man sich noch einen tieferen Überblick verschaffen - beide Links brauchen wir aber nicht unbedingt zu lesen.

Die RS232 hat mindestens eine Masseverbindung und zwei Datenleitungen (Tx und Rx), die für die beiden Endpunkte der Kommunikationsverbindung als Sendeleitung (Tx=Transmit x) und Empfangsleitung (Rx=Receive x) gesehen werden.

Was also für den einen Endpunkt die Sendeleitung ist, über die er Daten sendet, ist für den anderen Endpunkt die Empfangsleitung - et vice versa. Die Endpunkte können also (meist) beides - senden und empfangen und werden daher sehr oft als Tranceiver (Kunstwort aus Transmit und Receive) bezeichnet.
Weitere Leitungen der RS232 sind optional - werden von uns nicht eingesetzt.

Damit die Datenbits über die Entfernung (auch wenn es nur wenige Meter sind) unverfälscht übermittelt werden können, müssen bestimmte elektronische Voraussetzungen (auch hinsichtlich des Kabels) geschaffen werden. Z.B wird eine Spannung von typisch 12 - 15 Volt zwischen Tx und Masse bzw. Rx und Masse eingesetzt.

Zusätzlich wird das Signal noch codiert, z.B. um es "gleichstromfrei" zu machen (Details hier http://de.wikipedia.org/wiki/Leitungscode). Bei der RS232 Übertragung wird als Codierung die sogenannte Manchestercodierung eingesetzt. Sie sorgt eben für die Gleischstromfreiheit und die Taktung, aus der der Empfänger den Zeitpunkt ermitteln kann, zu dem er das Signal (das Bit) abtasten muss, um zu entscheiden, ob er eine NULL oder eine EINS empfangen hat.
Typische Entfernungen (Kabellängen) einer RS232 Übertragung liegen im Bereich 1 - 10 Meter!
Will man bis zu 1000 Meter seriell übertragen, muss man auf andere Standards gehen, z.B. die RS 422 http://de.wikipedia.org/wiki/RS422 (noch besser RS485 http://de.wikipedia.org/wiki/RS485 ).


Wie man nun eine Nachricht über eine digitale Kommunikationsstrecke mittels EINSEN und NULLEN elektrisch übere eine RS232 überträgt, kann man hier http://upload.wikimedia.org/wikipedia/c ... timing.png erkennen. Der gesamte Aufwand nur, um einen Buchstaben "G" zu übertragen.

Jetzt die Erleichterung: Solche Dinge wie RS232, RS422 und RS485 interessieren uns überhaupt nicht, wir verwenden nur den Teil der Seriellen Kommunikation bis VOR den Baustein, der z.B. die elektrischen Eigenschaften der RS232 Kommunikation (sagen wir mal als "Verstärker") übernimmt.

In anderen Worten: Die Daten, die aus einem Mikroprozessor rauskommen - oder reingehen, sind zwar seriell und gehen in oder kommen typisch aus einem RS232 Übertragungs- Baustein (z.B. dem IC MAX232, der nicht zum Mikroprozessor dazugehört), haben aber bezüglich ihrer elektrischen Eigenschaften lediglich die Spezifikation einer TTL - Normierung (5 Volt! zwischen Masse und Datenleitungen).
Die Daten sind auch nicht Manchestercodiert - also empflindlich gegen Störungen von aussen. Da wir aber die Daten auf der seriellen Leitung nur wenige cm (in der Lok) transportieren müssen, spielt das für uns gar keine Rolle.

Die Schnittstellen an den Endpunkten (Mikroprozessoren) der Kommunikationsstrecke, die die Daten mit 5 Volt Pegel seriell empfangen oder senden (UND die dann nach RS232 mittels z.B. eines ICs MAX232 weiter versendet werden könnten), nennen wir UART-Schnittstellen.
Das merken wir uns nun mal! Es empfiehlt sich auch diesen Link http://de.wikipedia.org/wiki/UARTeinmal zu lesen, ich finde, er ist nicht zu kompliziert - es muss aber nicht alles verstanden werden.

Fast jeder Mikroprozessor hat eine UART - Schnittstelle. Sie dient zur Standard-Kommunikation mit der Aussenwelt.

Zur Abgrenzung: Die SUSI - Schnittstelle überträgt auch Daten seriell, funktioniert aber grundsätzlich anders. Bitte SUSI nicht mit UART verwechseln. SUSI ist eine ganz private "Spielerei" bei der Modelleisenbahn - sie ist kein sogenannter Industriestandard, UART hingegen ist DER Industriestandard.
Darum hat auch kein Mikroprozessor in dieser Welt eine SUSI-Schnittstelle. Stattdessen muss man einen Programmcode (also Software) selbst schreiben, um an zwei selbst definierten Pins (I/Os) des Mikroprozessors eine SUSI-Schnittstelle zu realisieren. Diese Schnittstelle habe ich realisiert- sie ist ein Teil unseres Projektes.

Warum koppeln wir denn nun den Mikroprozessor nicht direkt über Funk mit dem Smartphone ?

Antwort ist ganz einfach:
  • Der Mikroprozessor kann nicht funken
  • Der Mikroprozessor beherrscht nicht das TCP/IP Protokoll
Daher brauchen wir das WIZnet610wi unbedingt.
Es hat auf der einen Seite eine UART Schnittstelle - und auf der anderen Seite eine TCP/IP (Funk-) Schnittstelle. Es ist sozusagen das Bindeglied zwischen Smartphone und Microcontroller in der Lok. Man könnte es auch als "Umsetzer" (engl. Gateway) oder als Router (technisch korrket) bezeichnen. Wobei ein Router nicht unbedingt eine UART Schnittstelle besitzt ...!

Damit wir nun auch verstehen, warum wir alles so kompliziert machen:

Man kann auch Daten über Funk seriell übertragen. Das tun z.B. die Anwendungen, die über 433 Mhz oder 868 Mhz Daten (oder Sprache) digital übertragen. Es gibt billige Funkempfänger und Sender, die das können, z.B. hier: http://www.pollin.de/shop/dt/OTI5OTgxOT ... modul.html. Abgesehen davon, dass diese Funkübertragung fehleranfällig auf Störungen reagiert, die Smartphones haben gar keine serielle Funkschnittstelle!!! Ist also keine Lösung.

Man müsste sich also extra ein Endgerät zur Steuerung basteln. Genau das haben Massoth, Zimo, etc... gemacht. Sie alle verwenden eine serielle Kommunikation über Funk.

Das genau machen wir aber nicht, wir verwenden ein viel komplexeres Protokoll (eben das TCP/IP- Protokoll), das eine sehr sichere Kommunikation erlaubt. Eine serielle Funkkommunikation einer TCP/IP Kommunikation (z.B. über WLAN) gegenüberzustellen, käme dem Vergleich eines Moped mit einem JumboJet gleich ...! Immerhin ist das Moped schneller zu starten ...!

Fortsetzung folgt!

IPTRAIN
Senior
Beiträge: 202
Registriert: Di 15. Jan 2013, 20:20
[phpBB Debug] PHP Warning: in file [ROOT]/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1275: count(): Parameter must be an array or an object that implements Countable

Re: Die Kommunikationsstrecken RS232 & TCP/IP

Beitrag von IPTRAIN » Sa 26. Jan 2013, 21:06

Kommen wir nun zum Funk!

R/C Anlagen habe früher an das Objekt (den Empfänger) ein ANALOGES Signal gesendet, das vom Empfänger ausgewertet wurde. Hier war die Signalform (z.B. die Frequenz oder die Höhe der Amplitude) entscheidend für die differenzierte Umsetzung in eine Reaktion.

Mit dem Entwicklung des Mikroprozessors hat sich die Übertragung DIGITALER Signale durchgesetzt, d.h. egal welche Funkart man verwendete, immer werden Sequenzen von NULLEN und EINSEN übertragen, die vom Sender generiert werden und vom Empfänger gesammelt werden.
Der Sender zerlegt also die eigentliche Information in NULLEN und EINSEN, der Empfänger setzt die Folge wieder zu der eigentlichen Information zusammen. Da Computer sowieso alle Informationen in NULLEN und EINSEN zerlegt behandeln, eigenen sie sich besonders gut, um als Sender und Empfänger der DIGITALEN Datenübertragung zu fungieren.

Man kann also klar sagen, dass die DIGITALE (mobile) Datenübertragung (=DIGITALE Funkübertragung) eine klare Konsequenz aus der Computerisierung und der Weiterentwicklung von Prozessoren erfolgte, die Digitale Signale direkt in geeignete Funkwellen umsetzen können. http://www.elektronik-kompendium.de/sit ... 211195.htm.

Unabhängig von dem Thema "Datenübertragung über Funk", stand seit der Entwicklung von den sogenannten Super-Mini Computern (und später den PCs) - im Gegensatz zu den sogenannten "Mainframes" mehr und mehr die Frage im Raum, wie man viele Computer in einem Netzwerk miteinander vernetzen kann.

Diese alle per seriellen Leitungen miteinader zu koppeln macht ja keinen Sinn, eine serielle Leistung ist immer eine Punkt-zu-Punkt Verbindung. Um viele Computer miteinander zu vernetzen braucht man eher "Datenautobahnen" mit Ein- und Ausfahrten, um Daten zu sammeln, zu transportieren und zu verteilen.

Um den Zugriff und den Transport auf den Datenautobahnen zu regeln, brauchte man effektive Protokolle (weitaus mehr als eine simple Manchester Codierung gegen Störungen) - vielmehr braucht man Protokolle, die u.a. Zugriff und Adressierung regelten.

Alles dies wird unter dem Begriff ETHERNET zusammengefasst. Ein Einführung von mir würde an dieser Stelle jeden Rahmen sprengen. Wen es interessiert, hier http://de.wikipedia.org/wiki/Ethernet kann man sich einführen lassen.

ETHERNET beinhaltet eine ganze Protokollfamilie, die in logischen Schichten implementiert wird. Eine Beschreibung dieser Schichten findet man im ISO/OSI Referenzmodell http://de.wikipedia.org/wiki/OSI-Modell. Es ist eine richtige Wissenschaft, die hier den Rahmen total sprengt, wenn man darauf eingeht. Auf diesem Modell arbeitet die gesamte IT- und Telekommunikationswelt.

Einige prinzipielle Worte möchte ich dennoch anhand des folgenden Bildes erläutern, sie sind für unser Verständnis zur WLAN Kommunikation sicherlich hilfreich:
ISO-OSI Referenzmodell.jpg
In obigem Bild sieht man 7 Schichten. Die unterste Schicht (1) ist die physikalische Schicht, die oberste Schicht ist die Anwendungsschicht (7) (z.B. das Programm am Bildschirm).

Wenn nun ein Anwender eine E-mail aus seinem Anwendungsprogramm Outlook versendet, dann wird seine E-mail (die Nutzdaten) wie ein Brief an die nächst tiefere Schicht gereicht und von dieser in ein Briefcouvert verpackt.

Auf das Briefcouvert werden von dieser Schicht zusätzlich Infos hinzugefügt, die für den sicheren Transport an den richtigen Adressaten notwendig sind. Das geht von Schicht zu Schicht (alles Software im PC) tiefer, bis die Nutzdaten in Form von elektrischen Signalen (Daten = NULLEN und EINSEN) in der physikalischen Schicht (1) z.B. im Kupferkabel (z.B. CAT6 Kabel) vom PC wegtransportiert werden.
Man muss sich das gesamte Datenpaket auf der untersten Schicht bildlich wie eine russische Puppe ("Matroschka") vorstellen, die aus 7 Hüllen besteht, wobei die innerste Hülle die E-mail darstellt.

Im nächsten Knotenpunkt (z.B. der Router im eigenen Haus im Keller) gibt es wieder einen Mikroprozessor (oder besser einen kleinen Computer - jeder Router ist ein abgespeckter Computer), der nun das in umgekehrter Reihenfolge die Matruschka wieder auspackt.
Allerdings packt ein sogennanter Switch (im Gegensatz zu einem Router) nur eine Schicht aus (so dass er nur die Informationen auf dem Briefcouvert in Schicht 2 lesen kann), um die weitere Versendung zu entscheiden. Diese Information ist die sogenannte MAC-Adresse - soll hier aber nicht weiter interessieren.

Der Router im Keller hingegen packt bis zur Schicht 3 aus - dort findet er die IP-Adresse. Aus dieser entscheidet er, ob das Paket im Haus bleibt oder an den Telekom-Provider übergeben wird. Der Router "routet" also - der Switch is eher dumm - er kann nie in die Aussenwelt weitersenden, weil er die IP-Adresse gar nicht sieht. Er regelt den Verkehr im LAN!

Bei der Telekom oder jedem anderen Provider stehen nun ganze Computerbatterien mit ähnlicher Basis- Funktion wie unser Hausrouter, aber die können auch zwischenspeichern, Datenströme verdichten ... und in die großen Lichtfaserkabel einspeisen, die dann in alle Welt führen.

Den Rest am Ankunftsort kann man sich vorstellen: Der Letzte PC, der die E-mail nun beim Adressaten darstellen soll, streift per Software alle Pakethüllen ab ... und präsentiert zum Schluss den Inhalt in dem Mail- Programm.

Nun habe ich die Kabelgebundene Ethernet Kommunikation beschrieben. (Ethernet war übrigends früher der Begriff rein für das LAN!). Heute spricht man nicht korrekt generell von einer Ethernet oder Internet Kommunikation.
Man muss schon studierter Netzwerkexperte sein, um die gesamten Begriffsabgrenzungen sauber zu erklären. Das ganze Kommunikationsmodell wird von Laien genutzt, die sich ja nur für Schicht 7 interessieren, diese noch nicht einmal kennen (sonder nur die E-mail wollen).
Da verschwimmen die Begrifflichkeiten in der Umgangssprache. Ich selbst bin teilweise nicht exakt, aber ich will ja nur festen Boden für Euch generieren und da helfen keine RFC-Definitionen http://de.wikipedia.org/wiki/Request_fo ... htige_RFCs (hier ist alles exakt beschrieben).

Wichtig für uns ist nun folgendes: Das ISO-Referenzmodell gilt immer - nicht nur für die Kabelgebundene Kommunikation, sonder auch für Funk.
Und die beiden wichtigsten Schichten sind die Schicht 3 und die Schicht 4. Also finden wir diese beiden Schichten nicht nur in der Kabelkommunikation sondern auch bei der Funkübertragung. Jeder in dieser Welt, der seine Daten nach einem standardisierten Verfahren übertragen möchte, hält sich an das ISO-OSI Referenzmodell.

Damit wird die gesamte Kommunikation weltweit "Plug & Play". Man kann Router von Linksys in seinem Hausnetzwerk kaufen, während die WLAN Dongles am PC von Netgear sind. Das geht nur deshalb, weil sich alle Firmen (incl. Microsoft!!!) an das ISO-OSI Referenzmodell halten und alle Software-Entwickler die für sie relevanten RFC-Dokumente gelesen haben (bzw. die Software - Bibliotheken kennen, die diese Vorschriften umsetzen).

Also, Schicht 3 ist die sogenannte IP-Schicht. In ihr wird die IP-Adresse als wichtigste Info behandelt.
Eine typische IP-Adresse ist die z.B. Adresse 168.1.2.50. Sie besteht also aus 4 Zifferblöcken, die alle unabhängig voneinander Zahlen zwischen 0 und 255 belegen können. Über diese Adresse ist jeder Teilnehmer im Internet eindeutig adressierbar ( identifizierbar). Es ist also eine Art Datensatz der wie der Datensatz LAND, STADT, STRASSE und HAUSNUMMER mehr oder weniger ausreicht, um eindeutig einen Brief beim Empfänger auszuliefern.
Mehr zu IP Adressen findet man hier http://de.wikipedia.org/wiki/IP-Adresse

Wozu braucht man nun noch die Schicht 4? In ihr findet man (unter anderem) die sogenannte PortNummer. Eine Portnummer kann man sich vereinfacht als eine Appartementnummer im Hochhaus vorstellen - bei einem Hochhaus reicht ja bekanntlich die Hausnummer nicht aus, um einen Brief zustellen zu können.

Eine Portnummer kann zwischen 1 und 65.xxx liegen. Es gibt Portnummern, die sind geschützt / vergeben, andere sind frei verfügbar. Bezogen auf den PC muss man sich das so vorstellen:

Wenn man im Internet surft und gleichzeitig das E-mail - Programm bedient, dann muss ja der Inhalt einer auf dem Server aufgerufenen Seite im Browserfenster erscheinen - und nicht im E-mail Programm.
Umgekehrt möchte man die E-mail nicht im Browser-Fenster sehen. Damit der PC (das Betriebssystem) entscheiden kann ob nun das empfangene Paket an den Browser geht oder an das E-mail Programm, muss er in der Schicht 4 des Datenpakets nachschauen, dort steht die Port Nummer.
Und der Browser hat eine andere Portnummer (meist 80) als das E-mail Program (nicht selten 25). Der PC selbst hat ja "nur" eine IP-Adresse, die ist aber für das Browser Datenpaket und das E-mail Datenpaket gleich.

Die Schicht 4 hat noch eine andere sehr wichtige Funktion: Sie arbeitet entweder "verbindungsorientiert" oder "verbindungslos".

In anderen Worten: Datenpakete können einfach versendet werden, ohne dass der Absender jemals die Rückmeldung vom Empfänger erhält, ob das Datenpaket angekommen ist (verbindungslos). Das tut es zwar in 99,999 % aller Fälle, aber dennoch - ein wichtiger Unterschied.

Bei der verbindungsorientierten Kommunikation wird vor der eigentlichen Datenübermittelung erst einmal eine Verbindung aufgemacht, die während der gesamten Kommunikation allen beteiligten Verbindungsknoten im Internet (im Netzwerk) bekannt bleibt, bis die Verbindung vom Initiator nach Beendigung der Datenversendung wieder "ordentlich" beendet wird.

Also ist in diesem Sinne ein Telefongespräch eine verbindungsorientierte Kommunikation, während der Versand einer SMS eine verbindungslose Kommunikation darstellt.
Eine verbindungslose Kommunikation das sogenannte Transportprotokoll UDP (aber nicht für die SMS) umgesetzt. Eine verbindungsorientierte Kommunikation läuft immer mittels TCP (bei der Datenübertragung)!

Wenn wir also von einer TCP/IP Kommunikation sprechen, meinen wir also immer eine Kommunikation, die IP-Nummern, Port-Nummern und einen, vor der eigentlichen Datenübermittelung, aufgebauten Kommunikationskanal benötigt.
Das TCP- Protokoll hat gegenüber UDP noch einen weiteren entscheidenden Vorteil (für uns aber völlig unwichtig), die Datenpakete, die versendet werden können sich im Internet überholen, weil sie evtl. unterschiedliche Wege zurücklegen. Das TCP Protokoll (an beiden Enden der Kommunikationsstrecke) setzt sie in der richtigen Reihenfolge wieder zusammen. Sonst könnte es passieren, dass unsere E-mail mit "freundlichen Grüssen" startet ... und mit der Anrede endet.

Um ein Gefühl zu geben: In ein IP Datenpaket passen ca. 1500 Bytes - die Größe ist fest definiert!. Will man also eine Datei von 3 MB versenden, gehen ca. 2.000 Datenpakete auf die Reise (allein für die Nutzdaten). Aber nur als Größenordnung!

Wir versenden nur wenige Bytes pro Befehl zur Lok. Die Lok sendet da schon mehr Bytes zurück. Aber genau genommen transportieren wir Erbsen im 40-Tonner LKW!

Der besondere Vorteil des (verbindungsorinetierten) TCP/IP Protokolls liegt aber für uns darin, dass wir mit dem TCP/IP Protokoll uns per Smartphone eine Lok fest ans Smartphone koppeln. Will ein anderer die Lok fahren, müssen wir erst die Verbindung beenden, dann wird die Lok frei zur Bindung an ein anderes Smartphone. Ein Dritter kann unsere Lok also nie ohne unsere Zustimmung kapern.

Da wir also eine weltweite genormte Protokolldefinition nutzen, ist es klar, dass wir über das "Internet" eine Lok in unserem Garten von der 5th Avenue in New York steuern können ...! Weniger ginge ja auch wohl gar nicht! :mrgreen:

Fortsetzung folgt!

IPTRAIN
Senior
Beiträge: 202
Registriert: Di 15. Jan 2013, 20:20
[phpBB Debug] PHP Warning: in file [ROOT]/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1275: count(): Parameter must be an array or an object that implements Countable

Re: Die Kommunikationsstrecken RS232 & TCP/IP

Beitrag von IPTRAIN » So 27. Jan 2013, 15:00

Hallo zusammen,

schauen wir uns nun einmal an, wie und wo die beiden Kommunikationsstrecken zum Einsatz kommen.

Anbei ein Schaubild, das die gesamte Kommunikationsstrecke vom PC bis zur Lok beinhaltet. Wobei der PC (momentan) als Smartphone Ersatz dient, da auf PC-Basis mehr Tools zur Verfügung stehen, um die Kommunikation in ihren Teilen darzustellen.
Kommunikationsstrecke WLANCROC.jpg
Wir sehen in diesem Schaubild ein Programm , das es uns ermöglicht, Daten über eine TCP/IP Strecke Daten in Paketen zu versenden und wieder zu empfangen.
Man kann es hier http://www.simplecomtools.com/productca ... category=5 als Freeware downloaden.

Das Programm zeigt in der Oberfläche (linke Hälfte) 3 Bereiche:

Im obersten Bereich trägt man die "Internet"- Adresse des Kommunikationspartners ein (Blaues Rechteck). Wie zuvor gelernt sind das die IP-Adresse und die Port - Nummer.

Unser Kommunikationspartner ist nicht die Steuerplatine mit dem Microprozessor (MC) in der Lok selbst, sondern das WIZnet610wi, das als Endpunkt der TCP/IP-Kommunikation angesehen werden muss. Der MC selbst hat ja keine IP Adresse, er beherrscht ja nicht die die TCP/IP Protokoll - er hat ja nur eine serielle Schnittstelle (wie oben schon gesagt). Das WIZnet610wi ist also ein Hilfsmittel, das die TCP/IP Kommunikation in eine serielle Kommunikation umsetzt, bzw. vice versa!

Im mittleren Bereich (Gelbes Rechteck) trägt man die Nutzdaten ein, die man an das MC-Modul versenden möchte.

Im unteren Bereich (Grünes Rechteck) werden die Daten angezeigt, die vom Kommunikationspartner an das Test-Tool zurückgesendet werden.

Wichtig zu erkennen: Rechts neben dem blauen Rechteck erkennt man einen Tastenfeld, das die Beschriftung "Connect" trägt. Darunter kann man den Connection Status ablesen (momentan "Idle" - was so viel wie "Leerlaufend", "Nicht Produktiv" , "faul" bedeutet).

Ich schalte nun einmal meine Lok V60 ein und zeige einmal, was passiert, wenn das WIZnet610wi an das TestTool TCP-IP "angebunden" wird.

Die Lok hat die IP-Adresse "192.168.1.75" und die Port Nummer "12345". Beides trage ich im Tool in die entsprechenden Felder im TCP-IP Test Tool ein:

Vorher
TCP-IP Idle.jpg
"Idle" zeigt an: Die Verbindung zur Lok ist noch nicht hergestellt (wir erinnern uns daran, dass TCP ein verbindungsorientiertes Protokoll ist und erst einmal die Verbindung zur Lok aufgebaut werden muss)!

Nun drücke ich auf "Connect" ...:

Nachher
TCP-IP Connected.jpg
Die Verbindung ist nun hergestellt, das Feld zeigt nicht mehr "Idle" sondern "Connected". Gleichzeitig hat das Tastenfeld seine Aufschrift zu "Disconnect" verändert, es ist nun bereit den Verbindungsabbruch als Beendigung der Kommunikation vom Benutzer entgegenzunehmen. Aber den Knopf wollen wir ja erst drücken, wenn wir die Lok in der Garage abstellen.

Wir sehen nun im neuen Screenshot ("Connected") Kryptische Zeichen im obigen "Grünen Rechteckbereich", die von der Lok an den PC (das Smartphone) zurückgesendet werden.

Der blaue Balken zeigt die Daten, die im letztgesendeten Paket enthalten waren. Man nennt eine diese Datenansammlung, die eine Einheit bildet, auch ein "(Daten-)Telegramm".

Fortsetzung folgt!

IPTRAIN
Senior
Beiträge: 202
Registriert: Di 15. Jan 2013, 20:20
[phpBB Debug] PHP Warning: in file [ROOT]/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1275: count(): Parameter must be an array or an object that implements Countable

Re: Die Kommunikationsstrecken RS232 & TCP/IP

Beitrag von IPTRAIN » So 27. Jan 2013, 16:04

Wir verfolgen nun einmal die Kommunikationsstrecke im 1. Schaubild des vorhergehenden Posts:

Wir sehen also den Laptop mit dem Programm "TCP Test Tool", weiterhin einen Router (Linksys), der auch eine IP-Adresse besitzt. Seine IP-Adresse muss irgendeine IP Adresse sein, die mit dem Laptop und dem WIZnet610wi in den ersten 3 Ziffernblöcken übereinstimmt und im letzten Zifferblock irgendeine Zahl xxx enthält die eindeutig ist und sich im WLAN Netzwerk von allen anderen Knoten (Laptop, WIZnet610wi) in den letzten 3 Ziffern unterscheidet. xxx darf einen Wert zwischen 0 und 255 annehmen.

Dann folgt das WIZnet610wi mit der bekannten IP-Adresse 192.168.1.75 und der Port-Nummer 12345. Das WIZnet Modul ist dann mit dem Microcontroller Board in der Lok über 3 Drähte verbunden. Diese 3 Drähte (Ihr ahnt es schon) stellen die Serielle Verbindung auf UART-Schnittstellenbasis (5 Volt Pegel) ohne irgendeine Codierung auf der Schnittstelle dar.

Damit ist nun die gesamte Kommunikationsstrecke erklärt: Die gelben und grünen "Blitze" stellen den Kommunikationsfluss in Tx und Rx Richtung vom Laptop zur Lok und umgekehrt von der Lok zum Laptop dar.

Es handelt sich um eine bidirektionale Kommunikation (bidirektional= in beide Richtungen). Das heisst jeder Kommunikationspartner kann senden und empfangen.

Der Router Linksys verhält sich vollkommen "transparent". Er übernimmt lediglich eine Vermittlungsfunktion zwischen den Kommunikationspartnern. Es empfiehlt sich immer, einen Router bei der WLAN Kommunikation einzubinden (sozusagen als "Vermittler"), wenn mehr als zwei Kommunikationspartner in einem Netzwerk vorhanden sind.

Tarnsparent heisst: Wenn einer der Kommunikationspartner ein Telegramm an den anderen senden möchte, dann braucht er nur die Adresse des Paretners zu kennen - nicht die des Routers. Das Netzwerk verwaltet sich durch den Router selbst. Das macht die TCP/IP Kommunikation so genial: Der Anwender braucht sich um Nichts zu kümmern, das Netzwerk sorgt selbst dafür, dass es kein Chaos zwischen den Kommunikationspartnern gibt. Auch sorgt es dafür, dass Datenpakete erneut ausgesendet werden, sollte der Empfänger dem Netzwerk (NICHT dem Sender) keinen Empfang des Datentelegramms mit einem sogenannten (ACK)nowledge "quittieren". Genauso kann der Empfänger bei (durch Störungen) verfälschten Daten dem Netzwerk ein NAK (NoAcKnowledge) zurückgeben und dadurch eine Wiederholung des Datentelegramms (auch Datagram genannt) anfordern.

Von alledem merkt der Anwender (oder der Programmier, der die Schicht 7 - also das eigentliche Nutzprogramm programmiert) gar nichts. Das regeln die unterlagerten Schichten des ISO/OSI Referenzmodells (alles Software). Nun wird auch klar, warum die ganze Welt mit großer Disziplin sich diesem Modell unterworfen hat. Es ist für alle eine Riesenerleichterung.

Man muss sich das ganze wie bei EBAY vorstellen: Weder den Verkäufer noch den Käufer interessiert die dazwischenliegende Logistik für Geld und Warenaustausch in den Details wirklich:
Die Logistik für die Waren übernimmt DHL, die Logistik für das Geld PayPal. (Na ja, manchmal geht etwas schief - aber PayPal entlastet den Käufer doch erheblich vom Risiko ...!)

Würde man nun ein serielles Protokoll über die Luft schicken, so würde es hier keine Normierung geben. Die DCC-Hersteller müssen sich für ihre Handhelds das Protokoll selbst schreiben. Dieses Protokoll muss also alles regeln: Was passiert wenn zwei Handsender gleichzeitig an die Zentrale senden, die Zentrale aber nur einen Handsender in einem Zeitintervall bedienen kann ? Wer darf zuerst senden ? Darf jeder wild darauf los senden, oder wird er von der Zentrale in regelmässigen Zeitabständen abgefragt, ob der Handsender einen Sendewunsch hat .... und und und).

Um alles das braucht man sich bei Verwendung des ISO-OSI Referenzmodells (mit dem sogenannten TCP/IP Stack) nicht kümmern, das Netzwerk regelt sich selbst.

UND GENAU DAS, MACHT WLAN & ETHERNET so GENIAL für die gesamte Welt - also auch für uns in der Modelleisenbahnsteuerung.

Um ganz deutlich zu sein: Ich kann hier gar nicht alle Aspekte (Vorteile) der Verwendung der ETHERNET oder WLAN Technologie erläutern. Man müsste schon Nachrichtentechnik über mehrere Semester an der UNI studieren, um alles zu verstehen und zu erkennen - aber wir wollen ja auch "nur" spielen!

Nun muss man sich noch zwei weitere Dinge merken:

Man braucht nicht unbedingt einen Router im WLAN verwenden, die beiden Kommunikationspartner können im sogenannten ADHOC Betriebsmodus auch direkt miteinander kommunizieren.
Schaltet man aber einen Router dazwischen, dann betreibt man das Netzwerk (die Kommunikation) im sogenannten INFRASTRUCTURE Modus. Ersteinmal stehen beide Modi gleichberechtigt nebeneinander.

Die Unterschiede sind dennoch vielschichtig

http://de.wikipedia.org/wiki/Wireless_L ... ktur-Modus

http://de.wikipedia.org/wiki/Wireless_L ... -hoc-Modus

Wir merken uns einfach:

Wenn wir mit wenigen WLAN Teilnehmern (ideal nur ein Smartphone, nur eine Lok) auf einer Anlage fahren, kann man sich den Router sparen.
Wenn die Umgebungsbedingungen schlecht sind (RC-Funker im 2,4 Ghz Bereich in Messehallen kollidieren mit WLAN-Frequenzen), ist ein Router dringend empfohlen.

Ein Router verdoppelt im günstigsten besten Fall die Reichweite: Man stelle sich vor, ein WLAN hat im freien Feld eine Reichweite von 100 Metern. Dann ist die maximale Entfernung zwischen Smartphone und Lok im ADHOC Modus 100 Meter.

Denkt man sich nun einen Kreis mit Radius 100 Meter (Durchmesser 200 Meter !!!) und stellt den Router auf den Mittelpunkt des Kreises, so verdoppelt man die Reichweite, wenn Smartphone, Router und Lok sich auf einer Linie befinden: Die Entfernung vom Smartphone zum Router beträgt 100 Meter, die Entfernung vom Router zur Lok noch einmal 100 Meter.

Wir lernen daraus: Ein Router gehört (Feuchtigkeitsgeschützt) in die Mitte der Anlage.

Die gute Nachricht: Das WIZnet610wi beherrscht beide Modi !
Die schlechte Nachricht: Die Umstellung von einen in den anderen modus bedeutet Aufwand, im schlimmsten Fall hängt sich das WIZnet auf (manchmal, wenn man es über Funk macht). Man muss dann mit einer Kabelverbindung an das WIZnet610wi, um es wieder neu zu konfigurieren. Das ist an einem Fahrtag lästig. Man solte sich also vor dem Fahrtag entscheiden, in welchem Modus man fahren möchte.

Fortsetzung folgt!

IPTRAIN
Senior
Beiträge: 202
Registriert: Di 15. Jan 2013, 20:20
[phpBB Debug] PHP Warning: in file [ROOT]/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1275: count(): Parameter must be an array or an object that implements Countable

Re: Die Kommunikationsstrecken RS232 & TCP/IP

Beitrag von IPTRAIN » Fr 1. Feb 2013, 04:02

Hallo zusammen,

um auch einmal zu zeigen, dass das OSI-Referenz-Modell nun in der Wirklichkeit angewandt wird und nicht nur eine theoretische Fiktion ist, habe ich mal ein sogenanntes "Sniffer-Programm" bemüht, um eine Kommunikation über WLAN zwischen meinem Laptop und einem Raspberry Pi (=RPi) abzuhorchen. So etwas ist streng verboten, wenn man im Sinne des Telekommunikationsgesetzes unbefugt Daten mitschneidet / abhorcht.

Das Programm Wireshark http://de.wikipedia.org/wiki/Wiresharkist aber legal, das Tun kann im speziellen Fall illegal sein (- aber nicht in diesem Fall)!

Anbei ein Screenshot:
WLAN-Sniff mit Wireshark.jpg
Anstelle des zuvor erwähnten E-mail-Programmes oder des Browsers habe ich in obigem Beispiel ein Terminal-Programm gestartet, das per SSH auf andere Rechner zugreifen kann:
Es erlaubt mir, mich von meinem Laptop aus über eine Kommunikationsstrecke (z.B. über WLAN) in einen anderen Rechner "einzuloggen" und dort als normaler Benutzer allen möglichen Sinn oder Unsinn anzustellen.

Näheres zu SSH hier: http://de.wikipedia.org/wiki/Ssh

Gleichzeitig habe ich auf dem RPi Wireshark gestartet, und die Daten, die zwischen meinem Laptop und dem RPi ausgetauscht werden, "mitzuhorchen" (zu "sniffen", also auch sichtbar zu machen). Der Output landet über andere Tricks in Echtzeit auf meinem Laptop. Von diesem Fenster habe ich genau den obigen Screenshot gezogen.

Wireskark zeigt nun einen Momentan-Mitschnitt in seinem Scrollbereich von geschätzt ca. 1 Sekunde Aufzeichnungsdauer!
Man sieht also, welche Unmengen an Daten über ein WLAN normalerweise "fliegen". Aus Vertraulichkeitsgründen habe ich bestimmte Netzwerkdaten mit Rechtecken ausgegraut.

Wir sehen also im oberen Scrollbereich pro Zeile ein Datenpaket ("Datagramm" http://de.wikipedia.org/wiki/Datagramm), das für eine eigenständige Datenübertragung zwischen dem RPI und dem Laptop stehen.

Es handelt sich hier um eine "verbindungsorientierte Datenübertragung", da in der Schicht 4 TCP verwendet wird (ginge ja auch nicht anders: Wenn man sich auf einem anderen Rechner einloggt, dann ist das ja ein fortwährender Vorgang, der eine dauernde Verbindung braucht - so wie ein Telefongespräch).

Im Scrollbereich habe ich ein Datagramm mit einem roten Rechteck strichmarkiert. Im darunterliegenden grauen Bereich (auch strichmarkiert) sieht man nun sehr schön die verwendeten Schichten im OSI-Referenzmodell, die für die Übertragung dieses einzelnen Datagramms genutzt wurden:

Es sind die Schichten 1 - 4 und die Schicht 7 (Anwendungsebene), in der SHH abläuft. Schicht 5 und 6 werden für SHH nicht gebraucht, das OSI-Modell erlaubt es per Definition, dass nicht benötigte Schichten einfach leergelassen werden (entsprechende Brief-Couverts werden also einfach weggelassen).

In dem untersten Bereich erlaubt Wireshark nun einen Einblick in die (asugewählte) Schicht 7 (ich kann aber auch die Schicht 4 oder jede andere Schicht zu diesem Datagramm auswählen), in der ich mir die in der Schicht jeweils übertragenen Daten anschaue.

In Schicht 7 sind das die reinen Nutzdaten, in Schicht 4 wären das zusätzlich die PortAdressen etc., in Schicht 3 dann auch noch die IP-Adressen etc., in Schicht 2 zusätzlich noch die MAC-Adressen etc.

Bezüglich Schicht 7 haben wir aber in einer Sicht nun doch Pech gehabt:

Alle Daten sind verschlüsselt, denn SHH ist ein Programm, das eine sichere Übertragung garantiert, die niemand mitlesen kann! Niemand kann also jemals rausfinden, was nun wirklich übertragen wurde.

Aber für die ganz Neugierigen unter uns habe ich dann doch mal einen Screenshot aus der Anwendung SSH gezogen (ein Programm, das SHH umsetzt, heisst unter Windows PUTTY):
Terminal Session auf RPi.jpg
:lol:

(Es zeigt die Statusmeldungen von meinem RPi, auf dem gerade ein Linux Software-Update aus dem Internet abläuft) ;)

Wireshark ist übrigends Freeware. Jeder von uns kann (auch als Laie) das Programm downloaden, installieren und seine Internet-Schnittstellen am PC "mitloggen" - es ist kinderleicht und macht Spass! So wird man zum Netzwerkexperten - ein erster Schritt zumindest. ;)

Fortsetzung folgt!

IPTRAIN
Senior
Beiträge: 202
Registriert: Di 15. Jan 2013, 20:20
[phpBB Debug] PHP Warning: in file [ROOT]/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1275: count(): Parameter must be an array or an object that implements Countable

Re: Die Kommunikationsstrecken RS232 & TCP/IP

Beitrag von IPTRAIN » So 3. Feb 2013, 11:19

Hallo zusammen,

nachdem wir die Theorie soweit verstanden haben, gehen wir nun ein Stück in die Praxis, um uns mit den Kommunikationsstrecken auch im "spielerischen" Umgang vertraut zu machen.

Dabei bedienen wir uns verschiedener Tricks, bevor es dann ganz ernst wird!

Dabei haben wir immer dieses Bild vor Augen, welches unsere spätere Kommunikation mit der Lok symbolisiert anzeigt:
Kommunikationsstrecke WLANCROC.jpg
Nun werden wir Teile dieser Kommunikationsstrecke wegnehmen (nämlich die Lok mit dem Microcontroller-Board) und durch einen "Kurzschluß" (kein elektrischer Kurzschluß, sondern ein nachrichtentechnischer oder kommunikationstechnischer Kurzschluß) ersetzen.

Schauen wir uns einmal dieses Bild dagegen an und konzentrieren wir uns auf die unteren Rechtecke in beiden Bildern:
Kommunikationskurzschluss.jpg
Wenn ich nun ein weiteres Board (was das ist, sage ich gleich) nehme, und dieses direkt mit dem Laptop (PC) verbinde, dann sieht man, dass ich die Lok selbst (mit ihrem Mikrocontroller Board) mit einem weiteren Programm auf meinem Laptop "simuliere". Ich simuliere also, wie die Lok Daten (gelbe Pfeile) entgegennimmt (diese verarbeite ich dann in meinem Kopf) und antworte dann, indem ich Antwortdaten am Laptop wieder in ein Fenster eingebe und die dann (als grüne Pfeile) wieder auf die Reise schicke (über mein kleines zusätzliches Board) zum Wiznet610wi - dann über den Router ... zurück zum Laptop, in das bekannte Fenster "TCP- Test Tool" .

Damit wir nicht durcheinanderkommen: Ich habe nun auf meinem Laptop zwei Programme aktiviert: Das bislang bekannte Programm simuliert das Smartphone (rechts auf dem Laptop - Bildschirm) und schickt Daten vom Smartphone über TCP/IP auf die Reise zur Lok (gelbe Pfeile).
Der dem Laptop am nächsten liegende Kommunikationspartner ist der Linksys Router. Gleichzeitig zeige ich mit dem Programm Daten an (grüne Pfeile), die von der Lok an das Smartphone zurückkommen.

Nun das zusätzliche Fenster (anstelle der Lok - auf dem linken Laptop Bildschrim)):
Dieses Programm ist ein sogenanntes "Serielles Terminalprogramm", das Daten von/auf einer Seriellen Schnittstelle empfangen / verschicken kann.

Im Bild seht Ihr das Programm "Terminalbpp", welches hier näher erklärt wird https://sites.google.com/site/terminalbpp/. Man kann es sich hier https://sites.google.com/site/terminalb ... edirects=0 herunter laden ...! Keine Angst - es ist zwar in Englisch, aber ich werde alles erklären!

Nun muss ich erst noch einmal im Detail erklären, was das ganze soll, damit es auch die Laien verstehen:

Die paketvermittelnde Kommunikationsstrecke (IP-basierend) habe ich oben erklärt.

Jetzt erkläre ich die serielle Kommunikation (vom Wiznet610wi zum MC-Board in der Lok).
Die simulieren wir aber momentan lediglich, dazu brauche ich aber eben den Ersatz für das Board mit seiner seriellen Kommunikationsschnittstelle.

Diesen Ersatz lege ich mir als zweites Programm auf meinen Laptop-Bildschirm (links). Somit kann ich also das Smartphone durch das Programm TCP-Test Tool (rechts) und das MC-Board durch das Programm "Terminalbpp" (links) simulieren.

Ich schicke also von einem Programm auf dem Bildschirm Daten zu einem anderen Programm auf dem Bildschirm (beide sind also im Computer aktiv), wobei ich aber die Programme nicht über den Computer selbst (in seinem Innern) miteinander kommunizieren lasse (das wäre auch möglich, aber ist für unser Lernen ja nicht hilfreich), sondern ich leite den Datenstrom aus dem Computer raus (über seine Schnittstellen) ... und wieder rein!

Also eine vollständige Simulation der gesamten Kommunikation mit Hilfsmitteln, wobe ich lediglich das Steuerungsboard in der Lok und die Lok selbst weglasse (ist doch ganz einfach - gelle :lol: ... oder nicht oder wohl oder doch ???)!

Damit das ganze funktioniert, müssen wir uns ein wenig mit unserem Computer auseinandersetzen:

Ein Computer hat eine Menge von Schnittstellen, über die er mit seiner Aussenwelt kommuniziert. So ist z.B. die Tastatur auch eine "Schnittstelle" - aber halt eine mechanische! Der Bildschirm ist eine visulle Schnittstelle.
Der Comuter hat aber auch Datenschnittstellen z.B. seine TCP/IP - Schnittstelle (- entweder über eine RJ45 Buchse http://de.wikipedia.org/wiki/RJ45 oder seine WLAN Karte) oder eben seine serielle(n) Schnittstelle(n).

Die klassischste Serielle Schnittstelle haben wir bereits ganz zu Anfang kennengelernt (oben - http://de.wikipedia.org/wiki/RS-232).

Jetzt kommt ein kleines Dilemma:
Die neuen Computer haben eine solche (physische) Schnittstelle gar nicht mehr - insbesondere die neueren Laptops nicht! An ihre Stelle sind die sogenannte USB-Schnittstellen http://de.wikipedia.org/wiki/Universal_Serial_Bus getreten, die diese Funktion (unter anderen) besser und schneller miterledigen. Dem Seriellen Terminalprogramm (z.B. "Terminalbpp") ist das egal, da aus seiner Sicht (softwaretechnisch) es gar nicht merkt, ob es über eine serielle RS232 oder eine serielle USB-Schnittstelle kommuniziert. Unter MS-windows heißen diese Schnittstellen immer COMx-Schnittstellen!

Das merken wir uns mal: COMx - Schnittstellen sind Serielle Schnittstellen -egal ob sie über USB oder RS232 hardwaretechnisch realisiert werden!

Jetzt muss ein jeder mal seinen PC/Laptop checken, über welche Schnittstellen er verfügt. Ich werde mich ab jetzt hauptsächlich auf die USB-Schnittstelle konzentrieren, da jeder Computer der letzten 10 Jahre eine solche haben dürfte. Wer aber dennoch - gleich aus welchem Grunde, seine RS232 beutzen möchte, der braucht nun ein solches Teil http://www.pollin.de/shop/suchergebnis. ... mmend=true (mit entsprechendem Kabel zum Anschluss an seine RS232 Computer-Schnittstelle)!

Diese Board ist ein sogenannter RS232 - (UART-) TTL - Umsetzer! Ihr erinnert Euch: Die Serielle Kommunikation wird über längere Strecken Manchester codiert und auf 15 Volt Level angehoben. Der Computer mit RS232 Schnittstelle kann also keine direkte 5Volt- UART Kommunikation, er versteht nur Manchester-Codierte serielle Signale. Also muss ein Umsetzer her!

Auf dem Bild oben sieht man zusätzlich noch ein Kabel, das RS232 auf USB umsetzt. Bedeutet also: Man kann dieses Board auch kaufen, wenn man über USB kommunizeiren möchte, braucht aber dann noch ein Kabel, das RS-232 auf USB transformiert.
Ein solches wäre dieses: http://www.pollin.de/shop/dt/MjIwODcyOT ... riell.html ... und ist im Bild dargestellt.

Aber Achtung: Es gibt sehr oft am Markt Billigschrott aus China, diese Dinger tun es nicht, wenn sehr kurze Datennachrichten übersandt werden. Das liegt an den Chips, die im Stecker verbaut sind. FTDI Chips tun es immer http://www.ftdichip.com/FTProducts.htm ... Problem ist nur, welche Chips sind im Stecker verbaut ...!

Evtl. muss man auf GutGlück kaufen und bei "Nichtgefallen" umtauschen.

Es geht aber auch anders, wenn man sowieso über USB-Buchsen die Serielle Kommunikation betreiben möchte. Dann nimmt man ein solches Teil http://www.elv.de/mini-usb-modul-um2102 ... usatz.html (Kabel nicht vergessen, mitzubestellen!!!). Das Board ist erst seit wenigen Tagen wieder erhältlich ...! War monatelang ausverkauft!

Dieses Teil macht als keine Umsetzung zwischen UART (TTL) und RS232, sondern zwischen UART und USB. Denn obwohl USB auf 5 Volt normiert ist, sind die Daten (für die längere Übertragung auch codiert).

Mit diesem Wissen kommen wir nun zu diesem Bild:
UART-Kurzschluss.jpg
In diesem Bild sieht man nun das ELV Uart Board. Die meisten von Euch dürften es bereits haben. Wir baruchen dieses (oder das RS232 Board von Pollin) auf jeden Fall auch später für die Wartung unserer Lok ...!

Wir lassen nun ersteinmal (hilfsweise) das ganze TCP/IP Gerümpel weg und konzentrieren uns nur auf die Serielle Kommunikation - wie im Bild dargestellt.

Wenn wir also dann aus unserem seriellen Terminalprogramm Daten versenden wollen, gehen die natürlich über die Schnittstelle raus .... aber landen an einem offenen Pin auf dem UART Port ... und nix passiert (die gehen dann auch nicht einfach in die Luft ... das wäre ja zu schön, um wahr zu sein). Die Information geht also (wie man zu sagen pflegt) ins "Nirwana".

Wenn man aber jetzt hinterlistigerweise :twisted: auf dem UART-Board den Tx-Pin mit dem Rx-Pin über eine kleine Drahtbrücke verbindet ("kurzschliesst"), dann werden vom UART-Umsetzer die Daten direkt wieder zurückgeleitet und landen dementsprechend im Empfangsbereich des Terminalprogramms, wo sie sichtbar werden. :roll: :idea: :mrgreen:

Hierzu kommen wir nun sehr detailiert! ;)

Fortsetzung folgt!

Benutzeravatar
Lippebahner
User
Beiträge: 48
Registriert: Di 15. Jan 2013, 20:18
Wohnort: Detmold
Kontaktdaten:

Re: Die Kommunikationsstrecken RS232 & TCP/IP

Beitrag von Lippebahner » So 3. Feb 2013, 15:48

IPTRAIN hat geschrieben:Wir verfolgen nun einmal die Kommunikationsstrecke im 1. Schaubild des vorhergehenden Posts:

Wir sehen also den Laptop mit dem Programm "TCP Test Tool", weiterhin einen Router (Linksys), der auch eine IP-Adresse besitzt. Seine IP-Adresse muss irgendeine IP Adresse sein, die mit dem Laptop und dem WIZnet610wi in den ersten 3 Ziffernblöcken übereinstimmt und im letzten Zifferblock irgendeine Zahl xxx enthält die eindeutig ist und sich im WLAN Netzwerk von allen anderen Knoten (Laptop, WIZnet610wi) in den letzten 3 Ziffern unterscheidet. xxx darf einen Wert zwischen 0 und 255 annehmen.

Dann folgt das WIZnet610wi mit der bekannten IP-Adresse 192.168.1.75 und der Port-Nummer 12345. Das WIZnet Modul ist dann mit dem Microcontroller Board in der Lok über 3 Drähte verbunden. Diese 3 Drähte (Ihr ahnt es schon) stellen die Serielle Verbindung auf UART-Schnittstellenbasis (5 Volt Pegel) ohne irgendeine Codierung auf der Schnittstelle dar.
Hallo,
habe mal zur veranschaulichung eines Netzwerks und deren Adressen eine Skizze angefertigt.
Grundsätzlich Arbeite ich mit "Statik IP " außer an Fahrtagen, da wird "DHCP" Aktive sein.
Ab einer gewissen Teilnehmerzahl auch zwingend erforderlich.

Bild

Wie zu sehen ist der Ziffernblock bis auf die letzten 3 Stellen immer =
Eine Kommunikation unter allen geräten möglich.
Der Aufbau basiert auf ein Gigabit (1000 Mbit´s) Netzwerk mit 2 Internetanschlüssen.
Gruß Marcel :D

http://tinypic.com/3ia3l0k3
Mein Kanal :http://www.youtube.com/user/Lippebahner
Meine Kamera : http://lippebahner.selfhost.me/
Zugang für 1ne Stunde : Name =Gast | PW =Gast

IPTRAIN
Senior
Beiträge: 202
Registriert: Di 15. Jan 2013, 20:20
[phpBB Debug] PHP Warning: in file [ROOT]/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1275: count(): Parameter must be an array or an object that implements Countable

Re: Die Kommunikationsstrecken RS232 & TCP/IP

Beitrag von IPTRAIN » So 3. Feb 2013, 17:19

Hallo Marcel,

Klasse, so gewinnen wir an Fahrt. Es kommen immer mehr Beiträge von Mitgliedern, so dass dieses Forum ein richtiger Wissenpool für die Modelleisenbahn wird.

Weiter so - vielen Dank.

LG vom Karl

Benutzeravatar
Lippebahner
User
Beiträge: 48
Registriert: Di 15. Jan 2013, 20:18
Wohnort: Detmold
Kontaktdaten:

Re: Die Kommunikationsstrecken RS232 & TCP/IP

Beitrag von Lippebahner » Di 5. Feb 2013, 21:01

Hallo,

Da wir uns hier mit TCP/IP befassen, mal eine kleine Fotostrecke wie man an die Infos der Adresse kommt.

Unter Windows ab XP bis Windows 8

Zunächst einmal öffnn wir die Systemsteuerung

Bild

Dort suchen wir das Netzwerk und Freigabecenter
Im Bild oben "Schwarz" makiert. Dort machen wir einen klick mit der Linken Maustaste

Bild

Dort finden wir die /den Netwerkadapter
Das " Scvhwarz" makierte Feld = Lan-Vebindung einmal anklicken

Bild

In den Statusfeld ist nun zu sehen , seit wann die Verbindung besteht, mit Welscher geschwindigkeit
und die Datenmenge die Gesendet und Empfangen wurde.

Wenn wir Jetzt auf " Details" klicken ( Schwarz eingerahmt ) Dann sehen wir die "Zugewiesenen" (DHCP) oder "Statischen" Daten

Bild

In meinem Beispiel ist bei DHCP = NEIN

Gateway ist nun bei mir die FritzBox 6360 Cabel

Diese Daten sind bei änderungen am Netzwerk sehr nützlich. Wenn wir das Fenster jetzt schließen , gelangen wir wieder zu den Details

Bild

wenn wir nun auf "Eigenschaften" klicken dann sehen wir die Eigenschaften des Netzwerk-Controllers.

Bild

Eventuell müssen wir runterscrollen bis wir das Schwarz markierte Feld sehen, " Internetprotokollversion 4 (TCP/IPv4)

Diese klicken wir einmal an somit wird das Blaue Feld " Eigenschaften" sichtbar und wir Klicken darauf.

Bild

In dem Schwarzen Feld geben wir nun die IP-Adresse ein die wir diesem Rechner geben möchten, wie von Karl so schön erklärt, müssen die ersten 3 Blöcke im
Netzwerk absolut Identisch sein die Letzte eine Zahl zwischen 1 und 254, wobei jede Zahl nur Einmal vertreten sein darf.
Ist im Router "DHCP" noch Aktive sollte Darauf geachtet werden, das die meisten Router Adressen von 20-200 Automatisch vergeben.
wir sollten also mit den Statischen ausserhalb dieses Bereiches bleiben dann giebt es keine Konflikte.
Im Netzwerk sollte auch darauf geachtet werden, das nur ein "DHCP" server Aktiviert ist falls jemand einen ACCESS-Point im Garten deponiert um sein W-Lan zu verbessern.
Die Gateway Adresse ist die vom Router ( Internetzugangspunkt )

Die DNS Adresse ist im Grunde die selbe wie die Gateaway oder bei mir die erste GOOGLE = 8.8.8.8

wenn das erledigt ist , mit OK bestätigen.

Wer ein Video Bevorzugt http://www.youtube.com/watch?v=sgBaTw--cqc
Gruß Marcel :D

http://tinypic.com/3ia3l0k3
Mein Kanal :http://www.youtube.com/user/Lippebahner
Meine Kamera : http://lippebahner.selfhost.me/
Zugang für 1ne Stunde : Name =Gast | PW =Gast

IPTRAIN
Senior
Beiträge: 202
Registriert: Di 15. Jan 2013, 20:20
[phpBB Debug] PHP Warning: in file [ROOT]/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1275: count(): Parameter must be an array or an object that implements Countable

Re: Die Kommunikationsstrecken RS232 & TCP/IP

Beitrag von IPTRAIN » So 10. Feb 2013, 12:58

Hallo zusammen,

wir schauen uns noch einmal dieses Schema an:
UART-Kurzschluss.jpg
Zur Wiederholung:

Es zeigt das Terminal Programm auf unserem PC, mit dem man Daten über eine serielle Schnittstelle versenden und empfangen kann. Eine Serielle Schnittstelle unseres PCs identifizieren wir immer über den Namen COMx !

Nehmen wir nun einmal unser Mini-USB-Modul UM2102 http://www.elv.de/controller.aspx?cid=726&detail=30827 und verbinden es über das entsprechende Kabel mit der USB Buchse an unserem PC.

Vorher gehen wir über ein entsprechendes Menu unter dem Windows Betriebssytsem in die "Systemsteuerung" und wählen dort den "Gerätemanager" aus. Man landet dort auch, indem man sich irgendwo den Begriff "Computer" im Startmenu oder auf dem Desktop auswählt und dann mit der rechten Maustaste auf "Eigenschaften" tippt. (Es gibt viele Möglichkeiten, in den Gerätemanager zu kommen, ich kann nur diese beispielhaft erwähnen. Den Gerätemanager gibt es in jeder PC-Windows Betriebssystem Version bis heute!)
Geraetemanager (ohne COMx).jpg
Wie sehen in obigem Bild noch nichts spannenendes. Lassen wir aber den Gerätemanager geöffnet und stecken jetzt das UM2102 über das USB-Kabel an unseren PC, dann verändert scih das Bild und wir sehen die nachfolgende Einfügung:
Geraetemanager (mit COM8).jpg
Der PC hat also das Modul erkannt und hat nach einem bestimmten Algorithmus, den wahrscheinlich nur noch Bill Gates kennt, diesem erkannten Board (dieser Schnittstelle) den Namen COM8 (momentan auf meinem PC) mitgegeben.

Nun ganz wichtig: Wahrscheinlich wird dieses Board bei mir nun immer die Identifikation COM8 für die Zukunft behalten, das muss aber nicht so sein. Wenn es Schwierigkeiten in der Kommunikation gibt, schaut der Profi erst einmal in den Gerätemanager und vergewissert sich (durch Ein- und Ausstecken des Boards), welche COMx Identifikation das Board aktuell hat.

Wenn bei Einstecken des Boards keine Reaktion kommt (im Gerätemanager) - oder Ausrufezeichen (Warnungen im Gerätemanager auftauchen - insbesondere bei älteren Betriebssystemversionen), de lade diese Treiberdatei http://www.elv-downloads.de/Assets/Prod ... 3_5_1).zip herunter und installiere sie.

Danach sollte es gehen. Wenn nicht, bitte bei Bill Gates anrufen ...!

Die COM8 (bzw. Eure COMx) nicht vergessen, die brauchen wir noch!

Nun starten wir das bereits erwähnte (serielle) Terminalprogramm (wenn noch nicht auf dem PC, dann hier https://sites.google.com/site/terminalbpp/ erhältlich).

Es öffnet sich dieses Fenster. Unter dem Pfeil sollte nun im PullDown Menu COM8 auswählbar sein - bitte selektieren.

Dann den CONNECT Knopf (ovaler Kreis) drücken. Und nun schaut Ihr bitte auf diesen Screenshot:
Erste serielle Verbindung (Kurzschluss).jpg
Ihr seht, dass sich der CONNECT Knopf in einen DISCONNECT Knopf geändert - hat (Drückt man ihn, wird die Verbindung wieder aufgelöst. Momentan nicht drücken!).

Ihr seht 4 Kennzeichnungen:

Kennzeichnung 1 ist die Eingabezeile, in der man Nachrichten eingeben kann, die dann über die serielle Schnittstelle versandt werden sollen.
Kennzeichnung 2 ist ein Steuerzeichen, das <CR> (Carriage Return = "Wagenrücklauftaste") genannt wird. Es ist ein einzelnes Zeichen (also auch ein Byte, wie auch jeder Buchstabe, Zahl, etc. ein Byte ist), dass auf dem Bildschirm des EMPFÄNGERS eine bestimmte Aktion in der Darstellung bewirkt.

Und zwar sorgt es dafür, dass nach Anzeigen der gesendeten Nachricht der sogenannte Cursor an den linken Rand positioniert wird, wo dann die nächste Nachricht anfangen wird.
Sendet man dieses Zeichen nicht, dann bleibt der Cursor beim Empfänger hinter der aktuellen Nachricht stehen, und die darauffolgende Nachricht wird nahtlos auf dem Bildschirm angehängt. Ihr könnt den Unterschied durch Ein-uns Ausschalten des Häkchens ausprobieren.

Kennzeichnung 3 (Taste "Send") versendet die Nachricht! Wichtig zu wissen: Der PC (die Hardware ... wie auch alle an einer Kommunikation beteiligten Bausteine versenden erst dann eine Nachricht, wenn man es ihnen ausdrücklich befiehlt (durch Drücken der Sendetaste z.B.). Ansonsten werden erst alle Zeichen gesammelt!
Anders die PC-Tastatur selbst, die man drückt, die "versendet" das gedrückte Zeichen immer sofort an den Mikroprozessor im Computer ...., der es sofort verarbeitet, z.B. um es am Bildschirm sofort anzuzeigen. Ansonsten würde man zwar eine Taste drücken, aber das Zeichen würde nicht am Bildschirm erscheinen ...!

Kennzeichnung 4 zeigt die Nachricht, die nach Drücken der Taste (Kennzeichnung 3) gesendet wurde (mit sogenanntem Zeitstempel des Empfangs).

Sooooo - nun das Entscheidende: Die Nachricht würde zwar normalerweise versendet werden, wenn man <Send> drückt, aber nicht im Bereich 4 angezeigt werden.
Bereich 4 zeigt nämlich nur Nachrichten an, die vom Terminalprogramm über die serielle Schnittstelle empfangen worden sind!

Wo kommt denn nun die Nachricht her ??? Durch einen Trick!

Fortsetzung folgt!

Antworten
[phpBB Debug] PHP Warning: in file [ROOT]/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1275: count(): Parameter must be an array or an object that implements Countable

Zurück zu „Aktueller Stand“