Beiträge von Timo-Schulz

So, ich führe mein Thema mal weiter...

Inzwischen läuft der eine unserer beiden Roboter einwandfrei! JUHU!

Bei dem zweiten gibts aber mal wieder ein Problem:
es ist nicht möglich die Betriebsart Automatik zu ändern. Durch Betätigen des Schlüsselschalters reagiert zwar der Schaltschrank (Relais gehen lautstark ihrer Berufung nach), aber im PHG steht immer noch "AUT". Demnach kann ich das PHG auch nicht aktivieren oder den Roboter verfahren. Was allerdings erstaunlich ist, ist das sich die Meldung im PHG auch ändert. Also ist soweit alles ok, nur das sich Meldung oben links im PHG "AUT" nicht ändert...

Jemand eine ?

MFG

So, um mein eigenes Thema mal abzuschließen :

Die Kontakte an der Halterung für das PHG waren eingerastet, obwohl das PHG nicht drin war. Naja, die Zeit zeigt ihre Wirkung...

MFG

Und noch ein Schritt weiter:

die Meldung "Active- Status erforderlich" bedeutete nichts weiter als das man das PHG aktiv setzen muss - sprich auf EIN Knopf drücken - naja, wenn man es nicht weiß ist auch schlecht...

gesagt getan, nun aber erhalte ich die Meldung "Active nur in AUT zulässig" - gut gut, mal nachgeguckt und herausgefunden, dass dieses bei "PHG ortsfest" der Fall ist. Hatte das PHG aber in der Hand, es war somit NICHT in der Halterung.
Laut Plan für den X111 ist der Pin 12 namens "PHG ortsfest" wohl irgendwie dafür verantwortlich... der ist aber zur zeit gar nicht belegt. In der MACHINE.DAT gibt es eine Variable "$HPU_fixed $IN[593]" die ebenfalls was mit PHG ortfest zutun hat....

Kann mir da einer weiter helfen? Will doch nichts anderes als im T1 oder T2 verfahren können...

MFG

So, nachdem ich einige Gespräche mit Kuka, Fronius und Servicepartnern von Kuka geführt habe muss ich feststellen, dass es eher schlecht aussieht was so eine Libo-Karte angeht. Also an alle die ebenfalls mal suchen: vergesst es...

Aber trotzdem nochmal kurz zum Thema KRC32:

Ich bekomme im T1 und T2 die ganze Zeit die Meldung "Active-Status erforderlich" und kann den Roboter auch nicht bewegen. Im Automatikmodus hingegen funktioniert alles... . Da ich keine ausführliche Beschreibung besitze und die Meldung auch nicht von der KRC1 her kenne: kann mir da einer helfen?

MFG

Und nochmal ich...

also nochmal etwas konkreter: aktuell benötigt man wohl für eine Nahtfindung wirklich "Touch-Sense 1.1" - geeignet ab KRC2 und mindestens 730 MHz des Prozessors. Für die Nahtfindung hab ich die Kombination aus "Arc-Tech analog" in Verbindung mit "Kuka Arc-Sense" gefunden (alles richtig soweit?). Ebenfalls erst ab KRC2 gültig

Kennt jemand ältere Versionen und deren Bezeichnungen für die KRC32? Schweißen gibts doch schon sehr lange - denke mal das es die Systeme auch für ältere Steuerungen geben muss. Nur finden ist schwierig...

MFG

Hallo zusammen,

öfters mal was Neues, somit hier mal wieder eine Frage:
Haben vor (wenns eben geht) einen alten KR15 mit einer KRC32-Steuerung zum Verschweißen von Bauteilen zu verwenden. Da hier allerdings zu große Toleranzen vorhanden sind, soll ein System zur Nahtfindung (von Kuka heißt das glaube ich "Touch-Sense") und zur Nahtverfolgung (mittels Lichtbogensensor und entsprechender Hard- sowie Software innerhalb der Steuerung) zum Einsatz kommen.

Nun zu den Fragen:
1. Ist ein solcher alter Roboter überhaupt in der Lage zum Bahnschweißen (kenn mich mit diesem Modell nicht aus)
2. Gibt es noch oder überhaupt entsprechende Hard- und Software für die Nahtfindung und -verfolgung?
3. Hat jemand Erfahrungen mit der Installation der Komponenten bzw. kann mir sagen wo man diese noch beziehen kann?

