Step 7 Gesamtmenge aus Durchfluss berechnen

[chains]

Zuviel Werbung?
-> Hier kostenlos registrieren

IF „Taktmerker_1Hz“ and Not „Flanke_Taktmerker_1Hz“ THEN
    „ZW_1l_Real“ := „ZW_1l_Real“ + („IW_L/h_Real“ / 3600.0);
    WHILE „ZW_1l_Real“ > 1.0 DO // WHILE statt IF, damit ggfs auch Überläufe >= 2.0 abgebaut werden
        „ZW_1l_Real“ := „ZW_1l_Real“ - 1.0;
        „ZW_Gesamt_in_l_DINT“ := „ZW_Gesamt_in_l_DINT“ + 1;
    END_WHILE;
END_IF;

„Flanke_Taktmerker_1Hz“ := „Taktmerker_1Hz“;

Ich habe mir 3 Änderungen erlaubt:
1. Die Leerzeichen in den VariablenNamen durch Unterstriche ersetzt.
2. Die zweite IF-Selektion in die erste integriert.
3. Die zweite IF-Selektion in eine WHILE-Schleife geändert.

Zu 1.:
"Unterbrechungen" in Namen (also auch VariablenNamen) sind bei SCL zwar zulässig, aber in sooo vielen anderen ProgrammierSprachen nicht, dass man die dort übliche Variante mit den Unterstrichen ohne Verlust an Lesbarkeit anwenden kann bzw. sollte.

Zu 2.:
Weil die Abfrage, ob die bedingte Ausführung des Übertrags erforderlich ist, nicht in allen Zyklen ausgeführt werden muss, sondern nur in den (wenigen) Zyklen, in denen sich der Zählerstand ändert.

Zu 3.:
Wegen 2. würde eine Differenz von >= 2.0 nicht mehr "nach und nach" abgebaut werden.
D.h., sollte sich - warum auch immer - eine grössere Differenz "angesammelt" haben, würde dieser Fehler beibehalten werden.

Nicht geändert:
'L' in 'l' in '„IW_L/h_Real“'.
Von der üblichen Gross-/KleinSchreibung von MassEinheiten sollte möglichst nicht abgewichen werden.
Leider hat man in diversen SchriftArten das Problem, dass z.B. 'I' (Klein-L) und 'l' (Gross-i) und evtl. auch '1' oder 'O' (Gross-o) und '0' (Null) kaum oder gar nicht zu unterscheiden *) sind, so dass Ausnahmen manchmal doch gerechtfertigt sein können.

*) Bei der Festlegung, wie die verschiedenen Zeichen in einer SchriftArt dargestellt werden, sollte m.E. der Eindeutigkeit endlich mal eine höhere Priorität vor dem Aspekt der "Schönheit" eingeräumt werden!
Ist diese Forderung denn nur in der AutomatisierungsTechnik relevant? Ich finde, man könnte sich auch in anderen Bereichen gut damit abfinden, ohne dafür grosse Opfer bringen zu müssen.

Zu 1:
Geschmackssache. Für jemanden der nur aus der TIA Programmierung kommt, spielt das erstmal keine Rolle. Ich denke viele Siemens Programmierer haben mit anderen Hochsprachen rein garnichts zutun. Meine Kollegen, grade die älteren, haben ja schon ein Problem mit SCL.
Meine Variablen werden in aller Regel aber mit _ geschrieben.
Zu 2/3:
Da nehme ich die eine Abfrage gerne in Kauf.

Was die Einheiten angeht. Ich habe Kunden die bestehen auf das kleine L weil eben korrekt, ich habe auch solche die das große, wegen der besseren Lesbarkeit bevorzugen.

 

[Heinileini]

...
4) Allgemeine Regeln zur Bildung von Variablennamen
(Unabhängig davon, ob der Hersteller der Programmiersoftware den Blödsinn irrsinniger Weise zulässt)

• der Variablennamen soll kurz aber auch möglichst selbsterklärend sein

