Beiträge von Dos6.2

Im Prinzip reicht es doch aus, den Schlüssel zu ziehen. Dafür ist er ja da *fg*. Und ja ich weiss, dass der immer dann weg ist,wenn er gebraucht wird. Oder plötzlich jemand von einem andern Roboter den Schlüssel klaut oder gar keiner mehr weiss, wo der Schlüssel hin ist.
Und weil man dann immer in Automatik ist, könnte man sogar über die SPS den Roboter verfahren lassen. Mit Taste hoch plus x 1 cm und runter taste - 1 cm runter auf einem OP. Geschwindigkeiten und Koordinaten vorgeben wäre dann auch möglich usw.
Aber alles sehr viel aufwendiger, als die Leute richtig zu schulen.

Aber wo genau verstellen die, die Koordinatensysteme. Im Programm? Das kannst du ja mit einem Schreibschutz versehen. Weil das ist doch dem Roboter egal, ob die in Hand mit World rumfahren. In Automatik, stellst du ja wieder alles so wie du es willst.

Und die Sache mit der sps.sub. Das bekommen die sicher schnell raus, wie man die ausstellt.

Nun da fehlen einige Details.
Wie ist die Verbindung zum Messprogramm, Profibus, Ethernet, Devicenet oder sogar E/A Verbindung?
Wie genau ist der Fehler, ist es ein KUKA Systemfehler, weil zB der Profibus weg ist oder ein Programmfehler?
Wer ist Master, falls es Profibus ist.
Und wer hat das Programmiert? Derjenige der es programmiert hat, sollte ja wissen, was das für ein Fehler ist.
Am besten wird es sein einen Experten kommen zu lassen, der das umprogrammiert bzw. euch dann berät.
Kostet zwar etwas, aber dann habt ihr jemanden an der hand. Über das Forum kann man sehr schwer so einen Fehler lösen. Mal ganz davon abgesehen, dass wir ja nicht mal wissen, ob du das ändern darfst. Vielleicht bist du ja ein Bediener der ohne erlaubnis vom Cheffe das überbrücken will, damit mehr Teile rauskommen
Leider alles schon erlebt. Vorallem im zusammenhang mit Messmaschinen wenn zuviele niO teile herauskommen.

Es müsste doch gehen, dass du in der eio.cfg die beiden Baugruppen rausnimmst oder hast du das schon versucht?

Mit dem ET200 dürfte wohl, eher nicht gehen. Weil die Profibuskarte und das E/A Modul sind über den Devicenet mit dem Roboter verbunden. Das Profibus Modul ist dann nichts anderes wie ein Gateway zwischen Profibus - Devicenet.
Zumindest wurde es mir so erklärt und macht auch von der Art des Anschlusses sinn.
Ich glaub erst bei den neuen Steuerung hat mach richtige Profibussteckkarte.
Und ich meine auch, dass man darum nur bei den neuen so einen Key braucht. Bei den alten kann ich mich nicht an sowas erinnern. Aber bin jetzt nicht der Experte darin. Und habe auch zu selten diese Karten/Module selber eingebaut bzw. ausgebaut.

Wenn du sagst, die Punkte werden 3d angezeigt dürfte da sicher bedarf sein. Weil man so schön sehen könnte, wo liegen die Punkte.
Ist immer dann notwendig, wenn jemand fremdes an die Anlage muss um Punkte zu teachen.
Auch für die Bediener, die eher selten mit Roboter arbeiten ist sowas nicht schlecht. Die können sich oft sehr schwer vorstellen, wo die Punkte im Raum liegen.
Noch besser wäre noch die Möglichkeit sowas in 2d umzuwanden, um damit zB eine Doku zu schreiben.

Wobei dann die Frage ist, du stellst da sicher nur in World geteachte Punkte da?
Wie sieht es mit Punkten in einer Base aus, wie würde die Dargestellt. Die Base im Bezug zum Ursprung Roboter und dort die geteachten Punkte. Sowas wäre auch nicht schlecht.

Von daher beantworte ich mal deine beiden Fragen

