Step 7 Linearhandling mit SPS S7 Steuerung und Anwendungsprogramme generieren

[emilio20]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo
ich habe heute eine sehr interessante Anlage gesehen. Eine Spritzgießmaschine mir einem Linearhandling. Das Interessante was dass das Handling über eines Siemens SPS 315 gesteuert wurde. Der Anwender konnte ein individuelles Programm an einem PC über eine Software in Klartext erstellen z.b

001  Fahre X 500,0  Z 3000,0   Y 0,0
002  Warte bis PE 03 EIN
004 Fahre X 300,0
004 Springe zu 0010 Wenn  X<500,0
005 PA 001 EIN                                                      // Schalte A01 auf TRUE
006 Vak01 EIN
007 * Fahre Y 100,0 // *Verrundung
008 Warte 5sec
009 C Achse 90°
010 Warte bid PE002 EIN                                          // Warte bis E02 TRUE
usw.

Diese konnte er an die SPS senden.
Was ich herausgefunden habe das die Parameter in Byte in einen DB geschrieben wurde und es einen Schrittzähler gab. Dieser muss allerdings auch Sprungbefehle achten.

Mir ist allerding nicht ganz klar wie die Abarbeitung der einzelnen Schritte Funktioniert und wie die Klartext Struktur in Byte in einem DB kommt .

Hat jemand schon mal sowas gemacht? Würde mich mal Interessieren wie man sowas SPS seitig erstellt erstellt?

Es war so wie eine CNC Fräse allerdings nicht mir Sinumeric sondern mit eine SPS S7 315.

 

[Blockmove]

Auf der SPS-Seite lässt sich sowas mit Zustandsautomaten umsetzen.
Ich nehm dafür sehr gerne S7 Graph.
Ein Befehl (Fahre, Warte, ...) hat eine Kennung und einen Parametersatz (Geschwindigkeit, Beschleunigung, Zeit, ...).

Jetzt musst du "nur" noch einen Parser für den PC erstellen, der dir aus dem Text die entsprechen DBs erstellt.
Wenn es eine einfache "Sprache" ist, dann reichen die Stringfunktionen, wenn es komplizierter wird, dann gibt es Tools wie Lex, Yacc und Konsorten.
Aber das ist dann schon eher Compilerbau.

Gruß
Dieter

 

[zotos]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja ich habe vor langer Zet mal sowas in der Art realisiert. Allerdings würde meine Umsetzung an der einen oder anderen Stelle scheitern.

Zum Vorgehen welches ich da angewendet hatte. Im DB war ein Zweidimensionales Array. In der S7 würde ich ein Eindimensionales Array von einer UDT machen.

Mann hat also sowas wie eine Tabelle vor sich und in der 1. Spalte stehen die Befehle in den folgenden Spalten stehen die Parameter. Die Befehle und Parameter können durch Zahlen repräsentiert werden.
Jede Befehlszeile entspricht einer Zeile im Array bzw. einer UDT in der S7 Welt.

001 | Fahre    | X        | 500,0    | Z        | 3000,0   | Y        | 0,0
002 | Warte bis| PE       | 03       | EIN      |          |          |
004 | Fahre    | X        | 300,0    |          |          |          |

Das ganze arbeitet man z.B. mit einer Schrittkette Zeile für Zeile ab. Man schaut also auf den Ersten Befehl und Verzeigt in den entsprechenden Pfad. Danach werden dann Parameter für Parameter abgearbeitet.

 

[Thomas_v2.1]

So wie die Anweisungen aussehen, ist die Sprache relativ einfach und besteht so wie es aussieht nur aus sog. Terminalsymbolen.
Wenn das Parsen der Eingabe auch noch am PC und nicht in der SPS gemacht wird, hat die SPS nicht mehr ganz viel zu tun. Dort braucht nur ein kleiner Interpreter für die Sprache geschrieben zu werden.

Ich habe mal ein kleines Beispiel für einen Formelparser-/Interpreter S7 geschrieben, da laufen beide Teile in der SPS ab:
http://www.sps-forum.de/simatic/50282-einfacher-formelparser-scl.html

 

[rostiger Nagel]

Vielleicht hilft dir auch folgender Beitrag
https://a248.e.akamai.net/cache.aut...716_FAQ/59421716_T-CPU_MovePath_Editor_de.pdf

fand ich das es sehr schön gelöst würde, das Projekt könnte man
sich runterladen.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

In der S7 würde ich ein Eindimensionales Array von einer UDT machen.

In dieser Art habe ich es auch laufen.
Zusätzlich zu den Parameter gibt es bei mir auch noch Resultatfelder in die Ergebnisse nach der Ausführung gespeichert werden können.
Dazu noch eine Art "Register" für vorherigen / aktuellen / nächsten Befehl. Dies hat sich als nützlich für Sprünge oder Abfragen erwiesen.

Mit dieser Programmierung lassen sich sehr übersichtlich viele Aufgaben lösen.
Angefangen von Hnadlings über Prüfstationen bis hin zu Bearbeitungszentren.

Gruß
Dieter

 

[zotos]

...
Zusätzlich zu den Parameter gibt es bei mir auch noch Resultatfelder in die Ergebnisse nach der Ausführung gespeichert werden können.
Dazu noch eine Art "Register" für vorherigen / aktuellen / nächsten Befehl. Dies hat sich als nützlich für Sprünge oder Abfragen erwiesen.
...

Sehr guter Ansatz. Gerade wenn man sowas wie im Beispiel der 004 Zeile realisieren will, würde ich einen Vergleichsbefehl schreiben und dessen Ergebnis in der nächsten Zeile auswerten, um einen Sprung zu realisieren.

 

[Blockmove]

Sehr guter Ansatz. Gerade wenn man sowas wie im Beispiel der 004 Zeile realisieren will, würde ich einen Vergleichsbefehl schreiben und dessen Ergebnis in der nächsten Zeile auswerten, um einen Sprung zu realisieren.

Zum einen ist es für Sprünge gut und zum anderen ist es wie im richtigen Leben:
Es schadet nie, wenn man weiss was als nächstes kommt.
Ein gutes Beispiel hierfür sind Klemmungen, Zentrierungen oder ähnliches.
Ist das NC-Mass im nächsten Schritt anders, muss ich eine Teileklemmung lösen.
Ist das NC-Mass im nächsten Schritt gleich, bleibt die Klemmung zu.

Gruß
Dieter