Hallo
Zitat:
SRC 167
***PTP HOME { X +446.185,Y +42.577,Z +3074.974,A +38.611,B +2.170,C +1.426,S 6,T 1 }
2033( 13) SATZENDE ODER KOMMENTAR ERWARTET
Entweder muss man schreiben: PTP HOME (nachdem HOME vorher als POS-Variable deklariert wurde) oder
PTP { X +446.185,Y +42.577,Z +3074.974,A +38.611,B +2.170,C +1.426,S 6,T 1 }
Gruß
PA
Hallo, Kai,
der Vorlaufzeiger bezieht sich auf $advance. Es werden soviel Punkte berechnet, wie $advance vorgibt, und darüber hinaus, bis der Vorlaufzeiger vor der Punktanweisung $advance+1 steht. Darauf muss man besonders bei der Abfrage von Sensoren achten, da bei einem zu großen Vorlauf beispielsweise der Sensor für einen Aktor bereits ausgewertet wird, bevor im Hauptlauf der Aktor überhaupt bewegt wird.
Beispiel: An einem bestimmten Punkt soll ein Zylinder ausgefahren werden, der Sensor dafür soll einen Punkt später abgefragt werden. Bei einem $advance=3 ist der Vorlaufzeiger bereits bei der Sensor-Abfrage, bevor im Hauptlauf der Zylinder ausgefahren wurde. Der Hauplauf ist das, was man auf dem KCP als Pfeil links neben den Programm-Zeilen sieht, der Vorlauf (wie beschrieben) entspricht $advance.
Für die Bahnplanung braucht der Roboter natürlich auch Geschwindigkeiten. Wie ich feststellen musste, sind deutliche Geschwindigkeits- bzw. Beschleunigungsdifferenzen zwischen 2 aufeinander folgenden Punkten problematisch. Besonders, wenn der 2. Punkt deutlich langsamer als der 1. Punkt ist, fährt der Roboter den 2. Punkt nicht so langsam wie vorgegeben. Das mag bei meinen Programmen daran liegen, dass ich einen $advance=1 wg. oben beschriebener Sensorik-Abfragen benutze. Wenn ich also einen Suchvorgang einleiten will, der mit langsamer Geschwindigkeit läuft, muss der letzte Punkt vor dem Suchen bereits entsprechend langsam sein. Wenn man das anders machen kann, ohne $advance>1 zu setzen, wäre ich für Hinweise dankbar.
Ist die Antwort passend auf die Frage?
Gruß
PA
Hallo, kai_n,
1.)
sowie ich das mit $OV_PRO sehe, wird bei der Änderung des Wertes auf <100 nicht nur die Geschwindigkeit, sondern auch die Beschleunigung gleichermaßen verringert, deshalb sind 75% $OV_PRO nicht nur 75% Geschwindigkeit, sondern auch nur 75% Beschleunigung. Ich habe vor Jahren mal Schätzungen machen müssen, weil mein Roboter einem externen Gerät die gleiche Geschwindigkeit vorgeben musste, die er selbst hatte. Mit einer selbst erstellten Formel habe ich die Robotergeschwindigkeit bei verringertem $OV_PRO ausgerechnet, allerdings ohne die verringerte Beschleunigung, das war mir erst später aufgegangen.
2.)
Wenn die Robotersteuerung den anzufahrenden Punkt incl. der Geschwindigkeits- u. Beschleunigungswerte berechnet hat, kann man, soweit mir bekannt, darauf keinen Einfluss mehr nehmen. Der Punkt ist dann einfach erledigt, die Steuerung wendet sich ja bereits dem nächsten Punkt zu, in Abhängigkeit von $advance. Wäre es möglich, das Schaumgummi zu suchen, indem man mit dem Roboter so weit fährt, bis der Analogsensor einen bestimmten Wert hat?
Gruß
PA
Ich arbeite nur mit KUKA-Robotern und habe mit dem KUKA-Service meistens gute Erfahrungen gemacht. Wir hatten schon die unterschiedlichsten Probleme, und bis auf wenige Ausnahmen wurden wir geholfen.
PA 
Hallo,
mein Vorschlag zu diesem Thema wäre: Den Roboter nach dem Ausschalten im Kaltstart wieder hochfahren lassen (Parametrierung s. KRC 2 läuft nicht mehr hoch). Dann wird das Programm automatisch neu gestartet (wenn in der SPS.SUB aufgerufen). Ich setze im Programm-Anfang der SPS.SUB eine Variable, die mein Anwender-Programm zurücksetzt, nachdem diese Variable geprüft wurde und mein Anwender-Programm erkannt hat, ob der Roboter ausgeschaltet wurde oder nur das Anwender-Programm zurückgesetzt wurde.
MFG
PA
