Beiträge von Programmiersklave

Jetzt werden wir gemeinsam verklagt....

$CIRC_TYPE=#PATH macht die bahnbezogene Orientierungsführung möglich.

$ORI_TYPE=#CONSTANT nagelt die Orientierungsführung fest, bei CIRC_TYPE==#PATH eben an der Kreisbahn (an der Startsituation). Wird nur selten verwendet, da es halt alle Koordinatenrichtungen betrifft.

Die älteren Dokus hatten da vier Bildchen, die alle vier Möglichkeiten illustrierten, wenn Du irgendwie die 5.4-Doku kriegen kannst.... ich hoffe, ich tu' mir kein Leid an wenn ich das hier paste....

*.tar ist ein Archivformat. 7zip...

Zitat von SuS

Die Punkte werden auf Interrupt geteached, sobald ich jedoch das Unterprogramm öffne und nochmals die gleiche Base zu initialisieren, verschiebt es mir den Mittelpunkt.

Ich fürchte, das musst Du noch deutlich ausführlicher erklären, besser mit Code. Was wird wann wo eingemessen, wie entsteht das Base und wodurch und was meinst Du mit Mittelpunkt?

Zitat von Hermann

Noch was. Bei dünnen Blechen ist es üblich einen Doppelblechsensor einzusetzen, damit man nicht versehentlich zwei zusammenklebende Bleche erwischt.

Und damit wären wir schon bei den Antworten, zu denen Towelie1110 noch gar nicht die Fragen kennt

Gibt auch recht viele mit IO-Link wie den hier:

https://www.leuze.com/de-de/ods9l2.8-l6x-450-m12/50137822

Auf KRC4-Seite muss man dann einen (unterstützten) Koppler von EtherCat nach IO-Link haben. Bei KRC2 vielleicht über DeviceNet nach https://www.beckhoff.com/de-de…kommunikation/kl6224.html , keine Ahnung, wie gesagt, das ist die größte Lücke.

Die zu überbrücken ist aber nichts, was man mit einer bestimmten Ausbildung mitbekommt, das ist nervtötende Fummelei, trial and error und Lesen der Dokus.

Die Frage geht in die falsche Richtung.

Dies mit einem binären Signal zu erledigen ist normalerweise anspruchsvoller, von den Basics her (Interrupts etc.). Es gibt heute messende Lasertaster, die Dir echte Zehntelmillimeter als Ganzzahl auf einen Bus schieben und zur Erkennung des Umstandes, dass sie selbst im Zweifel oder außerhalb ihres Meßbereiches sind, ganz konkrete Zahlenwerte am Grenzbereich verwenden. Kein Hickhack mit A/D-Wandlern, kein Theater mit Fehlinterpretationen von Rampen, keine Rechnerei, einfach nur ein Gruppeneingang an der KRC und alles ist gut.

Ich empfehle, Laberautomaten wegzulassen und stattdessen die Dokus und Spezifikationen zu lesen.

'Nen relativ großen Spalt gibt es zu überbrücken, wenn es darum geht, die Komponenten zu verbinden, Stichwort Buskoppler und deren Konfiguration. Da kommst Du aber so oder so nicht drumherum, und kann erst geklärt werden, wenn man weiß, was der Roboter haben wird oder haben soll.

Und dann kommt noch eine Lücke, weil Du möglicherweise noch nicht die Fragen kennst, deren Antworten Du bräuchtest, um eine Anlage zu konzipieren, die nicht nur unter optimalen "geradeaus"-Bedingungen funktioniert, sondern auch Fehler erkennt und behandelt. Da wirst Du wohl Lehrgeld bezahlen müssen, aber am Ende wird's laufen.

MaxBlackfield : Zwischen DefFrame, DefDFrame und DefAccFrame ist sicher was dabei... aber...

ich rate Dir dringend davon ab, beim ABB ein weit entfernt liegendes Koordinatensystem zu verwenden, und mit weit entfernt meine ich auch schon den Fahrzeug-Null beim Automobilbau. Ist zwar nice, wenn sich die Ergebnisse aus dem Meßraum 1:1 ins Roboterprogramm übertragen lassen, aber da darf es auf den Millimeter nicht ankommen.

