TIA Tipps für Anfänger in der SPS-Programmierung mit Siemens S7-1200 und TIA Portal gesucht

Timur12013

Level-1
Beiträge
2
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich bin noch relativ neu im Bereich der SPS-Programmierung und wollte mal fragen, welche Tipps ihr für Anfänger habt, um sich möglichst schnell in die Thematik einzuarbeiten. Ich arbeite aktuell mit einer Siemens S7-1200 und TIA Portal, stoße aber bei komplexeren Programmen und der Strukturierung oft an meine Grenzen.

Besonders interessiert mich:

  1. Welche Best Practices gibt es, um Projekte sauber und übersichtlich zu strukturieren?
  2. Wie baut ihr eure Bausteine auf, um sie möglichst wiederverwendbar zu machen?
  3. Gibt es Literatur oder Online-Kurse, die ihr besonders empfehlen könnt?
Ich freue mich über jede Anregung und bin gespannt, wie ihr an solche Herausforderungen herangeht. Vielen Dank im Voraus!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bei Youtube gibt es eine Menge von Videos, für Anfang reicht es vollständig. Und Bedienungsanleitung für S7-1200 in PDF herunterladen zusätzlich und lesen.
 
Ich würde dir empfehlen hier etwas Konkretes einzustellen - gerade wenn es dir um Wiederverwendbarkeit geht. Dann kann man auch konkrete Vorschläge oder Anregungen geben. Ich denke mal, dass du so recht schnell reinkommst ...
 
Welche Best Practices gibt es, um Projekte sauber und übersichtlich zu strukturieren?
Die Programmier-Styleguides & Leitfäden hat @Januar bereits verlinkt, damit erschlängst du schon einmal das meiste.
Wichtig: der Siemens Programmierstyleguide unterscheidet zwischen Regeln (musst/solltest du einhalten) und Empfehlungen (kannst du einhalten).
Und: frage dazu zwei Programmierer & du bekommst drei Meinungen. Gibt diverse Treads zu diesem Thema im Forum.

Wie baut ihr eure Bausteine auf, um sie möglichst wiederverwendbar zu machen?
Siehe Siemens Programmierleitfaden Kapitel 3, allgemeine Programmierung.

Betreffend der konkreten Umsetzung kannst du dich mal in den Siemens-Bibliotheken umschauen.
Speziell die LGF-Bibliothek halte ich für relevant, dort findest du auch Bausteinvorlagen (Templates) für verschiedene Arten von Aufgaben/Bausteinen (Enable, Execute, ...) incl. Code für elegante Umsetzung von Status-/Fehlercodes.

PLCOpen wäre vllt auch noch interessant.
Die Aufmachung der Unterlagen ist allerdings etwas an Normen angelegt (sehr trocken) & komplett englisch.

Gibt es Literatur oder Online-Kurse, die ihr besonders empfehlen könnt?
Kommt drauf an, was du genau machen möchtest.
Für viele Einzelthemen hat Siemens (meistens) gute Anwendungsbeispiele.
Speziell für SCL-Anfänge fand ich "SCl Programmierung im TIA-Portal" ISBN 978-3-8343-3344-5 ganz gut, gibt aber bestimmt schon ne neue Auflage davon.
Ansonsten noch "SCL und OOP im TIA-Portal" ISBN 978-3-8007-4432-9.
 
Du hast ja explizit nach Best Practice und Tipps zum Aufbau von Bausteinen gefragt. Ich fürchte, sowas wird in den meisten Büchern nicht behandelt, weil das auch bei jeder Firma anders ist und es die eine Lösung auch nicht gibt.
Was Siemens angeht fand ich die Bücher von Berger sehr gut, aber auch da wird nicht auf diese Themen eingegangen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Naja ... im Prinzip kann man sagen : wenn man durch sein "Werk" nach 6 Monaten noch ohne Weiteres durchblickt dann ist der Code schon mal nicht soooo schlecht.
Klar ... jeder Programmierer hat so seine eigenen "Angewohnheiten" - wenn ich das aber hier im Forum so sehe gibt es aber doch bei vielen Dingen eine recht einheitliche oder ähnliche Herangehensweise ...
 
