Programmverwaltung KRC5 durch Siemens SPS

Zitat von Handschuh #33

.. Somit ein Programmaufruf im Cell und ein Programm, das 900 Teiletypen abarbeiten kann,..

Also müssen die Programme schon vorhanden sein. Oder halt ein Programm über Parameter (offsets, werkzeuglänge...) einstellbar. Oder eine Mischung: mehrere Programme und innerhalb dann noch Parameter.

Zitat von T1m

Ich habe das gerade auch ausprobiert.

Leider mit dem selben Ergebnis.

Es ist immer toll, wenn Ihr einfach schreibt, es geht nicht.

Welcher Code ging nicht und was passierte ? Fehlermeldung ? Verhalten ? Was hast Du erwartet ?

Was sicher nicht geht, ist einfach sowas wie: "RUN/R1/Programme/Werkzeug123()"

Zitat von T1m

CWRITE($CMD,STAT,MODE,"RUN /R1/Program/Test2()")

Eigentlich geht dies. Programme können in Unterordner von R1 sein.

Was Du aber weglassen musst, ist im CWRITE die Angabe des Unterordners.

CWRITE($CMD,STAT,MODE,"RUN /R1/Test2()")

Und unbedingt so Ausprogrammieren, dass Befehl nur einmal ausgeführt wird.

Die Idee, das so machen zu wollen, ist nicht durchdacht, sage ich mal.

In diesem Fall muss nämlich die SPS wissen, welches Programm angewählt ist und warum, und man müsste ihr die Möglichkeit gewähren, das Programm auch abwählen zu können, denn ein fälschlich angewähltes Programm wäre dann ihr Problem (bedeutet: zusätzlicher Kommunikationsaufwand). Im Normalfall wird ein unterbrochenes Programm nicht abgewählt und kann fortgesetzt werden, die beschriebene Vorgehensweise sorgt aber für die Not, das laufende Programm immer finalisiert zu haben. Das wird eine endlose Quelle des Frustes, weil einem immer wieder zur Unzeit das Programm abgewählt wird. Bis dass Du das erste mal einen Fehler im Roboterprogramm verfolgen kannst, hast Du zigmal die SPS umprogrammiert und drölf Crash gefahren, weil der Roboter zwangsweise "von vorne" anfängt.

Das letzte Mal, als ich das machen musste, blieb CELL fast leer und verwies lediglich auf "haupt()".

CELL ließ sich anwählen, wenn umgeschaltet wurde und nichts angewählt war, so wie üblich, und die Maschine blieb ansonsten für immer im Programm.

Da dieses Programm sein Produkt über einen Barcode auch noch selbst herausfinden musste, geschah ein ganze Menge in haupt(). Und irgendwann kam ein String von der SPS (die paar Zeichen kann man durchaus auf der IO-Schnittstelle abbilden), und ein Bestandteil war eine Nummer, mit der ich in einem Unterprogramm namens "tabelle()" eine SWITCH-CASE-Verzweigung aufrief. Und die verteilte dann auf Unterprogramme, oder warf einen Fehler, wenn es den Eintrag nicht gab.

Einrichter musste also nur in "tabelle" editieren. Und da war weiter nichts drin ausser eben dies.

Der Einrichter muss sowieso ein bestehendes Modul kopieren und dabei umbenennen, wenn er ein neues Programm braucht. Das ist für ihn das Einfachste, da braucht man nichts vorbereiten. Und dann öffnet er "tabelle.src" und fügt die Verzweigung ein. Wenn er das nicht hinkriegt, sollte er auch nicht teachen dürfen.

Der fortgeschrittene Einrichter wird abseits des Automatikbetriebes dann sogar wissen, wie er die Anlage dazu zwingt, ein völlig anderes Programm mal eben zwischendurch teachen zu können, ohne die SPS erst davon überzeugen zu müssen, dass er das jetzt will.

Also: weniger Arbeit für den Einrichter. Weniger Frust für den Bediener. Weniger Arbeit für Dich.

Servus,

