Beiträge von Fred Clever

Guten Morgen Glöckler,

die Eigenschaft"%NOLOCKGROUP" eben im KAREL Programm.
Bedeutet, dass das KAREL keine Bewegungsgruppe blockiert und somit auch keine Bewegungen durchführen kann...

Also ich würd mir mal den ganzen KAREL-Quelltext mit "Debugger"-Meldungen vollschreiben. Mindestens eine Ausgabe pro Zeile... =D
Damit Du einmal verstehst, was genau gerade in der Steuerung passiert, wenn der Roboter sich bewegt (er bewegt sich sicher nicht "einfach so" =) ).

Wenn Du die Programme einzeln startest? Verhält sich der Roboter dann auch so seltsam? (Also z.B. nur das KAREL starten, ohne "Hauptprogramm"...)

Ist glaub recht schwierig hier herauszufinden, wo der Fehler sitzt, zumindest ohne die Programme zu testen (mit ganze vielen "WRITE"... =D ).
Wie schon erwähnt, prinzipiell sehe ich hier auf den ersten Blick nirgends eine Möglichkeit, warum der Roboter sich bewegt...

Gruß
Fred

Guten Morgen,

also ob es eine Doku für "Auto Singularity Acoidance" gibt, weiß ich leider auch nicht.
Was ich aber weiß ist, dass die Option tatsächlich selbsterklärend und super-einfach ist.

Im Prinzip bekommt man in den "Details" der Programme eine weitere Seite, auf der man "Auto Singularity Avoidance" auf TRUE/FALSE stellen kann. Mehr isses nit. =)
(Ok es gibt dann eben noch weitere Möglichkeiten den Roboter in Hand zu verfahren; JGFRM / S, TOOL / S, USER / S...)

Also eigentlich benötigt man fast keine Doku. =)

Gruß
Fred

Hmm.... verdammt... eigentlich hat das KAREL ja "%NOLOCKGROUP" als Parameter...
Trotzdem hab ich keine Ahnung was dieser KCL-Befehl und der CNCL_STP_MTN-Befehl bewirkt, schon gar nicht wenn die beiden hintereinander kommen... =)

Hallo Glöckler,

hmm...ist jetzt erstmal natürlich schwierig sich da reinzudenken.

Jetzt nochmal kurz zum Verständnis:
Obwohl beim Roboter ausser dem Programm "GrstTask" im Hintergrund KEIN ANDERES Programm läuft bewegt sich die Mechanik?

Falls ja, dann MUSS es an dem Hintergrundprogramm liegen, eine andere Möglichkeit gibt es nicht. =)

Wenn ich mir nun das KAREL genauer anschaue, sieht es auf den ersten Blick tatsächlich recht harmlos aus.
Jedoch bin ich mir bei einigen Befehlen etwas unsicher:
Was genau soll der KCL-Befehl bewirken? Soll damit das aktuelle Programm abgebrochen werden?
Wenn ich die Beschreibung in meinem schlauen Buch richtig verstehe, wird der aktuelle Befehl im genannten Programm ge"skipped", ergo übersprungen bzw. ausgelassen.
Falls Du das akutelle Programm abbrechen möchtest benutz einfach den "ABORT prog"-Befehl, ohne "KCL"

Im gleichen "IF"-Block wird dann noch der "CNCL_STP_MTN"-Befehl verwendet.
Den habe ich bisher auch noch nie irgendwo gesehen und musste deshalb auch erstmal nachschlagen.
Laut Handbuch werden mit dem Befehl alle angehaltenen Bewegungen abgebrochen, aber nur in dem jeweiligen Programm und es werden die nächsten Befehle ausgeführt.
Um ehrlich zu sein, werd ich aus der Beschreibung nicht besonders schlau... =D Daher einfach die Frage: Was möchtest Du denn mit dem Befehl bewirken?

Dass das Verhalten sporadisch auftritt könnte z.B. daran liegen, dass die Ursache genau in diesem "IF"-Block liegt und das Programm hier nicht immer "reinkommt"?!
Müsste einmal getestet werden.

Was passiert denn, wenn Du das Backgroundprogramm aus einem anderen Programm startest?
Was zeigt denn der Programmstatus für das UP an? Oder ist das Programm dann schon beendet=

