# Profinet vs EtherCat



## mkRE (12 Oktober 2015)

Hallo zusammen, ich hoffe ich kann etwas Unterstützung erhalten bei einem Thema was mich momentan reizt.
Und zwar habe ich heute mal diesen Link gesehen bzw. das Video: 

http://w3.siemens.com/mcms/mc-syste...simotion/video/seiten/profinet-schneller.aspx

hier wirbt Siemens das der Profinet schneller geht und Leistungstärker als alles andere ist und werben mit 31,25µs.

Klingt für mich überzeugend aber...

Jetzt zu meinen Frage hat jemand von euch schon Erfahrung mit dem Profinet unter Simotion gemacht?
Haben die von Siemens da bei EtherCat abgeguckt was die "Ein Telegramm" Variante für alle Teilnehmer angeht?
Wie verhält sich die Geschwindigkeit in Abhängigkeit von der Achs und EA Anzahl habt ihr da Erfahrungen?

Im gängigen EA-Bereich also nicht unter Simotion kann der Profinet doch nicht so schnell werden nicht einmal annähernd, habt ihr da Erfahrung mit dem Schnellsten Protokoll?


Was ist eurer Meinung nach besser und Stabiler EtherCat oder der Simotion Profinet? EtherCat wird da wohl etwas langsammer sein als das womit Siemens jetzt wirbt, jedoch würde mich die Stabilität interessieren.
EtherCat ist da eigentlich sehr solide und ich dachte das wäre der beste "Feldbus" auf dem Markt heutzutage.

Würde mich sehr über euren Rat und Erfahrungen freuen. Links wären auch interessant.

Viele Grüße


----------



## ChristophD (13 Oktober 2015)

Hallo,

ja Erfahrungen  mit PROFINET und SIMOTION habe ich , mit EtherCat dagegen keine.
Das mit dem abschauen glaube ich eher nicht, beide Protokolle basieren auf der gleichen IEC Norm 61158 welche das Grundgerüst liefert.
EtherCat ist halt von Beckhoff getrieben und PROFINET von Siemens.
Das mit dem "Ein Telegram" war schon von Beginn an bei PROFINET IO implementiert.
Bei der Geschwindigkeit muss man aufpassen welche Abhängigkeit man nimmt.
Die Achsanzahl ist untergeordnet für den Buszyklus das sind nur einfach Daten nicht mehr und nicht weniger.
Ein Profinet Telegram kann maximal 1440 Byte Nutzdaten transportieren und das dann aufgeteilt auf verschiedene Devices (FU, I/O,...).
Die Achsanzahl hat aber starken Einfluss auf die Applikationszyklen der Simotion, sprich je mehr Achsen genutzt werden desto größer die Rechenzeit, 
es kann also ein schneller Bustakt möglich sein, aber der Applikationszyklus ist langsamer.

Was verstehst du unter "gängigen EA-Bereich"?
Die genannten 31,25 µs urden mit Simotion und ET200SP IO erreicht, also schon gängige IO.
Es gibt auch kein Simotion spezifisches PROFINET, das ist das gleiche wie es auch bei der S7 verwendet wird, nur besteht dort kein großer Bedarf an Schnelligkeit und Taktsynchronität.

Was die Aussage des Videos angeht:
Die 31,25 µs werden nirgendwo erwähnt, lediglich mal eingeblendet.
Auch ob das dann taktsynchron ist wird nicht gesagt.
Das schnellste was ich selber projektiert und am laufen habe war 250µs mit CU320-2  PN am Profinet, weiter runter dürfte es momentan nicht gehen, eventuell macht man da ja mal was mit TIA ?

Gruß
Christoph


----------



## mkRE (13 Oktober 2015)

Hallo Christoph

Danke für deine Antwort.

Mit normalen EA Bereich meinte ich den üblichen für die meisten Anwendungen verwendeten Profinet RT. Simotion benutzt ja Profinet IRT sorry .
Wenn das "Ein Telegram" Prinzip schon von Anfang an bei Profinet war wobei du recht hast sorry, dann verstehe ich nicht wo der Unterschied zu EtherCat sein soll. 
Technisch gesehen funktiniert EtherCat ja folgendermaßen: 

