Roboterprogrammierung von Anfang an

Ah, einer, der strukturiert arbeiten will! Na, da haste Dir aber was vorgenommen!

Mein Tip: nimm erstmal alle Anforderungen mal 20. D. h.: wenn Projektleiter sagt: "da laufen 3 Artikel auf der Maschine", gehe insgeheim von 60 aus, und halte Dir entsprechende Kapazitäten offen.

Dann gehe dein Konzept in Gedanken durch und mach es modular. Dann gehe die Module in Gedanken durch und mach es noch modularer. Jede Nachlässigkeit dabei, jeder Gedanke: "ach, das kann hier mit rein" oder "das kann in den Code, dafür brauche ich keine Variable" rächt sich später mit 10fachem Arbeitsaufwand oder dem Zwang, Sonntags vor Ort erscheinen zu müssen, anstatt den Support am Telefon leisten zu können.

Dann kannste Dir 'nen Plan machen und anschließend wegschmeissen, denn sobald Dein Plan steht, wird das Projekt so geändert, dass er unbrauchbar wird. Das geschieht normalerweise 3 - 5 mal, und dann ist Vorabnahme.

Viel Erfolg!

Edit: ich seh' gerade, dass das im Fanuc-Forum läuft - hab nicht so drauf geachtet und von Fanuc so überhaupt gar keine Ahnung. Na ja, aber prinzipiell betrachtet....

Das hängt m. E. von den Anforderungen ab, die man in der Firma an das Bedienpersonal stellt.
Bei einem meiner Kunden hat die Konkurrenz ein paar Roboterzellen stehen, und für jene wird es als durchaus akzeptabel angesehen, dass der Roboter mit Getöse durch die Zellenwand fährt, wenn der Bediener vergisst, manuell auf Home zu fahren (mehrfach passiert). Man geht halt davon aus, dass der Anlagenbediener bzw. Einrichter das hätte wissen müssen.