Ja. Bedarf gibt es sicher, vorallem wenn das Programm nicht viel kostet. Weil nicht jeder Chef bereit ist, die teure CAD 3d Anwendung zu kaufen nur um Punkte anzuzeigen.

Und die Anwendung wäre zur Dokumentation einer bestehenden Anlage und der Schulung von Bedienern.

Tja da hast du m ich auf eine Idee gebracht. Wenn ich mal mehr zeit habe, werde ich das auch versuchen, um mal wieder in C# zu Programmieren.

Wie WolfHenk schon schrieb geht es nur mittels Vektorrechnung also mit Doppelpunktoperator. Der Vektor den du ausrechnest geht von deinem Fräser zum Messpunkt Laser.
Dieser Vektor geht mittels dem Roboter sicher zu berechnen.
Dürfte in der Theorie so gehen, irgendwo einen Punkt aufmalen. Dann den Fräser auf diesen Punkt fahren in World teachen und danach den Laser auf diesen Punkt fahren. Und dann über Vektorrechnung den Vektor errechnen.
Ist aber nur kurz überlegt. Bin auch nicht der Freak in Sachen Vektorrechnung.
Im Schweispaket von KUKA gibt es sehr viele Rechenoperationen zB Skalarprodukt usw. Eventuell brauchst du das auch noch. Zumindest kann man sich die Sachen dort einmal anschauen.
Habe damit einmal ein Basevermessungsystem angefangen zu programmieren. Vermessen wurde mit einem Lasersensor. Dort war es auch wichtig, die Orientierung herauszubekommen.
Hat sogar ganz gut Funktioniert. Vorallem dank dem Tip von WolfHenk mit dem Doppelpunktoperator.
Das machte die Sache deutlich einfacher.

Wird die Automatik Extern Schnittstelle genutzt?

An der v5.5 kann es nicht liegen, habe damit erst vor einem Monat eine ET200 als Master in einen KUKA integriert.
Das die LDB Datei stimmt, erkennt man daran, dass die simulierte Profibus LED in der Anzeige vom KUKA rot ist.
Bist du auch sicher, dass der Stecker auf der richtigen Seite der Karte steckt? Hatte es auch schöner öfters, dass die Elektriker den falsch gesteckt haben. Und es steht ja nicht drauf was Master und Slave ist. Nur an den LEDs zu erkennen und an dem Aufkleber EX der wohl für Slave steht.
Was auch falsch sein könnte, du hast im Siemens den Slave projektiert und nicht den Master, dann geht es auch nicht. Passiert schnell, weil die fast gleich heissen.
Hast du zum erstellen der LDB einer der Anleitungen aus dem Forum genommen? Weil wenn man sich daran hält, stimmt die Datei auch und es kann nur noch an der Verkabelung liegen.

Bleibt der Zeiger nur stehen? Oder ist das Programm wirklich im stopp.
Was ich mir nur vorstellen könnte, der Conveyor ist noch auf eine alte Bewegung getriggert und wartet jetzt bis die Bewegung in seinen Arbeitsraum kommt.
Sowas ähnliches hatte ich schon bei einem Adept Roboter, der stand vor dem Band und hat ewig gewartet.

Als erstes prüfen, ob die DC LED am ET200 grün leuchtet. Und blinken und vorallem rot darf auch keine der anderen LED sein.
Falls du ein Profibusmessgerät hast, gleich das nutzen und schauen, ob Verkabelung stimmt und die Adresse vom ET200 richtig gefunden wird.
Der Abschlusswiderstand kann auch am ET200 eingestellt werden, auch prüfen, ob da nichts doppelt ist.

Ich muss leider sagen, dass es doch meistens die Hardware, Verkabelung oder sehr oft Stecker sind, die dafür sorgen, dass der Bus nicht läuft. Daher messe ich immer recht schnell mit dem Gerät durch.

Sehr beliebter Fehler, Kabel im Stecker verdreht.