Die EtherCAT-Slave-Geräte entnehmen die für sie bestimmten Daten, während das Telegramm das Gerät durchläuft. Ebenso werden Eingangsdaten im Durchlauf in das Telegramm eingefügt. Die Telegramme werden dabei nur wenige Nanosekunden verzögert usw.

und Anhand der folgenden Daten ist Profiner IRT nicht so Leistungsstark:


EtherCAT verfügt über eine sehr hohe Netzwerk-Performance. Im EtherCAT-Slave erfolgt die gesamte Protokollbearbeitung in Hardware und ist damit unabhängig von der Laufzeit von Protokollstacks, CPU-Performance oder Software-Implementierung. Die Update-Zeit für 1.000 E/As beträgt nur 30 μs – einschließlich I/O-Durchlaufzeit. Mit einem einzigen Ethernet-Frame können bis zu 1.486 Byte Prozessdaten ausgetauscht werden – das entspricht fast 12.000 digitalen Ein- und Ausgängen. Für die Übertragung dieser Datenmenge werden dabei nur 300 μs benötigt. Für die Kommunikation mit 100 Servoachsen werden nur 100 μs benötigt. In dieser Zeit werden alle Achsen mit Sollwerten und Steuerdaten versehen und melden ihre Ist-Position und Status.

Quelle: http://www.feldbusse.de/EtherCAT/ethercat.shtml

Würd mich sehr freuen wenn du mir da ggf. etwas zu sagen kannst bezogen auf IRT auch zu Diagnose Komfort usw. wie ich sehe hast du schon viel Erfahrung gesammelt.


----------



## mkRE (13 Oktober 2015)

ChristophD schrieb:


> Was die Aussage des Videos angeht:
> Die 31,25 µs werden nirgendwo erwähnt, lediglich mal eingeblendet.



Im Video wird die Zykluszeit von 31,25 µs gesprochen und eingeblendet, sowie alles läuft Synchron im gleichen Takt.
Mich hat somit interessiert unter welchen Bedingungen und EA Bereich somit.

Viele Grüße


----------



## Glasesba (13 Oktober 2015)

Hallo,

das bisherige Profinet IRT konnte nur 250µs Zykluszeit, damit wurde sichergestellt dass zwischen den IRT Telegrammen noch normale Ethernet Telegramme übertragen werden können. Somit ist Profinet zu 100% kompatibel zu Standard Ethernet. Das geht bei Ethercat so nicht, normales Ethernet muss dort über spezielle Klemmen getunnelt werden (z.B Beckhoff EL6601). Dafür war Ethercat deutlich schneller. Mit der Profinet Spezifikation 2.3 wurde die minimale Zykluszeit auf 31,25µs gesenkt um mit Ethercat mithalten zu können (Allerdings kenn ich bisher kein Gerät welches das wirklich unterstützt). Dafür werden nun auch die Daten mehrerer Teilnehmer in einem Telegramm zusammengefasst (Dynamic Frame Packaging). Damit weiterhin Standard-Ethernet ohne Zusatzkomponenten funktioniert werden die Standard Telegramme vom ersten Profinet IRT 2.3 Teilnehmer "verpackt" in das Durchlauftelegramm und vom letzten Teilnehmer in einer Profinet IRT Linie wieder "entpackt".


----------



## Glasesba (13 Oktober 2015)

https://www.youtube.com/watch?v=5-5NfEo44Jc


----------



## Thomas_v2.1 (13 Oktober 2015)

Hier gibt es noch einen Vergleich zwischen Profinet und Ethercat mit Erläuterung der Unterschiede, allerdings durch die Ethercat-Brille gesehen:

https://www.ethercat.org/en/downloads/downloads_5AED3409F60546F9B5F0049D361969C4.htm


----------



