Technischer Hintergrund: RS232 in Profinet integrieren

N.Ewbie

Level-1
Beiträge
8
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

für mein Studium muss ich eine Arbeit zum Thema: "serieller Bus (RS232) in Profinet einbinden" schreiben.
Ich soll also erörtern, wie die Technik funktioniert auf der RS232-Profinet-Gateways basieren.
Meine Suche im Internet zeigt mir zwar eine Vielzahl von Lösungen vom Anybusmodul bis hin zum Siemens CM PtP, ich finde aber nichts, dass mir erklärt, wie solche Geräte denn generell funktionieren.
Wie funktioniert die Wandlung von einem seriellen Bus in ein Profinet? Und wie werden dabei die entsprechenden Spezifikationen eingehalten?

Kann mir da jemand entsprechende Literatur empfehlen? Ich muss es wissenschaftlich halten und Quellen vorweisen können.
Über gute Internetseiten zu dem Thema wäre ich natürlich auch schon glücklich.

Vorab schon mal Danke für Eure Mühen.

Bis dann dann,

Micha
 
Du kannst dir ja mal die Bedienungsanleitung von so einem Umsetzer ansehen, dann wirst du auch gleich die Problematik erkennen.

Denn RS232 beschreibt nur die physikalische Schnittstelle, aber nicht das Datenprotokoll was darüber gefahren wird. Je nach Protokoll welches darüber gefahren wird, kann es einfach oder kompliziert sein das in ein Paket-/Telegrammorientiertes Protokoll wie Profinet umzusetzen.
Bei Profinet hast du bei zyklischem Datenaustausch einen IO-Bereich von fest konfigurierter Datenlänge von z.B. 256 Bytes der ausgetauscht wird. Hast du nun eine Anwendung über eine serielle Schnittstelle welche z.B. lange Textnachrichten oder Dateien variabler Länge übermittelt, dann musst du diesen Datenstrom irgendwie paketieren um das auf Profinet umsetzen zu können.

Bei manchen Protokollen wie z.B. Modbus über RS232 ist das relativ einfach, weil es dort im Protokoll schon Registeradressierung gibt. Dann müsste dein Umsetzer nur konfiguriert werden wie Modbus-Register x auf Profinetadresse y umzusetzen ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Vielleicht noch als Ergänzung zu dem Beitrag von Thomas:
Die RS232 kann ereignisbezogen arbeiten - Profibus oder ProfiNet aktualisieren zyklisch den festgelegten Datenbereich.

Vorstellbar (oder Erkennbar, wo die Problematik liegt) wird das Ganze, wenn du es nicht abstrakt betrachtest sondern bezogen auf irgendein Gerät, das z.B. mit Hilfe eines ANYBus-Converters an den ProfiNet kommen soll, hier aber von Seiten der SPS eine Anfrage (wie auch immer) erfolgen muss, damit etwas ausgegeben wird.

Gruß
Larry
 
Hallo,

erst Mal Danke für eure Antworten. Der Tip mit den Handbuch war super.
Ok, bleiben wir als bsp bei einem Siemens CM PtP RS232 HF. Ich habe jetzt gelesen, dass diese Freeport, 3964 oder auch Modbus nutzen um die Daten zu übertragen oder zu empfangen.
Ich beziehe mich hierbei auf das Handbuch von Siemens s71500_cm_ptp_function_manual. Was aber leider nicht beschrieben ist, wie diese Protokolle denn die empfangenen Daten in ein Profinetprotokoll "übersetzen".
Kann ich vereinfacht sagen, dass die Nutzdaten des per Rs232 angeschlossenen Gerätes "einfach" in den Nutzdatenbereich eines Profinet-Datentelegramms verschoben werden und die zusätzlichen Informationen, welche ein Profinettelegramm ausmachen, dann vom Siemens-Modul automatisch hinzugefügt werden?

Gibts es dazu vielleicht Quellen, die mir das z.B. auch als blockdiagramm darstellen?

Danke schon mal im voraus.
 
ok,
um es mal auf eine unspezifische Basis zu bringen:
Wie funktioniert ein Protokollconverter prinzipiell?
Kennt da jmd eine gute Quelle um die Funktionsweise verstehen zu lernen? Literatur wäre als zitierfähiges Material präferiert.
Wenn ich Google bemühe finde ich immer wieder nur die handelsüblichen Angebote. Auf den Seiten der Hersteller selbst steht dann zwar was sie alles können, nicht aber wie sie es machen :-?

Danke
 
Ok, bleiben wir als bsp bei einem Siemens CM PtP RS232 HF. Ich habe jetzt gelesen, dass diese Freeport, 3964 oder auch Modbus nutzen um die Daten zu übertragen oder zu empfangen.
Ich beziehe mich hierbei auf das Handbuch von Siemens s71500_cm_ptp_function_manual. Was aber leider nicht beschrieben ist, wie diese Protokolle denn die empfangenen Daten in ein Profinetprotokoll "übersetzen".
Kann ich vereinfacht sagen, dass die Nutzdaten des per Rs232 angeschlossenen Gerätes "einfach" in den Nutzdatenbereich eines Profinet-Datentelegramms verschoben werden und die zusätzlichen Informationen, welche ein Profinettelegramm ausmachen, dann vom Siemens-Modul automatisch hinzugefügt werden?