Prinzipiell ist es kein Problem beim Fanuc Programme im Hintergrund aufzurufen. Jedoch sollte man mit KAREL und Roboter-Bewegungen vorsichtig sein.

Gib bescheid, falls Du noch etwas Neues dazu hast.

Gruß
Fred

Hallo masterky1,

also entweder Du schreibst die einzelnen bits als binäre Zahl und wandelst diese dann in eine Dezimalzahl um oder Du kombinierst die einzelnen DIs in einen Gruppeneingang, der macht Dir das Umwandeln von binär in dezimal im Prinzip.

Das Umwandeln musst Du relativ kompliziert in TPE (oder KAREL) selbst programmieren, der Rest ist dann einfach R[y] = Wert bzw. PR[z, x] = Wert...

Viel Erfolg noch.

Gruß
Fred

Hallo Glöckler,

wenn der Eingang rechtzeitig da ist fährt der Roboter ganz normal, wie wenn die WAIT-Anweisung gar nicht da wäre.
Wobei mit "rechtzeitig" natürlich auch noch der Vorlaufzeiger mit einberechnet werden muss (es reicht nicht, dass der Eingang gerade kommt, wenn der Roboter an den Punkt gelangt, dann wird er wahrscheinlich abbremsen...).

Falls der Roboter auf den Eingang warten muss, bin ich mir nicht ganz sicher, entweder er fährt den Punkt FINE an oder er würde eben den Punkt überschliffen anfahren aber dann an der entsprechenden Position warten (also nicht an der programmierten Position sondern an der überschliffenen Position, je nach CNT-Wert).

Was meinen die anderen? Fährt er FINE an? Oder wartet er an der überschliffenen Position?

Gruß
Fred

Hallo Glöckler,

muss auch noch kurz meinen Senf dazugeben.

Ich bin mir nicht sicher, ob der Vorlauf beim Fanuc überhaupt verändert werden kann (auch nicht über SysVars).
Der Bahnplaner schaut generell immer drei Positionen (Punkte? Zeilen? Bin mir da nicht sicher...) voraus, schon allein, um die Beschleunigung der Achsen zu berechnen.

Wie heini0707 aber schon gesagt hat gibt es dafür dann die "TB" und "DB" Bewegungsoptionen. =)

Gruß
Fred

Aloah,

nur noch kurz mein Senf dazu... =)

Prinzipiell bekommt man mit jedem Roboter vier Handbücher:

Roboter Bedienerhandbuch --> Installation, Konfiguration, Spezifikation, Montage, Greifermontage usw...
Roboter Wartungshandbuch --> Wann, wie, was muss am Roboter gewartet werden...
Steuerung Wartungshandbuch --> Wartung der Steuerung und Installation, Konfiguration... (Quasi Bediener und Wartung in einem Handbuch)
Applikationssoftware Bedienerhandbuch --> Wie wird programmiert, wie wird die Software eingestellt/konfiguriert, Fernsteuerschnittstelle...

Es stimmt schon, dass man bei gewissen Dingen erstmal nicht weiß wo man nachschauen soll.
Aber wenn man sich ne Weile mit den Handbüchern beschäftigt (bzw. beschäftigen muss =P) bekommt man schon ein Gefühl dafür wo was stehen könnte.

Trotzdem gibt es natürlich u.a. dieses Forum für Fragen jeder Art.
Es gibt keine dummen Fragen, nur dumme Antworten. =)

Gruß
Fred

Hallo heini0707,

das "alte" KAREL wird sich vom Neuen wahrscheinlich kaum unterscheiden. Es werden höchstens ein paar Routinen hinzugekommen sein.
Das Grundprinzip wird sich hierbei nicht verändert haben.

Aber Dein "Compiler" wird Dir dann sagen, wenn Du eine zu neue Funktion verwendest... =)
Wie gesagt denke ich aber nicht, dass es da Probleme geben wird.
(eine neue Routine, die mir jetzt gerade einfällt und neu dazugekommen ist, ist z.B. das Auslesen der "String-Register"...)

Das KAREL Handbuch solltest Du aber bei Fanuc direkt bekommen. Bisher hab ich ohne Probleme immer die neuste Version bekommen.
(sollte mal wieder nachhaken, ob es wieder ne aktuellere Version gibt... ^^)

Gruß
Fred

Hallo Biele,

