Beiträge von HEINI

Hallo,

dieses Angebot ist nicht mehr aktuell! Der Anbieter hatte etwas utopische Preisvorstellungen.

Sollte sich etwas neues ergeben werde ich es posten.

Tschüß

Heini

Hallo Roboterfreunde,

ich suche Hersteller von fertigen Linearachsen (Portal oder Bodenmontage) auf die ein Roboter z.b KUKA KR 30/60 aufgeschraubt und linear verfahren werden kann. Bisher habe ich gefunden: KUKA und Fa. Winkel
Welche Hersteller gibt es noch? Hat jemand Erfahrungen mit o.g. Linearachsen. Ich habe auch den KUKA Jet ins Auge gefaßt, aber der ist irgendwie vom Arbeitsbereich nicht so ideal (Achse 1 entfällt, dafür Linearachse)

Wie gesagt, wenn jemand nen Hinweis hat, bitte ich um Antwort.

mfg

Heini

Hallo Allerseits:

wenn jemand Interesse an drei Stück RV 3 AL hat, oder weiss wie man die am besten zu Geld machen kann, möchte sich bitte melden.
Die drei Roboter sind etwa 3 Jahre alt und funktionieren bisher einwandfrei. Der optische Zustand, speziell der Controller ist nicht mehr ganz so toll.

Schöne Grüße

Heini

Hallo Felix,

die vorher genannten Beiträge sind ne praktische Hilfe. Hier mal was ganz anderes, paßt aber voll hier rein.

Ich war mal auf nem Robotersymposium bei dem ein Dr. von der TU in München referierte. (Er hat auch ne eigene Firma) Dort hat er Softwarestrategien vorgestellt mit deren Hilfe eine Bahnplanung von A nach B nur durch "Mathematik/Software" errechnet wurde. Hier hat er genau diese Beispiele gebracht. Erst errechnet die Software eine Bahn von A nach B auf dem günstigsten Weg, dann kommt ein Hinderniss hinzu und die Software errechnet den gleichen Weg von A nach B aber um das Hindernis herum. Der Vortrag und die Vorführung war echt beeindruckend. Der Dr. war im übrigen vom Lehrstuhl für Informatik-Robotik TUM.

Was mich dort aber noch mehr beeindruckt hat war ein "Schlangenroboter" mit 20 oder mehr Gelenken, der um mehrere Hindernisse herumgefahren wurde. (mit der gleichen Bahnplanung wie vorher)

Wenn ich mich nicht irre suchen die auch praktische Anwendungsfälle. Ist aber alles sehr futuristisch und einmalig würde ich sagen. Naja, wenn man das nötige Kleingeld hat und etwas Geduld dann kann man sich dort wohl was machen lassen.

Tschüß

Heini

Hallo Robocop69,

wir haben grad einige KUKA in der Halle stehen. Da zittert nichts. Wir haben noch nicht mal die Lastdaten eingetragen. (Kommt noch )

Mich würde mal interessieren, ob das Zittern auch in verschiedenen Stellungen des Robarms und vor allem der Hand auftritt?
Vielleicht kann man erkennen ob es nur bestimmte Antriebe verursachen!
Sitzt das Schweißgerät auf der Schulter an Achse 3? (Lastdaten!)
In unserem Lehrgang wurde sowas auch erwähnt im Zusammenhang mit den Lastdaten!
Ansonsten klingt das mit den MADA recht plausibel. Wie gesagt ich hab das Zittern noch nicht "live" gesehn.
(Ein anderen Programmierer hatte mir schon mal vom Zittern berichtet. Er hat aber eine Kamera dran gebaut und in die "Ferne" gezoomt. Da war dieser IR nicht zu gebrauchen. Zitterte, war aber am IR von Außen nicht zu sehen. Vor allem nicht 5mm!!!)

Gruß

Heini

Hallo Wolf,
hallo IrrerPolterer,

erst mal vielen Dank für die Info. Sieht beides interessant aus. Ich melde mich wieder!

