Postprozessor: Auf der SPS oder schon davor?! Szenario1 vs Szenario2

Hallo Forum-Gemeinde,

ich richte eine erweiterte theoretische Aufgabenstellung an euch. Ich habe ein Problem und bin so langsam eine Lösung näher gekommen. Das Problem wurde hier schon einmal aufgefasst: http://www.roboterforum.de/rob…-krc1/msg53884/#msg53884.

Ein Besitzer einer Roboter-Zelle und dazugehöriger weiterer Prozessparameter (zB eine Schweißanlage, Fräsanalge o.ä.) ist nicht in der Lage ein Roboterprogramm zu manipulieren, dahingehend dass er nicht weiß wie man zB einen Schweißstrom/Drahtvorschub o.ä. ändert. Er sieht letzten Endes nur am gefertigten Prozess, dass an einer Stelle eine Änderung von Prozessparametern (Technologiebefehle) geändert werden müssen. Da er nicht weiß wie das geht, gibt er beim Entwickler an. an welcher Stelle es hakt und der Entwickler schickt den aktualisierten Programmteil zurück.

Es entstehen zwei Szenarien, die sich nun gegenüberstehen und wo ich eure Hilfe brauche. Ich muss mich für eins entscheiden und umsetzen und begründen können warum ich den Weg so gehe!

Szenario 1:
- Externe Firma mit eigener Entwicklungsumgebung (CAx), grober Ablauf des IR wird geplant, unspezifisches Roboterprogramm wird entwickelt
- eine "Zellenkonfiguration" wird geladen (sie enthält Manufactor IR, RobotLanguage, Ein-/Ausgänge des IR usw)
- externer Postprozessor übersetzt das Programm in die gewünschte Form, die der IR laut Zellkonfig erwartet
- Programm kann so - OHNE Vorkonfiguration des IR/SPS etc. gestartet werden

Szenario 2:
- wie im Szenario eins entwickelt eine externe Firma ein Roboterprogramm (zunächst universell, dann mittels Prostprozessor in gewünschte Sprache des IR)
- angesteuerte/überwachte Ausgänge/Eingänge werden durch Variablen angefahren
- es existiert keine Zellkonfiguration, kein Postprozessor, der weiß welche Ausgänge wie anzusteuern sind
- der Roboter muss vorkonfiguriert werden -> wird im Roboterprogramm ein Zugriff auf ein Ausgang vereinbart so muss das in einer Konfiguration stehen
- im Prinzip übersetzt die Robotersteuerung den Befehl und weiß anhand der Deklarationen wie die Ein/Ausgänge anzusteuern sind

Ich hoffe, dass was ich meine, wird hier klar. Im Prinzip entspricht das den zwei bekannten Wegen einem Roboter beizubringen welche Ein-/Ausgänge anzusteuern sind. Der Unterschied in den Szenarien besteht nun darin, wo ich mein Code übersetzen lasse.

Im Szenario1 weiß der Entwickler genau Bescheid darüber, wie die Zelle aussieht, anhand einer Zellkonfigurationsdatei. Das Programm kann so wie es ist, dem Robter zugeführt werden. Im zweiten Szenario hat der Entwickler keine Ahnung über externe Prozessparameter. Er kennt zwar meinetwegen die Sprache (Sprachversion etc), aber nicht die externen Komponenten. Er verwendet "allgemeingültige" vereinbarte Variablen (o.ä.) wie zB. "Greifer öffnen" etc. Im zweiten Szenario wüsste der Roboter schon was sich dahinter verbirgt...

Ich hoffe auf eine rege Diskussion

Vielen Dank vorab für jede Idee Eurerseits

Grüße

Angenommen: Es gibt eine Zelle. 1 Roboter, 1 Schweißanlage. Dieses Setup ist mehrmals verkauft worden und bei mehreren Kunden im Einsatz. Der Kunde selber hat nun mehrere Programme mit denen er Roboter und Schweißanlage bedienen kann. Der Anwender bekommt das Programm, lädt es, und das Setup erledigt den Rest (die eigentliche Arbeit).

Nun ist die Ausgangslage aber so, dass der Anwender eigentlich keine Ahnung hat wie ein Roboterprogramm aufgebaut ist. Er kann es starten und stoppen - kann Technologieparameter (falls diese nicht 100%ig stimmen) nicht ändern.

Der externe Programmierer weiß ja letztlich nicht wie das in Realität funktioniert. Simulationsumgebung entsprechen nie 100%ig der Realität. Es kann also sein, dass der Drahtvorschieb an der Positiion XY geändert werden muss, weil die Schweißnaht nicht "gut" ist.