Ohne Anwendung wird es immer schwer.
Eine Hausaufgabe ist keine Produktionsanlage.
Du brauchst echte Probleme, für die du Lösungen entwickelst.
Es hilft nichts, wenn du ein Beispiel zum 186. "nachprogramierst"
 
zu 3.

Kostet zwar etwas aber sehr gut. Teilweise auch auf YT kostenlos
Das kann ich empfehlen, habe damit meinen "Wiedereinstieg" gemacht. Ist für Anfänger sehr gut geeignet, für Fortgeschrittene eher als Orientierung zu anderen Möglichkeiten und als Nachschlagewerk
Was Siemens angeht fand ich die Bücher von Berger sehr gut, aber auch da wird nicht auf diese Themen eingegangen.
Die Bücher sind definitiv Klasse aber man sollte schon Grundwissen haben um sich damit zurecht zu finden. Ich kann noch ein anderes Werk zur Empfehlung bringen @oliver.tonn
Klar ... jeder Programmierer hat so seine eigenen "Angewohnheiten" - wenn ich das aber hier im Forum so sehe gibt es aber doch bei vielen Dingen eine recht einheitliche oder ähnliche Herangehensweise ...
Das zeigt die Kreativität und die daraus resultierenden Möglichkeiten, vielmehr noch die Kompetenz hier im Forum. Hier wird für jede Lösung ein Problem gefunden ;)
 
Was sich bei mir bewährt hat ist, von Zeit zu Zeit mit etwas Abstand sich nochmal alten selbst geschriebenen Code ansehen und ggf. überarbeiten.
Da stimm ich dir zu! So sehr, dass ich nochmal einen Extra-Beitrag verfasse und es nicht nur beim "Danke" belasse ^^
Ich hab letztens mal wieder an ein Projekt von vor 4 Jahren zurückgedacht (ja, für mich ist das eine lange Zeit :D ), und was ich damals alles verzapft hab... Heute würde ich das so viel eleganter lösen...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hab letztens mal wieder an ein Projekt von vor 4 Jahren zurückgedacht (ja, für mich ist das eine lange Zeit :D ), und was ich damals alles verzapft hab... Heute würde ich das so viel eleganter lösen...
Wie heißt es so schön? Man wächst mit seinen Aufgaben.
Auch ich würde heute die eine oder andere Sache anders angehen, das geht hier vermutlich vielen so.
 
Die Motivation in einem Internetforum zu fragen, impliziert für mich, dass es keine erfahrenen Kollegen gibt, die man fragen könnte oder möchte.
In dem Fall fährt man mit dem Styleguide schon gut und sollte möglichst auch die Empfehlungen mitnehmen.
Wenn man über die Zeit merkt, dass manche Empfehlung nicht sinnvoll sind, dann ist das ok.
Aber gerade gegenüber dem Kunden hat man erstmal eine solide Basis, wenn der am Stil rummeckert. Man kann dann sagen "Das ist aber 1 zu 1 der Siemens Styleguide, so soll man das laut Hersteller machen."
Sofern der Kunde keinen eigenen Standard hat natürlich.

Ein "muss man so machen" gibt es übrigens überhaupt nicht.

Und eine ernst gemeinte Bitte... nutze unterschiedliche Werkzeuge für unterschiedliche Aufgaben.
SCL eignet sich wunderbar für geschlossene Bausteine, die vom Entwickler durchgetestet sind und für Programmierung mit komplexen Strukturen und Befehlen.

Aber es eignet sich nicht für ein Verknüpfungsprogramm, in dem 10 Variablen über ODER und UND auf eine "Spule" wirken und wo unter Umständen mal ein Dritter reinguckt, um nen Fehler zu suchen... meist unter Zeitdruck.
 