Tschüß

Heini

PS: Ich glaube ich sollte mir ein anderes Pseudonym ausdenken. Klingt irgendwie doof!

Hallo Kollegen,

ich hoffe dies ist nicht wieder eine doofe Anfängerfrage. Bisher hatten wir bei anderen Herstellern wärend des Programmablauf "Merker" gesetzt um bei evt. Not Aus zu wissen, wo der Roboter ungefähr steht. In der Startroutine des Programm werden dann über CASE Verzweigungen die entsprechenden Bewegungen zum Freifahren des Roboter durchgeführt. Ziel ist es ja den Roboter wieder zur Grundstellung (HOME) zurückfahren zu lassen, ohne dass jemand ein KCP benützen muß. Danach kann das Programm wie gewohnt anlaufen. Diese Methode ist im jetzigen Fall etwas schwieriger, da der IR in eine sehr enge Druckgußm. einfahren muß. Da wirds gefährlich mit der ersten PTP SAK Fahrt. Hier die Frage:

Wie kann die Rückzugsstrategie (nach NOT-AUS oder Steuerung aus) sonst gelöst werden?
(Ich habe irgendwie den Verdacht man sollte dort weitermachen wo man vorher gestoppt hat)

Für Antworten bedanke ich mich bereits im Voraus.

Tschüß

Heini

Hallo Miteinander,

erst mal vielen Dank für die Info's. Wir haben auch schon negative Erfahrungen gemacht, deshalb die Frage. (Konnte nie geklärt werden, ob Schmutz, Temperatur oder Überlast die Ursache war) Die Hersteller die ich gefragt habe hatten kein Problem mit der 100%igen Auslastung. KUKA Load ist ein sehr schönes Programm um die Auslastung der Achsen zu bestimmen. Ich denke die 85% Faustformel klingt recht gut, wenn man dann noch den Bewegungsablauf hinzuzieht und den "ausgestreckten Arm".......

Wie ist das mit dem LoadDetect...Ist das Empfehlenswert oder besser formuliert, wann ist es zu empfehlen?

Viele Grüße

Heini

Hallöchen,

ich glaube meine Frage war , hätte trotzdem gerne gewußt was da für Sicherheitsfaktoren genommen werden?

Tschüß

Heini

oh oh....

lass unsern teueren "Wasserkopf" doch noch'n bischen machen!

Wir haben doch erst 70% der Weltliteratur an Gesetzen.

:fussballer::flagge_d1:...sind sozusagen schon wieder Weltmeister!! :flagge_d1: :fussballer:

.... bei 100% feiern wir dann....äh dann hätten die anderen ja 0%

Wo waren wir stehengeblieben...... ach ja. mir fällt grad ein unsere Programmierer schießen sich auch jede Mittagspause im Netzwerk tot....(Angst)

auweia.....

Hallo Kollegen,

ich möchte mal nachfragen nach welchen Kriterien bei Euch die IR ausgewählt werden?
Klar ist es die Reichweite, Traglast und Präzision.... Ich möchte hier nur auf die Traglast eingehen.

Nehmen wir mal an, man hat eine Applikation, bei der sich der Robi ständig mit sehr hoher Geschwindigkeit bewegen muss. Kann man hier bedenkenlos 100% der Traglast ausnutzen oder sollte man einen bestimmten Traglastanteil als Sicherheitsfaktor übrig lassen?

(Im MB geht man auch nie bis an die Grenze der berechneten Werte!)

Wie ist das beim Roboter?

Tschüß

Heini

Hallo Kollegen,

was soll ich sagen? Es funktioniert! Erst habe ich in der pfbms.ini die Einstellungen vorgenommen, wie "dingi" (Frank) und "SJX" (Stef) vorgeschlagen haben:

pfbms.ini:

