Erfahrungen mit Profinet-IO und Profinet-CBA

Maxl

Level-1
Beiträge
1.385
Reaktionspunkte
181
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute!

Wir hatten schon vor einiger Zeit einen Thread, der sich mit diesem Thema beschäftigt hat. In der Zwischenzeit ist etwas Zeit vergangen, und ich möchte hier erneut nachfragem wie es mit praktischen Erfahrungen mit Profinet aussieht.
Dieser Thread richtet sich also ganz gezielt an diejenigen, die bereits Anlagen damit laufen haben oder Versuche gemacht haben.

Ich bin derzeit dabei, die stufenweise Einführung von Profinet bei uns im Betrieb zu planen, Komponenten auszusuchen, und Richtlinien aufzustellen. Derzeit habe ich folgende Vorgangsweise im Kopf:

1. Kopplung von CPUs und mehrwöchiger Dauerbetrieb
Es werden 2 CPU 317-2PN/DP und das Paket Simatic imap bestellt, die Kopplung erfolgt einerseits über einen Standard-Switch, später dann über einen für Profinet zertifizierten Switch. Die zyklische Kommunikation soll per CBA erfolgen.

Hier die erste Frage: hat das schon jemand realisiert und welche Signallaufzeiten sind erreichbar?


2. Kopplung von Antrieben und ET200S per Profinet-IO - Feldtest an einer Anlage mit zeitkritischen Abläufen
Als Versuchsaufbau wird eine Schleifanlage verwendet, welche eine Wiederholgenauigkeit von 10ms erfordert. Dieser Test soll die Echtzeitfähigkeit feststellen.

Hat dies schon jemand getestet? Welche Buslaufzeiten sind hier erreichbar? Echte Taktsynchronität ist nicht gefordert!


3. Auswahl der Komponenten
Müssen es Siemens Scalance-Geräte sein oder gibt es bereits Alternativen? Das Ziel soll eine hier das Finden einer Geräteserie von einem Alternativen Hersteller sein - parallel zu Siemens-Geräten, welche sich ja hin und wieder nicht vermeiden lassen.


4. Festlegung der möglichen Topologien
Welche Topologien sind möglich, ohne die Signallaufzeiten unnötig zu erhöhen? Linien-Topologien ähnlich Profibus sind ja nicht mehr möglich, oder?



Bitte schreibt mal eure praktischen Erfahrungen nieder.
Ach ja: Gibt es brauchbare Literatur zu dem Thema?

mfg
Maxl
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

vielleicht hilft es etwas.

zu 2.)
Gearbeitet habe ich mit PROFINET IO mit SINAMICS S120 und den neuen ET200s PN HF Köpfen.
Ob einen Zykluszeit von 10ms erreichbar ist hängt bei der ET200S stark von den gesteckten Modulen ab, sollten meiner Erfahrung nach aber zu schaffen sein, insbesondere mit den neune HF Köpfen die eine minimale Zykluszeit von 250 µs schaffen.
Bei einem Antrieb (SINAMICS S120) liegt die normale Zykluszeit bei 1 bis 3 ms, je nach Ausbau des Antriebsvebundes.

zu 3.)
Mir sind nur die Geräte der SCALANCE Reihe bekannt. Für taktsynchrones Profinet muss es ein Gerät mit dem Ertec Chip sein, für normale RT (nicht Taktsynchron) sollten auch Standard- Komponenten eingesetzt werden können.
PhoenixContact bietet auch Switches für PROFINET IRT an, allerdings habe ich damit noch keine Erfahrungen sammeln können.


zu 4.)
Als Topologie sind eigentlich alle Netzwerktopologien denkbar, also auch Linien.
Das Problem ist die Anzahl der Port am PROFINET Gerät selber.
Die CPU317 PN z.B. besitzt nur einen Port und kann somit keine Linie aufbauen.
Eine ET200s PN HF hat 2 Ports mit einer integrierten Switching Funktionalität, kann also auch als Switch in einer Linie arbeiten.
Eine CBE20 Baugruppe (PROFINET Anbindung für SINAMICS S120) hat gar 4 Ports mit Switching Funktionalität und kann ebenso als Switch eingesetz werden.
Es kommt also auf die verwendeten Geräte an, ob eine Linientopologie möglich ist oder ob man auf zuätzliche Switsches setzt.

Hoffe es hilft ein wenig.

Gruß
Christoph
 
Hab dieses Buch bereits im Haus, ist zwar sehr Siemens-lastig aber verschafft mal einen guten Überblick darüber, worauf man aufpassen muss.

Für mich ergibt sich mal folgendes Bild: Wenn ich eine konstante Reaktionszeit haben will, muss ich Switches mit Ertec-Chip einsetzen. Hab mir mal die Preise davon angesehen und gleich einen Schreck bekommen............. Für mich bleibt nur die Frage, ob es auch Ertec-Switches mit 16 oder 32 Ports gibt.

Für die Anbindung von Visualisierung und dergleichen sollten nach wie vor Standard-Switches ausreichen, da hier "nur" RFC1006 zum Einsatz kommt.