solange Du noch die Original-Masterdaten hast, der Roboter mechanisch nicht verändert wurde und die Batteriespannung nicht unterbrochen wurde musst Du im Prinzip gar nichts rechnen. Da reicht es immer die Masterdaten einzutragen ($Mastercount...) "MasterDone" auf TRUE zu setzen und zu kalibrieren.

Falls der Roboter seine "Pulse Coder" Werte verloren hat musst Du die Masterdaten an einer anderen Stelle eintragen, den Roboter auf 0° fahren und einen "Quick Master" durchführen. Beim "Quick Master" rechnet die Steuerung dann mächtig in der Gegend herum.

Sie nimmt die aktuellen Weggeberwerte und teilt diese durch die Anzahl Pulse pro Motorumdrehung (fünf-hundert-schlagmichtot-tausend).
Die Stellen vom Ergebnis vor der Null sind quasi die Anzahl der Motorumdrehungen und eher uninteressant, die Nachkommastellen multipliziert mit den Pulsen/Motorumdrehung ergibt dann die Stellung des Weggebers zur Nullposition (Scheibenstellung).

Danach wird die gleiche Rechnung mit den original Masterdaten durchgeführt, nur dass diesmal die Nachkommastellen weggestrichen werden und die "ganzen Umdrehungen" berücksichtigt werden.

Mit beidem zusammen kann sich der Roboter dann seine Masterung wiederherstellen.

Aber prinzipiell muss man nie selber rechnen, die Steuerung ist schlau genug und macht das für einen. =)
Falls ich irgendwas durcheinander gebracht habe, dürft Ihr mich sehr gerne korrigieren!

Gruß
Fred

Hallo Robojoey,

klar kannste das machen. Es gibt jetzt hierfür zwei Möglichkeiten:

1. Du konfigurierst eine Zusatzachse für den Roboter. In Roboguide fügst du ein CAD-Modell als "Maschine" ein, diesem gibts Du dann einen "Link".
Auf diesen "Link" legst Du Dein Bauteil und verknüpfst das Modell dann mit Deiner Zusatzachse (unter dem Reiter "Motion"). Nun kannst Du mit der Zusatzachse das "Förderband" steuern.
Ist im Endeffekt ein wenig kompliziert und ungeschickt...

2. Du fügst in Roboguide wieder eine "Maschine" ein und gibst ihr wieder einen "Link". In den Eigenschaften des "Link" kannst Du dann unter dem Reiter "Motion" auch eine Bewegung via "I/O" einstellen. Hier kannst Du dann einen (bzw. mehrere) Ausgang definieren und auch zwei Positionen dazu (also eine Position für Ausgang aus und eine für Ausgang ein).
In dem Reiter kannst dann auch noch einstellen, dass die "Maschine" dem Roboter eine Rückmeldung geben soll, wenn die erwünschte Position erreicht ist.

Ich hoffe das hilft, viel Spass beim basteln. =)

Gruß
Fred

Hallo Lameda,

welche Fehlermeldung bekommst Du denn genau? Joint Speed Limit, Motor Speed Limit oder Motor Speed excess?

Bei den ersten beiden Fehlern würde, wie hermo bereits gesagt hat, empfehlen die Positionen umzuprogrammieren bzw. einfach die Geschwindigkeit in der Bewegung herunterzusetzen. Hier schafft eine Achse / ein Motor die programmierte Geschwindigkeit nicht und die Bewegung wird heruntergeregelt.

Gruß
Fred

Hallo Vfbflo,

wollte auch noch kurz meinen Senf dazu geben.

Von Fanuc gibt es übrigens auch eine (zwei) Schnittstelle(n) für Visual Basic, PCDK (und Robot Interface).
Hierbei handelt es sich sozusagen um "DLLs", die sicherlich auch in andere Sprachen importiert werden können.

Aber im Prinzip bist Du mit KAREL auf jeden Fall freier und hast mehr Möglichkeiten.

Gruß
Fred

Hallo Hermann,

anbei die Datei.
Darin sind im Prinzip die Numerischen Schlüssel zum gesamten I/O-System der Steuerung gelistet.

Viel Spass damit. =)

Gruß
Fred

Hallo roboluter,

