Programmierstil / schöner programmieren?

D4K!ZZ4

Level-1
Beiträge
149
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute,

da ich ja grade wieder anfange in die SPS Programmierung einzusteigen würde ich mich freuen wenn ihr mir ein paar Tipps geben könntet wie ich mein Programm schöner machen könnte.

Schöner im Sinne von Resourcen sparend etc.

Über ein paar grundlegende Tipps würde ich mich sehr freuen.

Vielen Dank schon mal.

Gruß Chris
 
:confused: Schön und Resourcen sparen ist schon ein Widerspruch !
Ein schönes Programm ist deshalb schön, weil es gut dokumentiert und somit gut verständlich und nachvollziehbar ist. Man kann bei ihm relativ schnell die Zusammenhänge erkennen. Dies läßt sich nach meiner Erfahrung idR nicht mit knappen, Resourcen sparenden, Programmcode verwirklichen.

Wo soll der Zug also hinfahren ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Deine Frage ist hier schon zig mal durchgekaut worden und meist endet alles im SV.
Schon bei einfachen, und grundlegenden Dingen wie das Bilden der statischen globalen VKE-Merker gibt es Diskussionen.;)
Dann sind da die Verfechter der jeweiligen Programmiersprache KOP/FUP/AWL/SCL...:rolleyes:

Hier mal meine Meinung zum "sauberen" Programmieren ("schön" klingt irgendwie tuckig):
  • Keine Codetrickserei mit indirekter Adressierung, nur um auf "dicke Hose" zu machen, wenns auch einfach geht - an die Instandhalter denken!
  • Symboltabelle komplett, d.h. keine Operanden unter den Referenzdatenliste "Operanden ohne Symbol"
  • Nicht verwendete Operanden möglichst aus der Symboltabelle entfernen - schlank und gut!
  • Eingänge für die Sensorik durchgängig benennen, z.B. im Kommentar "Endschalter", "Grenztaster" oder "Efektor" - dann lässt's sich später gut Filtern
  • Gut finde ich auch den Zusatz "=0" und "=1" für Öffner bzw. Schliesserkontakte.
  • Aussagekräftige Netzwerküberschriften
  • Erst überlegen, dann programmieren - Strukturen erstellen (UDT, FB, Struct usw - das macht das Leben hinterher leichter
  • keine direkten Zugriffe auf Lokaldaten ala U #L 0.1 - wenn mal etwas nachgefrickelt wird, dann fangen die Probleme an.
  • keine globalen Zugriffe auf Instanzen - ist meine persönliche Meinung - wird hier im Forum aber kontrovers diskutiert
  • keine meterlangen AWL-Netzwerke - an die Instandhalter denken
  • binäre Logiken in SCL nachzubilden finde ich gelinde gesagt auch nicht Instandhalterfreundlich
  • SCL-Bausteine ohne Quellen als AWL-Salat abzuliefert wird von mir nicht abgenommen.
  • Funktionen kapseln und Anlagenteile per Multiinstanz zusammenfassen - macht das Programm übersichtlich. Z.B. 20x Motor-FB im Multi-FB "Rollengang xy". Ist aber auch so ein Thema wo viel drüber gestritten wird.
zum Abschuss freigegeben...:rolleyes:


P.S.: Recourcensparen? Immer gerne, aber die S5-Zeiten sind eigentlich vorbei.
Approx
 
Zuletzt bearbeitet:
... ich hätte da auch noch einen ...

Wenn man durch sein eigenes Programm, 6 Monate nachdem man es in Betrieb genommen hat, noch durch steigt dann ist es gut.

Ansonsten : siehe Oben - damit ist m.E. das Wesentliche gesagt ...
 
Deine Frage ist hier schon zig mal durchgekaut worden und meist endet alles im SV.
[*]Funktionen kapseln und Anlagenteile per Multiinstanz zusammenfassen - macht das Programm übersichtlich. Z.B. 20x Motor-FB im Multi-FB "Rollengang xy". Ist aber auch so ein Thema wo viel drüber gestritten wird.
[/LIST]zum Abschuss freigegeben...:rolleyes:


P.S.: Recourcensparen? Immer gerne, aber die S5-Zeiten sind eigentlich vorbei.
Approx

Yep, das mit dem SV stimmt.

Bei Multiinstanzen bin ich inzwischen immer skeptischer geworden, ich halte das für einen ganz üblen Irrweg, den Siemens einigen Programmierern damit ermöglicht hat. Ich hab gerade ein Programm am Wickel, da ist alles, bis hin zur Schrittkette in einer Multiinstanz je Station verpackt, ich denke mal, Schachtelungstiefe 4-5. Das ist unwartbar, unänderbar, Suchfunktionen (Querverweis) über Alles kann man komplett vergessen. Da sind wir dann auch schon bei der kontroversen Diskussion. Es ist schon interessant, wie ein an sich ganz gutes Strukturelement (Multiinstanz), durch fehlende Unterstützung (Keinerlei Querverweis möglich) und übertriebenen Einsatz (große Schachtelungstiefe, keine einzige Globalvariable, alles in der Multiinzstanz) zu einem Ärgernis pervertiert. Also Vorsicht und Augenmaß beim Einsatz, das gilt für viele Möglichkeiten, die Steuerungen so bieten.

PS: Leider gilt das Augenmaß auch für den Einsatz von struct und udt, da Siemens hier durch die mangelnde Querverweisunterstützung fuchtbar geschlampt hat.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
naja die verwendung von Multiinstanzen würde ich nicht so verteufeln, genauso
auch den zugriff auf Adressregister. Mal eben einen IEC-Timer oder Zähler in den
Bausteinkopf, finde ich schon sehr Praktisch und garnicht unübersichtlich.

Schlechte Programme kann mann man auch schreiben, wenn nur Merker und
Global DB's verwendet werden. Alles eine Frage des Stils.

Ein Zugriff auf Instanzen des FB's sind doch mit der Suche oder Gehe zu Methode
zu finden und Außerhalb des FB's sollte dann ein Vollqualifizierte Zugriff verwendet
werden.
 
Ein Zugriff auf Instanzen des FB's sind doch mit der Suche oder Gehe zu Methode
zu finden und Außerhalb des FB's sollte dann ein Vollqualifizierte Zugriff verwendet
werden.

Jawohl! :ROFLMAO: Und dann noch ein paar Struct und UDT direkt als IN und OUT an den FB anlegen, dann ist nichts mehr zu finden, glaub mir, das wird zum großen Ratespiel für Dritte. Deswegen sag ich ja, mit Augenmaß verwenden und dann kann man damit schöne Dinge tun. IEC-Timer in der Multiinstanz, genau da sind sie richtig eingesetzt, werden ja auch außerhalb nicht benötig.

PS: Du weißt, für die vollqualifizierten Zugriffe auf IDB hau ich dich! :)
 