[SLAVE]
MODUL_USED=1 ; Slave aktiviert
MODUL_ADDRESS=91 ; DP Adresse wie projektiert in PBNet von SPS (S7) Master
START_TIME=20
ERROR_ACTION=0
STANDBY=0
SLAVE_TIMEOUT=0
CHECK_CONFIGURATION_DATA=0
ACCEPTABLE_INPUT_LENGTH=244
ACCEPTABLE_OUTPUT_LENGTH=244
IO_DATA_BASE=0 ; später auf 1 geändert (1=Wort, 0=Byte) dazu später mehr!
CONSISTENCE=0

Der Lesefehler mit Hinweis auf den PB Treiber war immer noch da.
Ab jetzt immer nachsehen was die gleichnamigen LOG files (pfbms.log + iosys.log)
pfbms.log scheint iO zu sein, aber iosys.log gibt Hinweise für die weitere Fehlersuche.
Hier nochmal ein an zsteve. Also weiter gehts, immer schön Schritt für Schritt.
Nun spiele ich mit der Datenlänge herum und verkürze die IN und OUT Bytes in der IOSYS.INI:

von 32 Bytes:

[PBMASL]
INB0=127,0,x32 ;$IN[1-256] Slave Eingaenge
OUTB0=127,0,x32 ;$OUT[1-256] Slave Ausgaenge

auf ...etwas weniger:

[PBMASL]
INB0=127,0,x1 ;$IN[1-256] Slave Eingaenge
OUTB0=127,0,x1 ;$OUT[1-256] Slave Ausgaenge

-> geht immer noch nicht! So langsam wird mein Verdacht immer stärker! Nochmal in die iosys von frank (dingi) reinschauen. Er hat doch Word und nicht Byte benutzt? Also nochmal die
pfbms.ini geändert:

[SLAVE]
.........
IO_DATA_BASE=1 ; (1=Wort, 0=Byte)
.........

und die iosys.ini

[PBMASL]
INW0=127,0,x1 ;$IN[1-256] Slave Eingaenge
OUTW0=127,0,x1 ;$OUT[1-256] Slave Ausgaenge

dann wieder das gleiche Spiel wie immer Treiber rekonfiguriert (Reset würde ich dazu sagen) und plötzlich staune ich nicht schlecht!! :party020:
Keine Fehlermeldungen mehr am KCP!! Na sowas...nun die Wortbreite langsam erhöht und ab >12 gibts wieder den alten Fehler. Ab dann hat's unser Programmierer in die Hand genommen. (Hatte vorher an allen Ecken und Enden zu tun, ist nämlich ne ganz schön große Anlage) Das mit den Byte/Word ist mir zwar etwas schleierhaft, habe aber heute keine Gegenprobe mehr gemacht. Das werde ich morgen nachholen. (Den ganzen Weg rückwärts) Ich vermute aber dass es dann wohl auch mit Byte funzt.

Tja dann kann man wohl klar sagen dass das neue unbekannte und fremde Wesen wohl völlig zu Unrecht vorverurteilt wurde! (kleiner Gruß an IrrerPolterer aber ich neige nicht zu nichtssagender politischer Korrektheit sondern zur Ehrlichkeit!!!) Und deshalb eine ehrliche
[glow=red,2,300]Entschuldigung[/glow] an KUKA! (Immer diese Vorurteile gegen "Neues"!) :schuldig:

Wie gesagt, es könnte sein, dass o.g. noch nicht ganz korrekt ist, aber aus dem Gedächtnis war das so. Morgen werde ich den ganzen Weg nochmal rückwärts verfolgen und dann das Ergebnis posten. Ich denke dann können wir diesen Beitrag abschliessen. Es hat auf jeden Fall Spaß gemacht. Hier nochmal ganz herzliche Grüße an WolfHenk. Wir haben uns gestern abend echt toll unterhalten.

Viele liebe Grüße

Heini

:OLA:

Hallo Stef,

Zitat von SJX

Wichtig:
Was hast Du für Softwarestand und Typ Karte ? (A2?)
Was steht im Pfbms.log?
Gruss Stef