Kurz, aber dennoch selbsterklärend? Hört sich sehr gut an, bleibt aber ein Widerspruch in sich. Leider.

Die Betonung auf 'kurz' entspricht sogar eher meinen Vorstellungen als die Betonung von 'selbsterklärend'.
Die Namen a und b für die Katheten und c für die Hypothenuse eines rechtwinkligen Dreiecks sind z.B. so geläufig, dass sie sich aufdrängen.
Sie werden verstanden und können notfalls in einem Kommentar bei der Deklaration erklärt werden.
Ich glaube, dass allein der Pythagoras in so vielen Formeln vorkommt (Geometrie und ElektroTechnik), dass das obige Heranziehen als Beispiel allemal gerechtfertigt ist.
Formeln mit extrem kurzen "VariablenNamen" sind doch nicht sooo ungewöhnlich und haben sogar einen grösseren "WiederErkennungsWert", wenn die kurzen Varianten NICHT durch ausführliche, "lesbare" Bezeichnungen ersetzt werden.

Das Thema "Sprache, in der die selbsterklärenden Namen gebildet werden", möchte ich hier hinzufügen.
Was für den einen in Spanisch selbsterklärend sein mag, kann dem anderen spanisch vorkommen.
Ein kürzlich erworbenes Medikament mit Beschriftung auf der Verpackung in Griechisch inkl. eines griechischen BeipackZettels - nein nicht im GriechenlandUrlaub, sondern in einer hiesigen Apotheke erworben, fand ich nicht so lustig.
Ich schlage Englisch vor. Weil es mir geläufig ist, aber natürlich auch, weil FachBücher, DatenBlätter, ... meistens in Englisch verfügbar sind und oft auch ausschliesslich in Englisch. Nicht zuletzt auch, weil Bezeichnungen für dies und jenes im Englischen oft kürzer bzw. platzsparender als in anderen Sprachen sind.
Auch die Erfahrung, dass Übersetzungen aus der Sprache X ins Englische oft wesentlich verständlicher sind als Übersetzungen aus X ins Deutsche, trägt dazu bei.

• Variablennamen dürfen keine Umlaute, Leerzeichen oder Sonderzeichen enthalten (einzige Ausnahme ist der Unterstrich für bessere Lesbarkeit/Strukturierung)

Umlaute lassen sich umgehen. 'ß' ebenfalls. Falls man sich z.B. auf die Sprache Englisch bei der Kreation von Namen einigen könnte, dann gäbe es diese Themen gar nicht.
SonderZeichen: eher schwierig, aber z.T. bereits jedem geläufig durch Beschränkungen bei z.B. Pfad- oder DateiNamen.
Für <, = und > sowie einige Kombinationen daraus könnte man auf die (so manchem noch) geläufigen Kürzel LT, LE, EQ, NE, GT und GE ausweichen.

Weitere Beispiele für Sonderzeichen:

• Variablennamen dürfen keine Rechenzeichen oder Klammern enthalten

Leider. Bei "Abkürzungen" wie bei Einheiten wie m/s oder l/h oder erst recht [m/s] oder [l/h] kann ich mir durchaus Ausnahmen vorstellen, die im Sinne der Lesbarkeit eher Vorteile als Nachteile bringen.
BindeStriche würden auch entfallen, weil mit dem "MinusZeichen" identisch bzw. ihm zu ähnlich.

• der Name einer Variablen darf nicht mit einer Zahl beginnen

Tja. Z.B. 1DropOnly oder 2DoList oder 2felhaft oder 8ung müssen nicht sein, würden aber auch ein wenig helfen, "kurz und dennoch selbsterklärend" zu produzieren.

• Schlüsselwörter und Funktionsnamen sind nicht erlaubt, können aber Bestandteil des Namens sein

Je mehr Funktionen dem System bekannt sind (z.B. mit Bibliotheken hinzugefügt oder durch eigene Kreationen), desto schwieriger wird es, neue Namen zu erfinden, die nicht "vorbelastet" und trotzdem verständlich sind.

