Beiträge von atw11m92

Könnte mir vorstellen, dass du INFO darüber in der SoftKeyKuka.ini findest.
Vielleicht musst du die entprechenden Einträge einfach löschen!!
Habs aber nicht selbst probiert!!

Habe noch nie das TTS als Regelungssystem verwendet -> daher keine Erfahrung

in der config.dat deklarierst du zb.

SIGNAL speed $out[10] to $out[25] ->16 bit reicht aus, weil deine Geschwindigkeit eh nicht negativ sein wird

in der sps.sub
speed=$ov_pro

dann musst du natürlich irgendwo deine 16 bit auf den Profibus legen -> iosys.ini

Wenn du einen Analogwert an die übergeordnete Steuerung übergeben möchtest,
dann ist dies ein REAL Wert.
Du musst dir also einen Bereich auf dem Profibus(oder wie du eben mit der Steuerung kommunizierst) definieren.
darauf in der sps.sub einfach die aktuelle Geschwindigkeit schreiben.

zb. SIGNAL speed $out[xxx] to $out[yy] ; je nach dem ob du 16 od. 32 Bit brauchst

im sps.sub
speed=$ov_pro ; oder was immer die Geschindigkeit ist

Das fertige Softwarepaket ist natürlich in seinem Umfang auf Standardprobleme zugeschneidert.
Wenn du Sonderlösungen brauchst, musst du dies bei KUKA gegen ein "kleines" Endgeld zukaufen, oder wie eben gesagt über die RSI-Bibliothek selbst erstellen.
Ich habe mir auch Mühevoll durch die Testprogramme von KUKA das RSI Wissen etwas angeeignet. Da mit Doku gegeizt wird war es einfach langes testen mit verschiedenen Einstellungen.

Wenn du fertige Funktionen über das RSI Paket hinaus haben möchtest, musst du das FTRCL Paket kaufen

am einfachsten ist, du bekommst von der übergeordneten SPS einen Eingangswatchdog(zb. INT Zahl) die ständig erhöht wird und spiegelst(im SPS.SUB) diesen Wert einfach wieder auf den Ausgangswatchdog zurück.
Vorsicht: so erkennst du, dass der Submitinterpreter steht - nicht unbedingt das der Profibus nicht geht.
Sollte es eine Profibus Störung geben bekommst du sowieso eine Meldung

Es stellt sich zuerst die Frage, was du für eine Sensoranwendung vor hast?
Möchtest du einen eigenen integrieren oder einen von ATI?
Für die Zukaufsensoren gibt es ja eine schöne Oberfläche, wo du die Sensoren konfigurieren kannst!!
Ansonsten reicht ja das RSI Softwarepaket und du kannst schöne Sensoranwendungen erstellen, ist aber ziemlich mühsam, weil die bereits von dir erkannt die DOKU ziemlich wenig ist.

Bevor du die Steuerung immer gleich neu startest solltest du vorher mal den Reset-Taster drücken - oder hast das eh gemacht?

Also ganz zu ängstlich müsst ihr jetzt auch nicht werden!!!
Habe es schon so praktiziert und mehr als einen kleinen Zucker macht der Roboter nicht!!!
Man sollte halt dann nicht unbedingt mit A2 austauschen sondern eher eine A4-A6 nehmen!!!

Naja bin davon ausgegangen, dass man dies nicht im Automatik macht oder T2, sondern schön langsam im T1 -> da kann nichts passieren!!

Hast keinen Brückenstecker für die X11 - damit du alles ausschliessen kannst

OK - es heisst dort nich DRIVES_OFF sondern ANTRIEBE AUS. So ist es zumindest bei den großen Brüdern vom KR5sixx.

Hat der KR5Sixx auch so etwas wie eine X11 Schnittstelle?
Wenn ja, muss dort das $DRIVES_OFF auf HIGH gebügelt sein!!

tausch einfach mal auf das RDW die Anschlüsse der Geberleitung von A3 mit einer anderen Achse aus,
wenn dann die Meldung für einen anderen Geber kommt, dann weisst du, dass es am Kabel od resolver liegt.

es gibt jetzt die neuen NET sensoren da brauchst einen sensor. von dort ein kabel zur kuka NET-BOX und von dort in die KRC.
für die KRC gibt es ein fertiges software paket - FTCRL. wenn es nicht zu komplizierte Anwendungen sind brauchst das ding nur über eine maske konfigurieren und den rest erledigt die krc für dich!!

nur mal ne blöde Frage: Wie soll der Neustart funktionieren, wenn der Submitinterpreter ja hängt??????
dann sollten eigentlich die CWRITE Kommandos nicht ausgeführt werden, ansonsten läuft er eh!!!!!

Du könntest das Ganze natürlich über RSI lösen, da kannst du auch die Richtung sofort umdrehen im IPO Takt.

Schau mal in der KUKA Doku nach, da steht irgendwo, dass er seine Bahn fertig fährt und dann erst den neuen Bewegungssatz startet, ausser du hast eine Brake Anweisung.

Wenn du etwas Geld zur Verfügung hast, könntest du ja eine zusätzliche Sensorik anbringen, sodass beim Annähern die Geschwindigkeit reduziert wird!!

Schaum mal im $custom.dat nach, was unter $Torqmon_def[5] steht!?
Dort steht als Standard 200!!

Einfach den entgegengestzten Weg programmieren ist ja schön und gut, aber auch hier musst du mal kurz anhalten.
Ein Brake F ist da sicher schneller(vermute ich zumindest).

Wenn die Suchfahrt immer gleich ist, dann könntest du ja die Ströme zusätzlich begrenzen um bei evtl. Kollission nichts zu verformen.