Bei einem anderen Kunden muss ich davon ausgehen, dass der Bediener ein Analphabet aus irgendeiner fernen kurdischen Provinz ist, der bei Störungen in beliebiger Reihenfolge beliebige Knöpfe drückt und als Dreingabe noch dazu die Situation in der Zelle manuell maximal verändert. Für den Fall hat es sich als äußerst nützlich erwiesen, den Robbi mit einer gewissen Eigenintelligenz auszustatten, bis rauf zu einer nonverbalen Kommunikationsebene. (Lach nicht: schon allein ein kleiner, von aussen beobachtbarer Nicker des Manipulators bei Programmstart, auch wenn das Programm noch warten muss, bis die Palette da ist oder so, erhöht die Zufriedenheit des Bedieners, weil er dann weiß: aha, der Robbi hat's kapiert, gleich gehts weiter.)

Ich würde versuchen, möglichst alle Fehlermöglichkeiten abzufangen, wenn sie zu Crashs führen können. Im Beispiel wäre das vielleicht die Möglichkeit, einen Fortsetzstart des abgebrochenen Programmes zu verhindern und bei Programmstart grundsätzlich einen neuen Kasten einzuschleusen.

Gerade um die "unnormalen" Zustände macht man sich als Neuling oft zu wenig Gedanken, sage ich mal - wobei es, wie gesagt, auch eine Philosophiefrage darstellt. Bei mir liegt der Aufwand am Anteil der Behandlung von Sonder- und Fehlerfällen im Logikprogramm bei ca. 50 - 80 % des Gesamtaufwandes, je nach Komplexität der Anlage und Möglichkeiten der Selbstzerstörung.
Beispiel: ein Initiator für die Greiferstellung des Bierkastenbefüllers. Wenn man "geradeaus" Programmiert, schaltet man den Greifer, wartet dann auf die Rückmeldung vom Ini, und weiter gehts, fertig.
Geht man tiefer, steckt mehr dahinter: Zur Sicherheit die Funktion des Inis testen (war er wirklich vorher aus, als er hätte aus sein müssen?), macht man vielleicht einen Timeout, wenn der Ini nicht kommt, und springt in eine Fehlerbehandlungsroutine? Und wenn ja, wie sieht die aus - unterstellt man eine schiefhängende Flasche im Greifer und versucht, sie automatisch abzuwerfen, um die Bearbeitung fortsetzen zu können? Testet man dann im mutmaßlich leeren Greifer noch einmal dessen Funktion? Macht man bei Erfolg da weiter, wo man unterbrochen wurde oder läßt man sich das erst vom Bediener bestätigen? Was ist, wenn man zwei Inis am Greifer hat (einen für auf und einen für zu) und beide gleichzeitig sind an? Oder keiner? Meckert das Programm dann rum und meldet den Fehler? Muß man die Möglichkeit einer mehrsprachigen / umschaltbaren Fehlermeldung in Betracht ziehen? Wenn man einen Timeout macht, sollte man dann die Zeit einstellbar machen? Vielleicht sogar Produktabhängig? Soll man einen Interrupt an den Ini hängen, falls der Robbi unterwegs die Flasche verliert?... Und so weiter.

-

Wie gesagt, eine Philosophiefrage. Kommt drauf an, was man verkauft und wie, und was man dem Kunden zumutet. Hin und wieder ist die von Dir angesprochene sture Vorgehensweise mehr gefragt.
Wenn ich die Freiheit habe, meine Anlagen nach eigenem Geschmack zu programmieren mit der Mindestanforderung "muss laufen", dann setze ich gerne auf die Variante, die mir hinterher am wenigsten Arbeit macht, und das ist meist die, die vorher etwas mehr Mühe bereitet. Lieber einmal dem Robbi etwas intelligenten Starrsinn einprogrammieren, als alle drei Wochen dem Greifer hinterherzuteachen, weil ständig Crash gefahren wird; lieber einmal eine Programmnummern-Mechanik mit 255 Möglichkeiten vorsehen als wochenlang immer mal wieder vor Ort für jedes neue Produkt cases und IF-THEN-ELSE-Verschachtelungen reinflicken.

Schema F gibt es bei mir jedenfalls nicht; teilweise gehe ich auch ganz neue Wege. Neulich z. B. habe ich bei einem Handlingroboter, der sich zwischen -zig Aktionen entscheiden musste, eine Art von Fuzzy Logic reingebastelt, Gewinner war dann immer das Programm mit der höchsten Dringlichkeit. Funktioniert auch.
Leider weiß ich nicht, was man mit einem Fanuc kann und welche Freiheiten man da hat.

Ich glaub', Faulheit ist eine gute Programmierertugend.

Grüße!

Beim Fanuc hast Du unter KAREL die dollsten Möglichkeiten deine Logik zu schreiben und dem User auch noch Klartextmeldungen zu geben:

"Programm läuft.
warte auf Flaschen...
warte auf Kisten..."
oder
"Timeout beim Greifen:
Prüfen Sie Druckluft und Ini7.
Wenn beides OK, rufen Sie HILFE"

Das Teachen der Bahnen geht dann einfach in TP. Dafür ist KAREL zu schade.

wh

Hallo lameda

Ich würde mir erst einmal eine zeitliche Abfolge meiner Aufgabe mit dem Roboter skizzieren und an jeder Stelle an der ein Prozessschritt erfolgt, mir Gedanken um das drum herum machen.
z.B
Schritt 1 - Roboter wartet auf Kiste - Kiste ist da --> O.K

- Kiste ist da, aber nicht in Position --> blöd --> Kann ich feststellen wieviel
--> kann ich das berücksichtigen und berechnen
--> wenn nein - was dann??

- Kiste ist nicht da --> noch blöder --> warum ist Kiste nicht da --> kann ich den Grund feststellen
--> kann ich mit dem Roboter etwas beeinflussen
--> brauche ich Hilfe von Extern ( Bediener )
Alle Bedingungen für Schritt 1 sind erfüllt

Schritt 2 - Roboter wartet auf Flasche
usw

Entscheidende Faktoren sind natürlich wie " Programmiersklave " schon gesagt hat, die Entfernung zur Anlage und das Personal welches sie
später betreut. Steht die Anlage im eigenen Betrieb um die Ecke, kannst du Situationen dann aufnehmen wenn sie eintreten, da man dann keinen
spekulierten Zustand sondern einen realen hat. Steht der Robbi 600km weit weg sieht das schon anders aus.
Die zweite unbekannte ist das Personal. Hast du ausgebildete Roboterbediener/programmierer oder hast du nur "Knöpfchendrücker". Dementsprechend offen und veränderbar oder eben nicht kann das Programm dann gestaltet werden.

Gruß

Schybulla