Programming Guidelines and Programming Styleguide for SIMATIC S7-1200 and S7-1500

[ADS_0x1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Forum,

Siemens hat die im Betreff genannten Guidelines herausgebracht, ich habe nach Suche im Forum nichts entdeckt (und war mir zugegebener Maßen unsicher, ob das nun hierher gehört oder in den Stammtisch).

Ich stelle den Link dazu mal hier ein, da es bisher noch keine Diskussion/Aufschrei/Lob/Kritik/Hinweis dazu gab.
[h=1]Programming Guidelines and Programming Styleguide for SIMATIC S7-1200 and S7-1500[/h]
Unter anderem um den Styleguide wird es bei den "Wissen kompakt"-Veranstaltungen in nächster Zeit gehen.

Viele Grüße!

 

[Draco Malfoy]

Ich habe diesen StyleGuide mir mal zu Gemüte geführt, ich finde, das ist harter Tobak. Es wird dadrin z.B. gefordert, auf den Gebrauch externer Quellen zu verzichten, und bei SCL ausschließlich Auto-Formatierung anzuwenden. Das würde ja zum Teil fast schon in Unlesbarkeit des Codes münden.

 

[zako]

Zuviel Werbung?
-> Hier kostenlos registrieren

... wenn ich mir den Styleguide durchlese, habe ich auch das Gefühl dass der aus einen hausinternen Vorgabe hervorging ( SCL; konsequent englisch; ...)
Andererseits hilft es schon wenn z.B. Bausteinkopf vorhanden ist (macht auch nicht jeder und v.a. auch mit allen notwendigen Info´s); Vorgaben für Variablennamen gemacht werden (damit man weiß ob es z.B. ein IN/OUT, TEMP; STAT; Konstante etc. ist). Wenn Vorschläge drinn sind, die auch zu einen effizienteren Betrieb der Steuerung führen, schadet es ja auch nicht.
Vielleicht gibt es ja hier ja noch weitere Meinungen (man kann ja auch mal schreiben was man gut findet und was man lieber anders macht (vielleicht auch warum)).

 

[Wincctia]

Hallo Beisammen,

muss sagen gibt wirklich gute Punkte z.b. das Warnungen zu vermeiden sind oder der Begriff was ein In InOut und ein Out ist einzuhalten sind. Muss sagen mittlerweile hab ich das gefühl das sich 99% aller Programmierer nichts darum kümmern und das Thema für einen Chef so abstrakt ist das er sich mit einen geht nicht anders abspeisen lässt.


Mit freundlichen grüßen Tia

 

[rostiger Nagel]

Diesen Stylguide finde ich als Ansatz nicht schlecht, ich setze ihn Teilweise um.
Zb für Constantan nur Großbuchstaben zu verwenden, kann doch hilfreich sein.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dieser Styleguide scheint so "gut" zu sein, dass nicht mal Siemens selber sich daran orientiert.
Oder hat schon mal jemand eine Siemens Bibliothek oder Codebeispiele gesehen, wo sich daran gehalten wird?

Ich vermute eher, das Erstellen des Dokuments ist ein Praktikantenprojekt gewesen.

 

[PN/DP]

Siemens hat die im Betreff genannten Guidelines herausgebracht, ich habe nach Suche im Forum nichts entdeckt

Die genannten Programming Guideline und Styleguide wurden hier im Forum schon öfters verlinkt, allerdings ohne Begeisterungsstürme sondern eher wegen den darin enthaltenen zahlreichen Fehlern :sad:

Suchbegriffe: 81318674, Programmierleitfaden, Styleguide

Harald

 

[Draco Malfoy]

Dieser Styleguide scheint so "gut" zu sein, dass nicht mal Siemens selber sich daran orientiert.
Oder hat schon mal jemand eine Siemens Bibliothek oder Codebeispiele gesehen, wo sich daran gehalten wird?

APL und BL sind von der Kommentarsprache intern größtenteils auf Deutsch verfasst. Auch die Variablennamen genügen nicht diesem Kodex.

Ich vermute eher, das Erstellen des Dokuments ist ein Praktikantenprojekt gewesen.

Das vermute ich auch.

 

[ADS_0x1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi Leute und danke für die Diskussion!

Ich muss mich einigen Meinungen hier anschließen, a la 99% der Programmierer halten sich eh nicht dran, u.a. die Programmierer von Siemens selber

Und dann sind einige Stellen, bei denen ich denke: "Das darf doch nicht war sein, das regt mich auch immer auf, wenn ich das irgendwo sehe". Andererseits sind da auch Dinge unter einer "Rule" aufgeführt, die ich so nicht mache und auch nicht machen werde.

Konkrete Beispiele aus dem Dokument:

- no global constants

Ich habe globale Konstanten (pi, pi halbe, pi viertel, Wärmeleitkoeffizienten usw...). Diese verwende ich allerdings nicht in mehrfach verwendeten Bausteinen, sondern in den "Sammel-FBs" einzelner Anlagenteile

- no prefix for formal parameters

Ich mache das anders als vorgeschlagen... meine Eingänge haben eine Präfix-Struktur wie bspw. i_b_LichtschrankeEinlauf

- Data exchange via block interfaces - Direct access to Static tags outside the FB is prohibited (und dann noch der Hinweis, dass nicht auf globale Merker zugegriffen werden darf)

JA VERDAMMT! Es ist unglaublich, wie viele Leute das eben genau NICHT einhalten. Und das nervt unglaublich. Das schlimme ist noch, dass das nur schwer Querverweis-fähig ist. Wenn ich z.b. folgende Struktur habe:

OB > FB1 > FB2

Dann muss ich im FB2 eine static nicht mit komplettem Namespace ansprechen ( #zaehler als Beispiel ). Greift man nun außerhalb auf diese Variable zu, wird diese unter FB2.zaehler geführt und auch nur diese Querverweise werden angezeigt. Dem kommt man teilweise nur schwer auf die Schliche. Einzige Todsünde, die noch darüber steht: globale Merker in einem Know-How-geschütztem Baustein verwenden

Ansonsten steht da viel hilfreiches, vieles, was ich verstehe, aber vieles, bei dem ich es anders mache und auch weiß, dass (aus gutem Grund) es andere auch nicht befolgen.

 

[Thomas_v2.1]

- Data exchange via block interfaces - Direct access to Static tags outside the FB is prohibited (und dann noch der Hinweis, dass nicht auf globale Merker zugegriffen werden darf)

JA VERDAMMT! Es ist unglaublich, wie viele Leute das eben genau NICHT einhalten. Und das nervt unglaublich. Das schlimme ist noch, dass das nur schwer Querverweis-fähig ist. Wenn ich z.b. folgende Struktur habe:

Das Schreiben auf die Instanzdaten von außen ist selbst bei neuen Siemens-Bausteinen für die 1500 notwendig. Ich meine das habe ich bei den Modbus RTU Bausteinen machen müssen, vor allem an der Stelle völlig unnötigerweise.

Ich habe mich erst beim Erstellen meiner ersten Standardbausteine für die 1500 daran etwas orientiert, also mit SCL, Variablenbezeichnungen, Kommentarbereich im Kopf usw. angeht. Dann muss kein separates Dokument für die Firma geschrieben werden. sondern kann sich direkt daran orientieren was ja auch Arbeit erspart. Aber vieles darin passt dann doch nicht oder würde ich niemals (wieder) so machen, und Siemens macht es ja auch nicht. Also dann lieber wieder etwas eigenes an der Praxis orientiertes verfassen, was dann auch nicht durch so viele Trivialitäten aufgebläht ist.

 

[zako]

... hat schon mal jemand eine Siemens Bibliothek oder Codebeispiele gesehen, wo sich daran gehalten wird?...

Schau Dir mal den "Axis Control Block" an. Ich finde das ist ein recht gutes Beispiel wie ein Programm aussehen sollte, bzw. wie man eine umfangreichree Funktionalität umsetzen kann (Auslieferung als Lib; mit entsprechenden UDT´s; "eigener Ordner" Baustein mit eigenen Errorcodes; Datenaustausch über Bausteinschnittstellen ...).
https://support.industry.siemens.com/cs/ww/en/view/48816191
Ich bin jetzt auch nicht der absolute Programmierprofi, von daher orientiere ich mich gerne an diesen Baustein. Aber wenn Dir hier was auffällt was besser im Sinne eines Styleguides umgesetzt sein sollte, würde mich das interessieren.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich bin jetzt auch nicht der absolute Programmierprofi, von daher orientiere ich mich gerne an diesen Baustein. Aber wenn Dir hier was auffällt was besser im Sinne eines Styleguides umgesetzt sein sollte, würde mich das interessieren

Auf den ersten Blick: Block Autonumbering nicht aktiviert bei den Bausteinen. Steht aber so im Styleguide. Und wahrscheinlich noch zig Sachen mehr wenn man danach sucht und in den Quellcode schauen könnte

Wenns nach mir ginge hätte ich diese Nummern in bei der 1200/1500 überhaupt nicht mehr eingeführt, das ist nur nervig und völlig unnütz.

 

[zako]

... der ist sogar mit Sourcecode. Aber ich verschalte nur die Ein-/Ausgänge um eben Motion Control Funktionalität möglichst einfach und schnell umzusetzen.

 

[Thomas_v2.1]

... der ist sogar mit Sourcecode.

Gut zu wissen, muss ich morgen mal reinschauen. Bin grad eh daran zu Lernzwecken etwas mit Motion Control rumzuspielen.

 

[rogseut]

Zuviel Werbung?
-> Hier kostenlos registrieren

Auf Anfrage gibt's bei Siemens einen Styleguidechecker. Dieser prüft den Code auf Übereinstimmung mit den Leitfaden. Damit auch der Auftraggeber ganz simpel überprüfen kann was er für sein Geld gefordert hat.

 

[maxder2te]

Der deutschsprachige Styleguide liegt übrigens hier:
https://support.industry.siemens.co...ür-simatic-s7-1200-und-s7-1500?dti=0&lc=de-WW

Bei uns im Betrieb (> 80 SPS-Programmierer) hat sich die Standardisierungsrunde darauf verständigt, dass der Styleguide und der Leitfaden mit kleineren Einschränkungen einzuhalten ist, vor allem in Bezug auf die Benennung der Datentypen und Variablen, Autonumbering, optimierte Bausteine, usw.

Für Leute, die jahrelang mit S7-300 und AWL gearbeitet haben und faktisch nichts anderes kennen, ist das wirklich harter Stoff. Für jemanden wie mich, der auch mit B&R, Rockwell und ein bisschen CoDeSys gearbeitet hat, ist der Umstieg natürlich etwas einfacher. Dort hat man sich an das konsequente "symbolisch und optimiert" arbeiten ja gewohnt, und das Zugreifen auf Instanzdaten ist. i.d.R. ohnehin nicht möglich.
Natürlich wird es immer Dinge geben, die mit absolutem oder indiziertem Zugriff kompakter oder schneller sind, aber wenns daran scheitert sollte man sich ernsthaft überlegen, ob man nicht den Siemens-Zug verlassen sollte.

 

[zako]

Bei uns im Betrieb (> 80 SPS-Programmierer) hat sich die Standardisierungsrunde darauf verständigt, dass der Styleguide und der Leitfaden mit kleineren Einschränkungen einzuhalten ist, vor allem in Bezug auf die Benennung der Datentypen und Variablen, Autonumbering, optimierte Bausteine, usw.

... da gehe ich mal davon aus, dass Ihr Euch das ernsthaft angeschaut und bewertet habt.
Andere Meinung aus dem Forum:

Ich habe diesen StyleGuide mir mal zu Gemüte geführt, ich finde, das ist harter Tobak.

Ich vermute eher, das Erstellen des Dokuments ist ein Praktikantenprojekt gewesen.

Die genannten Programming Guideline und Styleguide wurden hier im Forum schon öfters verlinkt, allerdings ohne Begeisterungsstürme sondern eher wegen den darin enthaltenen zahlreichen Fehlern
Harald

Also Fehler konnte ich da nicht entdecken und einem Praktikanten (allein) traue ich so ein Thema nicht zu. Aber mit solchen Themen (wie auch "Standardisierung" ) kann man sich schöne blutige Nasen holen (und war überrascht dass sich jemand das antut). Aber am schönsten sind Diskussionen über Styleguides für HMI- Oberflächen (da fallen meiner kleinen Tochter wahrscheinlich auch noch Vorschläge ein ("die Button´s könnten doch rosa sein")).

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich nehme alles zurück. Wenn das >80 Programmierer gut finden, dann muss es das Beste sein was es gibt.

Die einzige Empfehlung an die ich mich nicht halte: Programm übersichtlich und strukturiert gliedern.

 

[PN/DP]

Also Fehler konnte ich da nicht entdecken und einem Praktikanten (allein) traue ich so ein Thema nicht zu.

Guideline und Styleguide gibt es schon länger (seit 2013). Einige besonders krasse Fehler haben wir hier im Forum thematisiert, z.B. hier. Manchen Fehlern sieht/sah man an, daß sie von Leuten mit nur theoretischem Wissen aber fast keiner praktischen Erfahrung verzapft wurden.

Vielleicht findest Du in den aktuellen Dokumentversionen keine Fehler, doch schaue mal in die Historie der Dokumente. In jeder neuen Version steht bei Änderung: "Korrekturen in folgenden Kapiteln", "Diverse Korrekturen in unterschiedlichen Kapiteln", "Anpassungen und Korrekturen".

Harald

 

[PN/DP]

Seit 2013 gibt es auch folgende Empfehlungs-Sammlung:
Wie können Sie in STEP 7 (TIA Portal) für die S7-1200/S7-1500 effizient und performant programmieren?

(Ob die Einzelempfehlungen vielleicht mittlerweile in die Guides übernommen wurden habe ich jetzt nicht gecheckt.)

Harald