Beiträge von Hermann

$pos_int ist nur innerhalb eines Interrupts sinnvoll zu verwenden.

Wenn ich die Aufgabe richtig verstanden habe, dann sollte

merkpos = $pos_act

funktionieren.

Müsste passen, ist der allgemeine Fall.
Da hier Spezialfall müsste auch passen:

versatz = $nullframe
versatz.x = breite_palette
versatz.y = laenge_palette
base_neu=base_alt : versatz
base_neu.a=base_neu.a+180

Dafür gibt es die Dateien:

Menukeyuser.ini und Softkeyuser.ini

Die Suchfunktion hier im Forum serviert da einige Beispiele.

Das bringt nix.
Denn das Überschleifproblem taucht im Interrupt auf.
Da muss man dann schon im Ablegen() nach Brake F den $Advance hochsetzen.
Das sollte auch funktionieren, daher auch meine erste Bemerkung mit dem Verfrachten der Bewegungen in das Hauptprogramm.

Kamera mit analogem Ausgang fällt mir gerade keine ein.

Aber als Denkansatz mit der IFM-Kamera:
ein Toleranzfenster festlegen, bei dem es kein Problem gibt --> dig. Ausgang 1 --> alles ok Teil Greifen und umsetzen.
Toleranzfenster mit Abweichung in die eine Richtung --> dig. Ausgang 2
Toleranzfenster mit Abweichung in die andere Richtung --> dig. Ausgang 3

bei Ausgang 2 oder 3 Teil greifen und verdreht wieder ablegen --> Vorgang neu starten.

Blöd wär's wenn sich das Teil erst während des Greifens dreht, was schon auch mal vorkommen kann.

Häufig muss sich da eine Achse sehr schnell drehen, die ist dann Schuld an der Misere.
Vielleicht fast Strecklage, so dass sich Achse 4, 5 oder 6 sehr schnell drehen müssen.

Evtl. mal mit dem 'Oszilloskop' (ich meine das Tool von Kuka) die Ströme der
einzelnen Achsen aufzeichnen, da könnte man dann vielleicht sehen welche Achse das
Problem verursacht.

- Punkte zu dicht aufeinander,
- aktuell eingestellter Überschleifradius zu groß
- aktuell eingestellter Überschleifradius == 0

Aber $advance muss auf jeden Fall größer 0 sein, sonst kann's gar nicht gehen.

Und schon haben wir es:

$advance = 0
verhindert das Überschleifen wirkungsvoll.
Da sollte dann schon mal mindestens
$advance = 1 stehen.

Ist natürlich blöd, weil da mit resume gearbeitet wird.
Ohne jetzt das Programm komplett analysiert zu haben
denke ich mal es wäre besser (da man dann $advance wieder höher setzen kann),
das meiste Zeug, das im Ablegen() steht in's Hauptprogramm zu verfrachten (nach dem Aufruf von Ablegen())
und im Ablegen nur die Bewegung zu stoppen, die aktuelle Position
abspeichern und sofort mit resume rauszuspringen,

Da muss man wieder mal die Glaskugel befragen.
Etwas mehr Infos sollten da schon noch kommen:
Fehlermeldungen, Verhalten beim Fahren, fährt er gar nicht?
Vielleicht noch einen etwas größerer Programmausschnitt posten.

Die Ursachen können da vielfältig sein. Das meiste dürfte Dir da die Hotline schon gesagt haben.

Wenn man die Variable $STOPNOAPROX auf TRUE setzt, dann stoppt das Programm an der nicht überschleifbaren Stelle.
Such mal hier im Forum nach Stopnoaprox, da gibt's jede Menge Tips.

Die zwei Bewegungen mit 180 Grad sind schon richtig,
den Stop bekommt man mit Überschleifen weg.

ptp_rel{A6 180} C_PTP

Ich mach es normalerweise mit 3 mal 120 Grad, hatte bei 180 Grad ab und zu auch noch seltsame Phänomene.

Ja da gibt es immer Abweichungen.
Am besten man trägt das Gewicht von Hand ein, und lässt nur die Trägheitsmomente berechnen.

Das Gewicht lässt sich normalerweise auch recht einfach bestimmen, wenn man vor der
Montage am Roboter daran denkt das Ding auf die Waage zu legen.