ist mit "Depart" nicht sowas wie der Bewegungsbefehl INC gemeint?
Mit INC addiert der Roboter den Wert im Punkt auf die aktuelle Position.

z.B. steht im Punkt mit dem INC Bewegungsbefehl X: 100, Y: 0, Z: 0, W: 0, P: 0, R: 0,
dann fährt der Roboter von seiner aktuellen Position eben 100 mm in X-Richtung.

Weiß jetzt nicht, ob ich den "Depart" Befehl richtig verstanden habe...

Vielleicht hilfts ja. =)

Gruß
Fred

Hallo SMA,

in meiner kleinen aber feinen Sammlung steht dazu:

FILE-062 Backup files are not correct

Cause: The backup file is not correct.
Remedy: Try performing the file backup operation to another device, or use another media type.

Also nicht wirklich viel Information dazu... -.-
Du kannst einmal versuchen die MC vorher direkt über den Roboter zu formatieren und danach nochmal ein Backup darauf ausführen, vielleicht hilft das ja.

Gruß
Fred

Hallo privet199,

bei meinem Roboguide ist nur eine virtuelle Steuerung für V5.22 mit dabei.
Ob man die Steuerungen irgendwo runterladen kann bzw. ob es die überhaupt gibt weiß ich leider nicht.

Jedoch hab ich einmal den Tipp bekommen im Backup des Roboters in der "Backdate.dt" einfach die Softwareversion zu ändern.
Zumindest bei einem Backup mit V6.30 (o.ä.) hat dies wunderbar funktioniert.

Natürlich hab ich keine Ahnung, wie sehr sich der Roboter dann in Roboguide verändert, wenn Du aus V5.21 --> V5.22 machst.
Aber ich bin mir auch nicht sicher, wie "fein" die ganz "alten" Steuerungen in Roboguide überhaupt sind. =D
(wenn man mit V5.30 ein Video dreht sieht man ca. alle 90° ein Bild ^^)

Gruß
Fred

Hey PA,

also wenn Du in KAREL den Zusatz "IN CMOS" oder "IN SHADOW" schreibst werden die Variablen im permanenten Speicher abgelegt und bleiben bei einem Neustart der Steuerung samt Wert erhalten.

Beim Zusatz "IN DRAM" oder "IN DRAM UNINIT" (o.ä.) sind sie im flüchtigen Speicher abgelegt und gehen beim Ausschalten der Steuerung verloren.
(wobei ich mir bei "IN DRAM" und einem "Hot Start" nicht sicher bin, ob dann Variable + Wert erhalten bleibt...warum sonst gäbe es "IN DRAM UNINIT (o.ä.))

Standardmäßig werden Variablen immer im DRAM abgelegt (also wenn Du nichts dahinter schreibst) ausser Du verwendest dieses "%CMOSVARS" bzw. "%SHADOWVARS" (oder so...) dann werden alle im permanenten Speicher abgelegt.

Gruß
Fred

Hallo bucmat,

soweit ich weiß kannst Du nicht direkt in die Achssteuerung des Roboters eingreifen.

Nach meinem Wissensstand kannst Du zwar mit KAREL alle möglichen Bewegungen erzeugen, erstellen, generieren, aber diese muss man immer über einen Bewegungsbefehl in KAREL oder TPE starten (also ein "Standard"-Bewegungsbefehl der dann irgendwas und irgendwie mit den Daten macht; wobei dieser meist besser über TPE laufen sollte, da der Bahnplaner von KAREL wohl schon ein wenig veraltet ist)

Ich bin mir auch nicht sicher, ob bzw. wo der Bahnplaner seine Daten in den Systemvariablen hat.
Und ich bin mir auch nicht sicher, ob Fanuc diese Daten rausgeben würde...

Gruß
Fred

Hallöle,

geb auch noch meinen Senf dazu.

Um den INSTALL-Anwender zu entfernen kann man wie remote geschrieben hat einfach die Passwörter deaktivieren.
Jedoch kann man dies auch im normalen Betrieb tun, nicht nur im "Controlled Start" oder mit einem "Init-Start".

Einfach auf Menü --> Setup --> Password. Dort kann man irgendwo die Passwörter deaktivieren (also alles).
Dazu muss man sich aber im Vorfeld als INSTALL anmelden, danach sind dann alle Benutzer weg und die Passwörter deaktivert.

Gruß
Fred