## mkRE (14 Oktober 2015)

Glasesba schrieb:


> Dafür war Ethercat deutlich schneller. Mit der Profinet Spezifikation 2.3 wurde die minimale Zykluszeit auf 31,25µs gesenkt um mit Ethercat mithalten zu können (Allerdings kenn ich bisher kein Gerät welches das wirklich unterstützt).



Hallo Glasesba,

das ist sehr informativ eingentlich erklärt das alles was du sagtest. 
Aber was meinst du genau mit Geräten die das nicht unterstützen?Die EA Module unterstützen das doch oder nicht?Sonst macht es ja keinen sinn Reklame zu machen. Bei EtherCat - Die Update-Zeit für 1.000 E/As beträgt nur 30 μs – einschließlich I/O-Durchlaufzeit

Außerdem noch eine kleine Frage: kann man ihrgendwie bestimmen welche Auswirkungen die Achsanzahl auf die Zykluszeit haben? z.B. 10 Achsen und 2 EA Module in einem System System als Bsp.?

Viele Grüße


----------



## mkRE (14 Oktober 2015)

Thomas_v2.1 schrieb:


> Hier gibt es noch einen Vergleich zwischen Profinet und Ethercat mit Erläuterung der Unterschiede, allerdings durch die Ethercat-Brille gesehen:
> 
> https://www.ethercat.org/en/downloads/downloads_5AED3409F60546F9B5F0049D361969C4.htm




Thomas auch dir Danke für den Link, sieht interessant aus lese ich mir durch!!
Aber wie du schon sagt durch die EtherCat Brille gesehen. 
Diese Brillen Statistiken der Hersteller versuche ich dann immer noch durch meinungen von Praktikern im Netz zu erweitern. Nichts ist besser als die Erfahrung der Anwender. Daher frage ich liebe noch hier  das ist der beste support!


----------



## zako (15 Oktober 2015)

mkRE schrieb:


> hier wirbt Siemens das der Profinet schneller geht und Leistungstärker als alles andere ist und werben mit 31,25µs.
> 
> Wie verhält sich die Geschwindigkeit in Abhängigkeit von der Achs und EA Anzahl habt ihr da Erfahrungen?
> 
> ...



Ich denke mal, dass Du bzgl. Geschwindigkeit, Stabilität, Jitter keine nennenswerten Einschränkungen in der Praxis haben wirst (hier gibt es für beide Bussysteme entsprechende Referenzen). Aber wo sind denn die Applikationen, wo man 250 / 50 / 31,25µs braucht?
Schnelle IO- Logik kann gleich durch entsprechende Hardware lösen. Messtaster, Nocken durch entsprechende Zeitstempelfunktionalität (da ist man im 1µs Bereich an Genauigkeit).
Ist es da nicht interessanter welche Netzwerk- Topologien umsetzbar sind, geht z.B. WLAN (auch bei Taktsynchronität), Multimaster in einem Netzwerk, können TCP/IP- Daten  schnell mitübertragen werden (und nicht erst getunnelt)  ... (zumindest bei Profinet ist das gegeben).
Es gibt immer Anwender die sich von Sprüchen wie "aus ms werden µs" usw. beeinflussen lassen. Aber auch beim Schwanzvergleich gilt, dass erst das rein- und raus die Meter macht.


----------



## mkRE (15 Oktober 2015)

zako schrieb:


> Es gibt immer Anwender die sich von Sprüchen wie "aus ms werden µs" usw. beeinflussen lassen. Aber auch beim Schwanzvergleich gilt, dass erst das rein- und raus die Meter macht.



Beim Schwanzvergleich gibt es noch wichtigere Parameter "Die Effektivität und die Positioniergenauigkeit" nur mal nebenbei.

Naja ist jetzt nicht so wichtig.

Finde deine Antwort oberhalb dem Schwanzvergleich ok.
Es gibt aber Applikationen die eine exakte Positionierung benötigen und da können 1ms oder 31,25µs schon einen unterschied ausmachen.