Der Grund ist, dass die Datenstruktur wobjdata für Koordinaten und Quartenionen seit jeher "num" verwendet, und die ist m. W. immer noch ein 32-Bit-Float. Bei 'nem 5 Meter entfernten Nullpunkt kriegst Du massive Probleme, mit ausreichender Genauigkeit irgendwas zu berechnen. Geschweige denn, definierte Punkte auf der Vorrichtung in diesem Koordinatensystem genau genug einzumessen.

Glaub's mir, ich hab's probiert....

Wenn Du da nichts teacht kannst Du mit $BASE machen was Du willst. Und hinterher auch wieder in eine der vorbestimmten Datenschachteln schreiben.

Hat man ja gelegentlich, dass man komplizierte Messungen machen muss und dann irgendwelche Verschiebungen und Verdrehungen bekommt, die man als Zwischenergebnis benutzt, um auf diesem Base dann wieder weitere Verschiebungen und Verdrehungen zu messen.

Ich hatte mir nur zwischendurch angewöhnt, bei komplizierterem Kram BAS(#BASE,...) gar nicht mehr zu benutzen und nur noch direkt zu berechnen und zuzuweisen, gerne auch mit der Doppelpunkt-Frame-Verknüpfung. Das ging dann vor ein paar Jahren plötzlich in die Hose...

Zitat von Lukas Braun

falls die aber doch mal wer benutzt, wird diese von meinem Programm überschrieben. Das gefällt mir nicht.

Das ist aber ein grundsätzliches Problem. Man kann dem Base ja einen aussagekräftigen Namen geben. Wer es dann trotzdem benutzt, braucht sich nicht wundern.

Möchte gerne einen virtuellen Kuka haben und bekomme auf My.Kuka für OfficeLite 17 Treffer angezeigt.

Ich verstehe die KSS Versionsnummer.

Ich glaube zu verstehen, dass "U" nur Upgrades sind.

Was "MK" heisst, ist vermutlich irrelevant, da überall.

Annehmen tu' ich, dass "DL" Download bedeutet und "USB" heisst, dass man ein Päckchen bekommt.

Aber was heisst "F" und "N"?

Und wenn ja, welche Version verbindet sich mit KukaSim, falls mir später einfällt, das auch haben zu wollen?

Meine Güte! Warum steht das nicht dran? Kauft man da die Katze im Sack oder muss man immer erst den Kundenberater auf einen Cappucino einladen? Oder bin ich dort im Shop ganz falsch? Schließlich steht an WV ein Preis von 200 € dran und trotzdem ein Downloadlink.... Ich raff's nicht.

Bitte beachten: wenn Du $BASE direkt überschreibst (was problemlos funktioniert) geht bei den jüngeren Systemen (weiss nicht ab welcher Version) das Teachen in diesem Base nicht mehr. Es wird dann nicht in dem gleichen Frame geteacht, wie der, in dem gefahren wird, was unter ExpertTech u. U. gefährlich wird.

Je nachdem, was Du vorhast, ist es daher die bessere Idee, BASE_DATA[16] oder so als temporäres Berechnungsergebnis zu überschreiben und das dann zu verwenden, auch wenn es ein Schritt mehr ist.

Zitat von fubini

Da gibt es keine Garantien wo der Roboter kartesisch lang fährt.

Allerdings galt m. W. immer der heilige und unverletzliche Grundsatz, dass der Kuka bei allen Overrides GLEICH fährt - das heisst, keine andere Bahn fährt, wenn man lediglich den Override ändert.

Wenn man nun feststellt, dass sich der Roboter geschwindigkeitsabhängig "verfährt", lässt das doch eigentlich nur den Schluß zu, dass die Bahnplanung überlastet ist oder die Mechanik nicht mit den Annahmen der Steuerung übereinstimmt (Lastverhältnisse).

Die Stimmgabel am Greifer impliziert, dass SafeOperation im Spiel ist, um so unverständlicher. Denn die sollte ja merken, dass der Robbi nicht auf der Bahn ist.

Wäre gespannt zu erfahren, wie das bei Euch aufgelöst wird...

Bei richtiger Konfiguration brauchst Du kein Programm dafür schreiben, die Verknüpfung der Koordinatensysteme wird von der Steuerung korrekt umgesetzt.

Steht in der $config.dat eine vernünftige Maschinenkonfiguration unter

DECL MACHINE_DEF_T MACHINE_DEF[16] ?

Zitat von AtoK09

Ihr könnt auch "einfach" die Uhrzeit korrekt einstellen, dann ist's auch ok!

Bleibt ja nicht synchron auf Dauer.

Aber der Tip von DS186 scheint geholfen zu haben. Danke sehr!

Hi,

weiß einer, wie ich das loswerde?

Hab die Uhr am PC um 6 Minuten vorgestellt, dann ging's wieder. Das ist doch Quark, was mach' ich denn bei mehreren Robotern in einer Zelle, die alle zeitlich auseinanderlaufen?

Programmiert hast Du dieses Ding (X ist rechts, Y oben), zweimal rum, einmal als Kreis (mit CA), einmal oval (der zusätzliche "schräge" Punkt ist nicht von Dir, sondern den brauchte ich, weil FAMOS kein CA kennt, liegt aber bahnrichtig).

Wahrscheinlich ist das egal, ich kenne das TP nicht, und die erste und letzte halbe Umdrehung ist vielleicht nur die Anfahrbahn. Die C_DIS dürften auch noch eine Rolle spielen.

Aber unabhängig davon ist es eher unwahrscheinlich, mit einem fetten Kuka auf Anhieb reproduzierbar runde Vollkreise mit 1cm Durchmesser zu bekommen.

Die abgeflachte Stelle ist immer gegenüber des Nahtendes und dieses wiederum immer Richtung Mitte des Teils, daher gehe ich davon aus, dass Du das Futter drehst, und die Punkte in immer derselben Raumorientierung liegen.

Bei Vollkreisen mit konstanter Orientierung in der Ebene macht jede der 6 Achsen zwei Richtungsänderungen. Das muss die Mechanik erst einmal hergeben - tut sie meist nicht. Ich würde hier versuchen, für die anderen drei Punkte dieselben Voraussetzungen zu schaffen wie für den ersten, was ungefähre Lage und auch die großräumige Anfahrbewegung angeht. Ist die Ebene mit den 4 Punkten horizontal angeordnet? Wo steht der Roboter relativ zum Nahtende?

Das über BASEs zu machen scheint in diesem Programm eher blöd zu sein, schließlich will VA-B geteachte Punkte als Grundlage nehmen, und das BASE ist eh schon beschäftigt. Und gewonnen wär' damit eher nichts, zumindest nicht bei konstanter Orientierung.

Die Idee, das so machen zu wollen, ist nicht durchdacht, sage ich mal.

In diesem Fall muss nämlich die SPS wissen, welches Programm angewählt ist und warum, und man müsste ihr die Möglichkeit gewähren, das Programm auch abwählen zu können, denn ein fälschlich angewähltes Programm wäre dann ihr Problem (bedeutet: zusätzlicher Kommunikationsaufwand). Im Normalfall wird ein unterbrochenes Programm nicht abgewählt und kann fortgesetzt werden, die beschriebene Vorgehensweise sorgt aber für die Not, das laufende Programm immer finalisiert zu haben. Das wird eine endlose Quelle des Frustes, weil einem immer wieder zur Unzeit das Programm abgewählt wird. Bis dass Du das erste mal einen Fehler im Roboterprogramm verfolgen kannst, hast Du zigmal die SPS umprogrammiert und drölf Crash gefahren, weil der Roboter zwangsweise "von vorne" anfängt.

Das letzte Mal, als ich das machen musste, blieb CELL fast leer und verwies lediglich auf "haupt()".

CELL ließ sich anwählen, wenn umgeschaltet wurde und nichts angewählt war, so wie üblich, und die Maschine blieb ansonsten für immer im Programm.

Da dieses Programm sein Produkt über einen Barcode auch noch selbst herausfinden musste, geschah ein ganze Menge in haupt(). Und irgendwann kam ein String von der SPS (die paar Zeichen kann man durchaus auf der IO-Schnittstelle abbilden), und ein Bestandteil war eine Nummer, mit der ich in einem Unterprogramm namens "tabelle()" eine SWITCH-CASE-Verzweigung aufrief. Und die verteilte dann auf Unterprogramme, oder warf einen Fehler, wenn es den Eintrag nicht gab.

Einrichter musste also nur in "tabelle" editieren. Und da war weiter nichts drin ausser eben dies.

Der Einrichter muss sowieso ein bestehendes Modul kopieren und dabei umbenennen, wenn er ein neues Programm braucht. Das ist für ihn das Einfachste, da braucht man nichts vorbereiten. Und dann öffnet er "tabelle.src" und fügt die Verzweigung ein. Wenn er das nicht hinkriegt, sollte er auch nicht teachen dürfen.

Der fortgeschrittene Einrichter wird abseits des Automatikbetriebes dann sogar wissen, wie er die Anlage dazu zwingt, ein völlig anderes Programm mal eben zwischendurch teachen zu können, ohne die SPS erst davon überzeugen zu müssen, dass er das jetzt will.

Also: weniger Arbeit für den Einrichter. Weniger Frust für den Bediener. Weniger Arbeit für Dich.

RawBytes mit Umweg über Strings ist ja auch irgendwie doppelt übersetzt. Ich weiß jetzt gar nicht auswendig, wieviel Byte ein ABB num (ohne d) belegt, aber 'ne Zielposition (7 num) sollte damit auf jeden Fall gehen.

Zitat von CSaE1990

Habe ich realistische Chancen, als Nicht-Elektriker in einen derartigen Job hineinzufinden?

Ich würde sogar sagen, als erfahrener Konstrukteur hast Du einen Vorteil, zumindest was die Sparte im Anlagenbau betrifft.

Dort geht es ganz oft darum, den Prozess zu verstehen. Die Logik-Programmierung ist eine Sache, die Prozess-Programmierung eine ganz andere. In meiner alten Firma ging das manchmal bis zur Arbeitsteilung - einer machte die Logik, und ein anderer programmierte den Prozess.

Aber nicht immer stehen zwei zur Verfügung, also besser alles können. Und da kommen Fähigkeiten ins Spiel, beurteilen zu können, wie etwas geht und wie nicht, und das dann dem Roboter so beizubringen. Und selbst eine oberflächlich triviale Aufgabe kann gewaltige Reinfälle bereit halten, erst recht dann, wenn die Roboteranlage einen Arbeitsplatz ersetzen soll, der normalerweise von einem Facharbeiter ausgefüllt wurde.

Klar ist das möglich. Aber Du solltest es Dir ja nicht selbst unnötig schwer machen.

Die Routine, die den eigentlichen Ablauf macht, kannst Du außerhalb des Roboters durchdenken, schreiben, und dann reinladen. Das geht deutlich einfacher mit einem guten Editor auf einem PC. Kannste aber auch auf dem Panel zusammenstoppeln.

Auf der Partition D: im Roboter findest Du außerdem die Software "WorkVisual" (angemeldet als mindestens Experte), und die, auf einem Windows-PC installiert, kann Dir bei dieser Programmierung ebenfalls helfen. Einfach den Ordner auf einen USB-Stick kopieren und dann von diesem auf dem PC installieren.

Am Ende würde dann etwas rauskommen, wo Du den einen Startpunkt teacht oder einfach den Roboter manuell an diesen Punkt fährst, vielleicht noch ein paar Parameter eingibst, und das Ganze dann startest. Programmtechnisch ist das kein Problem.

Du solltest hier allerdings klarstellen, ob Du Dir das nun - ohne Vorkenntnis - komplett für lau im Forum erklären lassen willst. Das artet dann nämlich in Arbeit aus.

Hast Du denn schon das Tool eingemessen? Einen Automatikablauf?