Es gibt zwar nur 1 Roboterprogramm, dass die SPS "steuern" kann, aber es gibt 2 Wege um bis dahin zu kommen: 2 Szenarien.

Szenario1: Entwickler hat komplette Entwicklungsumgebung (Konfigurationsdatei der Zelle, Welcher Roboter? Welche Sprache? Welche Ein/Ausgänge? Wie steuer ich die Schweißanlage? etc..). Mit diesem Wissen kann er an alle Kunden mit dem gleichen Hardware-Setup das Programm schicken. Vor Ort muss nichts konfiguriert werden.

Szenario2: Der Entwickler weiß nicht wie er die Ausgänge ansteuert um zB den Drahtvorschub einer angeschlossen Schweißanlage zu manipulieren. Daher verwendet er eine vereinbarte Konvention: Variablendeklaration, diese ist auf jeder Maschine bekannt. Im Szenario2 werden also nur "allgemeingültige" Variablen verwendet, und die SPS kennt sie, weil diese vor Ort vereinbart wurden.

Ist das ein wenig besser rübergekommen... ich weiß sonst nicht wie ich das klar machen soll :-|

PS: Ich greife ein Problem auf, dass viele kleine Betriebe haben, die sich einen Programmierer oder eine Fortbildung nicht leisten können. Das Szenario an sich, die Tatsache dass vor Ort niemand da ist um etwas zu ändern - BITTE NICHT ANZWEIFELN... das ist nun mal so bei Aufgabenstellungen. Das bitte hinnehmen als Bedingung beim Suchen einer Lösung.

Zitat von Urmel

Ich hab mich doch extra bemüht, nicht grob zu sein. :angel:

Und extra nichts dazu geschrieben, dass "eine externe Firma ein unspezifisches Roboterprogramm entwickelt".

Ich wollte damit sagen, dass das entwickelte Programm nicht speziell auf einen spezifischen Hersteller ausgerichtet ist. Sondern erst im Nachhinein mittels eines Prostprozessors zugänglich gemacht wird für einen speziellen IR.

Zitat von Urmel

Genau diesen Teil halte ich für realitätsfremd, dazu sind die Robotersprachen zu unterschiedlich.

Manche arbeiten mit Vorlauf, andere synchron.
Manche haben Interrupts, manche machen alles mit Multitasking.
Bei manchen ist die IO-Konfiguration irgendwie global, bei manchen Teil des Programms.

Entweder kommt da so eine "kleinster gemeinsamer Nenner" Lösung raus, oder etwas in der Form "wir unterstützen Roboter aller Hersteller, solange es sich um Kuka Modell XYZ handelt".

Wenn man die (Roboter)-Zielgruppe genauer definiert, kann man mit einem der beiden Ansätze arbeiten. Mit welchem hängt aber sicher wieder davon ab worum es sich handelt.

Alles anzeigen

Ok, wir gehen davon aus, dass das entwickelte Roboterprogramm auf den IR in der Zelle passt. Das ändert eigentlich nichts an meiner Frage. Das Problem bezieht sich explizit nur auf die weiteren Prozessparameter (bzw Technologieparameter!), wie eben ein angeschlossenes Gerät (Schweißanlage, Kleber, Fräser, usw.). Da der externe Programmierer zwar den Roboter kennt, aber nicht die einzelnen angeschlossenen Ein/Ausgänge, kann er nicht sagen wie er das Gerät steuert

Beispiel:
--> er kennt bspw nicht die Bitreihenfolge von der Schweißanlage, um den Drahtvorschub zu ändern. Er verwendet den Befehl im Programm "Erhöhe Strom um 5V" (Strom und Drahtvorschub hängen immer zusammen).
Im Szenario1 wird mittels der Zellkonfig das direkt in einen Befehl umgewandelt den die Schweißanlage versteht (richtiges Absenden einer legalen Bitreihenfolge). Im Szenario2 müsste das vor Ort geschehen. "Erhöhe Strom um 5V" ist dort bekannt und wurde in einer cfg entsprechend vereinbart und ist bekannt.

Zitat von Urmel

2 ist dann entweder eine Art Interpreter, der eine Scriptsprache abarbeitet, oder ein Programm vom Typ 1, dass für bestimmte Funktionen auf Bibliotheken zurückgreift, die schon auf dem Zielsystem vorliegen.

Genau!

Ich sehe die beiden Wege, ... gibt es noch andere?

Welches Szenario macht nun mehr Sinn? Welches wäre wahrscheinlich (mit eurer Erfahrung) einfacher umzusetzen?

Zitat von Urmel

Schon klar, aber die beiden Ansätze widersprechen sich nicht wirklich, in unserer Software tauchen sie beide gemeinsam auf.

Höh?? SW? Wie? Was? ... Welche SW?

