Steuerungbasiertes MotionControl versus antriebsintern

[zako]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,
ich habe mal eine prinzipielle Frage an alle Steuerungs-/ Antriebstechniker.
Arbeitet Ihr lieber mit PLC Open Bausteinen, oder verwendet Ihr lieber eine "klassische" SPS und macht das Thema Motion control lieber im Antrieb?
Bei einem typischen Aufbau HMI --> SPS --> Antrieb und z.B. einer Positionier- oder Drehzahlachsenapplikation.

* Vorteile PLC Open-Bausteine (z.B T-CPU):
Einfacher Aufruf (Befehle flankengetriggert)
Größen wie Drehzahl, Drehmoment sind direkt als SI- Einheit verfügbar
Anlegen von Kommunikations-DB`s etc. wird von der T-Config übernommen.

* Vorteile Motion control im Antrieb (z.B. Einfachpositionierer im Sinamics S120)
Standardbausteine unterstützt mich bei der Kommunikation zyklisch/azyklisch (wobei ich bei einer Motioncontrol- Steuerung mich darüber auch keine Gedanken machen muss)
Antriebsgrößen werden als Prozentwerte übertragen und sind auch schnell umgerechnet (z.B. in Drehzahl-/Drehmoment)
Da ich direkt Steuerwort bitgranular anspreche, bin ich ggf. flexibler (?)

Ich will jetzt keinen Glaubenskrieg beginnen, aber wie sind hier Eure Erfahrungen?

Grüße
Zako

 

[rostiger Nagel]

Meiner Meinung immer Aplikationsabhängig, für nur eine einfache Point to Point
Positionierung, finde ich es besser wenn dieses der Regler übernimmt, in diesen
fall wird es dann auch SEW.

Soll es aber ein Bahngesteuerter Achsen Verbund sein finde ich du T-CPU mit S120
absolut spitze. Meiner Auffassung nach kommt man mit diesen Konzept zu einer sauberen
und durschaubaren Lössung. Dieses alles auf einer Plattform hat schon seinen Charme,
was mir dann fehlt ist dann die Visu, die T-Mikroboxen sind ja zur zeit nicht mehr angesagt.

Aber grundsätzlich finde ich die IBN bei den S120 viel zu aufwendig, macht man dieses
nicht regelmäßig, bricht man sich einen ab.

 

[Perfektionist]

Zuviel Werbung?
-> Hier kostenlos registrieren

Aber grundsätzlich finde ich die IBN bei den S120 viel zu aufwendig, macht man dieses
nicht regelmäßig, bricht man sich einen ab.

das ist erschreckend - hab damit nie zu tun gehabt und kommt nun auf mich zu. und sicher nicht regelmäßig.

Ich hab seither immer mit eigenem Code Gleichlauf und Synchronlauf mitsamt fliegender Säge gemacht. Kommt noch aus einer Zeit, als es keine T-CPUs gab und ich das mit Pulsrädern und Drehstromasynchronmotoren mit einer für uns ausreichenden Genauigkeit auf der 945 gemacht habe.

Da nun Technologie bei den 1500ern serienmäßig an Bord ist, werd ich mal darüber nachdenken.

Im Prinzip bin ich Hemuts Meinung, wenn er schreibt, dass es von der Applikation abhängt. Eine Antwort schwarz-weiß ist hier bestimmt nur für die konkrete Aufgabenstellung möglich und oftmals wird es dann auch heißen, beides geht, mach das, was dir einfacher erscheint.

 

[zako]

... wenn man mit einer T-CPU mit einem S120 sehr gut zurecht kommt, dann ist der Schritt zu einer klassischen SPS mit antriebsintegriertem Positionierer (beim S120: EPos) auch nicht mehr weit - man muss halt noch das Funktionsmodul aktivieren und statt eines Standardtelegramms 5 oder 105 einfach das EPos- Telegramm verwenden (z.B. Telegramm 111).
Ich denke das ist Gewohnheitssache (die LENZE Fraktion wird Ihre IBN- Tools favorisieren und die Rexroth entsprechend wieder Ihre eigenen).
Aber ist eben schon der Trend zu erkennen, dass einerseits die typischen Antriebshersteller immer mehr den Steuerungsmarkt beackern und umgekehrt.
PLC- Open Bausteine gibt es ja auch bei B&R usw....
Ansonsten wachsen auch die Engineering- Tools immer weiter zusammen - siehe Automationstudio oder TIA- Portal usw...

Wenn ich z.B. einen klassischen FU habe (nur Drehzahlsollwerte), dann ist es wohl am schnellsten den Hochlaufgeber im Antrieb zu nehmen und Steuerwort und Drehzahlsollwert direkt vorzugeben (Einbindung als normaller Slave). Bei komplexeren Anwendungen (z.B. Kurvenscheiben, Aufsynchronisieren), dann ist es wohl effizienter das in einer MotionControl Steuerung zu machen. Bei sehr vielen Achsen kann ich mir aber auch wieder vorstellen dass man das Thema MotionControl den Antrieben überlassen möchte...

FAZIT: Ich als Antriebstechniker (der eben lieber eine Positionierapplikation oder Gleichlaufapplikation "parametriert" als "programmiert") kann sich hoffentlich trotzdem noch sehen lassen ...

 

[rostiger Nagel]

@zako,
ich hoffe das du, obwohl du Antriebtechniker bist, uns SPSler hier weiterhin unterstützt,
da kommt ja so einiges. Zum Thema, ich habe die T-CPU erst vor kurzen für mich
entdeckt und bin wirklich über die Möglichkeiten mehr als begeistert, ich würde
niemals versuchen, wie der Perfekte es macht, Motion Funktionalitäten in einer
Standard SPS nachzubilden, da sind mir die PLC-Motion Bausteine lieber. Vorteil,
ich kann mich auf die Aufgabenstellung konzentrieren und muß nicht meine zeit auf
das drumherum verschwenden und habe verlässliches Funktions bzw. Zeitverhalten
meiner Applikation.

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

@rn

Ich habe vor Jahren mal eine T-CPU (V1.0) genutzt. Ich würde es nur empfehlen, wenn es denn wirklich sein muß. Mein Hauptproblem damit ist, absolute Abhängigkeit von der Siemens-T-CPU, extra Softwarepaket, dass mit dem eigenständigen Starter nicht kompatibel ist, nach Jahren muß man Änderungen vornehmen, Softwarepaket alt, Updateorgie, Firmware alt, nochmal Orgie, bzw. geht nicht mehr, zu alt. Ein Servo muß i.d.R. seltener angefaßt werden, in der SPS kann man problemlos die Ansteuerungsbausteine verwenden/ändern.

Klar, bei Synchronläufen, Verschleifen etc. kommen andere Anwendungen/Hardware zum Tragen, aber eine T-CPU wäre für mich die letzte mögliche Variante.

 

[rostiger Nagel]

Na ja Ralle,
das ist leider so bei jeder Siemens Software, nimm flexibel hast du
vor 5-8 Jahren mal flex auf einen Panel PC installiert und musst heute
einen Button nachrüsten, stehst du vor dem selben Problem.
Das System selber finde ich gut, das mit den Wartbarkeit ist natürlich ein
Grundsätzliches Problem bei Siemens, im Prinzip wird doch bei erscheinen
eines neuen Produktes die Abkündigung, von diesen erklärt. Die stehen sich
da selber im weg.

 

[Perfektionist]

Zum Thema, ich habe die T-CPU erst vor kurzen für mich
entdeckt und bin wirklich über die Möglichkeiten mehr als begeistert, ich würde
niemals versuchen, wie der Perfekte es macht, Motion Funktionalitäten in einer
Standard SPS nachzubilden, da sind mir die PLC-Motion Bausteine lieber. Vorteil,
ich kann mich auf die Aufgabenstellung konzentrieren und muß nicht meine zeit auf
das drumherum verschwenden und habe verlässliches Funktions bzw. Zeitverhalten
meiner Applikation.

Nachteil:

Mein Hauptproblem damit ist, absolute Abhängigkeit von der Siemens-T-CPU, extra Softwarepaket, dass mit dem eigenständigen Starter nicht kompatibel ist, nach Jahren muß man Änderungen vornehmen, Softwarepaket alt, Updateorgie, Firmware alt, nochmal Orgie, bzw. geht nicht mehr, zu alt.

...

Klar, bei Synchronläufen, Verschleifen etc. kommen andere Anwendungen/Hardware zum Tragen, aber eine T-CPU wäre für mich die letzte mögliche Variante.

Beim Verschleifen habe ich zugegeben noch meine Hauptprobleme, Synchronlauf, Positionieren, fliegende Säge beherrsche ich seit seid Oktober 1997 mit AWL auf 945er. Der Code und das Know-How läuft nach nun 16a unverändert auch auf einer 1500er, wenn ich das noch in SCL rübernehme auch auf der 1200er. Ggf. dann auch auf nicht-Siemenssteuerungen und wenn es sein muss, auch mal abweichender Antriebstechnik (wobei ich in Zukunft auch bei der Antriebstechnik auf TIA setzen werde - z.B. wegen Alarm_S bzw. sonstiger Direktverbindung mit der Visu).