Meiner Erfahrung nach ganz wichtig vor der Lastdatenermittlung: Roboter warmfahren, und zwar richtig warm,
nicht nur 2 / 3 Minuten.

Also ich hab' da auch manchmal gewisse Schwierigkeiten in der Fanuc-Doku eine bestimmte Info zu finden,
obwohl ich genau weiss, dass ich schon mal was darüber gelesen habe.
Daher kann ich solche Fragen manchmal schon nachvollziehen.

Die Doku-Leute der Roboterhersteller sollten mal ein Praktikum bei uns machen,
und jeden Tag mindestens 3 Infos suchen müssen. Nach einer Woche hätten die nur
noch graue Haare auf'm Kopf. Info's verstreut über hunderte PDF-Dateien, oder wie bei Fanuc
teilweise dann noch in hmtl-Dateien. Wer soll da in angemessener Zeit etwas finden?

Ja, so sieht es aus,
das habe ich eben jetzt auch gefunden.
Wenn man im CMD-Tool auf die Anschaltbaugruppe geht, rechte Maustaste -> Prozessdaten dann gibt es da eine
Spalte Zuordnung, und da kann man die Reihenfolge festlegen.
Da muss dann bei der BK die 0 stehen, bei den DI/O's der entsprechende Offset. Und bei der DSQ kann irgend ein Fantasiewert stehen (bei mir 896).
Muß ich damals wohl auch so gemacht haben, Alzheimer läßt grüßen.

Ich habe da nicht wirklich viel Erfahrung und es ist alles schon recht lange her.
Soweit ich mich noch erinnern kann habe ich normalerweise mit dem CMD-Tool die Bustopologie eingelesen,
und dort nichts mehr verändert.
Dann habe ich die E/A's halt so genommen wie sie waren. Wen juckt's wenn's denn funktioniert?
Ob da ein Bit bei Nummer 1 oder 18 ankommt ist doch Jacke wie Hose.

Hallo,
so auf den ersten Blick sieht alles ok aus.
Nur bei der Busklemme beginnen die E/A's bei 9 und nicht bei 1?
Ist alles schon recht lange her, aber soweit ich mich noch erinnern kann sind die Zuordnungen physikalischer Eingang - Eingangsnummer in der EIO.cfg
etwas durcheinandergewürfelt. D.h. wenn eine LED leuchtet, dann mal alle Eingänge durchsehen, ob nicht irgend einer auf 1 steht.

Bei den Ausgängen: Separate Versorgung angeschlossen?

Hallo,
im Anhang ist ein kleines Beispiel: Screenshot aus IBS-CMD und Ausschnitt aus EIO.cfg.
Das dürfte teilweise sogar genau Deiner Konfiguration entsprechen.

Dabei sind die E/A-Einheiten nicht nur der Buskoppler, sondern auch die daranhängenden Module auf dem Lokalbus.
Da unterscheidet sich die Konfiguration des Interbus doch deutlich vom Profibus.

Hinweis zum Post von Sven: Bei der S4C wird auch der Profibus-Master noch nicht über das Softing-Tool konfiguriert, da darf man in der EIO.CFG wilde Einträge machen,
um dann hinterher festzustellen, dass z.Bsp. die modernen Murr-Module MVKP usw. nicht funktionieren. Ist halt alles schon etwas betagter

Da gibt es eine Beschränkung.
Mit der Festplattenkapazität hat das allerdings nichts zu tun.
Das Roboterbetriebssystem VXWorks und alle Programme/Daten befindet sich komplett im Arbeitsspeicher, und der ist nunmal begrenzt.
Man kann den verfügbaren Speicher über einen Registry-Eintrag etwas erhöhen, aber auch da ist dann irgendwann Schluß.

@Rama83:
Warum so böse?
Sollte nur ein gutgemeinter Rat für die Zukunft sein.
Das gilt für alle Karten, die da mitgeliefert werden und im Roboterbetriebssystem selber genutzt werden.

Ist auch weder notwendig noch hilfreich irgendwas von der Siemens-CD auf dem Roboter zu installieren.
Das Roboterbetriebssystem bzw. ein entsprechendes Softwarepaket von Kuka bringt alles notwendige mit.