Nur wie ist es den nun bzw. wie ändert sich den die Zykluszeit wenn ich entweder 10 oder 100 Achsen laufen habe bei Simotion ob da jemand Erfahrungen hat.

Die andere Frage war wie hat den Siemens nun die 31,25µs hinbekommen die mussten doch einige Geräte aus ihrem Portfolio angeschlossen gehabt haben. EA Module usw. die diese Zeiten verarbeiten können.

Viele Grüße


----------



## zako (16 Oktober 2015)

mkRE schrieb:


> Es gibt aber Applikationen die eine exakte Positionierung benötigen und da können 1ms oder 31,25µs schon einen unterschied ausmachen.



*NEIN !* , siehe folgend:
Ich gehe mal davon aus, dass Du einen SINAMICS S120 als Antrieb unter der SIMOTION hast. Dann haste eh gewonnen, da das Störverhalten im Lageregler im Stromreglertakt des Antriebs gerechnet wird (derzeit min. 31,25µs). Mir sind keine Applikationen bekannt, wo diese niedrigen Abtastzeiten noch Vorteile bzgl. einer Positioniergenauigkeit bringen.
Hier spielen ganz andere Daten eine Rolle (der Stromregler zieht zwar bereits bei Standardeinstellung auf eine Grenzfrequenz >1000Hz). Aber wenn es um schnelle Maschinen geht, dann muss auch das Moment noch gestellt werden können. Da ist es eben ganz gut, wenn der Umrichter nicht nur den "klassischen" Innenkreis als Ausgangspannung fährt. Ebenso wenn Du eine geregelte Einspeisung nimmst (ALM) kannst Du auch bei einem 400V Netz Ausgangsspannungen von >500V stellen und entsprechend den Strom gegen der EMK und Induktivität in den Motor treiben. Das hat nichts mit einer Zykluszeit zu tun.
Jetzt kommst Du zum Drehzahlregler:  Du hast es immer mit Mechaniken zu tun. D.h. Resonanzfrequenzen (typ. Schwingung zwischen Last und Motor) und Tilgerfrequenzen (Schwingung der Masse selbst (wenn Motor festgebremst wäre). Hier kannst Du dann per Bodediagramm diese Frequenzen identifizieren. Da wirst Du feststellen, dass auch bei Trägheitsärmeren Aufbauten entsprechende Stellen identifizierbar werden. Tilgerfrequenzen stellen da eine  Grenze da (es gibt noch ein paar Kniffs, wie Nullstellenkompensation durch entsprechende Überlagerungsfilter aber das hat auch nichts mit der Abtastzeit zu tun). Das sieht man am besten wenn man mit der Messfunktion mal das Übertragungsverhalten zwischen Motorgeber und externen Geber aufnimmt. Dies ist dann auch gleichzeitig die Grenze für den Lageregelkreis. 
Es gibt theoretische Betrachtungen (die man auch in der Praxis nachweisen kann) inwieweit die Abtastzeit auf die einstellbaren Regelparameter wirkt. Gerade beim Lageregler spielt die Abtastzeit nicht mehr die ganz große Rolle (aber mit einem DSC- Telegramm bist Du dann relativ unabhängig davon).  Ich habe auch schon Druckmaschinen in Betrieb genommen, da sind wir damals mit 1,6ms Lagereglertakt gefahren ohne DSC und die Genauigkeitsanforderungen wurden erreicht.
Ich bin auch schon gefragt worden, wenn man an der Rechenzeitgrenze der Steuerung gestoßen ist, ob man jetzt die nächst größerer nehmen muss (meist haben die Leute dann an den Takten eh nichts geändert und nutzen die Voreinstellung). Wenn man jetzt etwas langsamer rechnet, heisst das noch lange nicht, dass die Maschine nicht mehr so genau positioniert. Gut ein Vertriebsmann wird Dir gerne die nächst größere Steuerung verkaufen,  bzw. sagen, häng doch noch eine weitere daneben, ist ja bei PROFINET nicht das Thema wegen die Multimasterfähigkeit. Aber wenn Du Dir das von irgendwelchen Verkäufern erzählen lässt, dass Du unbedingt überall das schnellste brauchst ...

Grüße
  Zako


----------



## Glasesba (17 Oktober 2015)

mkRE schrieb:


> Hallo Glasesba,
> 
> das ist sehr informativ eingentlich erklärt das alles was du sagtest.
> Aber was meinst du genau mit Geräten die das nicht unterstützen?Die EA Module unterstützen das doch oder nicht?Sonst macht es ja keinen sinn Reklame zu machen. Bei EtherCat - Die Update-Zeit für 1.000 E/As beträgt nur 30 μs – einschließlich I/O-Durchlaufzeit
> ...



Das bedeutet das Profinet 2.3 theoretisch 31,25µs kann, ich aber keine Geräte kenne die das wirklich unterstützen. Z.b. kann die neue S7-1500 auch "nur" 250µs, genauso kann die Simotion/Sinamics aktuell "nur" 250µs. Genauso die ET200SP, auch "nur" 250µs.


----------



## mkRE (18 Oktober 2015)

Hallo zusammen, vielen Dank für die ausführlichen Informationen!
Im großen und ganzen gäbe es vom heutigen Stand gesehen somit keinen Unterschied mehr zwischen EtherCat und Profinet bezogen auf die möglichen Zykluszeiten. 
Das hat mich sehr überzeugt.

Vielen Dank.


----------



## mkRE (18 Oktober 2015)

zako schrieb:


> *NEIN !* , siehe folgend:
> Ich gehe mal davon aus, dass Du einen SINAMICS S120 als Antrieb unter der SIMOTION hast.



Benutzt wird sehr warscheinlich ein Sinamics S120 wie du vermutet hast und eine SIMOTION D435-2 Steuerung. Insgesamt 9 Achsen sowie einige EA Module.

Sollte eigentlich so in Ordnung sein 

Viele Grüße


----------



## SUW (16 November 2015)

Es gibt durchaus Geräte die schon die 125µs haben, S120 und Simotion
Und wer das benötigt, sind vor allem diejenigen, die ihre Reglerstrecke auftrennen, sprich den Drehzahlregler in einem überlagerten System rechnen wie z.B. der Simotion aber keine Technologiefunktionen verwenden (eigene Drehzahlregler)
Dann brauch ich eine schnelle, taktsynchrone Kommunikation zwischen meinem Stromregler und meinem Drehzahlregler


----------



## mkRE (16 November 2015)

Hallo SUW, danke das ist auch ein guter Tipp.Simotion ist in dem Fall ein überlagertes System hab ich richtig verstanden?!

Gesendet von meinem D5803 mit Tapatalk


----------



## zako (19 November 2015)

SUW schrieb:


> Es gibt durchaus Geräte die schon die 125µs haben, S120 und Simotion
> Und wer das benötigt, sind vor allem diejenigen, die ihre Reglerstrecke auftrennen, sprich den Drehzahlregler in einem überlagerten System rechnen wie z.B. der Simotion aber keine Technologiefunktionen verwenden (eigene Drehzahlregler)
> Dann brauch ich eine schnelle, taktsynchrone Kommunikation zwischen meinem Stromregler und meinem Drehzahlregler



Im Gegensatz zu Positionierachsen (Ausführungen hierzu siehe Beitrag #12) spielt bei drehmomentgeregelten Achsen die Zykluszeit eine bedeutendere Rolle. 
Ein Beispiel das mir hier einfällt, ist eine Produktionsmaschine die mit einer Steuerung ausgestattet war, die als Kommunikationsbus Ethercat eingesetzt hat (4ms). Laut Aussage des Maschinenbauers hängt der Interpolationstakt in dieser Steuerung fest vom Buszyklus ab . Die Achsen werden lagegeregelt verfahren. 
Nun wurde zur Vermeidung von Leistungsspitzen ein Schwungradmotor eingesetzt.   Aber bei Laststößen von z.B. 300kW ist so ein Zwischenkreis schon mal in ein paar wenigen Millisekunden leergesaugt. Also ist hier eine schnellere Zykluszeit sinnvoll, v.a. da ein dynamischer SERVO- Antrieb die Leistung in <1ms aufbaut und den Antriebszwischenkreis puffern kann.
Mit der vergleichbaren SIEMENS- Steuerung (aus Sicht der Rechenleistung) mit PROFINET IRT kann nun die gleiche Zykluszeit für die Positionierachse verwendet werden, aber zusätzlich eine SERVO FAST- Task, wo z.B. in 250µs der Schwungradspeicher geregelt werden kann.
Ist jemanden bekannt, ob das mit Beckhoff / Ethercat  auch möglich ist?


----------



## MasterOhh (19 November 2015)

Ich weiß nicht wie die 4ms mit EtherCAT zusammenhängen sollen. Das kann doch nur eine Zykluszeitbegrenzung seitens der verwendeten Steuerung gewesen sein. Rein vom Bus her könntest du bei EtherCAT locker weit unter 100µs kommen.
Du brauchst natürlich eine potente Steuerung die solche Zykluszeiten auch bedienen kann. Bei einem Beckhoff IPC oder einer CX20xx kannst du schon stink normale SPS-Tasks im Sub-ms Zyklusbereich haben und wenn die Achsen über einen NC-Kern laufen sind 250µs oder weniger locker drin. Bei den Multi-Core Steuerungen von Beckhoff kannst du die NC dann noch auf einen eigenen CPU Kern auslagern der durch nichts anderes belastet wird.


----------



## zako (19 November 2015)

Der Maschinenbauer hat eine passende Steuerung gewählt, die seine Anforderungen erfüllte (er hätte noch mehr Geld ausgeben und eine schnellere Steuerung wählen können). Nachdem auch einiges an Anwenderprogramm drinn ist und entsprechende Anzahl von Achsen hat er eine Sollwertinterpolationszeit von 4ms gewählt, was auch ausreichte.
Nun ging es darum die Anwendung um eigene schnellere Regelungsstruktur zu ergänzen.


----------



## MasterOhh (19 November 2015)

Wenn die 4ms bewusst gewählt wurden, dann verstehe ich das Problem nicht.


----------



## zako (20 November 2015)

MasterOhh schrieb:


> Wenn die 4ms bewusst gewählt wurden, dann verstehe ich das Problem nicht.



Wenn man z.B. eine höhere Anzahl von Achsen (+ Anwenderprogramm)  hat und nicht gleich in einer höher performanten Steuerung investieren will, dann macht es eben Sinn, dass man unterschiedliche Interpolationstasks für die Achsen einstellen kann.  Dann kann man z.B. die Positionierachsen rechenzeitoptimal rechnen und z.B. Achsen wie Schwungradspeicher in einer schnelleren Task.
Das geht mit der entsprechenden SIEMENS Steuerung mit PROFINET IRT.


----------



## blue0cean (29 November 2015)

Was ist eigentlich die Aufgabe die Erledigt werden soll?
Ist ein Steuerungstyp/Hersteller gesetzt?
Die schnellste Achsregelung die ich in den Fittichen hatte lief mit 125µs mit Ethercat und NC auf der Steuerung. Aber mal erhlich entscheidend sind die Randbedingungen...
Noch ne Frage an die Mitwirkenden
Welchen Bus setzt ihr standardmäßig ein?
Welche Steuerungsplatform?
Die minimalste Zykluszeit die ihr Inbetreibgenommen habt und läuft(mal weg von der Theorie)?


----------



## MasterOhh (1 Dezember 2015)

Auf der IPC & Drives hat auf dem Stand der EtherCAT Technology Group ein mittelklasse IPC 30(?) Achsen mit einer Zykluszeit von 12,5µs geregelt.


----------



## RobiHerb (1 Dezember 2015)

*Ethercat*

Wenn ich die Wahl hätte, würde ich Ethercat nehmen.

Protokollabwicklung in einem Chip auf der Hardware gelöst.

Protokoll elegant konstruiert und nicht gefrickelt wie bei Profinet.

Seit Jahren ausgereift und nicht alle paar Monate eine neue Version (analog TIA Updates).

Durch "Distrubuted Clock" absolut feste Synchronisation.

Offene Dokumentation, was wie und wo abgeht ...

(Ich gebe zu, dass ich auch aus beruflichen Gründen eher zu Ethercat neige, wer mehr Infos braucht, kann mir eine PN senden)


----------



## zako (1 Dezember 2015)

MasterOhh schrieb:


> Auf der IPC & Drives hat auf dem Stand der EtherCAT Technology Group ein mittelklasse IPC 30(?) Achsen mit einer Zykluszeit von 12,5µs geregelt.


12.5 µs laufen bei Ethercat nicht taktsynchron. Weiterhin sind arbeiten die unterlagerten Antriebsregelkreise mit anderen Takten. Derartige Jitter kann  man sich bei anspruchsvolleren Anlagen nicht leisten.



RobiHerb schrieb:


> Protokoll elegant konstruiert und nicht gefrickelt wie bei Profinet.
> Seit Jahren ausgereift und nicht alle paar Monate eine neue Version (analog TIA Updates).



Ich weiss ja nicht wie Du zu solchen Ansichten kommst, aber als Profinet Anwender sehe ich das nicht. Alle paar Monate eine neue Profinet Version ... - wo denn ? 
 "gefrickelt"?? Also für mich gestaltet sich die IBN und Toolunterstützung ähnlich komfortabel wie schon bei Profibus.  Ebenso bei den Diagnosemöglichkeiten wird man entsprechend toolunterstützt.

Ich sehe die Stärken von Profinet z.B.
a) Multimasterfähigkeit (z.B. bei Druckmaschinen wichtig)
b) sehr flexible Topologien, insbesondere wenn man z.B. ein Druckwerk während der Produktion herausnehmen muss, ohne dass man Busunterbrechnungen hat bzw. in Zusatzhardware investieren muss
c) Profinet IRT auch bei WLAN 
d) Bandbreitenreservierung für TCP/IP. Da ist das EoE von Ethercat zig- fach langsamer
e) mit der entsprechenden Hardware unterschiedliche Interpolationstask´s, Taktuntersetzung, etc.
f) Funktionalitäten wie Diagnosekanal, Profienergy, ...
g) Möglichkeiten / Flexibiltät im Bereich SAFETY
...


