Beiträge von fubini

Hallo,

das ist ein Absturz der Benutzeroberfläche. Schau mal ins LOG-Verzeichnis, da sollte ein KUKA_HMI.exe.log oder so ähnlich liegen. Da sollte auch mehr Info drin sein.

Gruß
Fubini

Hallo,

Die Meldung kommt meines Wissens in zwei Fällen:
1) Falls keine Referenzfahrt angewählt ist und der Referenztaster angefahren wird.
Daher: hast du die Referenzfahrt über das JusrefReq Programm im TP/SafeRobot Ordner verwendet?
Sind dort alle notwendigen Punkte getaecht? Also die Punkte in JusRefStart und JusRefBack?
2) Eine Referenzfahrt angewählt ist aber nicht beite Kontakte am Referenzschalter bedämpft werden.
Daher: Überprüfe doch mal ob in der Referenzposition beide LED an der Rückseite des Schalters
ihren Zustand wechseln.

Ansonsten könntest du bitte etwas genauer beschreiben welche Versionen du einsetzt KRC v5.4 Build
xx (?) und SafeRobot V1.0 oder V1.1 Build xx(?)

Gruß
Fubini

Hallo Irrer Polterer,

ich kann dir aus eigener Erfahrung sagen, dass es dazu keinen Professor der Mathematik braucht. Mein Diplom tuts auch. Mir sind auch schon Ingenieure untergekommen, die daran nicht gescheitert sind.

Spaß beiseite, wer wissen will wies geht kann z.B. in das Buch:

John J. Craig: "Introduction to Robotics - Mechanics and Control"

schauen. Mit der dort bereitgestellten Methodik kann man das machen. Allerdings müsstet ihr um es auf eine konkrete Maschine anwenden zu können von eurem Roboter die Längen von Verbindungen u.ä. kennen. Das steht zwar alles in den Maschinendaten nur aufgrund der manchmal kryptischen Bezeichner sollte zu Zuordnung was denn nun was bei welchem Robotertyp darstellt nicht so einfach sein.

Gruß
Andreas

Hallo Markus,

CP_STATMON hat drei mögliche Optionen (CHECK_S, CHECK_TS, NONE). Die Überwachung dient der Prüfung von Status (_T) oder Status und Turn (_TS). Ist die Option aktiv wird überprüft ob bei CP Bewegungen der Turn wechselt. Gerade bei Achsen 4 und 6 (endlos drehend) kann es sonst zu eventuell nicht erwarteten kompletten Umdrehungen kommen, falls Anfangs- und Endpunkt unterschiedlichen Turn haben. Bei PTP Bewegungen kann es sein das unter Umständen bei ungünstigen unterschiedlichem Status eine ungünstige Konfiguration angefahren wird. Es wird also eigentlich ein Plausibilitätstest für Status und Turn durchgeführt- Ist die Überwachung inaktiv sind alle Punkte auch anfahrbar es kann aber eben zu dem angesprochenen vielleicht zunächst nicht erwarteten Verhalten kommen.

Gruß
Fubini

Hallo Markus,

ich glaube da gab es mal bei KUKA dieses Problem, da der Turn für die Zusatzachsen fälschlicherweise mit eingerechnet wurde. Die Aussage, dass KUKA nichts davon weis ist also falsch. Meinem Kenntnisstand nach müsste das Problem ab der 5.2.15 behoben sein. Wende dich doch mal an LindePaul der sollte das klären können.

Gruß
Fubini

Hallo zusammen,

ich kann euch versichern, dass es so etwas bei KUKA nicht gibt. Wie schon angesprochen, kann die Steuerung ja nicht wissen wie ausgewichen werden sollen. Stellt euch mal vor die Steuerung würde einfach festlegen wie es passieren soll und fährt dann Crash. Ich glaube 99.999999% aller Kunden würden KUKA dann die Hölle heiß machen, was für nen Scheiss die machen.

Gruß
Fubini

Hallo,

die IEEE-Synchronisierung dient nur um die Antriebshardware und die Robotersteuerung auf eine gemeinsame Zeitbasis zu initialisieren. Für den fehlerfreien Betrieb des Roboters hat das keine Bedeutung. Es bezieht sich auf den Ethernet-Standard nach IEEE 802.3.

