Denkansätze Portallader

spskarl

Level-1
Beiträge
21
Reaktionspunkte
2
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi,

ich bin grad dran ein Be- und Entladehandling (Flächenportal) zu projektieren. Bin noch auf der Suche nach der besten Lösung (Programmieransatz). Wie würdet ihr sowas programmieren?
Das Flächenportal hat eine X, Y und Z-Achse. Der Ablauf ist immer der gleiche. Aus einem Magazin wird ein Teil genommen, in die erste Maschine gelegt. Aus der ersten Maschine rausnehmen, in die zweite Maschine legen. Falls Teil Ausschuß ist (kann bei Maschine 1 und 2 sein), dann in Ausschuß. Falls das Teil ok ist (nach dem Bearbeiten in Maschine 2), dann Teil in Entlademagazin. Es muß natürlich erst das Teil aus Maschine 2 genommen werden, bevor das Teil von Maschine 1 in Maschine 2 gelegt werden kann.
Als CPU wird eine 317DP/PN verwendet. Den Achsen sollen über Profibus nur die Positionen übergeben werden. (keine Siemens Servos, deshalb kann ich keine T-CPU verwenden).

Bin für jeden Vorschlag dankbar.

spskarl
 
Hallo,

Schrittketten ?

Grobes Beispiel

- Grundstellungsschrittkette
- Start durch Maschine 1 bereit
- Teil entnehmen
- Warten auf Maschine 2 bereit
usw....

Oder immer bei 2 Freigaben arbeiten, d.h.

Maschine 1 bereit zum entladen UND Maschine 2 bereit zum beladen =>
Übergabe SKT. starten


Daniel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bin voll und ganz mkd's Meinung, eine Schrittkette ist für diese Anwendung das Optimale. Wenn Dir S7-Graph zur Verfügung steht ist das die übersichtlichste Möglichkeit Deinen Ablauf darzustellen und auch jederzeit bequem anzupassen. Ich selbst nutzte für 4-Achsportale gerne S7-Graph.

Von der Gliederung her:
1. Initialisierung
2. Sichere Position anfahren (z. B. Hubachse nach oben)
3. Greifer mit Teil? -> zum Entladen / Greifer ohne Teil -> zur Aufnahme
4. ...

Welche Servos kommen zum Einsatz? SEW (gute Wahl)?
CPU 317PN/DP? Je nach Programmgröße würde ich die 315'er (mit FW >3.2) empfehlen. Wir haben mit S7-Graph und mehreren großen Schrittketten in der aktellen CPU keine Probleme!
 
Wie man so etwas letztendlich programmiert, sollte man doch eher mit Papier und Bleistift skizzieren.
Ich glieder solche Aufgaben in kleine Einzelabläufe (Schrittketten) und rufe dann entsprechend verschiedener Bedingungen auf, bzw. starte diese Abläufe.
Manchmal ist es auch ratsam eine Kette zu realisieren die alle anderen Schrittketten aufruft und organisert, eben je nach Aufgabe.

Die Graph Geschichten finde ich zu mächtig und habe mir 8er, 12er und 16er Schrittkettenbausteine gebaut. Im Baustein nutze ich eine Sprungleiste.

Da gibt es aber massig Lösungen und Möglichkeiten.

Die neue 315 ist schon nicht schlecht, werkelt auch in einem aktuellen Projekt.


Daniel
 
Bin voll und ganz mkd's Meinung, eine Schrittkette ist für diese Anwendung das Optimale. Wenn Dir S7-Graph zur Verfügung steht ist das die übersichtlichste Möglichkeit Deinen Ablauf darzustellen und auch jederzeit bequem anzupassen. Ich selbst nutzte für 4-Achsportale gerne S7-Graph.

Sehe ich auch so. Für solche Anwendungen ist Graph wie gemacht.
Übersichtlicher gehts kaum mehr.
Wir setzen seit Erscheinen Graph ein. Die Fehlersuche für die Instandhaltung ist damit um einiges einfacher.

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
...Die Graph Geschichten finde ich zu mächtig...

Das Stimmt das S7-Graph recht ressourcenlastig ist, jedoch überwiegen mit aktuellen CPU's die Vorteile von Graph! Zykluszeit- und Speicherplatzprobleme kenne ich in unseren Anlagen nicht und in denen mache ich sehr viel mit Graph. Auch ich nutze oft mehrere Schrittketten parallel, wie z. B. eine Hauptschrittkette, div. Funktionsketten sowie für die übergeordnete Achspositionssteuerung.
 
Für solche Aufgaben finde ich Graph7 optimal, so was habe ich schon öfter gemacht, einziger Unterschied: kein Portal sondern ein Roboter.