----------



## blue0cean (2 Dezember 2015)

Ich stelle nochmal die Frage auch an zako was ist die schnellste Zykluszeit die ihr wirklich einsetzt und die dann auch an einer eurer Maschinen läuft? Theoretische Werte nutzen keinen was.

Hier noch die passenden Auszüge von Wiki:
https://de.wikipedia.org/wiki/Profinet  (hier sind schon 2 Versionen beschrieben)



https://de.wikipedia.org/wiki/EtherCAT

ich selber habe beide Technologien im Einsatz (Praktisch!) Ethercat mit 125ys bei PN 1ms das lag aber an der Anwendungsfällen. Das Entscheidende ist meiner Meinung nach immer die aus der Anwendung entstehende Aufgabe.


----------



## zako (4 Dezember 2015)

@blueOcean ... kannst Du mal beschreiben, warum Du die 125µs gebrauchst hast? Hast Du evtl. einen Antrieb gehabt, wo der Lageregelkreis nur über die Steuerung geschlossen wurde?


----------



## blue0cean (4 Dezember 2015)

richtig erkannt.


----------



## blue0cean (4 Dezember 2015)

ist zwar für den einen oder anderen eine "Spielerei":
https://www.youtube.com/watch?v=cmETioVtRG0

hier der Integrator:
http://www.mkt-ag.de/de/exponat/changi-airport-kinetic-rain-2012