Schonmal !!!!

MFG

Hallo @all

und für alle Tipps.... !!!!

Es war wirklich die *.dat - die schien irgendwie defekt zu sein. Neues Programm: und alles tut

MFG

Hallo Zusammen!

Habe mal wieder ein (hoffentlich kleines) Problem(chen):

Bei dem Versuch einen Punkt über TouchUp zu teachen erhalte ich die Fehlermeldung:
"Abs.: TPBASIS - Meldung: Der Punkt ... konnte nicht angelegt werden"
Der Name des Punktes scheint dabei egal zu sein - hab alles Mögliche probiert. Wenn ich hingegen einen bestehenden Punkt änder klappt es komischerweise. Ist ein sehr kleines Progi, also nur sehr wenige Punkte vorhanden. Benötige die Funktion dringend für "ARCTech" - also

Danke an alle!

MFG

Alles klar, danke!

Sorry nochmal für die vielleicht "doofen" Fragen, wir tun uns aber hier ziemlich schwer gerade im Bereich der I/O der Steuerung - ist halt Neuland für uns....

Dann werden wir uns mal um die neue Karte kümmern...

MFG

Hallo Zusammen,

paast zum Thema, deshalb "häng" ich mich mal dran:
wir besitzen ebenfalls diese Schnittstelle und benötigen eine dynamische Analogausgabe - ist dieses ebenfalls über diese Karte realisierbar und wenn, wie?!

Danke!

MFG

Hallo LindePaul,

ja ja, so klein ist die Welt... Habe den Thraed hier vor ein paar Tagen begonnen bzw. wieder aufgegriffen. In der Zwischenzeit haben aber meine zwei Kollegen, die sich ebenfalls mit dem Thema auseinandersetzten, hier weitergemacht. Wir "teilen" uns sozusagen den Benutzer da wir immer zusammen an den Roboterprojekten arbeiten. Und auf ihren letzten Beitrag hin haben sie mich mal angesprochen - ist ja echt ein Ding!

Haben jetzt einiges an Infos hier und am Telefon gesammelt und werden das mal alles nachher direkt vor Ort überprüfen - müssen leider immer ein Stück fahren bis zum Roboter ... geben aber eben bescheid was sich so getan hat.

MFG

T.Schulz

Hallo Hermann!

Es erfolgt ein Aufruf der Ini:

Zu Beginn des Programms "BAS (#INITMOV,0 )" und vor jeder PTP-Fahrt "BAS (#PTP_PARAMS,50)" (wobei hier die 50 wohl für 50% von max. entspricht). Aber ich verstehe nicht warum auf einmal die Geschwindigkeit so im Keller ist - und das mit Auswirkungen auf alle Programme - wie gesagt mindestens Faktor 10. Konnte denn das Programm aus CamRob die Default-Werte überschreiben?

MFG

Keiner eine Idee welche DEFAULT-Einstellung dafür verantwortlich ist?

Hallo Zusammen,

erstmal vielen Dank für die vielen Ratschläge!

Die Einstellung CVEL=100% haben wir übernommen und die Beschleunigungsfaktoren mal angepasst:
$ACC.CP=10
$ACC.ORI1=1000
$ACC.ORI2=1000
$ACC_MA.CP=10
$ACC_MA.ORI1=1000
$ACC_MA.ORI2=1000
das Ganze auch in der config.dat (wir ich NIEMALS draufgekommen !!!!).

Die Bewegungen sind auch schon viel flüssiger geworden, noch nicht ganz der Hit, denke aber wir können mit arbeiten.

Haben also mal das erst übersetzte Programm aus Kuka Cam-Rob eingeladen und abfahren lassen. Soweit so gut, nun ist aber irgendwas passiert:
Die Geschwindigkeit hat sich rapide verringert! Sind vorher (auch bei den von Hand programmierten Programmen) immer mit $CP.VEL=0.01 vefahren - das entspricht ja 10 mm/s. Doch plötzlich ist diese Geschwindigkeit viel geringer geworden, und das in allen Programmen! Man sieht kaum noch das der Roboter sich bewegt. Woran kann das liegen? Hat das Programm aus Cam-Rob irgendeine Einstellung verändert, die für ALLE Programme gilt? Müssen inzwischen mit mindestens 0,1 verfahren, also Faktor 10!!! Jemand eine Idde?

