# Zugriff auf SEW CCU mit Motion Studio via SPS



## ThomasM (6 September 2017)

Hi Leute,

hab mal ne Frage und warte leider schon ne Weile auf ne Antwort von SEW.

Ist es möglich mit Motion Studio über eine SPS (1515F-2 PN) auf die CCU im Profinet zuzugreifen?

Hintergrund ist folgender:
Ich hab ne 1515F-2 PN welche mit der Schnittstelle 1X2 im Firmennetz des Kunden hängt. Auf diese Schnittstelle habe ich auch den Fernzugriff.
An der Schnittstelle 1X1 hängen alle ProfiNet Teilnehmer unter anderem auch die CCU.

Jetzt wäre es halt schön, wenn ich per Fernzugriff mich mit Motion Studio von 1X2 quasi zu 1X1 durch routen könnte, da 1X2 und 1X1 in unterschiedlichen Netzen hängen (10.xxx.xxx.xxx und 192.xxx.xxx.xxx) 

Ist das überhaupt möglich?

Hoffe es wurde verständlich was ich mir vorstelle 

Gruß ThomasM


----------



## zako (12 September 2017)

ThomasM schrieb:


> Hi Leute,
> 
> hab mal ne Frage und warte leider schon ne Weile auf ne Antwort von SEW.
> 
> ...



... bin mir ziemlich sicher dass das nur mit  SIEMENS- Antrieben geht. 
Früher musste man hierfür auch extra Drive ES Basic installieren (welches dann auf die S7- Dienste aufsetzt). Der STARTER (bzw. STARTDRIVE) bringt das mittlerweile von Haus aus mit - ist ja auch ein entsprechender Vorteil.


----------



## maxder2te (13 September 2017)

ThomasM schrieb:


> Hi Leute,
> 
> hab mal ne Frage und warte leider schon ne Weile auf ne Antwort von SEW.
> 
> ...



Grundsätzlich unterstützt SEW MotionStudio ja TCI, d.h. wenn Umrichter am Profinet oder am Profibus hängen, dann klappt der Zugriff durch die S7-Steuerung hindurch. Außerdem gibts von SEW noch Bausteine, mit denen man einen SMLP-Server auf einer S7-CPU realisieren kann (die gibts allerdings nur für S7-300 nur nur für Ethernet-CPs - das Adaptieren für integrierte PN-Schnittstellen oder S7-1500 muss man selber machen).

Bei beiden Lösungen besteht allerdings das Problem, dass bei den aktuellen SEW-Controllern die Profinet-Schnittstellen sich nicht oder nur bedingt als Engineering-Schnittstellen eignen. D.h. du kommst zwar durch die Steuerung durch, allerdings auf die falsche Schnittstelle.

Ob das mit TCI klappt kannst du einfach austesten (Netzansicht öffnen -> CCU markieren -> Device Tool starten -> Movitools MotionStudio).