hier  laufen jeweils 200 Achsen über einen Ethercat-Strang  an einem von 5  Taksyncronen PC's koordieniert von einem Master PC mit einer Taktzeit  von 1ms. Das ist Real und keine Theorie hier war ich bei der Grund IBN  dabei.


----------



## zako (4 Dezember 2015)

Im TIAP hatte ich mal 198 Achsen angelegt mit 1ms PROFINET IRT Takt. Die Auslastung für den IRT- Anteil lag bei ca. 480µs (meines Wissens sogar ohne Dynamic Frame Packing). Und Du hast immer noch 50% Bandbreite für TCP/IP Daten (und das ist dann wieder ein wesentlicher Vorteil von Profinet).

Ich  selbst kenne keine Anlage, wo man Einschränkungen aufgrund der Zykluszeit hatte. Da sind die in Beitrag #26 Eigenschaften schon entscheidender.
Positiv wirkt sich bei Verwendung eines SINAMICS S120 aus, dass dieser eine Multiachsarchitektur hat. Das bedeutet z.B., dass man bei 6 Servoachsen nur ein Device angesprochen werden muss.


----------



## mkRE (4 Januar 2016)

Hallo zusammen,

das Thema hat sich nach meinem letzten Besuch sehr entwickelt und freue mich über die ganzen interessanten Themen.