Was mir noch Kopfschmerzen bereitet, ist die Projektierung der CPU-CPU Kommunikation mit iMAP.
Hat hier schon jemand Erfahrung?

Danke!

mfg
Maxl
 
Hi,

hier mal die ersten Schritte von iMAP.
Vielleicht hilft es weiter um sich einen Überblick zu verschaffen.

Gruß
Christoph
 

Anhänge

  • GS_iMap_d.pdf
    1 MB · Aufrufe: 89
Ich möchte eigentlich PUT/GET nicht verwenden, da es eine vergleichsweise langsame Form der Kommunikation ist (zumindest mit CP343 wars so).

Es wird mir wohl nichts anderes übrig bleiben, als das ganze selbst ordentlich auszutesten. Zum Glück haben wir derzeit noch keine Projekte in unmittelbarer Zukunft, wo das ganze schon vorgeschrieben ist.


Danke an alle
mfg
Maxl
 
Erster Erfahrungsbericht mit Profinet-CPUs

So, habe gestern meine ersten Versuche damit gemacht.
2 x CPU317-2PN/DP - die Ethernet-Verbindung ist derzeit über einen Standard-Switch realisiert. Die CPU-Zykluszeit habe ich mit SFC47 künstlich auf 20 ms gedrosselt.

Hab in der Nacht von gestern auf heute mal 3 S7-Verbindungen parallel laufen lassen.


#1 PUT/GET - 212 Byte Nutzdaten (lt. Hilfe ist das maximum - mit mehr hats auch nicht funktioniert) - durchschnittliche Laufzeit (1 x hin und zurück) 300-350 ms (wobei sich durch geschicktere Bausteinreihenfolge noch 50 ms rausholen ließen). Wichtig: kein einziger Auftrag brachte einen Fehler - nur 1 mal dauerte ein Auftrag länger (ca. 1400 ms)

#2 USEND/URECV - 212 Byte Nutzdaten - durchschnittliche Laufzeit (1 x hin und zurück) 200ms - ca. alle 30 sek ging ein Auftrag verloren, was allerdings nicht tragisch ist, da ich nach einer gewissen Zeit ohne Antwort den Auftrag erneut absende

#3 BSEND/BRECV - 20 bzw. 240 Byte Nutzdaten - durchschnittliche Laufzeit 350 ms - alle 2 bis 3 Sekunden geht ein Auftrag verloren, manchmal auch 2 hintereinander --> unbrauchbar!!


Soweit hat das ganze zwar noch nichts mit Profinet zu tun, aber es gibt doch schon mal ein ungefähres Gefühl, dass man ohne CBA erreichen kann.
Extrem wichtig !!!! Nur Profinetswitch nutzen. Ich habe ein Tag vorloren um den Fehler zu finden.
Mich würde interessieren, was hier nicht funktioniert hat? Mit meinem Standard-Switch (Surecom) gabs bislang keine Auffälligkeiten.


Seit heute Nachmittag läuft nun eine CBA-Verbindung, die ich mit iMAP projektiert habe. Erster Eindruck: DP/DP-Koppler sind wesentlich einfacher einzusetzen. iMAP ist ja nicht für CPU-CPU-Kommunikation konzipiert - und das merkt man ganz deutlich!
Ich hab das ganze dann noch eine Stunde laufen lassen bzw. lasse es übers Wochenende laufen. Die Signallaufzeit (240 Byte pro Richtung) ist nicht berauschend. Es ist eher gleich bis langsamer als PUT/GET. Bin gespannt, ob hier ERTEC-Switches was bringen.


Weitere Berichte folgen..............
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi,

wie schon mal gesagt habe.
Solange kein IRT gefahren wird kann auch ein StandardSwitch eingesetzt werden.
Das RT Protokoll ist lediglich ein IP Packet wie jedes andere auch, IRT PAckete dagegeen habe eine spezielle Kennung zur Priorisierung und werden von IRT Switches bevorzugt behandelt, Standardswitches machen dies nicht mit.

Gruß
Christoph
 
So, heute hats die Ernüchterung gegeben:
CBA ist eher langsamer und instabiler als PUT/GET - damit ist das für mich mal gestorben. iMAP ist ja eine Katastrophe! Und Siemens will dafür 1900€ pro Lizenz haben - bringt wohl nix!

Hast Du schon mal PN/PN-Koppler eingesetzt?


mfg
Maxl
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wozu ein PN/PN-Koppler?

Bei GET/PUT-Kopplung braucht ein Signalumlauf 350ms und bei CBA bis zu 450 ms. Bei Profibus DP/DP-Kopplung bin ich Umlaufzeiten zwischen 30 und 50 ms gewohnt.
Vergleichbare Leistungswerte müssen doch mit ProfiNET auch erzielbar sein, sonst wäre es ja ein absoluter Rückschritt. Und dabeio dachte ich an einen PN/PN-Koppler, da dieser ja nicht über eine S7-Verbindung oder CBA arbeitet, sondern mit Profinet RT (IO) - und dieses sollte ja wesentlich schneller sein.

mfg
Maxl
 
Zurück
Oben