Artikelprogramme mit KUKA verwalten

Wir haben ein Projekt, bei dem die KUKA-Roboter verschiedene Artikelprogramme fahren müssen. Der Kunde hat den Wunsch eine so große Anzahl an Artikelprogrammen zu benutzen, dass hierbei das CELL-Programm an seine Grenzen stößt.
Bisherige Anlagen wurden von uns mit anderen Roboterfabrikaten realisiert, wo dann über die SPS Artikelprogramme extern auf ein Laufwerk gesichert und von dort wieder geladen werden konnten.
Hat jemand schon mal ähnliches realisiert und kann mir ein Beispiel zukommen lassen? Ich hatte schon ein flüchtiges Gespräch mit einem KUKA-Mitarbeiter, der dieses Szenario mit CREAD, CWRITE, SPS.SUB und einigen weiteren Programmierschritten verwirklicht hat. Er wollte mir das Beispiel, das von unserer Seite noch angepasst werden müsste, zukommen lassen. Jedoch habe ich ich dieses Bsp. bis jetzt nicht erhalten. Auf Rückfrage bei KUKA ( leider nicht der Mitarbeiter, der mir dies telefonisch versprach ), hieß es, dass dieser Mitarbeiter etwas nicht richtig verstanden hätte. Ich vermute, dass es den Hintergrund mit dem KUKA eigenen Technologiepaket hat, das für unseren Fall einiges an zusätzlichen Kosten verursachen würde.

Dem Kunden wurde versprochen Artikelprogramme von bis zu 500 - 1000 verschiedenen Artikeln zu verwalten. Ob er die je verwendet ist fraglich, aber da muss halt die Technik die Versprechungen erfüllen, leider.
Bei einem Artikelprogramm ( hier sprech ich aus der Erfahrung mit den Altanlagen mit anderem Roboterhersteller ) können je nach Design schon mal 40 bis 50 Punkte pro Station und bis zu 5 Stationen anstehen. In wie weit Punkte von Station auf Station durch BASE - Verschiebung übertragbar sind ist schwer zu sagen, da die Erfahrung von früher gezeigt hat, dass jede Station unterschiedlich reagiert und so oft jede Station separat zu teachen ist.
Die käufliche Option ist Directory Loader von KUKA und schlägt kräftig zu Buche, und das für jeden Roboter. Da es bis zu 4 - 5 Roboter sein können, summiert sich das. Und hier schlagen auch wieder die kaufmännischen Leute zu und verlangen günstigere Lösungen. Archivieren und Wiederherstellen wäre die günstigste Lösung, doch hier ist wieder die Frage wie sinnvoll ist das einem Kunden zuzumuten.

Zitat von IrrerPolterer

Es bleibt die Frage, wie sich die Artikel unterscheiden. Es wird ja wohl zumindest mehrere gleiche Typen geben und nicht einerseits Würstchen gegrillt und anderseits Waschmaschinen verpackt.
Was muss ich also in dieser Datenbank/Artikelverwaltung speichern?
Welche Unterschiede kann ich automatisch im Programm z.B. durch Vermessung bestimmen?
Kann ich Einrichtern/Bedienern zumuten noch nicht vorhandene Artikel selbst nach einem Basisprogramm zu teachen? Hier können dann z.B. Positionsdaten per RSI o.ä. mit einem Leitrechner ausgetauscht werden. So haben wir es schon mal gelöst.

Wir arbeiten für die Porzellanindustrie, die Artikel variieren so extrem, dass die Unterprogramme individuell geteacht werden müssen.
Es besteht derzeit ein Basisprogramm, dass die einzelnen Stationen anfährt, die einzelnen Stationen werden in Unterprogrammen abgearbeitet. Leider kann man für die Artikel nicht ein allgemein gültiges Unterprogramm erstellen, es ist je nach Gestaltung des Artikels eine unterschiedliche Anzahl an Verfahrpunkten nötig. Hier ist bekanntlich den Designern keine Grenze gesetzt.
Das Teachen wird von geschultem Personal erfolgen müssen. Jedoch sollte ein Artikelwechsel auch von eingewiesenen Bedienpersonal erfolgen können.

Zitat von m.c.zapp

Oder eben diese Nachladeoption (heißt irgendwas mit "loader"). Damit habe ich aber noch keine Erfahrungen gemacht.

Das Paket heißt Directory Loader, kostet ca 2500 pro Roboter.
Hat mit Sicherheit einen Funktionsumfang, der für uns nicht voll nötig wäre.
Und auf lange Sicht für jedes Projekt die selben Paketkosten, da drängt sich die Eigenentwicklung auf. Zumal auch KUKA nur mit Wasser kochen kann. Ich vermute, dass der KUKA-Mitarbeiter mit seinem Beispiel nur zurückgerufen wurde um nicht Konkurrenz zum Directory Loader zu schaffen.
Würde ich in dieser Situation nicht anders machen.

Zitat von Martl

Servus,

warum dann nicht selber ein "CELL" erstellen?

Eingangsgruppe mit einem "Wort" Länge für die Programmnummer nehmen, und gut is.
Und damit UP aufrufen.
Das dürfte dann auch genügen von der Anzahl her

Grüße

Martl

Alles anzeigen

Danke für die Anregung. Kannst Du hierfür auch ein Beispiel schicken?
Das Problem ist, dass ein Grundgerüst mit den Positionen vor jeder Station bleiben muss. In dem Gerüst muss für jede Station die BASE angepasst werden und dann ein Artikel spezifisches Unterprogramm gestartet werden. Die Artikel spezifischen Unterprogramme werden vom Kunden bei neuen Artikeln selbst erstellt aus einem Urunterprogramm. Hier muss dann immer eine "WorkBASE" verwendet werden, da über das OP Nachjustagen erfolgen müssen, die keine KUKA-Kenntnisse voraussetzen dürfen.