ein geführtes teachen ist doch die beste Lösung. Du hast ein Hauptprogramm, das du immer durchläufst, du fragst das Werkzeug ab, wenn es in einer .Dat Datei existiert bzw. da stehen Positionen drin, fährst du mit diesen Positionen deine Bahn. Ich hatte damals drei .Dat Dateien aus denen ich mir die Positionen abgeholt habe. Stand in der .Dat Datei nichts drin habe ich das Teachen ausgeführt. Der Bediener ist zur Pos gefahren hat eine Taste übernehmen gedrückt bzw. Touch Up und die Position wurde im Typ gespeichert. Ist der Typ beim nächsten mal gekommen habe ich die Daten ausgelesen und los geht es. Vorteil du kannst die Positions.Dat Sichern und im Notfall wieder zurückspielen und alles passt. Du hast ein Hauptprogramm das immer das gleiche ist nur die Positionen die du ausliehst sind unterschiedlich. Hier war ich noch begrenzt auf 1000 Typen durch die Dateigröße. Aber du siehst am Datum 2014 es ist schon eine weile her. Habe es nur mit KRC2 gemacht aber ich denke das geht auch mit KRC4 oder 5.

Ich würde in der SPS aus dem String ein Typ 1 bis x generieren mit jedem neuen String ein neuer Typ, den übergibst du als Integrer an den Roboter und der macht dann den Rest.

So habe ich das gemacht ich hatte damals 2000 Typen und hatte für jede Position 2 Dateien :

In der RFTNR stand der Typ von der Steuerung. Mit Touch Up habe ich die Position in den Typ reingeschrieben.

Ist der Typ bekannt habe ich die Position, in die Position vom Programm reingeschrieben.

Das heißt Aufposdreh war im Programm immer die gleich nur die Werte sind Typspezifisch.

Zitat von T1m

Hallo Handschuh,

Könntest du das bitte etwas genauer erläutern?

Hat jedes der 900 Teile ein eigenes (Unter-)Programm?

Und wenn der Einrichter neue Typen anlegen kann, wie werden diese dann ausgewählt?

Oder existieren die Programme bereits im Vorfeld und der Einrichter editiert dann das "leere" Programm, welches benötigt wird?

Dein Anwendungsfall klingt ähnlich wie meiner, daher würde mir das sehr weiterhelfen.

Gruß

T1m

Alles anzeigen

Sorry, war im Urlaub

Ich habe nur ein Programm, wo bestimmte Prositionen als Variable (z.B. Z-Höhe) hinterlegt sind, diese Variablen habe ich in einem Array in der config.dat zusammengefasst und eine Programmnummer (Barcode) mit hinterlegt, an Hand dieser Nummer durchsuche ich mit einer Suchroutine (entweder wird die im Programm durchlaufen oder manuell von einem Einrichter, um ggf. einen neuen Datensatz anzulegen) die Arrays nach dem passenden Barcode und aktiviere, bei korrekter Nummer, dann die entsprechenden Variablen aus dem gefundenen Array im Programm.

Servus,

Zitat

Wenn ich das richtig verstehe, hat bei diesen Methoden jedes Programm den selben Ablauf, nur die Positionen sind unterschiedlich, oder?

Richtig genau so und wie viel Stützposition du dazu machen möchtest ist auch Wurscht und auch relativ einfach gemacht. Aber wie du es am Ende umsetzt ist dir überlassen, ich Versuche immer so wenig wie möglich den Bediener mit einzubeziehen, das reduziert die Fehlerquellen. Im Produktionsstress passieren die meisten Fehler (mach mal schnell!).

Gruß

Zitat von Team Rosario

Servus,

Richtig genau so und wie viel Stützposition du dazu machen möchtest ist auch Wurscht und auch relativ einfach gemacht. Aber wie du es am Ende umsetzt ist dir überlassen, ich Versuche immer so wenig wie möglich den Bediener mit einzubeziehen, das reduziert die Fehlerquellen. Im Produktionsstress passieren die meisten Fehler (mach mal schnell!).

Gruß

Genau so, ich hab alles mögliche in meinem Array, Teilename, Positionswerte, Programmnummer für Bildverarbeitung, Teilezähler, Programmablauf (also z.B. bestimmte Maschinen nicht anfahren) da ist man eigentlich ziemlich offen.

Den Array einmal erstellen, kopieren und einfügen, dann braucht anschließend der Bediener nur noch ein paar Werte eintragen, die man dann auch nur noch auf Plausibilität prüfen muss, dann sind Fehler schon ziemlich ausgegrenzt.