Ein "muss man so machen" gibt es übrigens überhaupt nicht.
Das ist so nicht ganz richtig, als Auftraggeber kann ich den Anlagenbauer durchaus vorgaben machen. Wie z.B. es darf kein AWL Code verwendet werden oder es muss in FUP oder STL programmiert werden. Der daraus resultierende Mehrpreis kann selbstverständlich weitergegeben werden.
Auch sind Berechtigungsebenen vorzusehen die mittels Key Pilot geschalten werden, das sind aber dann schon Funktionen die gefordert werden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
In meinen Augen viel Theorie.
Zum einen besteht, wenn der Kunde schon einen Standard hat oder Vorgaben macht, ja gar keine Notwendigkeit mehr, sich selbst was auszudenken ;)

Zum anderen hab ich es bisher auch selten erlebt, dass der Kunde auf seinem Standard beharrt hat und man das Programm wirklich umbauen oder anpassen musste. Meist konnte man sich damit der Diskussion entziehen, dass es eben ein Standardprogramm ist und man das nicht für jeden Kunden auf seinen jeweiligen Standard anpassen kann. Denn den Mehrpreis dafür, den will der Kunde in aller Regel nicht bezahlen, schon gar nicht selbstverständlich, weil am Ende kein echter Mehrwert dahintersteht.

Aber genau da ist es dann natürlich wichtig, dass man wirklich einen Standard hat und den auch konsequent umsetzt und begründen kann.
Da ist der Styleguide, als Richtlinie direkt vom Marktführer, natürlich eine ziemlich gute Argumentationsgrundlage.

AWL sollte man übrigens nicht mehr verwenden und zwar wirklich niemals und grundsätzlich nicht mehr.

Am Ende des Tages ist es wie mit Normen und Gesetzen. Man kann dem Vorschlag aus der Norm folgen, dann hat man sie erfüllt.
Oder man baut sich seinen eigenen Weg und muss dann aufwendig(st) nachweisen, dass diese Lösung den Vorschlägen in der Norm mindestens gleichwertig ist.
Wir haben uns dafür entschieden der Norm weitgehend zu folgen, unsere Abweichungen können wir gut begründen. Ist der einfachste Weg in meinen Augen.

Und dann muss man auch noch unterscheiden:
Ist es wirklich ein Standard oder eine Anforderung im Sinne einer IEC? Oder ist es "nur" good practice?
Ich darf nicht über rot fahren, das ist eine Anforderung.
"Good practice" ist es, wenn ich auf die gelbe Ampel zurolle und kurz aufblende, damit der Linksabbieger vor mir weiß, ich fahre nicht mehr drüber, er braucht nicht warten.
 
Zum anderen hab ich es bisher auch selten erlebt, dass der Kunde auf seinem Standard beharrt hat und man das Programm wirklich umbauen oder anpassen musste. Meist konnte man sich damit der Diskussion entziehen, dass es eben ein Standardprogramm ist und man das nicht für jeden Kunden auf seinen jeweiligen Standard anpassen kann. Denn den Mehrpreis dafür, den will der Kunde in aller Regel nicht bezahlen, schon gar nicht selbstverständlich, weil am Ende kein echter Mehrwert dahintersteht.
Dann warst Du aber noch nie im Automotive Bereich oder im Bosch-Umfeld (Bosch direkt oder Zulieferer) tätig. Da wirst Du mit Vorgaben/Standards bombardiert.
 
Zuletzt bearbeitet:
Zum anderen hab ich es bisher auch selten erlebt, dass der Kunde auf seinem Standard beharrt hat und man das Programm wirklich umbauen oder anpassen musste.
Ich bin jetzt zwar erst seit etwas mehr als 5 Jahren als Programmierer unterwegs, aber freie Hand bei der Programmierung hatte ich erst ein einziges mal. Und das bei einem sehr kleinen Projekt.
 
Zurück
Oben