wie gesagt, Daten aus dem Gedächtnis: KRC 2 edition 2005 Software 5.2.12 (könnte auch .14 sein bin nicht sicher) Die Karte ist die original KUKA (von KUKA bereits eingebaut) CP5614 A2 (Hersteller Siemens) Pfbms.log kann ich erst am Montag einsehen! Wir gepostet!

Viele Grüße

Heini

geändert: Softwarestand ist: 5.2.14

Hallo,

erst mal vielen Dank für die Hilfe. Wir hatten heute die volle Hektik. Den neuen Forumbeitrag habe ich noch in der Arbeit geschrieben. Bin jetzt zuhause, deshalb folgende Angaben aus dem Gedächtnis.
Softwarestand: Version 5.2.14 (Roboter sind erst vor 4 Wochen bei uns eingetroffen, also nagelneu!!)
Roboter 1: KR30-3
Roboter 2: KR6
Roboter 3: KR6
KRC 2 edition 2005

Ich habe mich seit zwei Tagen erst in dieses Thema (Profibus) eingelesen. Bin leider nur das "Eisenschwein" (mech. Konstruktion) , habe aber viel Erfahrung mit S5/S7/MelfaBasicIV uvm (ehem. Monteur) und hoffentlich bald mit KUKA. Mit der Nachfrage wollte ich unsere Programmierer unterstützen. Wir waren erst zu Dritt bei KUKA und haben zwei Kurse besucht. (Bediener und fortgeschrittene Programmierung) Wie wir bereits bei KUKA erfahren haben sind für das Thema Bussysteme weitere Kursen zu besuchen.

Am Montag früh werde ich die Sachen mal mit unseren Programmierern durchsprechen und hoffe wir kommen dann weiter. Danach werde ich auf jeden Fall das hoffentlich positve Ergebnis reinschreiben.

Ich bin jedenfalls angenehm überrascht wie schnell hier geantwortet und geholfen wird.

Hallo,

wir sind Maschinenbauer und haben erstmals KUKA Roboter in einer Anlage verwendet. Nun sind wir dabei, die Anlage zu testen, kommen aber mit der CP 5614 Profibusschnittstelle des KUKA Roboter nicht zurecht. Von KUKA kam bisher keine Hilfe, außer dass wir schon alle Dokumentationen haben und diese lesen sollen!!?
Nach der Doku von KUKA können wir keinen Fehler unsererseits finden. (Vielen Dank KUKA)
Wir kommen uns langsam etwas doof vor, vor allem, weil wir seit 10 Jahren Mitsubishi eingesetzt haben mit allem drum und dran. (Ethernet, Profibus etc. kein Problem!!)

Ich habe alles was ich im Forum finden konnte ausgedruckt und unserem SPS-Programmierer vorgelegt, sind aber trotzdem noch nicht weitergekommen.

Folgende Konfiguration haben wir geplant:

SPS ist Master, KUKA ist Slave (Es wird nur die Slave Schnittstelle benutzt!) Als zentrale Steuerung dient die SPS, auch für Greifer usw. Der KUKA ist Teilnehmer Nr. 90. (fangen erst mit einem der drei an, der Rest ist dann wohl einfach)

Wenn wir unsere IOSYS.INI und die PFBMS.INI ausprobieren kommt die Fehlermeldung:
!! 1034 Fehler beim Schreiben Treiber CP561DRV !!
!! 1033 Fehler beim Lesen Treiber CP561DRV !!!
Unter dieser Fehlermeldung leuchtet die gelbe LED der CP Schnittstelle nicht.

Wenn wir die IO Belegung aus der IOSYS ausklammern erscheint der Fehler nicht. Natürlich haben wir dann auch keine Verbindung.

Es ist Samstag und nächste Woche kommen unsere Kunden Wenn alles nicht klappt müssen wir schnellstmöglich einen Kuka Programmierer anfordern. Für jede Hilfe bin ich dankbar.

Im Anhang sind die beiden Betreffenden Dateien.