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...
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...
P.S.: Recourcensparen? Immer gerne, aber die S5-Zeiten sind eigentlich vorbei.
Approx