Jawohl! :ROFLMAO: Und dann noch ein paar Struct und UDT direkt als IN und OUT an den FB anlegen, dann ist nichts mehr zu finden, glaub mir, das wird zum großen Ratespiel für Dritte. Deswegen sag ich ja, mit Augenmaß verwenden und dann kann man damit schöne Dinge tun. IEC-Timer in der Multiinstanz, genau da sind sie richtig eingesetzt, werden ja auch außerhalb nicht benötig.

PS: Du weißt, für die vollqualifizierten Zugriffe auf IDB hau ich dich! :)

die gesamte struktur einer station in einem instanzdb und die "multiinstanzen" mit UC aufgerufen ... genial! :rolleyes:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Ralle:
Du weißt schon, dass du jetzt mit der SV-Geschichte anfängst ... :rolleyes:

Was die Multi-Instanzen etc. angeht :
Wenn ich einen FB (oder SFB) in einen anderen FB einlagere mußt ich die Funktion des eingelagerten Bausteins isoliert betrachten und vor Allem betrachten können. Siehe z.B. die MI-Timer - hier ist es vollkommen egal, wie die innen drin funktionieren. Kann ich sie nicht isoliert betrachten, so hast du Recht.

Gruß
Larry
 
bei der Instanziererei bin ich bislang bei Tiefe 3 angekommen. Wenn ich mal die Mutter als Tiefe 1 betrachte. Und da finde ich bislang nichts unübersichtlich, nichts unwartbar, nichts unauffindbar. Weil gekapselt, keine Querzugriffe, weil eben "sauber" programmiert. Ausser dass bei mir die HMI direkt in die Multis reinpoken dartf ;)

Verwendungsstellen finden? Strg-Umschalt-f und Strg-Umschalt-b sind meine Freunde ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Einen Fehler, den ich leider oft mache ist, dass man sich vorhher wirklich ein durchgängiges Konzept ausdenkt. Eventuell sogar mit einfachen Ablaufdiagrammen etc. Manche Programme habe ich wohl dreimal neu angefangen weil mit es mit dem ausgedachten System nicht aufging.

Und dabei auch Gedanken machen, welche Variablen soll Global verwendet werden, was soll ich in die multiinstanz "abschieben". Z.B. einen Flankenmerker oder Timer brauche ich mmn nicht global deklarieren.

Kommentare sind wichtig, aber wenn du in einem Netzwerk ein paar Bitabfragen machst, muss man dazu keine Seite Netzwerkkommentare schreiben.
Machst du eine etwas schwierigere Berechnung, dann macht es mehr sinn drei vier Zeilen über das Netzwerk zu schreiben, als hinter jede Zeile "und hier nehme ich das mal zehn und wandle in real" zu pinnen.
Ich denke ein Kommentar sollte erklären warum an dieser Stelle diese Aktion gemacht wird und nicht wie die Aktion im Detail aussieht.
 