Selbstverständlich sollten Namen nicht so aussehen, dass sie auf einen oberflächlichen Blick fälschlich als Formel gedeutet werden.

 

[Cassandra]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kurz und selbsterklärend schließt sich nur leider in der Regel gegenseitig aus.
Also macht es mehr Sinn sich für einen Weg zu entscheiden:

Kurz, aber dennoch selbsterklärend? Hört sich sehr gut an, bleibt aber ein Widerspruch in sich. Leider.

Oh – da habt ihr mich erwischt, wie unlogisch von mir.

Klar, es gibt nur die 2 Extreme:

P1s : BOOL; (* ein Puls jede Sekunde generiert aus dem Takt-Merkerbyte der Steuerung*)

ein_Puls_jede_Sekunde_generiert_aus_dem_TaktMerkerbyte_der_Steuerung : BOOL;

 

[chains]

Um das meinerseits abzuschließen, ich programmiere hauptsächlich Abwasseranlagen. Darum ging es hier im Ursprung wohl auch mal.

Letzten Endes juckt es mich auch nicht , was andere von meinen Variablennamen halten, aber eine kurze Erläuterung gebe ich doch.

Wie gesagt, jede Messung, jeder Antrieb bekommt bei mir einen eigenen FB.
Zb:
„FB Zulauf Durchflussmessung“
„FB Ablauf Durchflussmessung“
„FB Zulaufpumpe 1“
„FB Zulaufpumpe 2“
Usw…

Ich lege in meinen DBs (Zählwerte, Istwerte, Sollwerte…) vollständig an.
Dann wird ein FB programmiert und kopiert. Mit suchen und ersetzen wird dann nach „Zulauf“ gesucht und durch „Ablauf“ ersetzt. Klappt natürlich nur, wenn alle variablen einheitlich beschriftet sind. Außerdem müssen die Namen so vergeben sein, dass die Suchfunktion nichts verwechseln kann.
Die Netzwerkkommentare sollen ja im Klartext bleiben, deshalb habe ich alles im Klartext, im Regelfall mit unterstrich.

Habe ich viele ähnliche Aggregate, bin ich mit der Methode inzwischen ziemlich flott und kann ein Aggregat mit PLS Steuerung, Rückmeldung, Störmeldung, Handbetrieb, Betriebsstundenzähler, usw. innerhalb weniger Minuten vollständig programmieren. Automatik Ansteuerung erfolgt dann im Nachgang.

Für mich ist das aktuell eine praktikable Lösung, aber ich bin auch nur bei Siemens zuhause.

 

[Heinileini]

Kurz und selbsterklärend schließt sich nur leider in der Regel gegenseitig aus.

Das sehe ich auch so.

Also macht es mehr Sinn sich für einen Weg zu entscheiden:

Sicherlich, aber hier streiten sich schon die Gemüter.

Man kreiert kryptische Namen, die man dann im Kommentar erläutert oder man nimmt gleich sprechende Variablennamen und spart sich den Kommentar.

Mir schwebte vor 1 Kommentar dort, wo die Variable deklariert wird und nicht an jeder Stelle, wo sie vorkommt. Das bietet sich besonders bei temporären Variablen an.

Wobei ich, zwecks besserer Lesbarkeit, inzwischen auch gerne auf Unterstriche verzichte.

Die Unterstriche stammen ja noch aus der Zeit, in der es bei vielen Druckern und manchen Bildschirmen bzw. AnzeigeElementen noch keine KleinBuchstaben gab. CamelCasing ist mittlerweile sehr gut möglich und spart zusätzlich Platz, macht aber nicht jeden Unterstrich überflüssig.

Zu 1:
Geschmackssache. Für jemanden der nur aus der TIA Programmierung kommt, spielt das erstmal keine Rolle. Ich denke viele Siemens Programmierer haben mit anderen Hochsprachen rein garnichts zutun. Meine Kollegen, grade die älteren, haben ja schon ein Problem mit SCL.