Es gäbe auch noch 2 Alternativen:
1. Du die Engineering-Schnittstelle des SEW-Controllers ebenfalls aufs Firmennetz hängen und dir den Fernzugriff dazu geben lassen.
2. Die kannst z.B. zwischen Firmennetz und Maschinennetz (ich vermeide den Ausdruck Profinet) eine simple NAT-Bridge setzen (z.B. http://www.helmholz.at/prod.d,18_35_255.html?p_id=250 ) und dir die Engineering-Schnittstelle des Controllers und den betreffenden Port heraus mappen.
Beides ist mit einem gewissen Sicherheitsrisiko verbunden - so wie immer wenn man Maschinen an Firmennetze hängt.

lg


----------



## ThomasM (13 September 2017)

Hi erstmal danke für eure Antworten.



> Grundsätzlich unterstützt SEW MotionStudio ja TCI, d.h. wenn Umrichter  am Profinet oder am Profibus hängen, dann klappt der Zugriff durch die  S7-Steuerung hindurch.



Das hat mir SEW auch gesagt und sollte auch funktionieren. Bis jetzt gehts noch nicht aber mal schauen was die Kuden-IT dazu sagt.



> Es gäbe auch noch 2 Alternativen:
> 1. Du die Engineering-Schnittstelle des SEW-Controllers ebenfalls aufs  Firmennetz hängen und dir den Fernzugriff dazu geben lassen.
> 2. Die kannst z.B. zwischen Firmennetz und Maschinennetz (ich vermeide  den Ausdruck Profinet) eine simple NAT-Bridge setzen (z.B. http://www.helmholz.at/prod.d,18_35_255.html?p_id=250 ) und dir die Engineering-Schnittstelle des Controllers und den betreffenden Port heraus mappen.



Zu 1.
Geht leider baulich bedingt nicht, deswegen hängt die Engineering Schnittstelle mit im Maschinennetz.
zu 2.
Nicht möglich da nicht erlaubt 



> aktuellen SEW-Controllern die Profinet-Schnittstellen sich nicht oder  nur bedingt als Engineering-Schnittstellen eignen. D.h. du kommst zwar  durch die Steuerung durch, allerdings auf die falsche Schnittstelle.



Das mit der Profinet Schnittstelle ist gar kein Problem. Der einzige Unterschied zur Engineering Schnittstelle ist die Verbindungsgeschwindigkeit, da über die Feldbusschnittstellen zuerst alle Prozessdaten gehandelt werden und wenn dann noch Zeit ist die MotionStudio Daten. Also wenn man beim Laden der CCU-Kofiguration kein Problem hat 10 Minuten länger zu warten als über die Engineering Schnittstelle ändert sich nichts.

Gruß
Thomas


----------



## maxder2te (13 September 2017)

ThomasM schrieb:


> Das mit der Profinet Schnittstelle ist gar kein Problem. Der einzige Unterschied zur Engineering Schnittstelle ist die Verbindungsgeschwindigkeit, da über die Feldbusschnittstellen zuerst alle Prozessdaten gehandelt werden und wenn dann noch Zeit ist die MotionStudio Daten. Also wenn man beim Laden der CCU-Kofiguration kein Problem hat 10 Minuten länger zu warten als über die Engineering Schnittstelle ändert sich nichts.


Mhm, dann gilt diese Einschränkung nur für die CCU Power (also die PC-Variante). Irgendwo hatte ich mal was dazu gelesen.
Da die CCU-Anwendungen bei uns bis dato an einer Hand abzählbar sind, ist meine Erfahrung damit noch überschaubar.

Generell ist die Geschwindigkeit bei den Profinet-IO-Interfaces von SEW nicht so berauschend, das liegt laut interne Auskunft vor allem an der Firmware. Mit der Serie Movi-C soll das aber wesentlich besser werden, ich hoffe ich hab heuer noch Zeit für den ersten Laboraufbau (vlg. Kundenprojekt).

lg


----------



## ThomasM (13 September 2017)

Die CCU Power kenn ich nicht. Wir verwenden eigentlich nur die DHR41B und laut SEW Auskunft ist wie gesagt nur ein Geschwindigkeitsunterschied, da Prozessdaten auf der Schnittstelle vorrang haben. Gibt es über die Movi-C Serie was zu lesen? Hab von der bis jetzt noch nichts gehört, würde mich aber auf jedenfall interessieren.

Gruß
ThomasM


----------



## rostiger Nagel (13 September 2017)

maxder2te schrieb:


> Mhm, dann gilt diese Einschränkung nur für die CCU Power (also die PC-Variante). Irgendwo hatte ich mal was dazu gelesen.
> Da die CCU-Anwendungen bei uns bis dato an einer Hand abzählbar sind, ist meine Erfahrung damit noch überschaubar.
> 
> Generell ist die Geschwindigkeit bei den Profinet-IO-Interfaces von SEW nicht so berauschend, das liegt laut interne Auskunft vor allem an der Firmware. Mit der Serie Movi-C soll das aber wesentlich besser werden, ich hoffe ich hab heuer noch Zeit für den ersten Laboraufbau (vlg. Kundenprojekt).
> ...



Ja die Kommunikation ist wirklich ein _großes_ Problem. 
Da SEW da eher auf CAN oder Ethercat setzt, Profinet ist bei
SEW nicht so das Maß der Dinge.
Was ich so von SEW gehört habe werden die auch bei Movi C
Profinet hinten dran stellen.


----------



## zako (13 September 2017)

rostiger Nagel schrieb:


> Ja die Kommunikation ist wirklich ein _großes_ Problem.
> Da SEW da eher auf CAN oder Ethercat setzt, Profinet ist bei
> SEW nicht so das Maß der Dinge.
> Was ich so von SEW gehört habe werden die auch bei Movi C
> Profinet hinten dran stellen.



Also wenn ich mir da die Werbebroschüren zu MOVI-C anschaue, dann sehe ich da erstmal nichts von Ethercat oder CAN zur Feldbusanbindung:




Bei der Variante mit dem Motion Controller sieht man da etwas von Ethercat (eher als Antriebsbus eingesetzt). Für SAFETY hat man einen zweiten Bus gewonnen (Profisafe):


----------



## rostiger Nagel (13 September 2017)

Hier im Thema geht es ja um Moviaxis, da ist der
Hausbaus CAN und einen schnellen Zugriff bekommt
man über Ethercat. Profinet kann kein IRT. 
Auf meiner Anfrage an SEW ob das bei Movi C anders
wird wurde mir das mit eine Klaren NEIN erwidert,
es gibt Anbindung über Profinet aber nicht mehr. 
Da ja jetzt Movi C auf den Markt ist, wird mit Sicherheit 
kein IRT bei Moviaxis kommen.


----------



## zako (14 September 2017)

rostiger Nagel schrieb:


> Hier im Thema geht es ja um Moviaxis, da ist der
> Hausbaus CAN und einen schnellen Zugriff bekommt
> man über Ethercat. Profinet kann kein IRT.
> Auf meiner Anfrage an SEW ob das bei Movi C anders
> ...



Zunächst mal ging es hier darum dass der Themenstarter von seinen Firmennetz auf die Antriebe durchrouten will.
Durch Einsatz eines weitern Systembus wird der Zugriff auf Antriebsparameter sicherlich nicht performanter oder man muss eben dafür eine weitern Bus spendieren.
Wenn nun SEW kein PROFINET IRT unterstützen will (bzw. auch kein Profidrive- Profil) dann ist es zwar verständlich (wenn man selbst ein Motion Control - System entwicklet hat und das am Markt durchsetzen will).
Andererseits werden sich Anwender einer S7-1500 überlegen, wozu sie ein weiteres Motion Control System brauchen, wenn das bereits von Ihrer SIMATIC geleistet werden kann (da geht es ja nicht nur um zusätzlichen Invest, sondern auch um die Einarbeitung in ein anderes Engineering- System etc.).


----------



## rostiger Nagel (14 September 2017)

Ich würde ja gerne Motion Controll mit der 1500 in Verbindung mit
SEW nutzen, nur leider geht das nicht. Das ärgerliche ist das Sie
das sehr wohl mit Beckhoff unterstützen.


----------



## ThomasM (15 September 2017)

Also das mit dem durchrouten probier ich in 2 Wochen direkt  vor Ort aus. Dann steck ich mich mitm PG auf die Firmennetz Schnittstelle der SPS und versuchs mit TCI, wenns dann geht liegts am Fernzugriff Kunden. Wenn nicht dann siehts wohl so aus, dass man nicht von 1X2 mit TCI auf das Anlagennetz 1X1 durchkommt. Oder aber ich bin dann halt einfach zu blöd dafür 

Gruß
ThomasM


----------



## maxder2te (21 September 2017)

zako schrieb:


> Also wenn ich mir da die Werbebroschüren zu MOVI-C anschaue, dann sehe ich da erstmal nichts von Ethercat oder CAN zur Feldbusanbindung:
> Bei der Variante mit dem Motion Controller sieht man da etwas von Ethercat (eher als Antriebsbus eingesetzt). Für SAFETY hat man einen zweiten Bus gewonnen (Profisafe):



Deshalb nennt man es auch Werbebroschüre. Das hat mit handfesten technisches Details oft wenig zu tun.
Grundsätzlich muss man wohl Äpfel mit Äpfel und Birnen mit Birnen vergleichen. Da der Vergleich Siemens Motion Control und SEW Motion Control gefallen ist, folgende Analogie:
- Siemens CU320 vs. SEW Movi-PLC (egal ob CCU oder offen)
- DriveCliq vs. EtherCat
- Sinamics Achsmodul vs. Movidrive modular

Die Unterschiede liegen eigentlich im Detail:
1. wenn man Siemens mittels T-CPU oder T-Teil der Standard-CPU Motion Control durchführen will, benötigt man taktsynchrones Profinet (IRT) mit der entsprechenden kostspieligen Infrastruktur - faktisch wird man ein eigenes IRT-Netzwerk betreiben, getrennt vom herkömmlichen RT-Profinet. Löst man gleiches mit SEW, hat man halt eine SEW CCU am Profinet-RT und unterlagert ein Ethercat.
2. Die Geberanbindung erfolgt bei Siemens generell per DriveCliq - bei SEW direkt am Achsmodul - wo die Vor- und Nachteile liegen darf sich jeder selber aussuchen.
3. Sinamics S120 sind reine Stromregelmodule, der Rest läuft auf der CU320. Betreibt man den S120 an einer Simotion oder T-CPU, bleibt ihr nur noch der Drehzahlregler. Bei SEW laufen die Regler jeweils auf den Achsmodulen, lediglich die Bahnberechnung und Vorgabe erfolgt zentral. Dementsprechend können mehr Achsen auf einem Controller gerechnet werden.

Bzgl. IRT:
An en bestehenden Profinet-Komponenten wird meines Wissens nach nichts mehr entwickelt - nur was notwendig ist. Die Movi-C Profinet-Karten sollen IRT-tauglich sein. Ob sich das "IRT-tauglich" lediglich darauf bezieht, dass der Controller als Teilnehmer in einer IRT-Kette hängen darf (so wie aktuell Murrelektronik-Module), oder ob tatsächlich dann Tasks synchron zum IRT-Takt laufen, ist mir nicht bekannt.

Und man darf eines nicht vergessen:
SEW muss sich nun mal für alle Hersteller öffnen. Die Siemens-Herangehensweise, jedem einfach Profinet aufzuzwingen, kann sich nicht jeder leisten. Deshalb sieht auch die neue Safety-Lösung etwas anders aus als bei Siemens. Profisafe ist aktuell Teil des ersten Wurfes. Für uns als Maschinenhersteller, der das SEW-Zeug auch mal an Rockwell-Steuerungen betreibt, ist die Offenheit das schon eine feine Sache.

lg


----------



## zako (21 September 2017)

maxder2te schrieb:


> Deshalb nennt man es auch Werbebroschüre. Das hat mit handfesten technisches Details oft wenig zu tun.
> Grundsätzlich muss man wohl Äpfel mit Äpfel und Birnen mit Birnen vergleichen. Da der Vergleich Siemens Motion Control und SEW Motion Control gefallen ist, folgende Analogie:
> - Siemens CU320 vs. SEW Movi-PLC (egal ob CCU oder offen)
> - DriveCliq vs. EtherCat
> ...


Das ist ja gerade die Stärke von Profinet. Da machst Motion Control (IRT), SAFTETY, Standardkommunikation, IBN etc. über einen Bus und kannst noch über eine Kamera Deinen Prozess beobachten. Die Profinetteilnehmer die ohne IRT arbeiten hängst Du ins gleiche Netzwerk.



maxder2te schrieb:


> 2. Die Geberanbindung erfolgt bei Siemens generell per DriveCliq - bei SEW direkt am Achsmodul - wo die Vor- und Nachteile liegen darf sich jeder selber aussuchen.


Der Geber wird typischerweise auch am Achsmodul beim SINAMICS angeschlossen. Mit DriveCliQ hat man aber z.B. den Vorteil dass man dezentral einen Hub setzt und mehrere Geber anschließt. Dann braucht man nur noch eine Leitung in den Schaltschrank führen. Bei mechanisch gekoppelten Achsen kann man z.B. aufgrund der Multiachsarchitektur mit softwaremäßigen Gebersplitting arbeiten (d.h. man braucht nur einen Geber was z.B. bei Direktantrieben wo mehrere Primärteile an unterschiedlichen Achsmodulen angeschlossen sind ein deutlicher Vorteil ist).


maxder2te schrieb:


> 3. Sinamics S120 sind reine Stromregelmodule, der Rest läuft auf der CU320. Betreibt man den S120 an einer Simotion oder T-CPU, bleibt ihr nur noch der Drehzahlregler. Bei SEW laufen die Regler jeweils auf den Achsmodulen, lediglich die Bahnberechnung und Vorgabe erfolgt zentral. Dementsprechend können mehr Achsen auf einem Controller gerechnet werden.


Siemens arbeitet hier typischerweise mit DSC. Die Sollwertinterpolation erfolgt auch hier in der Steuerung. Profinet ist zusätzlich noch multimasterfähig, was zu noch mehr Rechenpower führt. 
Vorteil der Multiachsstruktur des SINAMICS ist z.B. bei gekoppelten Achsen, dass man z.B. Sollwerte achsübergreifend ohne Verzögerung durch einen Kommunikationsbus koppeln kann. Da kann man z.B. auch gleichzeitig PRBS Signale an mehreren Achsen vorgeben (z.B. für mechatronische Analysen gekoppelter Achsen (Bodediagramme)) oder achsübergreifende Traces im Stromreglertakt.


maxder2te schrieb:


> Bzgl. IRT:
> An en bestehenden Profinet-Komponenten wird meines Wissens nach nichts mehr entwickelt - nur was notwendig ist. Die Movi-C Profinet-Karten sollen IRT-tauglich sein. Ob sich das "IRT-tauglich" lediglich darauf bezieht, dass der Controller als Teilnehmer in einer IRT-Kette hängen darf (so wie aktuell Murrelektronik-Module), oder ob tatsächlich dann Tasks synchron zum IRT-Takt laufen, ist mir nicht bekannt.


Laut Info von Rostiger Nagel plant SEW kein IRT.
Bzgl. Profinet hat SIEMENS in letzter Zeit schon einige Neuerungen gebracht. Z.B. bzgl. Redundanz; Oversampling.  Da geht es nicht nur um Motion Control sondern z.B. auch um Prozessleitsysteme (PCS7).



maxder2te schrieb:


> Und man darf eines nicht vergessen:
> SEW muss sich nun mal für alle Hersteller öffnen. Die Siemens-Herangehensweise, jedem einfach Profinet aufzuzwingen, kann sich nicht jeder leisten. Deshalb sieht auch die neue Safety-Lösung etwas anders aus als bei Siemens. Profisafe ist aktuell Teil des ersten Wurfes. Für uns als Maschinenhersteller, der das SEW-Zeug auch mal an Rockwell-Steuerungen betreibt, ist die Offenheit das schon eine feine Sache.


Den SINAMICS kannste auch in ein Ethernet IP Netzwerk integrieren.


----------



## maxder2te (26 September 2017)

zako schrieb:


> Das ist ja gerade die Stärke von Profinet. Da machst Motion Control (IRT), SAFTETY, Standardkommunikation, IBN etc. über einen Bus und kannst noch über eine Kamera Deinen Prozess beobachten. Die Profinetteilnehmer die ohne IRT arbeiten hängst Du ins gleiche Netzwerk.
> 
> 
> Der Geber wird typischerweise auch am Achsmodul beim SINAMICS angeschlossen. Mit DriveCliQ hat man aber z.B. den Vorteil dass man dezentral einen Hub setzt und mehrere Geber anschließt. Dann braucht man nur noch eine Leitung in den Schaltschrank führen. Bei mechanisch gekoppelten Achsen kann man z.B. aufgrund der Multiachsarchitektur mit softwaremäßigen Gebersplitting arbeiten (d.h. man braucht nur einen Geber was z.B. bei Direktantrieben wo mehrere Primärteile an unterschiedlichen Achsmodulen angeschlossen sind ein deutlicher Vorteil ist).
> ...



Hui, es wurde eine Marketingschlacht los getreten ;-)
Die Info von Rostiger Nagel gilt für das MoviAxis-System, nicht für Movi-C.


Ansonsten ist alles, was du schreibst, absolut korrekt. In der Theorie klingen viele dieser Features auch hochinteressant. Im tagtäglichen Sondermaschinenbau, wo man sich nicht unbedingt die Zeit nimmt, aus jeder Komponente das letzte herauszukitzeln, da der Engineering-Aufwand schlicht zu hoch ist und wir nicht unbedingt die personellen Kapazitäten dazu haben.

Die Geschichte mit den DriveCliq-Hubs ist mir bekannt und wurde auch schon bei einer Anlage eingesetzt, an der eine Reihe direkter Wegmesssysteme im Einsatz war. Das ganze wurde streng nach Handbuch ausgeführt, dennoch sind immer wieder sporadisch einzelne Geber ausgefallen. Eingrenzen ließ sich der Fehler nur ganz eingeschränkt, der Siemens Support war recht hilflos dabei. Lösen ließ sich das ganze nur durch verstellen der Timings am DriveCliq (ja, die Sache war knapp ausgelegt, aber innerhalb der Siemens-Vorgaben). Es war das bisher einzige Experiment mit den dezentralen Hubs - die Kosten für die Fehlersuche mit wiederkehrenden Anreisen usw. haben den Einsparungseffekt um ein vielfaches übertroffen - seither gibts wieder klassisches Geberkabel-in-den-Schaltschrank.

Die Geschichte mit IRT und RT mischen - ja, auch das klappt fein. Man muss halt das Geld für die IRT-Switches für die IRT-Strecke in die Hand nehmen. Das ganze ist recht spannend, wenn man sich ansieht, welche Geräte es da gibt, und wie das von so manchem deutschen Premium-Auto- und Motorradbauer gehandhabt wird (keine Linientopologie - jedes Device geht direkt zum zentralen Switch). Unser Glück: die sind bereit, das zu zahlen. Ob diese Philosophie auf Anraten vom großen S zustande gekommen ist, oder ob es bei den ersten Profinet-Anwendungen entsprechend große Probleme gab, kann ich nur vermuten. Für uns hat sich eins klar herauskristallisiert: IRT = nur IRT. Der Rest hängt an einem eigenen Netz.

DSC klingt in der Theorie ebenfalls super. Für uns als Sondermaschinenbauer ist das eine feine Sache, wenn ich einfache Hilfsachsen und komplexere Mehrachsfunktionen mit den gleichen PLCopen-Funktionen programmieren kann. Aber von 1000 Antrieben, die nicht an Sinumeriks hängen, brauchen wir die Mehrachsgeschichten bei ca. 20. Bei den anderen 980 macht es recht wenig Sinn, die Rechenlast für den Lageregler von der CU auf die CPU heraufzuziehen, außer man muss die zusätzlich notwendige Rechenleistung nicht selber zahlen. Es war eine recht spannende Erfahrung, als die erste 1512er-CPU mit 6 Hilfsachsen, die per DSC gesteuert wurden, eine Basiszykluszeit von 80 ms hatte, ohne dass da ein nennenswertes Programm drauf lief .

Hört man heraus, dass ich mit der "Eines für Alles"-Strategie von Siemens bzgl. Profinet nicht recht viel Freude habe? Ist es wirklich notwendig, jeden Sch... über das gleiche Kabel zu fahren?
Was war so schlimm daran, dass die PCS7-Fraktion ewig mit Profibus-PA und H1 gearbeitet hat - S7 mit Profibus-DP? Faktisch hat irgendjemand bei Siemens ganz oben gesagt: "wir wollen alles total integriert mit einem System abdecken". Faktisch ist genau der gleiche Stumpfsinn herausgekommen, wie damals, als die Sinumeriker von oben die Simatic S5 aufgezwungen bekommen haben, mit dem Effekt, dass sich heute zwei Divisionen bei Siemens darum streiten, wer die Profisafe-Lizenzgebühren kassiert.
Ich denke, dass Rockwell (Ethernet/IP, Sercos und DeviceNet), B&R (Powerlink, Standard-Ethernet und X2X) und Beckhoff (EtherCat, Standard-Ethernet und offen für alles andere) mit der 3-System Strategie nicht schlecht fahren. Probleme, dass die automatische Zuweisung der Gerätenamen trotz korrekter Topologie nicht funktioniert, gabs bei Powerlink übrigens noch nie - die Unterscheidung RT und IRT übrigens auch nicht. Von den weiteren tagtäglichen Problemen, die beim Planen und in Betrieb nehmen von Profinet auftreten, will ich erst gar nicht sprechen.....

Sorry, das war jetzt Off-Topic.


----------



## zako (26 September 2017)

maxder2te schrieb:


> In der Theorie klingen viele dieser Features auch hochinteressant. Im tagtäglichen Sondermaschinenbau, wo man sich nicht unbedingt die Zeit
> nimmt, aus jeder Komponente das letzte herauszukitzeln, da der Engineering-Aufwand schlicht zu hoch ist und wir nicht unbedingt die personellen Kapazitäten
> dazu haben.


Ja, allgemeine Regel "Keep it simple" und "setz auf Standards wo es geht und mache es nicht zu kompliziert". Aber es ist auch immer gut zu wissen, wenn man noch ein paar Joker ziehen kann. Z.B. bei schwingungsfähigen Mechaniken die man durch entsprechende SW- Module in Griff bekommt.



maxder2te schrieb:


> Die Geschichte mit IRT und RT mischen - ja, auch das klappt fein. Man muss halt das Geld für die IRT-Switches für die IRT-Strecke in die Hand
> nehmen. Das ganze ist recht spannend, wenn man sich ansieht, welche Geräte es da gibt, und wie das von so manchem deutschen Premium-Auto- und Motorradbauer gehandhabt wird (keine Linientopologie - jedes Device geht direkt zum zentralen Switch). Unser Glück: die sind bereit, das zu zahlen. Ob diese Philosophie auf Anraten vom großen S zustande gekommen ist, oder ob es bei den ersten Profinet-Anwendungen entsprechend große Probleme gab, kann ich nur vermuten. Für uns hat sich eins klar herauskristallisiert: IRT = nur IRT. Der Rest hängt an einem eigenen Netz.


"Premium-Auto- und Motorradbauer" sind halt auch diejenigen, die entsprechende Benchmarks durchführen. Da geht es dann auch um Anlagenverfügbarkeit etc. Wenn die auf ein Bussystem setzen würden, wo der ganze Bus ausfällt, blos weil eine Klemme ein Problem hat, wäre dies für deren Anwendungen nicht akzeptabel.


maxder2te schrieb:


> DSC klingt in der Theorie ebenfalls super. Für uns als Sondermaschinenbauer ist das eine feine Sache, wenn ich einfache Hilfsachsen und komplexere Mehrachsfunktionen mit den gleichen PLCopen-Funktionen programmieren kann. Aber von 1000 Antrieben, die nicht an Sinumeriks hängen, brauchen wir die Mehrachsgeschichten bei ca. 20. Bei den anderen 980 macht es recht wenig Sinn, die Rechenlast für den Lageregler von der CU auf die CPU heraufzuziehen, außer man muss die zusätzlich notwendige Rechenleistung nicht selber zahlen. Es war eine recht spannende Erfahrung, als die erste 1512er-CPU mit 6 Hilfsachsen, die per DSC gesteuert wurden, eine Basiszykluszeit von 80 ms hatte, ohne dass da ein nennenswertes Programm drauf lief .
> Es gibt z.B. auch die Möglichkeit die "Motion Intelligenz im Antrieb" zu nutzen.


Prinzipiell bevorzuge ich mittlerweile die Technologieobjekte in der Steuerung. Ich hatte neulich das Vergnügen mit einer 1517TF. Da geht dann schon die Post ab. Bei den kleineren muss man evtl. eine größere nehmen, oder man kann ggf. auch die Abstastzeit des Servo-OB´s hochsetzen und mit Taktuntersetzung arbeiten. Kommt halt auf die Anwendung an.
Alternative wäre es, die Achsinterpolation direkt im Antrieb zu machen ("GMC Bibliothek").



maxder2te schrieb:


> Hört man heraus, dass ich mit der "Eines für Alles"-Strategie von Siemens bzgl. Profinet nicht recht viel Freude habe? Ist es wirklich notwendig, jeden Sch... über das gleiche Kabel zu fahren?
> Was war so schlimm daran, dass die PCS7-Fraktion ewig mit Profibus-PA und H1 gearbeitet hat - S7 mit Profibus-DP? Faktisch hat irgendjemand bei Siemens ganz oben gesagt: "wir wollen alles total integriert mit einem System abdecken". Faktisch ist genau der gleiche Stumpfsinn herausgekommen, wie damals, als die Sinumeriker von oben die Simatic S5 aufgezwungen bekommen haben, mit dem Effekt, dass sich heute zwei Divisionen bei Siemens darum streiten, wer die Profisafe-Lizenzgebühren kassiert.
> Ich denke, dass Rockwell (Ethernet/IP, Sercos und DeviceNet), B&R (Powerlink, Standard-Ethernet und X2X) und Beckhoff (EtherCat, Standard-Ethernet und offen für alles andere) mit der 3-System Strategie nicht schlecht fahren. Probleme, dass die automatische Zuweisung der Gerätenamen trotz korrekter Topologie nicht funktioniert, gabs bei Powerlink übrigens noch nie - die Unterscheidung RT und IRT übrigens auch nicht. Von den weiteren tagtäglichen Problemen, die beim Planen und in Betrieb nehmen von Profinet auftreten, will ich erst gar nicht sprechen.....


Ich war vor nicht einmal allzu langer Zeit auf einer neuen Anlage wo Antriebe eines bekannten deutschen Hersteller verbaut sind. Da waren auch drei Bussysteme 
eingezogen (getrennt nach Kommunikation zur SPS, Leitwertkopplung über SYNC- Bus, Fernwartung). Gut der Maschinenbauer hatte das auch als Stand der Technik akzeptiert.
Aber wenn ich z.B. auf der Anlage immer wieder zum Umrichter rennen muss, blos weil ich von der Leitwarte nicht auf dessen Parameter zugreifen kann, dann ist das halt bescheiden. Da ist z.B.  ein netzwerkübergreifender Zugriff einfach von Vorteil, womit wir auch wieder beim Themastarter sind.


----------