Ich sehe das änhlich, man kann alles irgendwie übertreiben.

Ob das ewige Bitverknüpfungen in SCL sind oder 10 geschachtelte Multiinstanzen. Schuld hat in beiden Fällen nicht das Werkzeug sonder der Anwender. Mit einem gesunden Augenmaß ist beides sinnvoll einzusetzen.
 
die gesamte struktur einer station in einem instanzdb und die "multiinstanzen" mit UC aufgerufen ... genial! :rolleyes:

Du solltest den TE doch lieber gesondert auf deine Signatur aufmerksam machen, sonst nimmt der dich noch ernst! :)

@Larry
Klar weiß ich das, aber was solls, lieber gleich als später.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Huch,

mit soviel resonanz hab ich jetzt nicht gerechnet :D

Das ein oder andere Nützliche ist auf jeden Fall dabei ;)

Vielen Dank schon mal bis hier.

Natürlich bin ich für jeden weitern Tipp Dankbar.

Gruß Chris
 
Natürlich bin ich für jeden weitern Tipp Dankbar.
Gruß Chris

Dann solltest Du wenigstens die Frage im Post #2 beantworten...
Willst Du "schööööön" (im Sinne von "sauber") programmieren, oder einen Weltrekord im Resourcensparen aufstellen? Wobei bei Letzterem heutzutage wirklich die Grundlage fehlt - es sei denn man will uralte Anlagen aufbohren, ohne Geld in die Hand zu nehmen.

Approx
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi,

ich denk schon eher an sauber.

Also Regeln für die lesbarkeit.

Oder einfach Sachen die häufig zu Fehler führen können und als schlampig gelten vermeiden. Solche Sachen eben.

Gruß Chris
 
Deine Frage ist hier schon zig mal durchgekaut worden und meist endet alles im SV.
Schon bei einfachen, und grundlegenden Dingen wie das Bilden der statischen globalen VKE-Merker gibt es Diskussionen.;)
Dann sind da die Verfechter der jeweiligen Programmiersprache KOP/FUP/AWL/SCL...:rolleyes:

Hier mal meine Meinung zum "sauberen" Programmieren ("schön" klingt irgendwie tuckig):
  • Keine Codetrickserei mit indirekter Adressierung, nur um auf "dicke Hose" zu machen, wenns auch einfach geht - an die Instandhalter denken!
  • Symboltabelle komplett, d.h. keine Operanden unter den Referenzdatenliste "Operanden ohne Symbol"
  • Nicht verwendete Operanden möglichst aus der Symboltabelle entfernen - schlank und gut!
  • Eingänge für die Sensorik durchgängig benennen, z.B. im Kommentar "Endschalter", "Grenztaster" oder "Efektor" - dann lässt's sich später gut Filtern
  • Gut finde ich auch den Zusatz "=0" und "=1" für Öffner bzw. Schliesserkontakte.
  • Aussagekräftige Netzwerküberschriften
  • Erst überlegen, dann programmieren - Strukturen erstellen (UDT, FB, Struct usw - das macht das Leben hinterher leichter
  • keine direkten Zugriffe auf Lokaldaten ala U #L 0.1 - wenn mal etwas nachgefrickelt wird, dann fangen die Probleme an.
  • keine globalen Zugriffe auf Instanzen - ist meine persönliche Meinung - wird hier im Forum aber kontrovers diskutiert
  • keine meterlangen AWL-Netzwerke - an die Instandhalter denken
  • binäre Logiken in SCL nachzubilden finde ich gelinde gesagt auch nicht Instandhalterfreundlich
  • SCL-Bausteine ohne Quellen als AWL-Salat abzuliefert wird von mir nicht abgenommen.
  • Funktionen kapseln und Anlagenteile per Multiinstanz zusammenfassen - macht das Programm übersichtlich. Z.B. 20x Motor-FB im Multi-FB "Rollengang xy". Ist aber auch so ein Thema wo viel drüber gestritten wird.
zum Abschuss freigegeben...:rolleyes:


P.S.: Recourcensparen? Immer gerne, aber die S5-Zeiten sind eigentlich vorbei.
Approx

Damit wurde m.E. schon alles gesagt. Und wenn von "Instandhaltern" gesprochen wird: Nicht nur "Instandhalter" kommen ins Straucheln, wenn ein "Profi" die Möglichkeiten ausreizt...
 
wenn hier schon wieder von "Instandhaltern" gesprochen wird:

Instandhalter müssen in der Lage sein, einen Backup und einen Restore durchführen zu können. Am Programm selbst ist normalerweise nichts instand zu halten, sodenn es vernünftig geschrieben ist. Und wenn dem Instler mein Code nicht passt, warum muss ich das dann coden, nicht er?
 
Zurück
Oben