Die bisherigen Vorschlage für den groben Schrittkettenaufbau waren mir allerdings etwas zu "linear". Ich könnte mir durchaus vorstellen, dass, während ein Teil in Maschine 2 bearbeitet wird, schon das nächste Teil in Maschine 1 eingelegt wird, das spart massiv Taktzeit, wenn es vom Prozess her möglich ist. Auch so was lässt sich wunderbar mit Graph7 lösen. Einfach nach der Initialisierung eine Alternativ-Verzweigung, was das Portal als nächstes tun soll.

Gruß
Erich
 
Danke für die Antworten.
Ich werde mal die neue 315DP/PN testen.
Programmieren werde ich das Ganze konventionell in mehreren Schrittketten.

spskarl
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Danke für die Antworten.
Ich werde mal die neue 315DP/PN testen.
Programmieren werde ich das Ganze konventionell in mehreren Schrittketten.

spskarl

Also für ein einfaches Portal würde auch eine kleinere CPU reichen

Gruß
Dieter
 
Also für ein einfaches Portal würde auch eine kleinere CPU reichen...

Soll die CPU nur das Portal steuern, dann hat Blockmove völlig recht, das bekommst Du auch in eine kleinere CPU rein!

Welche Step-7 Version hast Du? Pro? Wenn ja, dann ist Graph automatisch dabei!

Aber mit AWL und dann mit ner Sprungliste (SPL) oder Merkern für den Schritt geht das natürlich auch. Ist nur nicht so schön übersichtlich um die Schrittkette zu verfolgen und ggf. anzupassen.
 
Ich nutze für solche Aufgaben Schrittkettenbausteine (intern als Sprungleiste ausgeführt) wie diesen:

attachment.php


- bWSB sind hier die Weiterschaltbedingungen
- bOutStep die "Schrittmerker"
- iStepNo die aktuelle Schrittnummer als INOUT Parameter, so können auch Schritte übersprungen werden
- bBusy ist true, sobald die Kette über bWSB0 gestartet wurde

Sehr Ressourcenschonend und m.M.n. übersichtlich.
Der Baustein ist schnell an weniger/mehrere Schritte angepasst.

Aber Lösungsansätze für Schrittketten gibt es hier ja viele...

Ich kann Blockmove auch nur Recht geben, die aktuelle 315 ist für ein Portal schon fast zu viel des guten.


Daniel
 

Anhänge

  • Schrittkettenbaustein.jpg
    Schrittkettenbaustein.jpg
    27,3 KB · Aufrufe: 110
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Also ich habe früher fast zu jeder Maschien eine Lader oder Portal zu steuern gehabt.
Die Idee mit Graph 7 ist nicht schlecht, aber auch in meinen Augen nicht so der bringer. Na ja Kollegen, eminten sie müssen es in ner Graph Kette machen, was dabei rasu kamm möchte ich keinem antun. Zumal die Ketten nicht logisch nach Funktionen sondern nach Abläufe aufgebaut waren. Dadurch war man halt mal wieder auf den Ablauf gebunden und nicht flexibel wie ich es immer mag.

Also ich habe da immer wenn ne Kette eingesetzt wird (egal welche art) einmal diese Kette und dann eine Job Verwaltung. Diese Job Verwaltung ist im Prinzip der Sprungverteiler oder halt der Kordinator und entscheidet was gemacht werden soll. Dies geschiet auf Anforderung bzw. anhand des Statuses des Laders / der Maschine(n) ...
 
Die Idee mit Graph 7 ist nicht schlecht, aber auch in meinen Augen nicht so der bringer. Na ja Kollegen, eminten sie müssen es in ner Graph Kette machen, was dabei rasu kamm möchte ich keinem antun.

Das hat nun aber nix mit Graph zu tun, sondern eher mit dem Können deiner Kollegen. :)
Ein solches Handling lässt sich wunderbar und flexibel in Graph realisieren.

Gruß
Dieter
 
Also ich habe früher fast zu jeder Maschien eine Lader oder Portal zu steuern gehabt.
Die Idee mit Graph 7 ist nicht schlecht, aber auch in meinen Augen nicht so der bringer. Na ja Kollegen, eminten sie müssen es in ner Graph Kette machen, was dabei rasu kamm möchte ich keinem antun. Zumal die Ketten nicht logisch nach Funktionen sondern nach Abläufe aufgebaut waren. Dadurch war man halt mal wieder auf den Ablauf gebunden und nicht flexibel wie ich es immer mag...

Ich würde das auch nicht pauschalisieren! Graph kann schon sehr viel, es ist auch kein Thema Schleifen und Verzweigungen zu programmieren und das noch überschaubar und verfolgbar! Alles eine Frage des Kettenaufbaus. Wie schon geschrieben, schreibe ich gern eine Hauptkette und rufe von dieser Unterfunktionen auf. Meine Portale sind im Funktionsumfang sehr flexibel und übersichtlich!
 
Zurück
Oben