Wegen dem nicht erkennen. Manchmal hilft es, den/die USB Sticks woanders reinzustecken bzw. untereinader zu tauschen. Ich musste einmal sogar 3 reinstecken, damit der mit den keys richtig erkannt wurde.

Das steht in der Doku, sollte also so gehen mit dem Path = -20

Mit Strecke geben Sie die gewünschte Entfernung vom
nach dem Trigger programmierten Zielpunkt an.
Ist dieser Zielpunkt ein überschliffener Punkt, so gibt
Strecke die gewünschteEntfernung der Schaltaktion von
der dem Zielpunkt am nächsten liegenden Position des
Überschleifbereichs an.
Der Schaltpunkt kann durch eine negative Strecke bis
zum Startpunkt vorgezogen werden. Ist der Startpunkt ein
Überschleifpunkt, so kann der Schaltpunkt bis zumAnfang
des Überschleifbereichs verschoben werden.
Mit einer positiven Angabe von Strecke ist eine Verschiebung
bis zum nächsten nach dem Trigger programmierten
Genauhaltpunkt möglich.
Die Einheit ist Millimeter.

Das DISTANCE=20 sollte doch so gar nicht gehen oder? LAut Doku kann man doch nur 1 und 0 nehmen (0 für Startpunkt 1 für Endpunkt). Oder wird 20 als 1 interpretiert?
Wenn man eine Entfernung will sollte man doch WHEN PATH nehmen?
Haber bisher kaum Trigger benutzen müssen. Und in der letzten Anlage dann doch und da ist mir das aufgefallen, weil ich am Anfang DISTANCE = 0 hatte und dachte das wäre dann 0 mm vom Endpunkt weg. Habe dann festgestellt, dass er immer im Startpunkt Triggert und nochmal genau in der Doku nachgelesen.

Also mir würde es schon reichen, wenn der Override immer zu bedienen ist. Egal ob Todmannschalter gedrückt mit und ohne Starttaster. Finde es immer nervig, dass ich den Todmannschalter loslassen muss um mal eben die Geschwindigkeit zu ändern.
Besonders ärgerlich, wenn man Punkte abfährt (Einzelschritt gedrückte Starttaste) und man will für den nächsten Punkt die Geschwindigkeit ändern. der Roboter ist aber schon auf dem Punkt. Dann wird aus dem Override die X Richtung bzw. Achse 1. Da kann es schnell passieren, dass man den Roboter verfährt. Ja ich weiss man muss nur den einen Finger loslassen. Aber es nervt schon etwas.
Das gleiche beim reinen Handverfahren. Da würde ich auch gerne während dem fahren schon die Geschwindigkeit runternehmen. Geht aber nicht, weil Override nur ohne Todmannschalter zu sehen ist. Kann nervig sein, wenn man schnell wohinfahren will, weil eine weite Strecke zurückgelegt wird.
Ich meine auch beim teachen könnte man mit einem immer sichtbaren Override Taktzeit optimieren

Geht leider wirklich nur als OUT. Hatte auch schon das Problem. Du musst es ja nicht als out nutzen. Das Programm bleibt ja gleich. Ist nur ein Schönheitsfehler im Programm, aber immer noch besser, als für das Feld ein Globales anlegen zu müssen.
Und da wird gerade bei Feldern sind. Die haben auch eine maximale Größe. Das steht glaubisch nirgends in der Doku.

Aber nicht, wenn man die kürzesten Weg jeder Achse nimmt. Dann kommt ein Bogen raus.
Wie es KUKA genau macht weiss ich net, aber im Studium wurde es so erklärt:
Es wird der Endpunkt in Achswinkel umgerechnet, dann fährt jede Achse auf diesen Wert.
Da die Achsen aber von +-180 Grad gehen, kann es da schnell so Rechenproblemen kommen.
Und das sind dann die Geschichten mit Achse macht Hubschrauber. Der Roboter sieht ja nicht, wie rum es kürzer wäre.

