Step 7 Profinet Datenübertragung im Vergleich zu Profibus

bernd67

Level-2
Beiträge
138
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
ich möchte einige Daten über Profinet übertragen.
Habe bei einer ähnlichen Anlage schon mal Daten
über Profibus übertragen.
Meine CPU 315-2 PN/DP war da der Slave und in der
Hardware konnte ich unter Betriebsart Slave einstellen, um
dann unter Konfiguration meine Adressbereiche festlegen.
Geht das bei der Profinet Übertragung ähnlich?

Gruss bernd67
 
Hallo,

ja das geht ähnlich.
Frage ist ob du PROFINET RT oder PROFINET IRT benutzt.
Wenn IRT dann muss eine CPU als SYNC-MASTER und eine als SYNC-SLAVE konfiguriert sein.
Diese Einstellungen findest du an der PN Schnittstelle der CPU unter Domain-Management.

Wei schaut der Rest der Anlage aus, also wer greift die Daten ab, eventuell kann man die CPU auch als I-Device mittels GSDML Datei einbinden.

Gruß
Christoph
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Christoph!

Kenne den Unterschied RT zu IRT leider nicht.
Beim PB war meine CPU der Slave und der andere Anlagenteil
der Master.
Die beiden haben dann jeweils 8Byte ausgetauscht.
Also in beide Richtungen.
So soll es jetzt mit PN auch sein.
 
hattest du bei der PB Konfiguration einen äquidistanten DP Takt?
Wenn nein dann reicht RT wenn ja dann IRT

Waren beide Geräte in einem Projekt oder war der Slave per GSD an den Master angebunden?
 
Meine CPU war als Slave
an den Master per GSD angebunden.
Die Programmierung am Master wurde
aber von jemand anders gemacht.
 
Hallo,

ok dann wird das am sinnvollsten per i-Device Kopplung gemacht.
Du konfigurierst deine Steuerung als i-Device und legst die Transferbereiche an. Anschließend erzeugst du die GSDML Datei für dieses I-Device und bindest sie in das projekt ein
wo die Master CPU konfiguriert ist.

Gruß
Christoph
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die CPU auf SLAVE schalten ist immer doof.

Das sinnvollste ist ein PN-PN-Coupler. Da kann man (anderes als beim DP-DP-Koppler) ganze RECORDs (also z.B. DBs) übertragen.

Dazu ist zu beachten, dass es bei der Hardwarekonfig eine LINKE-PN-Seite und eine RECHTE-PN-Seite gibt.
 
@IBFS
Kannst du näher erläutern warum du einen PN-PN Koppler einsetzen würdest?
Es geht hier um 8Byte Daten , ist da der Koppler nicht ein bißchen Kanonen auf Spatzen?
 
@ChristophD

Da man den PN-Anschluss heutzutage eigentlich für das Anbinden für Displays oder zum Programmieren
verwendet, kann man den Anschluss nicht mal schnell aus SLAVE umbiegen. Also ich würde es nicht machen.
Und ob man 8Byte oder 88Byte austauschst ist fast egal Hauptsache man hat einen transparenten Aufbau.
Gerade in Verbindung mit CPUs von Fremdfirmen nehme ich fast nur noch den PN-PN-Koppler.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi,

Also wenn wir von PROFIBUS reden würden dann würde ich das mit dem Slave ja verstehen, aber bei PN?
Selbst wenn die CPU als SyncSlave konfiguriert ist werden an der PN Schnittstelle alle Funktionen wie gewohnt funktionieren.
Bei PROFIBUS war das problematisch da die CPU dann meist in einen passiven Modus gewechselt ist und z.B. eine HMI Kommunikation nicht mehr möglich war, aber bei PN
ist mir das noch nie untergekommen, sämtliche HMI Geräte, Step7 Funktionen (beobachten, Steuern etc.) funktionieren an einer PN Schnittstelle unabhängig vom eingestellten Modus, einen reinen SLAVE Modus wie bei PROFIBUS gibt es da nicht.
 
Warum wirft niemand dinge wie PUT/GET T_SEND/T_RECV etc in den Raum?

Danach kann der TE dann im Forum suchen und findet für sich hoffentlich das richtige!

Grüße

Marcel
 
Warum wirft niemand Dinge wie PUT/GET T_SEND/T_RECV etc in den Raum?

Weil es den Raum nicht gibt, also nicht bei mir. - Scherz beiseite -

