Ansonsten wenn ihr mit dem Roboter nicht an der Lastgrenze seit und Extrem schnell fahrt, wird die Sache auch ohne Lastdaten gehen. Ich meine, dass hat sogar KUKA uns/mir bestätigt, dass die Roboter auch so gehen, nur wenn es Zeitkritisch wird, wären korrekte Lasdaten immer vorzuziehen.
Das kann in Verbindung mit Spline-Bewegungssätzen ganz bös ins Auge gehn. Immer schön die RICHTIGEN Lastdaten verwenden, da habt ihr beide was davon (Du und der Roboter)! 
Da für die KUKA-Steuerung die Bremsen geschlossen sind, dürfte die Achse 1 sich ja auch nicht bewegen. Bewegst du diese nun mit einer externen Kraft, wird dadurch wohl der Bremsenfehler angenommen.
Und "immer Kaltstart" find ich persönlich eine super Sache. 
@ IrrerPolterer: Also ich hab noch keine KR C2sr Steuerung gesehen, welche ich nicht von USB booten konnte.
Ich tippe auch auf eine defekte HDD. Die benötigte Sotfware bekommst Du bei der KUKA-Hotline!
Manchmal klappt es auch mit einem USB-IDE-Adapter ein Image der Platte zu erzeugen und auf eine neue aufzuspielen.
ON_ERROR_PROCEED geht aber erst ab KSS 5.5.x !
Ja dann rate ich dir Tool und Base neu zu vermessen.
Ich hoffe du hast noch den Referenzpin mit dem die Bases eingemessen wurden, ansonsten muss den auch noch machen und einmessen. 
Hallo Chepe,
also der KR3 kann nur mit der Nonius-Justage justiert werden daher wird Dir das EMT auch nix bringen.
Zu deiner Frage, die KR3-Roboter werden im Werk mit vorgesehenen Messmitteln justiert, dh. die Justage ab Werk ist schon sehr genau.
Tool und Basevermessung sind NICHT unabhängig von der Justage.
Ist der Punktversatz auf eine bestimmt Achse zurückzuführen? Wenn ja kannst du das ja mit der Justage "ausgleichen".
Alles anzeigen
Hallo Cycflag,
ich vermute es handelt sich um einen Kr200 oder Kr2000? Bei Kr2000 ist es auf keinen Fall ratsam mit falschen Lastdaten zu fahren, systembedingt.
Ich vermute der Massenschwerpunkt des Tools ist bereits korrekt eingetragen. Werden extreme Orientierungsänderungen durchgeführt? Dann könnten die korrekten Trägheiten noch was bringen.
Gruß, robots
genau wie robots schon sagt mal Lastdatenermittlung dürchführen, wenns noch nicht gemacht wurde.
Erstens findet das dein Roboter super und zweitens kann das deine Taktzeit wegen optimierter Bremsrampen usw. verbessern.
Mit "GripperTech" könntest du dies auch lösen. Das wäre sogar leichter und schneller als "UserTech".
Hmm ich hab noch ne Idee!
vielleicht liegt es daran dass du den Interrupt nicht ausgeschalten hast, kommt er öfter hintereinander?
versuch das ma
&ACCESS RVO
&REL 33
&COMMENT PROJEKT
&PARAM TEMPLATE = C:\KRC\Roboter\Template\vorgabe
&PARAM EDITMASK = *
DEF UNTERPROG( )
BRAKE
INTERRUPT OFF
...
...Fahrbewegungen
...
...
...
...
RESUME
END
Und was auch wichtig ist der Interrupt geht nur bei einem Flankensignal.
das heisst wenn der eingang schon 1 ist bevor der Interrupt an geschalten wird kommt er nicht!
Nur wenn das Signal nach dem Einschalten des Interrupts auf 1 geht (positive Flanke) funktioniert er.
MFG
Syrix
Und nochmal
Haben Sie schon einmal unter Anzeige/Eingänge geschaut ob Ihr declarierter Eingang auch wirklich auf High geht?
Der Interrupt kommt nur mit einer ansteigenden Flanke.
Hallo nochmal,
nur die Interrupts mit der Priorität 40 - 80 sind durch eine automatische Prioritätsvergabe durch das System reserviert.
1-39 und 81-128 können verwendet werden.
Hallo Herr Kaiser
also ich würde Ihr Unterprogramm folgendermaßen abändern.
&ACCESS RVO
&REL 33
&COMMENT PROJEKT
&PARAM TEMPLATE = C:\KRC\Roboter\Template\vorgabe
&PARAM EDITMASK = *
DEF UNTERPROG( )
BRAKE
...
...Fahrbewegungen
...
...
...
...
INTERRUPT OFF
RESUME
END
Ich hatte auch öfters Probleme mit Interrupts das entfernen der INI Zeile wirkt manchmal Wunder.
Nach Ablauf des Unterprogramms wird wieder an die stelle gesprungen in der der Interrupt deklariert wurde.
evtl bei der Interrupt deklaration folgendes probieren.
GLOBAL INTERRUPT DECL 5 WHEN $IN[6]==TRUE DO unterprog()
