Beiträge von EricH

Bei JMF kannst du die Werte manuell eintragen, statt kopieren. War zwar nicht gefragt, hat aber auch eine gewisse Daseinsberechtigung.

Also zu hohes Drehmoment bedeutet grundsätzlich erstmal, dass Kräfte auftreten, die nicht erwartet sind. Check mal die Lastdaten, ob die in Ordnung sind.

Offsets und Reltool gehen tatsächlich nicht direkt von der Station aus, nur über Controller. Genauso auch MoveGO etc. Alle die nicht MoveJ, MoveL oder MoveC sind, werden nicht ausgeführt.

Ich glaube ABB würde das evtl. mal patchen, wenn das Thema genug Aufmerksamkeit bekommt.

https://forums.robotstudio.com…hronize-to-station-movego

Gerne mal upvoten, wenn ihr das auch haben wollt und die Funktionen, die ihr in der Station ausführbar haben wollt mit dazu schreiben. Der Upfeed ist nur wegen movego.

Es gibt das Add-In Worldzones. Visualisiert aber leider nur die simplen Formen, keine Achsenzonen. Das wäre gerade bei schrägen Zonen interessant, weil die Box immer 90° zur Welt steht und damit nicht geeignet ist.

Meistens startet das Program in der Cell.src

Hängt davon ab wie stark dein CAD Modell mit Einzelteilen verkettet ist, weil er glaube bei Nearest Object die ganze Hierarchie durchsucht. Wäre zumindest meine Theorie dazu.

Da stellt sich auch noch die Frage, wieviel Toleranz denn der Vakuumgreifer mit sich bringt und wie genau die Leitpaste in Position liegt, wo es aufgenommen wird. Es gibt da ne Menge zu beachten.

Ok, danke für den Tipp. OrangeEdit sieht echt gut aus im Vergleich zu WorkVisual, deutlich praktischer.

In meinem Fall ist es etwas komplizierter. Und Ja, wir haben Probleme mit dem TCP, weil die Mechanik des Greifers, es nur mit Ach und Krach schafft das Teil vernünftig zu greifen. Der Kunde lässt nur ne ziemlich kleine Greiffläche zu und die Ablagen verschrammen die Dichtflächen bei kleinsten Abweichungen. Gleichzeitig sorgt eine nur leichte Verkantung in der Ausrichtung des Teils zu Verklemmungen.

Gleichzeitig werden 4 Teiletypen auf 1/4 des Greifers gegriffen. 4 weitere Teiletypen auf dem nächsten 1/4 und und 2 Teiletypen verteilen sich auf den restlichen Vierteln des Greifers. Heißt, wenn irgendwas schiefläuft und es ne Verbiegung gibt, dann müssen wieder im Worst Case die anderen 3-9 Teiletypen gecheckt und korrigiert werden. Leider wurde der Greifer schon des öfteren verbogen.

Jetzt wollen wir den TCP von einem Greiferpin auf das äußere Ende des gegriffenen Teils legen. Dadurch können wir die Ausrichtung des Teils schneller parallel zur Ablage ausrichten und Zeit sparen.

Hermann Die Punkte werden referenziert auf TOOL und BASE gespeichert. Heißt sobald sich eins im Wert ändert und man will trotzdem den selben physikalischen Ort befahren, muss man die Punkte entsprechend anpassen, oder ist das bei KUKA anders gelöst?

Hallo geehrte Programmierkollegen,

ich bin gerade nicht so im Saft beim KUKA. Weiß zufällig jemand, ob man nach Neudefinition eines TCP, die Punkte die über dieses TCP genutzt werden entsprechend neu berechnen kann? Gibt es da eine aufwandsarme Funktionalität?

Ich weiß, dass es bei ABB die Funktion "Adjust Robtargets" gibt.

Beste Grüße

Logische Zusammgehörigkeit. Ich schätze mal weil sie zum selben "Projekt" zugeordnet sind und beide in der gleichen Zelle sind.

Sind die Robbis vom selben KRC gesteuert? Falls ja, sollten bei Lieferung schon beide im selben Projekt drin sein.

Zitat von woodys

Hmm nicht unbedingt….

Im Moment erstelle ich da meine Programme offline ohne dass ich an der Maschine sein muss bei neuen Produkten….

Spiele es ein und fertig

Wenn das bei dir läuft, dann gut. Aus meiner Sicht ist es eben nicht so praktisch. Ich habe sehr komplexe Aufgaben und viele unvorhergesehene Probleme mit Simpro. Wenn man z.B. Punkte kopiert, dann werden zwar neue Punkte deklariert, aber teilweise alte Zusatzdaten weiter verwendet. Um nur mal einen Punkt zu nennen.

Dann gibs das Problem, dass beim import des an der realen Welt angepassten Programmes, einfach völlig falsche Tools und Bases verwendet werden usw.

Für mich entsteht da einfach deutlich mehr Aufwand als bei RobotStudio.

Moin!

Hier ist ne Liste, die Modelle sind ja auch öffentlich einzusehen:

Wirklich nützlich ist in meinen Augen Simpro aber nur für Erreichbarkeitsprüfungen und Taktzeitanalysen. Eine Vorlage für die reale Maschine lässt sich nur schwierig erstellen.

ABB hat da die Nase vorn.

Zitat von Robo_Sim78

Hallo Erich!

Ich denke das hängt davon ab, wann du die Bedingung auslesen musst.

Bei mir ist die Bedingung schon viel früher gesetzt, wodurch es kein Problem gibt.

Vielleicht wurde bei dir die Bedingung zu früh abgefragt?

Nee, also das war so, dass der Robbi erstmal auf Freigabe von SPS warten sollte und auf die hat er dann nicht mehr gewartet. Die Freigabe dürfte zu dem Zeitpunkt nicht aktiv gewesen sein. Ist aber auch schwer nachzuvollziehen welche Signale zu dem Zeitpunkt wie geschalten waren (Fehler ist aber nach dem Löschen vom CONTINUE nicht mehr aufgetreten). Gibs da eigentlich ne Möglichkeit zur Auswertung von Signalen zu Zeitpunkt x?

Danke Martl, fehlt tatsächlich der Aufruf in der sps.sub

SJX die Ausgänge wurden grundsätzlich softwaretechnisch nicht geschalten. Also, nur per ansteuern über "Wert" in der EA-Ansicht konnte man schalten.

Hallo,

hatte schonmal jemand das Problem, dass zugeordnete Ausgänge nicht geschaltet werden? Vorraussetzungen sind deaktiviert. Ansonsten alles normal zugeordnet.

Ich kanns verstehen, die Taktzeit hat immer ne hohe Priorität nach der Funktionalität und letzte Prio hat leider immer die Übersichtlichkeit und Lesbarkeit des Codes.

Ich machs immer so, dass ich die Lesbarkeit verbessere, wenn sich mal die Zeit ergibt.

Hast du keine Probleme mit dem CONTINUE Befehl?

Ich habe jetzt die Erfahrung gemacht, dass er die Bedingung garnicht mehr prüft, was ich völlig verrückt finde.