mal ein Beispiel: Start Achse ist bei 90 Grad Endachse soll aber bei -90 Grad sein. Wie rum soll er jetzt die Achse drehen links rum oder rechts rum.
In dem Beispiel ist es egal, aber wenn man andere Winkel nimmt und dann noch die Stellung aller Achsen einbezieht, wird ja schell klar, wie schwer sowas wird.

Bei Lin prüft der Roboter vorher nach, ob er überhaupt zu der Position fahren kann. Geht auch, da der Weg der Linbewegung vorher schon bekannt und berechnet werden kann.
Bei PTP fährt er den kürzesten/schnellste Weg. Damit ist der kürzeste Weg für die Achsen gemeint.
Da kann es dann schnell passieren, dass der Roboter erst bei der Fahrt merkt, dass das was er vorhat nicht klappt.
Theoretisch kann die PTP Fahrt auch jedesmal anders ablaufen.
Tut sie nicht oder so minimal, dass man es nicht sieht, da ja der Start und Endpunkt immer gleich sind.
Daher passiert es auch schnell, dass man sich wundert, wieso der Roboter per Hand an eine Stellung gut fahren kann, es aber in Automatik plötzlich nicht mehr geht.

Einfach einen Timer laufen lassen und den zum Berechnen des Teils nehmen. Und dann suchst du dir etwas in der Anlage, was immer etwas anders reagiert. z.B. die Anforderung Teil einlegen, die wir ja sicher nicht millisekunden genau erfolgen.
Dann hast du im Prinzip einen Zufallsgenerator.
Wenn du dann noch eine krumme Zahl dazuaddierst und durch irgendwas noch Teilst.
Das wäre dann die schnelle unschöne Art.
Ansonsten hier steht es ja beschrieben, wie es umgefähr gehen sollte. http://de.wikipedia.org/wiki/Zufallsgenerator
Du musst nur schauen, ob du die Rechenoperationen im KUKA hast, sonst diese gleich mitentwickeln.

Hatte mal mit Europlatten zu tun.
Die wurden zwar "nur" mit Zylindern zentriert, damit der Roboter dort etwas aufstapeln konnte, aber schon das war ziemlich nervig. Alleine die Ecken der Paletten waren jedesmal anders. und und und.
Das Hauptproblem ist einfach, dass es Holz ist, das arbeitet eben. Und je nach Wetter (Feuchtigkeit) und den Menschen die vorher mit dem Ding schon umgegangen sind, passen eben die Masse nicht mehr.
Also in euren Greifer viel viel Toleranz einplanen damit der die Palette immer erwischt oder es mit einem Kamerasystem riskieren.
Eventuell kann man die Paletten auch komplett anders greifen. Wir hatten mal einen Sauger, der auch Holz greifen konnte.
Die gehen auch einigermassen gut, solange nicht zuviel Harz oder Sägespäne in den Weg kommen.

Alternative, die Dinger werden doch sicher neu dort genutzt? Oder werden auch alte Reycelt? Weil dann kann man schauen, ob jemand die Dinger passgenauer liefern kann. Aber auch das wird schwer. Weil das halt ein Massenprodukt ist, was schnell und billiger hergestellt wird.

Hm, das mit dem umteachen kann aber trotzdem gehen.
CONST verhindert nur das ändern zur Programmlaufzeit.
Zumindest geht das beim ABB so. Da sehe ich es öfters, dass Positionen als Konstanten definiert sind, aber umteachen kann man die trotzdem.
Ich glaube aber, wenn du für die DAT File, in der die Punkte definiert sind, den Schreibschutz aktivierst, dann kann man die Punkte nicht mehr teachen.
Das dürfte dann eher sein, was du suchst. Daher war auch meine Frage, was du vorhast.
Schreibschutz kannst du unter Eigenschaften der Datei ändern. Also einfach mal ausprobieren. Bin mir bei der Sache nicht so sicher.

Ja, einfach als Konstante deklarieren, aber dann hast du keine Variable mehr.
so z.B.
GLOBAL CONST INT errSpiegeln=1

Vor was willst du die Variable schützen? Nur vor Manipulation von aussen? Oder vor Veränderungen im Programm