Ich weiß jetzt nicht genau was du mit Offline-Tool meinst, aber in der Entwicklungsumgebung des Roboterprogrammes gibt es auf jeden Fall einen Postprozessor der KUKA KRL unterstützt (einige wenige Versionen...) (via VBA-Script).

Anpassung des Codes soll wohl auf jeden Fall Offline passieren. Naja, der Anwender an der Maschine versteht den Code ja wohl nicht - insofern kanns ka nur Offline vom Experten aus Externshausen passieren.

Zitat von Urmel

Eine 3D Robotersimulations- und Programmiersoftware.

Und die bereits existierenden Roboteranwendungen wurden damit geschrieben ?

Das kann schon gut sein, dass bereits existierende Anwendungen von dort entstammen. Ganz genau wissen tue ich es aber nicht. Inwiefern könnte das interessant sein?

Zitat von Urmel

Wenn man nicht alle Roboterprogramme neu schreiben will, braucht man ja irgendwo einen Anfang.

Wieso "neu schreiben"?

Zitat von Urmel

Für Variante 1 muss man dann sehen, dass man Roboterprogramme generieren kann, die den vorhandenen nahe kommen.

Wir gehen mal davon aus, dass es eine Simulationssoftware gibt, die lauffähigen KRL-Code produziert. Ob ein Postprozessor einen "universellen" AblaufCode in zB KRL-Code wandelt, ist relativ egal. Ich komme da nicht ran, da ich nicht die API hab und auch selbst wenn ich sie hätte nicht öffnen will.

Zitat von Urmel

In der zweiten Variante muss man die Roboterprogramme auf den Zielsystemen entsprechend umbauen und sehen, dass das mit den generierten Programmen zusammenpasst.

In jedem Fall muss ich "Mache dies und das" dem Roboter beibringen können. Wie das geht, ist erstmal für mich egal.

Zitat von Urmel

Einfacher hat man es sicher, wenn man nur mit neuen Systemen anfängt. Auf jeden Fall wird man dann Zugriff auf entsprechende Robotersysteme brauchen, um sein Produkt dann auch zu testen.

Das ist für mich wichtig... zu wissen: Was macht weniger Aufwand? Was lässt sich auf viele Fälle beziehen, wo Zellen einen gleichen Aufbau haben? Was kann ich jetzt für eine Lösung vorschlagen, so dass ich ein erstes Ergebnis ziemlich schnell vorführen könnte?

Was für mich wichtig ist bei der Auswahl eines Szenarios: Wie schaffe ich es am Einfachsten, ein Roboterprogramm zu "updaten", nachdem erkannt wurde, dass dort ein Teil des Codes angepasst werden muss - unter der Voraussetzung das der Anwender DIES NICHT KANN!
Es geht dabei ausschließlich um Technologiebefehle (externe zusätzliche Prozessparameter).

Zitat von Urmel

Beide Lösungen erfordern den Umbau des Postprozessors, oder einen zweiten nachgeschalteten.

Ja und Ja!!!!! Und jaaa endlich... es scheint angekommen. So wie ich das seh, muss ich entweder einen neuen nachgeschalteten Postprozessor schreiben (Szenario1), oder eine zweite Variante finden wo das Programm auf dem Setup vor Ort (Zelle) übersetzt wird (Szenario2).

Und nix mit PowerPoint. Das ist bitterer Ernst! Ich MUSS eine Lösung finden, vorschlagen, umsetzen und testen bzw. vorzeigen.

Zitat von Urmel

Bleiben nur die beiden Vorschläge mit den Konfigurationsdateien oder dem Werker, der Lesen und Schreiben kann.

Stellt euch doch einfach mal vor, dass es in kleinen und mittelständischen Betrieben keine festangestellten Programmierer gibt. Was ist daran denn bitte so unklar, dass man das Szenario hier verniedlichen muss und meinte "Lernt Schreiben und Lesen" ....

Ich MUSS dafür Sorge dafür tragen und mir einen Kopf machen darüber, dass es auch in Zukunft möglich ist (in verschiedenen kleinere Firmen), eine Veränderung am Roboterprogramm vornehmen zu können .

Hast du denn eine andere, bessere, konkrete, einfachere Lösung als ich, Urmel? Von mir aus kannst du meine Szenarien-Beschreibung vergessen. Die Ausgangssituation und das Ziel sollte klar sein. Alles was dazwischen liegt, ist verhandelbar! Nur die beiden Szenarien sind mein Ansatz bzw. Ansätze das Problem zu lösen.

Generell find ich es schade, dass sich nicht noch mehr Leute an der Diskussion beteiligen. Vll. liegts auch daran, dass hier schon so viel geschrieben wurde.....