Es besteht generell eine gewisse Scheu, andere ProgrammierSprachen kennenzulernen, als diejenige, die man kennt/beherrscht.
Das gilt aber bei Wechseln in beiden Richtungen: HochSprache ==> zyklische Sprache aber auch zyklische Sprache ==> HochSprache.
Sogesehen ist das Beibehalten von uralten Gepflogenheiten bei einem Wechsel doch ganz positiv wirksam!

Wenn ich von mir selbst ausgehen und mich auch zu den "älteren" zählen darf (bin Jahrgang 1950):
Mit FORTRAN IV ab 1969 und etwas später ALGOL 60 hatte ich schon zu tun 14 Jahre bevor ich zyklische Sprachen wie S5 oder FANUC-Ladder kennengelernt habe.
Aber auch mit AssemblerSprachen, diversen BASICs und COBOL hatte ich beruflich zu tun. Zunächst privat habe ich auch Bekanntschaft mit C und PASCAL gemacht und später beruflich und sogar in zyklischen Anwendungen (FANUC) benutzt.
Ich hatte aber auch mit HardwareEntwicklung (überwiegend TTL-Technik) zu tun, so dass mir z.B. diverse FlipFlop-Arten oder SchiebeRegister durchaus vertraut waren.
Mein Fazit: einige Wechsel können durchaus sehr angenehm sein, manche weniger erstrebenswert bis hin zu unangenehm.

Meine Variablen werden in aller Regel aber mit _ geschrieben.

OK, warum auch nicht?

Zu 2/3:
Da nehme ich die eine Abfrage gerne in Kauf.

Welche?

Was die Einheiten angeht. Ich habe Kunden die bestehen auf das kleine L weil eben korrekt, ich habe auch solche die das große, wegen der besseren Lesbarkeit bevorzugen.

Gross vs. klein ist beim L extrem wegen der Zweideutigkeit des Klein-L. Aber besteht ein Grund, z.B. aus MilliSekunden MegaSekunden oder MegaSiemens oder sogar MilliSiemens zu machen? Wäre ein 'µ' sooo schlimm, dass man es als Sonderzeichen verbannen müsste, um statt µF lieber mF oder sogar MF oder uF zu schreiben?

...
Klar, es gibt nur die 2 Extreme:
...

Na klar gibt es 2 Extreme, aber auch so manche ZwischenStufe!
Sich nur zwischen den Extremen entscheiden zu müssen, wäre doch viel zu einfach!

Wie änderst Du 'P1s' ab, wenn's PulsProHalbeSekunde sein soll?
'P1/2s' geht nicht. 'P0,5s' und 'P0.5s' auch nicht. 'P500ms' ginge aber und (die halbe s) ist gut lesbar. Und 'P5ds' (deziSekunden) wäre richtig schön kurz, aber (für mich) kaum lesbar.

Außerdem müssen die Namen so vergeben sein, dass die Suchfunktion nichts verwechseln kann.

Unter Berücksichtigung der Gross-/KleinSchreibung können Namen unterschiedlich sein, die beim Ignorieren der Gross-/KleinSchreibung identisch werden.
Wonach sollte man streben? Sollte man darauf bestehen, dass SuchFunktionen wahlweise mit oder ohne o.g. Berücksichtigung suchen können? Oder darauf bestehen, dass sie generell auf beide prüfen und generell beide Ergebnisse anzeigen?
Früher war es üblich, dass SuchFunktionen eindeutig sagen konnten "den gesuchten Eintrag gibt es nicht". Heutzutage traut man sich oft nicht, den Benutzer so herb zu enttäuschen und bieten deshalb jede Menge PseudoVergleichsErgebnisse an. Um festzustellen "gibt's nicht" muss dann die unterbreiteten, schwachsinnigen Vorschläge alle zu Fuss durchgehen und prüfen.
Die "WildCards" waren doch so schön und so effektiv ... warum wurden sie verdrängt?