Hat jemand von euch erfahrung in der Regelung von Hydraulischen Achsen mit Simotion?

Grund dafür ist das eine Applikation mit 9 oder mehr Hydraulischen Achsen eine gewisse Arbeit durchführen soll.
Wenn  ich jetzt davon ausgehe das diese neun Achsen über Profinet IRT mittels  einer Überlagerten Steuerung eine Simotion geregelt werden, das ich  dann dort ggf. durch kürzere Taktzeiten meine Positionsgenauigkeit
nicht erreiche. Wie kann ich das vorab Prüfen?

Würde mich sehr über eine Antwort freuen.

Viele Grüße


----------



## mkRE (9 Februar 2016)

Hat jemand zu den oberen Fragen eine Antwort?

Viele Grüße


----------



## zako (12 Februar 2016)

... nachdem sich hier kein Erfahrungsträger gemeldet hat, kann ich Dir auch nur von zwei Gesprächen mit Anwendern berichten. Der eine nimmt immer 1ms ´Zykluszeit, der andere hatte mit 250µs begonnen, ist dann aber aufgrund damaliger Einschränkungen eines anderen Busteilnehmer auf 500µs gegangen, ohne Genauigkeitsverlust (und ist seitdem auch nicht mehr zurück auf 250µs). 
Evtl. kannst Du ja mal auf die Euroblech. Dort sind einige Maschinenbauer unterwegs, die z.B. für´s Tiefziehen hydraulische Achsen mit SIMOTION regeln. 
Wenn Du Aussagen konkret auf Deinen Anwendungsfall brauchst, gibt es bei SIEMENS die Dienstleistung des  "Mechatronic Support". Die werden dann auch konkrete Daten von Deiner Regelstrecke abfragen und mittels Simulationen genauere Angaben machen können (aber das ist dann auch aufwändiger - mittels Finiten Elementen Methode usw. ..).


----------



## mkRE (13 Februar 2016)

Hallo zako danke für die interessanten stellungnahmen.

Es gibt ja diese Siemens Variante SymoHyd für Hydraulische Achsen habe ich gelesen.Dort sind wiederum zwei Varianten die man nutzen kann.

Variante 1 ist mit Drive Click erweiterungskarten wo man Servoventile mit Klassischer Sollwert Istwert abfrage Regeln kann +-10V usw..

Die andere Variante zwei ist mit Servo Ventil Karten, die Ihren eigenen Regelkreis bilden und nur über Profinet mit der Simotion kommunizieren.

Ich kann nicht unterscheiden welche variante da besser wäre abgesehen von mehraufwand usw.
Mich interessiert die Performance.

Viele Grüße

Gesendet von meinem D5803 mit Tapatalk


----------