Gruß
Fubini

Hallo,

DEVNET=2,dnInit,dn2drv.o

bedeutet nichts anderes als das der Devicenet Treiber dn2drv.o im DRIVERS Verzeichnis C:\KRC\ROBOTER\DRIVERS verwendet werden soll.
dnInit ist dabei wahrscheinlich die Funktion die in dem Modul dn2drv.o aufgerufen werden soll und die 2 ist dabei wohl ein Parameter an diese Funktion. Was damit intern gemacht wird weis dann wohl nur KUKA selbst.

Gruß
Fubini

Hallo,

"Masteringtestswich_ok Variable ungültig" bedeutet, dass ihr in der STEU/$machine.dat dem Signal $MASTERINGTESTSWITCH_OK keinen Ausgang zugeteilt habt. Defaultmäßig steht dort nämlich FALSE. Damit die Variable schreibbar wird müsst ihr also $MASTERINGTESTSWITCH_OK=$OUT[xx] auf einen noch freien Ausgang setzen. Das solltet ihr übrigens auch mit allen anderen Signalen die dort auf FALSE stehen machen und zwar auch dann wenn sie nicht von euerer SPS weiterverarbeitet werden

Das Problem mit dem Bremsentest hört sich schon etwas schwieriger an. Vielleicht löst es sich aber auch mit der obigen Methode. Ausser Achse 7 in BrakeTestDrv.INI sollte eigentlich nichts zu konfigurieren sein. Poste die Datei dochmal dann kann ichs mir morgen, wenn ich wieder in der Arbeit bin, mal anschauen.

Gruß
Fubini

Hallo,

zunächst wird der Scara eigentlich genauso betrieben wie alle anderen KUKA Roboter. Er hat als Software die KRC V7.0 die vom Funktionsumfang im wesentlichen mit der KRC V5.4 identisch sein sollte. D.h. Oberfläche und Programmierung sind absolut gleich geblieben. Einziger Punkt der mir jetzt auf Anhieb einfällt und nicht identisch ist, ist die Justage. Bei den neuen kleinen KUKA-Robotern gibt es nämlich keine EMT-Justage und auch keine Uhr-Justage. Vielmehr muss hier in den Endanschlag des Roboters verfahren werden (keine Angst, das macht der Roboter bei entsprechender Auswahl der Justage im Inbetriebnahme Menü von selbst).

Es gibt vielleicht noch nicht alle Techpakete, d.h. ich würde, da du ja eventuell an PalletTech zum palletieren interessiert bist, einfach mal bei KUKA nachfragen ob es für die V7.0 schon zur Verfügung steht.

Eine Jump Funktion beim KUKA so in dieser Form kenne ich nicht. Falls du etwas genauer beschreibst was man damit beim Epson so alles machen kann, bin ich mir sicher das man ein ähnliches Verhalten auch mit einem KUKA nachahmen kann.

Gruß
Fubini

Hallo,

du brauchst dir keine Sorgen zu machen. Es gibt absolutgenaue und nicht absolutgenaue Roboter. Der Unterschied ist im wesentlichen nur, dass jeder absolutgenaue Roboter von KUKA vor der Ausleiferung genau vermessen wird. Dies sorgt dafür, dass absolutgenaue Roboter einfach noch genauer sind. Nicht positioniergenau bedeutet im Umkehrschluss nur, dass für diesen Roboter die genauere Vermessung nicht durchgeführt wurde.

Hallo mike,

Bei Arbeitsraum 9 handelt es sich um einen sogenannten Melderaum der bei Verletzung zwar den Roboter nicht anhält, aber die Verletzung über einen sicheren Ausgang meldet. Nachdem die Räume immer aktiv sind sollte eigentlich nie die Meldung Arbeitsraum Nr. x verletzt kommen, sondern beim Überfahren der Bereichsgrenze Arbeitsraum Nr. x überschritten. Falls dem so ist,
kann es dann sein dass die Maschine, die nicht mehr zufahren kann direkt oder über SPS an diesem Ausgang hängt und die Bewegungsfreigabe wegnimmt, falls der Ausgang false wird?