Gibts es dazu vielleicht Quellen, die mir das z.B. auch als blockdiagramm darstellen?

Danke schon mal im voraus.

Der Siemens PtP CM ist ja kein Gateway von "RS232 nach Profinet" sondern nur eine RS232 Schnittstelle für die SPS. Wenn die SPS jetzt auch noch eine Profinetschnittstelle hat, kann die SPS vom "RS232" lesen, bearbeiten und per "Profinet" weiterschicken bzw. umgekehrt.

Also generell, die Steuerung bzw. das Gateway muss beide Systeme RS232 sowie Profinet physikalisch und protokolltechnisch lesend wie schreibend beherrschen. Dann kann auch zwischen beiden Welten ausgetauscht werden...

Gruß.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Kann ich vereinfacht sagen, dass die Nutzdaten des per Rs232 angeschlossenen Gerätes "einfach" in den Nutzdatenbereich eines Profinet-Datentelegramms verschoben werden und die zusätzlichen Informationen, welche ein Profinettelegramm ausmachen, dann vom Siemens-Modul automatisch hinzugefügt werden?

Vereinfacht gesagt ja ...
ABER
Findet auf der RS232-Seite ein echter Handshake (also ein komplexes Datenaustausch-Protokoll) statt, dann wird es sehr schwierig werden, dies z.B. mit einem ANYBUS-Konverter abzubilden/nachzubilden.

Gruß
Larry
 
Vereinfacht gesagt ja ...
ABER
Findet auf der RS232-Seite ein echter Handshake (also ein komplexes Datenaustausch-Protokoll) statt, dann wird es sehr schwierig werden, dies z.B. mit einem ANYBUS-Konverter abzubilden/nachzubilden.

Wobei man hier bei RS232 mit den Begriffen vorsichtig sein muß.
Bei RS232 gibt es mehrere Arten von Handshake, die erstmal noch gar nichts mit den eigentlichen Daten zu tun haben.
Neben den normalen Sende- und Empfangsleitungen (TxD / RxD) gibt es noch weitere Hardware-Signale (z.B. RTS / CTS, RING, DTE, ...)
Darüber kann ein Hardware-Handshake stattfinden. Dann gibt es noch den Handshake über Software (Xon und Xoff).
All das kann direkt über die entsprechende Hardware ohne Benutzereingriff laufen.
Erst danach kommen dann die entsprechenden Kommunikationsprotokolle.
Fazit:
Bei RS232 / V24 sind alle Konstanten variabel.

Gruß
Blockmove
 
um es mal auf eine unspezifische Basis zu bringen:
Wie funktioniert ein Protokollconverter prinzipiell?

Mal an einem einfachen Beispiel:
Über die serielle Schnittstelle werden über ein einfaches Protokoll Temperaturwerte im ASCII-Format ausgetauscht. Es kommt dabei die Messstellenbezeichnung, ein Gleichheitszeichen, der Wert (als Integer-Ganzzahl) und als Abschluss ein Semikolon. Z.B.
"TemperaturOben=45;TemperaturMitte=32;TemperaturUnten=26;"

Dein Protokollwandler liest nun auf der seriellen Schnittstelle diese Daten ein, extrahiert die Werte 45, 32, 26 und stellt sie im Binärformat (z.B. als 16 Bit Integer) als Profinet-Device einem Profinet-Controller zur Verfügung. Damit das funktioniert gehört dazu eine Beschreibung, damit jemand weiß dass er auf den Eingangsbytes 0/1 die Temperatur oben, auf 2/3 die Temperatur mitte und auf 4/5 die Temperatur unten als 16 Bit Integerzahlen übermittelt bekommt.

In die andere Richtung würde es in gleicher Weise funktionieren. Angenommen das Gerät mit dem da über die serielle Schnittstelle kommuniziert wird ist ein Temperaturregler, dem du über die Zeichenkette "Solltemperatur=25;" übermitteln kannst, dass es einen Raum auf 25 Grad regeln soll.

Dann bekommst du auf der Profinetseite wieder 2 Bytes, dieses mal als Eingangsdaten in deinem Profinet-Device (also Ausgangsdaten bei z.B. einer SPS). Wenn die SPS dort 25 Grad Solltemperatur haben möchte, schickt sie 2 Bytes 0x00, 0x19 eingepackt im Profinet-Protokoll, du wandelst das ins ASCII-Format und baust den String "Solltemperatur=25;" daraus zusammen und schickst es auf der seriellen Schnittstelle raus.
 
Zurück
Oben