Ich versuche weitestgehend auf so etwas wie PUT/GET etc. zu verzichten.

In einigen Firmen werden die Hardwareprojekte getrennt von der Software erstellt (im CLASSIC)
und dann vom Masterprojekt die Hardware in alle CPUs gebügelt.
Wenn ich jetzt anfangen würde da irgendwelche Verbindungen projektieren zu wollen das frisst das Zeit
und ist mit dem Risiko verbunden, das jemand daherkommt und die falsche Hardware einspielt.

Dann schon lieber einen DP-DP-Koppler oder PN-PN-Koppler. Das versenke ich das Geld lieber in die Hardware
und weiß sicher das es immer geht, als aus der Ferne doofe Anrufe zu bekommen "Verbindung ist unterbrochen".
Jede "Freifahrt" nachher ist bestimmt teurer als die 500€ für die Hardware.

Für mich ist das ein fest eingeplanter Risikobeseitigungszuschlag.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bei solchen Sachen gebe ich dir recht.

Aber bei der Kommunikation von 2 CPU wo vorher kein DP/DP Koppler nötig war, wird vermutlich auch kein PN/PN-Koppler nötig werden. Daher mein Vorschlag!

Ich setze auf Kommunikation ala send/recv... allein schon bei der F-Kommunikation.
(ich habe aber kleinste Inselanlagen und der einzige der an HW und SW fummelt)

Grüße

Marcel
 
Bei Profinet IO wird im Gegensatz zum Master-Slave-Verfahren von Profibus ein Provider-Consumer-Modell verwendet, das die Kommunikationsbeziehungen zwischen den gleichberechtigten Teilnehmern am Ethernet unterstützt.
 
In einigen Firmen werden die Hardwareprojekte getrennt von der Software erstellt (im CLASSIC)
und dann vom Masterprojekt die Hardware in alle CPUs gebügelt.
Wenn ich jetzt anfangen würde da irgendwelche Verbindungen projektieren zu wollen das frisst das Zeit
und ist mit dem Risiko verbunden, das jemand daherkommt und die falsche Hardware einspielt.

Eine vermurkste Projektplanung durch Einbau von zusätzlicher Hardware korrigieren? Kann man machen, aber der Königsweg sieht denk ich mal anders aus.
Ein Step7 (Classic) Projekt lässt sich auch übers Netzwerk mit mehreren Benutzern bearbeiten, falls das nicht bekannt sein sollte.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also mit den PN/PN-Kopplern haben wir auch ne Weile geliebäugelt ... Schliesslich hatten wir vorher auch jede Menge DP-Buskoppler verbaut.
Für die Vernetzung ganzer Linien bauen wir ein eigenes Netz auf und nehmen für jede Stationen einen eigenen CP. Somit haben wir eine ganz klare Trennung der Anlagen und zusätzlich die Möglichkeit an MES-Systeme zu koppeln.
Für die Kopplung nur 2er Stationen würde ich eine normale ISO on TCP Verbindung verwenden mit AG_SEND und AG_Recv.
Wenn es zeitkritisch ist, dann stattdessen eine Station als I-Device parametrieren.

Gruß
Dieter
 
Zuletzt bearbeitet:
@Alex:

Du schreibst hier Quatsch.
Es geht nicht um Master - Slave auf Ebene 2 des Iso-Schichtmodells sondern um Ebene 7 Kommunikationsverbindungen.
Und da ist mit Master-Slave was komplett anderes gemeint
 
Ein Step7 (Classic) Projekt lässt sich auch übers Netzwerk mit mehreren Benutzern bearbeiten, falls das nicht bekannt sein sollte.

Wenn du mir erklärst, wie das gehen soll, wenn die einzelnen Programmierer aus getrennten Abteilungen, Standorten und Firmen kommen, dann bitte!

Du darf nicht immer von propagierten Idealfall ausgehen. Einzelne Anlagenteile müssen schon produzieren, da gibt es bestimmte andere Anlagenteile noch gar nicht.

Da kann man nicht mal schnell irgendwelche Hardwarestrände einspielen. Ausserdem gehen - aus Erfahrung - solche projektierten Verbindungen oft leider nicht auf Anhieb.

Da muss man dann - ohne das das Projekt nochmals geändert wurde - die HWKonfig noch eine oder zweimal überspielen bis sich die CPUs gefunden haben. Frage SIEMENS warum das so ist.
 
Zurück
Oben