Für mich ist das aktuell eine praktikable Lösung, aber ich bin auch nur bei Siemens zuhause.

Sooo "unzuhause" sind doch andere Systeme/Sprachen bezüglich der Schreibweise von Namen auch nicht!?
Spätestens dann nicht, wenn man sich - gezwungenermassen oder freiwillig - auf bestimte Regeln bzw. Beschränkungen einigt.

 

[Januar]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kurz, aber dennoch selbsterklärend? Hört sich sehr gut an, bleibt aber ein Widerspruch in sich. Leider.

Da verweise ich immer gern auf die Prinzipien der Messtechnik. Nicht so genau wie möglich, sondern so genau wie nötig
Ich für meinen Teil finde die Konventionen ganz in Ordnung, die BigS im Styleguide aufführt.
- Englisch als Sprache für Variablen
- a-z, A-Z, 0-9 sowie _ als erlaubte Zeichen
- maximal 24 Zeichen pro Name

 

[Timbo]

Guten Morgen zusammen,

ich danke für die schnelle und gute Hilfe.
Ich habe den Code in einen FB verpackt und getestet. Das Ergebnis ist wirklich gut.
Ich habe es auch mit dem alten Step 7 Totalizer verglichen und gesehen das das Ergebnis bei dem Code von euch genauer ist.

Hintergrund ist das ich in meinem Durchflusssensor auch einen Mengen Zähler habe. üblicherweise gibt dieser einen Puls pro Liter aus. dieser Ausgang ist allerdings defekt. Somit habe ich euren Code verwendet. Wie so oft muss natürlich das Ergebnis auf der HMI mit dem des Messgerät übereinstimmen.

Also vielen Dank noch einmal.

Das ich jetzt hier eine Grundsatz Diskussion über Style los gebrochen habe tut mir leid. Ich finde die Diskussion sehr interessant glaube aber das sie hier im falschen Trade ist.
Wir führen die Diskussion bei uns in der Firma auch oft. Leider ist es schwierig DAS perfekte System zu nutzen da es für viele Schreibweisen gute Argumente dafür oder dagegen gibt.
Ich habe den Code von euch auf unser System angepasst. Ich glaube der wichtigste punkt ist das es innerhalb einer Software harmonisch ist. wenn in einem Code unterschiedliche Systeme genutzt werden wird es unübersichtlich und verwirrt am ende nur das Wartungspersonal unnötig.

 

[PN/DP]

Übrigens gibt es einen Integrator-Baustein und dessen SCL-Quelltext schon fertig für TIA von Siemens: LGF_Integration. Ab welcher Version der halbwegs fehlerfrei ist, weiß ich aber gerade nicht. Ich kann mich gerade nur erinnern, dass wir hier mehrmals drüber diskutiert haben.
Und ob der Baustein auch einsatzfertig zur SPS und zum Programmiersystem von @Timbo passt, weiß ich auch nicht, da er dazu keine Angaben gemacht hat. Auf jeden Fall müsste da noch eine eigene Pulserzeugung dazugestrickt werden.

 

[Timbo]

Zuviel Werbung?
-> Hier kostenlos registrieren

Oh danke für die Info. dann habe ich den entweder übersehen oder in meiner Version liegt der noch nicht vor.
kannst du mir sagen wo ich die aktuelle LIB her bekomme? Meine Version habe ich vor langer Zeit einmal von einem Kollegen erhalten.

Ich verwende eine Siemens 1500er CPU mit TIA V17.

Ja den Pulsausgang habe ich mir gespart da dieser nur auf einen Zähler gesetzt wird. So habe ich den Zähler entfernt und direkt den Wert beschrieben.

Aber Danke für den Hinweiß.

 

[PN/DP]

Die LGF findet man immer hier:
Bibliothek mit generellen Funktionen (LGF) für SIMATIC STEP 7 (TIA Portal) und SIMATIC S7-1200 / S7-1500