MFG

ich glaube den kleinsten Abstand kann man gar nicht pauschal sagen... wir verfahren auf einer Kontur mit ständigem Neu-Ausrichten des Roboters. Der wird auch nur extrem langsam wenn eine ständige Neu-Ausrichtung erfolgt, z.B. bei Spitzen auf dem Bauteil.

Die Punkte kommen direkt aus Kuka Cam-Rob. Zuletzt waren es knapp 1400 für eine Strecke von ca. 600 mm. Aber davon fielen wohl annähernd 90% auf eine Strecke von 50 mm, eben an diesen kritischen Stellen. Durch die Einstellmöglichkeiten beim Reduzieren der Punkte kommen wir locker unter 500. Wir benötigen jetzt nicht so die riesige genauigkeit, allerdings sollte der Werkzeeugweg schon erhalten bleiben.

Wie läuft denn das mit einer "Spline"?

MFG

Arbeiten mit Kuka Cam-Rob, die niedrigste Einstellung für das Reduzieren der Punkte betrug soviel ich noch weiß 1,3 mm.

Haste vllt nen Tipp für Werte der Beschleunigungs-Variablen? Nur so nen Richtwert...

Hallo Zusammen,

dieser Thraed ist zwar schon was her, ich greife ihn aber doch noch mal auf weil wir vor einer ähnlichen Frage stehen:

wir verfahren zum Teil sehr komplexe Wege mit einer Vielzahl von Punkten und das Einhalten der Bahngeschwindigkeit ist dabei eine Katastrophe Haben schon fast alles probiert, mit C_DIS gehts fast gar nicht und mit C_VEL ist es auch kein großer Unterschied - auch bei $APO.CVEL=100 ...
Wir haben die Möglichkeit die Anzahl der Punkte zu beeinflussen und sie mal drastisch auf ein echtes Mininum gedrückt - ohne wirklichen Erfolg, wobei die Genauigkeit der Bahn stellenweise nicht mehr tragbar war. :angry:
Bei einer sehr großen Anzahl von Punkten steht das Werkzeug sogar an manchen Stellen - und das bei $APO.CVEL=100

Das ganze Schauspiel findet auf einen KR16 L6 KS mit einer KRC2 statt.

Hat jemand vielleicht noch eine Idde? Kann man das Überschleifen eventuell noch in einer weiteren Variablen beeinflussen, abgesehen von den drei bekannten ... ?!

Sind dankbar für jeden Tipp!!!

MFG

Hallo nochmal,

so, es ist soweit alles verkabelt, allerdings funktioniert eine Sache noch nicht: Die Ausgänge Out1 und Out2 am X12 werden nicht geschaltet. Die Anzeige der digitalen Ausgänge zeigt dieses aber an und durch "OUTW0=0" in der iosys.ini sollte es doch funktionieren, oder?! Zudem haben wir mal den Pin 57 vom X12 (+24 V - GRP. 0) durchgemessen - kommt keine Spannung an.

Müssen wir vielleicht erstmal 24 Volt am Pin 57 anlegen? Wenn ja, wo kriegen wir die innerhalb der Steuerung denn her?

Nochmals für jede Hilfe!

MFG

Hallo nochmal,

haben inzwischen schon den Personenschutzkreis miteinbezogen - aber Interrupt wäre natürlich auch ne super-Idee gewesen

In der IR_STOPM.SRC finde ich folgende Bedingung:

IF $STOPMESS==TRUE THEN
BRAKE
ENDIF

Wenn wir die um "$OUT[1]=FALSE" erweitern dürfte es doch schon reichen... , oder ?!?!

MFG

OK, sagen wir lieber Konfigurieren statt Programmieren.

"OUTW0=0" sind also Ausgänge $OUT[1] bis $OUT[16]. Aber wie verklicker ich der Steuerung jetzt das ich z.B. mit $OUT[10]=TRUE den physikalischen Ausgang OUT1 am PIN 93 vom X12 setzten will? Das raff ich einfach nicht... :-|

MFG