Beiträge von Hermann

Hallole,
diese Problematik ist mir auch nicht ganz unbekannt.
Noch besser wird es, wenn man statt Distance=0 ein Distance=1 vor dem letzten Befehl im Programm hat, dann macht der Roboter den Trigger manchmal, aber meistens dann lieber doch nicht.
Mit einem Delay=-0.1 kann man die Situation etwas entschärfen, funktioniert dann aber immer noch nicht zu 100 Prozent.

Und noch etwas, bei den neueren Robotern scheint mir noch ein neues Problem aufgetaucht zu sein.
Folgende Situation:
Am Ende des Programms ein:
'Trigger when distance=1 delay=-0.1 do variable=1

Am Anfang des folgenden Programms ein :
'Trigger when distance=0 delay=0 do variable=2

Es scheint so, als ob die Trigger nicht korrekt ausgeführt werden. D.h. dass der zweite entweder gar nicht, oder vor dem ersten ausgeführt wird.

Der INI-Teil wird eh schon immer übersprungen, damit kein Vorlaufstop stattfindet.

Tschau,
Hermann

Hallo,
die 'Doku' liegt im Moment leider nur in Papierform vor.

Muss ich mal danach fahnden (vielleicht find ich's noch) und wenn ich Zugriff auf einen Scanner hab einscannen.

Kann also noch eine Weile dauern (bin ab morgen bei einer Inbetriebnahme, also wird's mindestens kommendes Wochenende).

Tschau,
Hermann

Hallo,
ja genau, soweit ich weiss gibt es da keine Doku. Es gibt nur ein paar wenige Leute bei Kuka, die sich da auskennen. Ich habe mal eine kleine inoffizielle 'Doku' bekommen. Das waren zwei A4-Seiten mit einer Liste der unterstützten Funtionen inclusive rudimentärer Parameterbeschreibung. Der Rest: Ein kleines Beispielprogramm und jede Menge Versuch und Irrtum.

In der Zwischenzeit habe ich da recht vieles damit gemacht: unverselle Oberfläche, mit Fehlerausgabe, -protokollierung, Parametereingabe, Parameterauswahl aus Datenbank, Benutzertasten für Handfunktionen, Start, Halt bei Taktende, Benutzerführung, Passwortveraltung für Funktionsverriegelung, Offline Punkteänderung anhand von Bildern der Werkstücke. Und jetzt kommt der Hammer:

Ab der Betriebssystemversion 5.xx gibt es diese Schnittstelle nicht mehr! Daher lohnt sich eine Einarbeitung wohl nicht mehr so richtig.

Jetzt fängt der ganze K(r)ampf von vorne an .

Ab Version heisst das ganze 'KRC-Interface', basiert 'natürlich' irgendwie auf .NET. Aber auch dazu gibt es selbstverständlich (Stand von vor ca. 5 Wochen) keine offizielle Doku (inoffiziell habe ich da auch nichts). Man solle sich da an den techn. Support in Gersthofen wenden, und dort vielleicht einen kleinen 'Privatkurs' buchen, war damals die Aussage eines freundlichen Kuka-Mitarbeiters.

Das einzige das ich bisher gefunden habe sind zwei kleine Beispielprogramme auf den neuen Robotern. Hatte aber bisher entweder gerade keine Zeit, oder keinen freien Roboter zur Hand um mich näher damit zu beschäftigen.

Wäre auch über jede Info dazu dankbar.

Tschau,
Hermann

Hallole,
hatte mal Kuka-Sim (Pro) als Testversion unter den Fingern. Das taugt zur Zugänglichkeitsprüfung ganz gut. Ist recht einfach zu bedienen aber nicht gerade spottbillig.

Mit der PRO-Version kann man sich sogar eigene Komponenten (auch Roboter) zusammenbauen.

Das habe ich testweise mal mit einem ABB-Roboter gemacht. D.h. man kann dann mit dem Kuka-Simulationspaket einen ABB-Roboter simulieren (Ob das so gewollt ist ). Ist aber recht aufwändig, und nirgends so richtig dokumentiert (wie so oft).

Tschau,
Hermann

Hallole,
da fällt mir doch spontan noch eine weitere Möglichkeit ein:

Die Variablenliste, die man über Anzeige - Variable - Übersicht - Anzeigen aufrufen kann. Da kann man bis zu 10 Seiten mit jeweils 10 Variablen (glaube ich) einrichten, in denen man die Parameter eintragen könnte. Vor dem Programmstart muss man dann eben diese Liste öffnen und die Daten eintragen.

Die Liste selber erstelle ich normalerweise mit einem Editor (fällt mir persönlich leichter) und nicht mit dem eingebauten Konfigurator.
Die Datei, in der die Einstellungen gemacht werden heisst Configmon.ini und befindet sich unter C:\KRC\Roboter\Init\

Sonst fällt mir da nix mehr zu ein, ausser man programmiert selber was in C, Pascal oder VB, das über das sogenannte KRC-Interface (ab V.5.x ) oder Crosscomm.exe (bis V4.x) die Parameter abfragt und auf den Roboter überträgt. Das ist dann aber schon wieder was für hartgesottene.
Ausserdem kenne ich mich da auch nur bei Crosscomm.exe aus. Zu der neuen Schnittstelle KRC-Interface suche ich gerade selber noch nach Infos.

Apropos: Hat hier vielleicht jemand eine Ahnung wie man das programmiert?

Tschau,
Hermann

Hallo,

So was in der Art gibt es tatsächlich.
Ist aber meiner Meinung nach nicht sonderlich gut gemacht, und eines der grössten Mankos bei den Kuka-Robotern.

Normalerweise ist auf jedem Roboter dieses Programm MSG_DEMO.src zu finden,
Dort sind einige Beispiele aufgeführt. U.a eine Möglichkeit die Softkeys zu benutzen,
Wenn man dann z. Bsp. eine Zahl abfragen möchte, dann muss man sich eine Krücke über die Softkeys basteln, um eine vorgegebene Zahl in 1er, 10er 100er Schritten zu erhöhen/verkleinern...
Die Anzeige erfolgt dann jeweils in dem Meldungsfenster am unteren Bildrand.

Eine andere Möglichkeit habe ich bisher noch nicht gefunden (Ausser über OPC, HMI und weiss nicht was noch alles, das dann aber immer zusätzlich Geld kostet).

Tschau,
Hermann

Naja, mit dem einfachen Ja ist es doch nicht getan:

Parameter kann man wie 'üblich' nach dem Programmstart über die digitalen E/A's übergeben/einlesen.

Oder man liest die Paramter schon im SPS.SUB vor dem eigentlichen Programmaufruf über dig. Eingänge ein, dann kann man diese natürlich auch dem aufgerufenen Programm übergeben,

Tschau, Hermann

Hallole,

Bei LIN_REL / PTP_REL muss der Roboter aber schon auf dem Bezugspunkt stehen.

Wenn man den Teachpunkt vorher nicht anfahren will/kann, dann lautet der entsprechende Befehl bei Kuka:

LIN {X 0, Y 0, Z 300, A 0, B 0,C 0 }:XP1
Oder
LIN XP1:{X 0, Y 0, Z 300, A 0, B 0,C 0 }

Dabei heisst der Punkt im Inlineformular P1.

Erste Zeile sollte das selbe sein wie MoveL Offs, die zweite sowas wie MoveL Reltool (....). Das ganze aus'm Gedächtnis ohne Gewähr, könnte also auch genau andersrum sein.

Tschau,
Hermann

Hallole,
von Kuka gibt es da nichts vernünftiges.
Aber OPC ist ja ein allgemeingültiger Standard. Der von der OPC-Foundation herausgegeben wird.

Über den Suchbegriff 'OPC Foundation' bei Google sollte sich da einiges rausfinden lassen.

Vor langer Zeit habe ich da selber ein/zwei Tage rumgesucht, bis ich alles beisammen hatte. So aus dem Stand heraus bekomme ich das auch nicht mehr zusammen.

Aber ich habe damals eine kleine ActiveX-Komponente gefunden, mit der man ganz einfach auf die OPC-Objekte zugreifen konnte.

Bei Interesse kann ich da mal danach fahnden.
Das ganze basierte damals aber noch auf OPC Version 1.0. Soweit ich weiss sind die bei KUKA jetzt auch bei Version 2.0 angelangt.

Wenn ich mich noch recht erinnere sollte es da von der OPC-Foundation eine DLL geben, mit der der Zugriff auf den OPC-Server sehr einfach relaisert werden kann.

Tschau,
Hermann

Den Fall hatten wir vor kurzem an einer KRC2.
Zumindest da gibt es die Möglichkeit über einen Registry-Eintrag die Speicheraufteilung zu ändern, dann geht's wieder mit den grossen Programmen.

Den Registry-Eintrag kann man bei der KUKA-Hotline erfragen.

Ich weiss aber nicht, ob das auch schon bei der KRC1 geht.

Tschau,
Hermann

Das selbe kann's ja nicht sein.
Aber vom Prinzip her hört es sich so ähnlich an:

Repli-Programm, standardisierte Anzeige der E/A's...

Da haben die PSA-Menschen halt auch für KUKA-Roboter einen eigenen Standard gebastelt. Was ja an sich keine schlechte Sache ist.

Eine Frage: Wie habt ihr Euch den da eingearbeitet? Gibt es da tatsächlich Kurse, Doku, oder was weiss ich was? Wenn es da was gibt, dann sollte es vermutlich für die KUKA's genau das selbe geben. Vielleicht hilft das ja bobby37 weiter.

Tschau, Hermann

Ahja,
das kommt mir alles ein klein wenig bekannt vor.

Aber nur im Zusammenhang mit ABB-Robotern. Da gibt es auch so einen
PSA-Standard, mit dem sich hier in Deutschland kein Mensch auskennt.

Angeblich gibt es da eigene Schulungen bei den Franzosen.
Vielleicht gibt es die auch für die KUKA-Version.

Praktische Erfahrungen damit habe ich leider (oder vielleicht auch zum Glück) nicht, einen Roboter sollten wir mal programmieren, und haben den dann einem französischen Programmierer überlassen. Der Einarbeitungsaufwand ist da doch ziemlich gross.

Tschau, Hermann

Hallole,
wir hatten hier auch schon tschechische, französische und spanische KRC2's. Da gab es ausser bei der tschechischen (da lief einiges nicht (namentlich die Archivierung), selbst der Kuka-Service hat da einen Tag lang rumgebastelt) eigentlich keine grösseren Probleme.
Mit etwas Fantasie was die Sprache angeht kommt man da eingentlich recht weit.

Bei uns war da alles wie gewohnt in der deutschen Version, nur die Menütexte waren halt anders.
Allerdings hatten wir die genannten Programmpakete nicht installiert.
Wo liegt denn genau das Problem?

Tschau, Hermann

War ja nicht so gemeint,
wollte nur meine Erfahrungen mitteilen.

Auch ich habe da nur die Auslösung der Grundstellungsfahrt, Taskverwaltung und ständige Überprüfung von Eingangssignalen in Karel programmiert, für sowas ist das Zeug ganz gut zu gebrauchen.

Alles andere wurde dann auch mit der herkömmlichen Spagetti-Code-Sprache ertellt.

Kann mir nicht helfen, aber es kommt mir alles so ABB-S3-mässig vor, wobei der Datenaustauch mit dem PC über die Flash-Disk oder das Netzwerk schon mal eine Erleichterung darstellt.

Tschau, Hermann

Hallole,
Also bei den beiden Robotern, die wir im vergangenen Jahr 'verarbeitet' haben war dokumässig alles dabei, zumindest hat's mir gereicht.

So richtig empfehlen kann ich das KAREL-Zeugs auch nicht.
Die Programme sehen zwar aus wie bei ABB und KUKA und funktionieren tut's auch, aber:

Programme müssen im Editor erstellt werden und dann compiliert werden. Das geschieht entweder offline mit kostenpflichtiger Software oder auf dem Roboter mit (soweit ich weiss kostenpflichtiger) Option.
Wenn man compilierte KAREL-Programme hat, dann laufen die ohne Aufpreis auf dem Roboter (so war's jedenfalls bei unseren Robotern).

Das Debuggen gestaltet sich schwierig, da man auf dem Roboter das KAREL-Programm nicht sieht. Da kann man nur starten und dann sehen was so passiert, und sich dann hinterher Gedanken machen warum und wieso.

Punkte teachen ist auch so eine Sache: da legt man Variable an und teacht die dann, oder man erledigt das über die Positiosregister. Also nichts mit Programm schrittweise ausführen und dann die entsprechenden Punkte teachen, oder mal kurz noch eine Bewegung einfügen oder löschen. Das erfordert jedesmal einen neuen Compilerlauf.

Naja, dann viel Spass beim 'KARELieren'

Tschau Hermann

Hallo,
dazu die Punktedefinition im .DAT-File von E6POS auf Frame ändern.
Dabei natürlich die überzähligen Komponenten ab S aus der Definition
entfernen.

Damit könnte es dann klappen.

Tschau

Hallole,

die Variable $robruntime sollte das verraten.

Tschau.

Also ich würde mich auf diese Zeitreise nicht so sehr freuen.

Das zweizeilige Display ist meiner Meinung nach nicht das Problem.

Hier mal meine Eindrücke der S3 (hatte vor kurzem mal wieder
das zweifelhafte Vergnügen):

-Spagetti-Code vom Feinsten. Es wimmelt nur so von
Labels und Goto's. Nach zwei Tagen rumwühlen
in einem Palettierprogramm mit Fehlerbehandlung ...
hat man da Knoten im Hirn.

-Unterprogramme sind einfach durchnummeriert.

-Punktenamen? Fehlanzeige

-Variable sind durchnummeriert.

- TCP ordentlich vermessen? Fehlanzeige

-Offline-Programmierung? Ist möglich, wenn man so ca.
8000 Öre locker macht (weiss aber nicht ob das OLP-Paket
tatsächlich noch zu kaufen ist).

Naja, dann viel Spass mit den ollen Kamellen.

Das dachte ich auch schon mal und hab mich zwei/drei Tage damit beschäftigt.
Das Ergebnis ist zwar halbwegs brauchbar, aber auch nicht ganz so, wie ich mir
das vorstelle.
Das ganze endet mehr oder weniger in einem halben Compiler, in dem eigentlich
nur noch die Codeerzeugung fehlt.

Realisiert wurde das ganze mit Lexx, Yacc und Delphi.
Ist dann aber schnell wieder eingeschlafen, da ich in letzter Zeit weniger mit ABB-Robotern zu tun habe.

Tschau, Hermann

Ja genau,
eigentlich ist das Programm CELL.src völlig unnötig.
Genau so gut kann man ein eigenes Programm anwählen und dann
per Automatik Extern starten. Das Programm sollte dann
als Endlosschleife angelegt sein.

Eine andere Möglichkeit wäre sich im SPS.SUB selber was zu basteln,
wo man dann aufgrund bestimmter Signale das gewünschte Programm
aufruft (Beispielaufruf von CELL.SRC ist in jedem SPS.SUB drin).

Wird so zum Beispiel bei Daimler Chrysler in Sindelfingen gemacht.
Roboter in Grundstellung fahren, Programm abwählen, Automatik Extern
anwählen, dann geht es mit der Leitsteuerung weiter.

Tschau,
Hermann.