TIA Siemens Roboter Integration und CPU-Last

Raijin Tycho

Level-1
Beiträge
85
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin zusammen,

hat jemand von euch schon Erfahrungen mit der Roboterintegration (z.B.: von Kuka Robotern) von Siemens gemacht? Wie wirkt sich das auf die Resourcen der CPU aus? So wie ich das aus den Unterlagen lese, duerfte sich die Merhbelastung durch den Roboter ja in Grenzen halten, da die CPU nur Positionen vorzugeben scheint und die Roboter-Steuerung den rest zu uebernhemen scheint.
 
Ich verbaue sein 20 Jahren Kuka Roboter an Anlagen. Letztendlich wird ja nur eine Verbindung ( damals über Profibus, heute über Profinet ) aufgebaut und
Daten hin und her gesendet. z.B. 160 Byte zum Roboter und 160 Byte vom Roboter.

Von der CPU Last ist da kaum etwas merklich, unsere älteren Anlagen laufen mit 315-2AG10, also im Vergleich zu heute eine langsame "Krücke".
 
Zuviel Werbung?
-> Hier kostenlos registrieren
da die CPU nur Positionen vorzugeben scheint und die Roboter-Steuerung den rest zu uebernhemen scheint.
Die CPU schaltet den Roboter ein ( Roboter steht auf Betriebsart Auto Ext ). D.h. es findet ein bestimmter Zuschaltprozess statt, der
die Antriebe zuschaltet ( das was man in Betrieb Auto mit dem weißen Schalter "Antriebe ein" macht ).

Der Roboter bekommt dann Anweisungen, wohin er fahren soll, was er machen soll. Bei uns per Bitbefehl. Kompliziert sind eher die Homefahrten
aus unterschiedlichsten unbekannten Positionen.
 
Was Raijin meint ist, es wird eine Libary von Siemens (Und auch anderen SPS Herstellern) die den kompletten Ablauf der Roboter schreibt. Der Controller übernimmt nur noch das ausführen der befehle. Das Mobile Panel dient dann als TeachPendant...

Die Last wird schon merklich sein, da halt viele Moves in einem Graph hin und her geschoben werden. So weit ich weiss ist das aber alles noch in der Beta Phase...
 
Ist das mit der Simatic Robot Integrator Bibliothek auch so? Bei Yaskawa weiß ich das es wei Arten der Implementierung gibt: Einmal über Profinet, wo man im Prinzip einfach Befehle über Bits auslöst, und MotoLogix wo der Roboter anscheinen etwas mehr in die SPS eingebunden wird über diese Roboter Integrator Bibliothek. Da funktioniert zum Beispiel der Teach-Pendant nicht mehr im vollen Umfang.
[h=2][/h]
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Was Raijin meint ist, es wird eine Libary von Siemens (Und auch anderen SPS Herstellern) die den kompletten Ablauf der Roboter schreibt. Der Controller übernimmt nur noch das ausführen der befehle. Das Mobile Panel dient dann als TeachPendant...

Wo steht dass?

Ich habe folgendes von ihm gelesen:
da die CPU nur Positionen vorzugeben scheint und die Roboter-Steuerung den rest zu uebernhemen scheint.
 
Also bei Yaskawa gehen 436 Byte hin und her wenn man MotoLogix nutzt. Da aber alle ge-teachten Punkte in der SPS gespeichert werden, sollte der Remanzspeicher nicht zu klein sein.
Ich arbeite gerade an einem Projekt mit 2 Yaskawa's und den Micro-Steuerungen. Hier werden 2x 436 Byte benötigt, da die Micro-Steuerung nur einen Robi kann.

Wir werden eine 1515F einsetzen. Das sollte reichen.

Der Simatic Robot Integrator setzt immer auf die kostenpflichtigen Librarys der Hersteller also z.B. Yaskawa MotoLogix oder KUKA.PLC mxAutomation.

Wer sich dafür interessiert sollte sich mal die entsprechenden Robot-Integratoren vom Siemens Support mailen lassen.

Die Bedienteile der Hersteller braucht man dann eigentlich nur noch für Systemeinstellungen oder zum Teach-Punkt anfahren, wenn man dafür nicht
die Siemens HMI nutzen will.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja, schon.

Ich meinte wo steht das er dass sucht. Seine Frage bezog sich auf eine separate Robotersteuerung und eine SPS welche Steuersignale sendet / empfängt.
Wenn die SPS die Roboterkinematik übernehmen soll ist das natürlich wieder eine ganz andere Welt
 
Es gibt eigentlich 4 Varianten:

1. Klassische EA-Verdrahtung zur Kommunikation. Kein Bus benötigt. Macht heute eigentlich kaum noch jemand.
2. Steuerung über Bus, aber nur Aufruf von vorher per Bedienteil programmierten Abläufen ggf. Savety-Funktionen. Kleiner EA-Bereich. Geht auch mit einer 1510.
3. Steuerung über z.B. Yaskawa MotoLogix oder KUKA.PLC mxAutomation. Grössere EA-Bereich. CPU ab 1515. Die Hersteller-Steuerung übernimmt immer noch die Berechnung der Bahnbewegung.
4. Steuerung komplett über SPS, z.B. bei 4-Arm-Kinematiken (Delta-Roboter). Hierfür ist wird bei Siemens eine T-CPU benötigt. Bei Beckhoff z.B. eine Leistungfähige CPU und ein TwinCat-Kinematik-Paket.
 
Aus dem Text von ihm so verstanden. Da die CPU ja Positionen vorgibt...

Ja, schon.

Ich meinte wo steht das er dass sucht. Seine Frage bezog sich auf eine separate Robotersteuerung und eine SPS welche Steuersignale sendet / empfängt.
Wenn die SPS die Roboterkinematik übernehmen soll ist das natürlich wieder eine ganz andere Welt

Es gibt noch eine 5. Variante:
Der Controller des Roboters übernimmt die Pfadplanung. Der Positionen und Accuracy, usw... werden von der SPS vorgegeben.
 
Zurück
Oben