# Tipps zur Standardisierung der Programmierung



## SPS-Guru69 (7 Juni 2016)

Hey Leute,

ich befinde mich gerade im Praxissemester und meine Aufgabe ist es Standards für die Programmierung zu finden, um diese zu optimieren (Zeit sparen, effizienter, wartbarer). Bei den Programmierumgebungen handelt es sich zum einen um das TIA-Portal V13 und zum anderen um  das e!Cockpit. Bisher habe ich Festlegungen bei der Namensgebung getroffen und allgemeine Projektabläufe definiert. Zusätzlich habe ich für das TIA-Portal eine Excel Tabelle mit Makros erstellt, die das Bearbeiten und Einlesen von PLC-Variablen erleichtert.

Allerdings sind meine Ideen jetzt am Ende, daher die Frage, welche weiteren Möglichkeiten und Mittel bestehen , um die Programmierung zu erleichtern?

Danke im Voraus
Grüße Michael


----------



## Käse (7 Juni 2016)

Hallo SPS-Guru69,

Dieses Dokument von Siemens könnte dir weitere Anregungen geben:
Programmierstyleguide für S7-1200/1500
https://support.industry.siemens.com/cs/ww/de/view/109478084

Gruß Käse!


----------



## zako (7 Juni 2016)

... auf folgender Seite ist der 
Programmierleitfaden und der
Programmierstyleguide genannt (Vorschlag für einen einheitlichen Programmierstil)

https://support.industry.siemens.com/cs/ww/de/view/81318674


----------



## bike (7 Juni 2016)

Das versuchen wir auch schon seit Jahren.
Das kann nicht funktionieren, denn es ist doch so:
Wer bezahlt schafft an.
Es wurde mit Transline2000 eine Richtung für die Autobastler zu entwickeln und das ging böse in die Hose.
(Es gab aber Higraph  )

Denkst du deine Symbolik oder deine  Beschreibungen der Abläufe können universell den Kunden aufgedrückt werden?
Was willst du machen, wenn deine Vorgaben nicht gekauft werden?
Dann hast du eine schöne Beschreibung und ein schönes? Programm, doch kein Geld in der Kasse. 

Wir geben unseren Studis auch immer wieder solch eine Aufgabe.
Weniger wegen der Lösung, sondern um zu sehen, wie die sich dem Problem annähert und entsprechende Lösungsansätze erarbeiten.


bike


----------



## EisenWolf (21 September 2016)

*Sorry*,
 bin mal klein-laut aber...

es scheitert nicht an Ideen sondern am Ego der Personen.

Frage 5 programierer und du hast 6 Wege, nach Wochen vileicht nur noch 3, aber auf einen Einigen ??????????


----------



## Accused (21 September 2016)

In unserer Firma programmieren Anlagen für Maschinenhersteller und arbeiten somit als Subunternehmer. Vor 4 Jahren begann ich mit einem Kollegen eine Standardisierung unserer Programmierung.
Verwenden wir unseren Standard und sind wir viel schneller mit der Programmierung fertig, wovon auch der Kunden profitiert, da der Projektierungsaufwand geringer ist und jeder unserer Programmierer, ohne die Maschine zu kennen,
Erweiterungen schnell und einfach implementieren kann.

Detailliert will ich nicht auf den Standard eingehen, aber wichtig ist, dass man SPS-Bausteine in Gruppen nach Ihrer Funktionalität aufteilt. Somit gibt es schon die einfache Gliederung nach Aktorik, Sensorik, usw.
Diese Bausteine erhalten eine Schnittstelle zu dem HMI, womit Bildbausteinen das jeweilige Objekt visualisiert wird. Durch diese Aufteilung ist man schon mal in de Lage jede Anlage, den mechanischen Aufbau einer Anlage nach dem Baukastenprinzip durchzuführen. Dieses Prinzip lässt sich mit allen Komponenten einer Anlage durchführen.

Angelehnt ist diese Konzept an die Objektorientierte Programmierung aus der Hochsprachenprogrammierung nur halt ohne Klassen und Vererbung.

Für deine Konzeptbeschreibung  solltest du einen ähnlichen Weg einschlagen, da dieses Konzept erfolgreich in unserem Unternehmen und bei meinem vorherigen Arbeitgeber Aumann funktioniert.

EDIT: Oh...hab gerade bemerkt, dass der Thread schon etwas älter ist, hoffe aber er ist noch relevant.


----------



## ducati (21 September 2016)

Warum die Standardisierung immer Praktikanten machen und nicht die alten Hasen, welche die notwendigen Erfahrungen besitzen, und wissen, was in dem jeweiligen Unternehmen Sinn macht, wird mir vermutlich auch fuer immer ein Rätsel bleiben...
Am Besten noch Praktikanten, die nie zuvor eine SPS gesehen haben... Nichts fuer ungut.


----------



## EisenWolf (21 September 2016)

Für mich selber Arbeite ich auch so,
Anfang - Gruppen einteilung .....
innerhalb einer Firma ist das auch mehr als sinnvoll (aleine die Fehlersuche bei Kolegen)
aber darüber hinaus sieht man schon wielange es dauert z.b. USB oder HDMI.... oder DOS, MAC oder doch WIN.
und selbst dan kan man nur hoffen keine nichen entwicklung hervorgebracht zu haben.
Wie bei Linux und ihren ganzen Ablegern.

Warum es nicht die Alten Hasen machen ist auch klar, den die wissen wie schwierig es ist und Anfänger sind doch voller Elan und Tatendrang 

Aber ein gewisser Programier standard wäre für ein Forum wie hier sinvoll und ein Anfang, zumal Fehleranalyse und Tips schneller umsetzbar wären.


----------



## bike (24 September 2016)

Ist es vielmehr nicht so, dass die Kunden verschiedene Spezifikationen haben und diese auch  geliefert bekommen wollen?
Wenn zum Beispiel zu den Autobastlern geliefert wird, dann ist jedes Werk anders.
80 Maschinen, selber Konzern aber 5 verschiedene Programme und Hardwarepläne.
Solange dies so ist, hilft Standardisierung bei den Liefertanten wenig, wer bezahlt schafft an,  das ist leider? die Realität. 

Früher dachte ich, als TL2000 kam es wird leichter.
Erare humanum est.


bike


----------



## miasma (26 September 2016)

ducati schrieb:


> Warum die Standardisierung immer Praktikanten machen und nicht die alten Hasen, welche die notwendigen Erfahrungen besitzen, und wissen, was in dem jeweiligen Unternehmen Sinn macht, wird mir vermutlich auch fuer immer ein Rätsel bleiben...
> Am Besten noch Praktikanten, die nie zuvor eine SPS gesehen haben... Nichts fuer ungut.



Weil alte Hasen gerne mal sagen...

- ich kenne alle Merker die ich brauche und habe da ein System
- das funktioniert 
- ich kenne alle Timer die ich brauche 
- das funktioniert
- ich mache das schon immer so 
- das muss in AWL sein 
- ich brauch keine Strukturen!
- das funktioniert
- ich brauche keine Doku und keine Engineering Richtlinie die anderen machen das genau wie ich  
- Du hast doch keine Ahnung 
- das funktioniert

Und damit auch gerne mal für die Ausgangslage gesorgt haben das Standardisiert werden muss/soll/wird/kann/darf usw. 

Trotzdem gebe ich dir recht das Praktikanten für den Job genauso falsch sind.


----------



## Larry Laffer (26 September 2016)

miasma schrieb:


> Weil alte Hasen gerne mal sagen...



Da hast du aber eigenartige Erfahrungen gemacht ... 8)

Da ich da auch schon so meine Erfahrungen gemacht habe ... sehe ich das genau wie Ducati ... !!!


----------



## de vliegende hollander (26 September 2016)

miasma schrieb:


> Weil alte Hasen gerne mal sagen...
> 
> - das muss in AWL sein



Ja, das sehe ich aktuell bei mir im Umfeld passieren




miasma schrieb:


> Trotzdem gebe ich dir recht das Praktikanten für den Job genauso falsch sind.



mann soll ruhig die Praktikanten ein standart machen lassen.
Dann lernen die auch
mann soll sie aber bloss nicht verwenden.

und sonnst ist für mich ein Standard Baustein eine die herstellerübergreifend ein zu setzen ist.
Und in die ganze Siemens Familie.
dann ist man wieder beim SCL.

Bram


----------



## PN/DP (26 September 2016)

de vliegende hollander schrieb:


> und sonnst ist für mich ein Standard Baustein eine die herstellerübergreifend ein zu setzen ist.
> Und in die ganze Siemens Familie.
> dann ist man wieder beim SCL.


Mit Verwendung von SCL verliert man aber einen Vorteil der Siemens-Steuerungen, daß man notfalls ohne Originalprojekt das Online-Programm unkompliziert ins Projekt zurückladen und bearbeiten kann. Baustein-Detailvergleich geht bei SCL meines Wissens auch nicht.

Harald


----------



## de vliegende hollander (26 September 2016)

PN/DP schrieb:


> Baustein-Detailvergleich geht bei SCL meines Wissens auch nicht.



stimmt ja. Nicht bis in die Quelle, wenn  du das meinst.

Bram


----------



## rostiger Nagel (26 September 2016)

PN/DP schrieb:


> Mit Verwendung von SCL verliert man aber einen Vorteil der Siemens-Steuerungen, daß man notfalls ohne Originalprojekt das Online-Programm unkompliziert ins Projekt zurückladen und bearbeiten kann. Baustein-Detailvergleich geht bei SCL meines Wissens auch nicht.
> 
> Harald



Kommt auf der Steuerung an, in der neuen Welt 1200/1500 geht es.


----------



## miasma (27 September 2016)

Mit der Verwendung von AWL verliert man aber bei den 1500er Steuerungen die Möglichkeit lange Datentypen zu nutzen. 

Konkret bedeutet das man sich einen Betriebsstundenzähler basierend auf Time + TONR bauen kann, der entweder 24 Tage und ein paar zerquetschte anzeigen kann oder basierend auf LTime + TONR  106751 Tage (> 300Jahre) anzeigen kann.
Auch bei der Verwendung von VARIANT gibt es Einschränkungen im Zusammenhang mit AWL.

Bei neuen Standards sollten auch solche Punkte im Auge behalten werden.


----------



## ducati (27 September 2016)

Also ich hätte bisher noch nie ein Problem, nen Betriebsstundenzaehler zu bauen, der mehr als 24 Tage zaehlen konnte. Auch in AWL nicht. Aber nagut. Auch wenn ich lieber SCL machen wuerde und aktuell aber AWL programmieren muss, gibt es gute Gründe fuer und gegen SCL und AWL... Haelt sich ungefähr die Waage denke ich...


----------



## miasma (28 September 2016)

Genau da liegt mein Problem, ich will mir nichts bauen müssen nur weil ich auf eine Sprache gesetzt habe die das System nicht vollständig nutzen kann. 
Wenn ich mir was bauen muss bedeutet das immer (viel) mehr Code und eine individuelle Lösung.

Setze ich hingegen auf das System und nutze es geschickt, bin ich in zwei Zeilen Code fertig plus eine 3. Zeile für das mapping in die UserInterface Struktur.




3 Zeilen mit der Sicherheit einer Systemfunktion gegen eine selber programmierte Lösung, da fällt mir die Entscheidung nicht schwer.


----------



## Thomas_v2.1 (28 September 2016)

miasma schrieb:


> Setze ich hingegen auf das System und nutze es geschickt, bin ich in zwei Zeilen Code fertig plus eine 3. Zeile für das mapping in die UserInterface Struktur.



Und hast einen Betriebsstundenzähler sich bei Warmstart der SPS auf Null setzt!

Leider ist das Anlaufverhalten der Timer weder in der Online-Hilfe nicht im Systemhandbuch dokumentiert. Man muss es also testen, das Verhalten feststellen und hoffen, dass sich auch alle anderen Steuerungen so verhalten, und sich dann auch noch darauf verlassen, dass Siemens dieses Verhalten nie mehr ändert. Was ja theoretisch möglich wäre, denn es war ja noch nie irgendwo festgeschrieben.


----------



## miasma (28 September 2016)

In dem Beispiel fehlt lediglich der Haken bei Remanenz.
Und natürlich ist das Dokumentiert sogar für die einzelnen Controller.


----------



## Thomas_v2.1 (28 September 2016)

Ich meine wie sich die Timer an sich verhalten, nicht die Remanenz. Wird ein TON/TOF etc. im Anlauf zurückgesetzt? Läuft er weiter wenn er später keine Flanke bekommt?

Die Remanenz lässt sich beim TONR auch nur einstellen, wenn es sich um eine Multiinstanz handelt. Einzelinstanz ist wohl immer "nicht remanent".


----------



## miasma (28 September 2016)

Also ich kann den Haken auch in der Einzelinstanz bei Remanenz setzen.


----------



## RONIN (29 September 2016)

Thomas hat schon Recht dass er das Anlaufverhalten der Timer auf der 1500 hinterfragt.

Da passieren die wundersamsten Sachen in Kombination mit Remanenz bei den Timern.
Ich kann mich an einen Fall vor einem Jahr erinnern, Kunde hatte einen (oder mehrere) Netzausfälle und damit CPU-Restarts und ruft an weil danach was nicht ging.
Ich schau per Remote rein und finde die Ursache bei einem T#5m-TON-Timer der eigentlich nur mit nem anderen Timer zu nem Impulsformer verschalten war. Simpel wie Brot.

Der besagte Timer hatte High am IN und hat am ET auch gezählt. Nur stand da -T#12h... (oder waren es gar -T#12D), vielleicht find ich den Screenshot noch wo.
Der Timer hätte also die 12 Stunden (oder Tage) gegen 0 gezählt bis er dann die T#5m erreicht die eigentlich Soll waren.

Ein CPU-Stop oder gar Netz-Aus hat nix dran geändert, der Timer war ja remanent gespeichert.... Keine Ahnung was da abging.
Seit dem bin ich vorsichtig geworden mit den Dingern und programmiere meist irgendwo eine Reset-Funktion ein.

Mich würde eine Beschreibung des Kalt/Warmstart-Verhaltens schon interessieren.


----------



## miasma (29 September 2016)

Ich habe noch nie Probleme mit IEC Funktionen gehabt und nutze diese schon konsequent seit ca 10 Jahren. 
Ich muss allerdings auch gestehen das ich die CPU und SCADA immer an einer USV habe um die Daten vom Netz aufzeichnen zu können. 
Das CPUs sehr empfindliche und teilweise auch nicht vorhersagbar auf mehrfache Netzausfälle oder Spannungsschwankungen reagieren ist mir bekannt. 

Das Anlaufverhalten der IEC Timer wird doch in der Doku der S7 installation beschrieben.




Oder meinst Du was anderes ?


----------



## RONIN (29 September 2016)

Ja, das ist die Beschreibung von SFB4 der 300/400er-Serie, die ist auch bekannt.
Das heißt aber noch lange nicht dass das bei dem 1500er-TON gleich ist.
Bei den ganzen Änderungen gegenüber dem alten SFB4 würde mich nicht wundern wenn man dort was geändert hat.

Dieses von die als "empfindlich reagieren" bezeichnete Verhalten ist eben das was Thomas meinte. Beschrieben ist es meines Wissens nirgens.
Da kanns auch gut sein dass dein LTIME-TONR-Betriebsstundenzähler nach dem x-ten Netz-Aus mal Blödsinn macht.
Hunderprozentig wissen tun wir's zumindest nicht.

Nur wegen der USV kannst du dich auch nicht drauf verlassen dass deinen CPU keine Kalt/Warm-Starts macht.
Gibt genug "Betriebselektriker" die im sicherheitshalber erstmal den Run/Stop oder Spannungsspecker an der CPU-bedienen.


----------



## miasma (30 September 2016)

RONIN schrieb:


> Ich kann mich an einen Fall vor einem Jahr erinnern, Kunde hatte einen (oder mehrere) Netzausfälle und damit CPU-Restarts und ruft an weil danach was nicht ging.



Jetzt mal ganz im ernst, der Timer ist schuld und nicht das schlechte Netz oder ein Betriebselektriker der nicht weiß was er macht? 

Ich selber habe in jeder Software hunderte IEC Timer und die haben noch nie nicht funktioniert. 
PCS7 als eines der größten Prozessleitsysteme am Markt nutzt intern nur IEC Timer und da funktioniert es auch. 




> Seit dem bin ich vorsichtig geworden mit den Dingern und programmiere meist irgendwo eine Reset-Funktion ein.



Das Initialisieren von Funktionen bzw. ganzer Bausteine ist doch ungeschriebenes Gesetz und wird in jeder Siemens Schulung oder Ausbildung gelehrt.

Ist es echt so schwer den Fehler mal bei seiner Lösung zu suchen und der Art und Weise wie man implementiert anstatt immer alles auf das System zu schieben? 
Ich selber stelle immer wieder fest wenn irgendwas nicht funktioniert liegt es in der Regel an *mir *und nicht an der Steuerung.

Ich hatte mal einen ganz pragmatischen Prof. der hat immer gesagt.
"Gewöhnen Sie sich dran, in 99% aller Fälle sitzt oder saß das Problem vor der Tastatur"


----------



## PN/DP (30 September 2016)

miasma schrieb:


> Jetzt mal ganz im ernst, der Timer ist schuld und nicht das schlechte Netz oder ein Betriebselektriker der nicht weiß was er macht?
> [...]
> Ist es echt so schwer den Fehler mal bei seiner Lösung zu suchen und der Art und Weise wie man implementiert anstatt immer alles auf das System zu schieben?


Deine Implementierungen sind bestimmt immer hochelegant, nur leider kommen die in realen Industrieumgebungen ohne eine USV nicht klar?

Harald


----------



## miasma (30 September 2016)

PN/DP schrieb:


> Deine Implementierungen sind bestimmt immer hochelegant, nur leider kommen die in realen Industrieumgebungen ohne eine USV nicht klar?
> 
> Harald



Doch es laufen auch Anlagen ohne und da gibt es auch keine Probleme.
Ich finde es nur echt merkwürdig Fehler immer nur bei Siemens zu suchen und nicht bei mir.


----------



## Thomas_v2.1 (30 September 2016)

miasma schrieb:


> PCS7 als eines der größten Prozessleitsysteme am Markt nutzt intern nur IEC Timer und da funktioniert es auch.



Wo soll das denn sein?

In den PCS7 Bibliotheken von V7.1 und V8, sei es die Basis Library, oder die komplette APL, wird kein einziges mal ein IEC Timer verwendet.


----------



## miasma (30 September 2016)

Thomas_v2.1 schrieb:


> Wo soll das denn sein?
> 
> In den PCS7 Bibliotheken von V7.1 und V8, sei es die Basis Library, oder die komplette APL, wird kein einziges mal ein IEC Timer verwendet.



Ein Blick in ein Projekt zeigt tatsächlich die TONs stammen von eigenen Erweiterungen, ich bin fest davon ausgegangen das auch die APL und die IL IEC Timer nutzt. 
Aber in dem Projekt funktionieren die auch wie sie sollen. 

Um noch mal auf die Timer direkt zu kommen, es kann doch nicht wirklich ernsthafte Probleme mit diesen geben.
Diese setzte ich auch schon wirklich lange ein und habe noch nie Ärger gehabt, ob mit oder ohne USV. 
Ich habe schon viele Projekte gesehen die auch alle Zeiten in IEC realisieren bzw. Bausteinbibliotheken zur verpflichtenden Verwendung bekommen die auch IEC nutzen.
Alle Zeiten im Safety Teil von S7 setzen ja auch auf IEC Timer.

Ich glaube einfach nicht das der Fehler bei Siemens als Hersteller liegt sondern eher bei mir bzw. uns als Programmierer/Betriebselektriker/Inbetriebnehmer usw.


----------



## Thomas_v2.1 (30 September 2016)

Ich verwende die IEC Timer ja auch. Nur muss man eben das Verhalten beachten. Bei der 1200/1500 ist dieses z.B. beim Anlauf überhaupt nicht definiert.
Und z.B. beim TONR hat Siemens mit dem aktuellen Betriebssystemupdate der 1500 wieder was geändert. Vorher lief der Timer bei IN=TRUE und Reset=TRUE nicht weiter, sondern erst nach einer erneuten Flanke. Bevor ich mich auf solche Späße einlasse, baue ich mir doch lieber meinen eigenen Zähler.


----------



## miasma (30 September 2016)

Thomas_v2.1 schrieb:


> Ich verwende die IEC Timer ja auch. Nur muss man eben das Verhalten beachten. Bei der 1200/1500 ist dieses z.B. beim Anlauf überhaupt nicht definiert.
> Und z.B. beim TONR hat Siemens mit dem aktuellen Betriebssystemupdate der 1500 wieder was geändert. Vorher lief der Timer bei IN=TRUE und Reset=TRUE nicht weiter, sondern erst nach einer erneuten Flanke. Bevor ich mich auf solche Späße einlasse, baue ich mir doch lieber meinen eigenen Zähler.



Ich kann das schon nachvollziehen. Vermutlich haben wir da auch eine andere Herangehensweise, das ein Timer gleichzeitig True an zwei von seinen Funktionen hat gibt es bei mir z.B. nicht.


----------



## RONIN (30 September 2016)

miasma schrieb:


> Jetzt mal ganz im ernst, der Timer ist schuld und nicht das schlechte Netz oder ein Betriebselektriker der nicht weiß was er macht?


Du als Programmierer bist sehr wohl für eine sauberes Kalt/Warmstart-Verhalten deines Programmes zuständig. Das macht gute Software aus.
Der Betriebselektriker soll schalten walten können ohne das was schiefgeht und von der USV soll die Ablaufqualität auch nicht abhängen.



miasma schrieb:


> Ich selber habe in jeder Software hunderte IEC Timer und die haben noch nie nicht funktioniert.


Was war dann die ET#-12D -Anzeige. Nicht existent? Nie passiert?
Du hast doch geschrieben dass dir bekannt ist dass Siemens-CPUs beim Kalt/Warmstart "empfindliche und teilweise auch nicht vorhersagbar" reagieren...
Wo kommt jetzt das niemals nie her?

Keine Sorge ich verwende auch ausschließlich IEC-Timer. 
Heißt aber nicht dass die problemlos sind, wie oben ja angemerkt, deshalb finde im meinen Rat zur "Aufmerksamkeit" durchaus berechtigt...



miasma schrieb:


> Das Initialisieren von Funktionen bzw. ganzer Bausteine ist doch ungeschriebenes Gesetz und wird in jeder Siemens Schulung oder Ausbildung gelehrt.


Ja komisch, sind die Siemens-Programmierer des IEC-Timers wohl nicht auch deine Schulung gegangen... 
Denn deren Funktionen initialisieren sich ja schon mal nicht sauber...

Ich würde ja nichts sagen wenn der Timer nach CPU-Neustart bei 0 beginnt, stehen bleibt oder einfach weiter läuft.
Aber wenn der Timer im negativen Bereich zu arbeiten beginnt, dann ist das wohl nicht sauber oder korrekt.

Damit ist es also die Aufgabe des Programmierens dieses *schlechte Initialisierungsverhalten *selbst abzufangen.
Wobei wieder keiner weiß wie dieses Verhalten genau aussieht, da nicht beschrieben.



miasma schrieb:


> Ist es echt so schwer den Fehler mal bei seiner Lösung zu suchen und der Art und Weise wie man implementiert anstatt immer alles auf das System zu schieben?


Hmm... ich nenne einen Fünf-Minuten-Timer der bei T#-12H(D) herumgurkt durchaus als fehlerhaft. 
Wenn du selber einen Timer schreiben würdest, würdest du ja (oben hast du es geschrieben) dafür sorgen dass er sich korrekt initialisiert?

In dem Fall wurden 2 simple Timer im FUP zu nem Taktgeber verschalten. An die Reset/Initialisierungsroutine wurde tatsächlich nicht gedacht.
Bei so nem simplen Scheiß denkt man nicht immer dran...

Wobei, im Endeffekt stimmst du mir ja zu.
Der Programmierer ist verantwortlich dass sich sein Programm sauber initialisiert, dementsprechend muss er sich auch um jeden IEC-Timer kümmern den er verwendet.
Denn wie du oben ja beschrieben hast, verhalten sich CPUs unter bestimmten (undokumentierten Bedingungen) " sehr empfindliche und teilweise auch nicht vorhersagbar".
Ich sag ja nicht dass der Programmierer in dem Fall schuldfrei war, das System aber schon ganz sicher ebenso nicht....


----------



## miasma (30 September 2016)

RONIN schrieb:


> Du hast doch geschrieben dass dir bekannt ist dass Siemens-CPUs beim Kalt/Warmstart "empfindliche und teilweise auch nicht vorhersagbar" reagieren...



Ich meine hier nicht die Fehler mit den Timern, sondern allgemein das es Probleme mit remanenten Daten geben kann wenn die CPU durch das Netz oder durch eine Person unkoordiniert ein uns ausgeschaltet wird. 


```
Du als Programmierer bist sehr wohl für eine sauberes Kalt/Warmstart-Verhalten deines Programmes zuständig. Das macht gute Software aus.
```

Ja na klar, deshalb initialisiere ich immer alles meine Bausteine vor dem ersten OB1 Durchlauf. Die USV soll ja nicht das Anlaufverhalten beeinflussen sondern lediglich dafür sorgen das ich auch Meldungen erfassen kann wenn das Netz ausgefallen bzw. dessen Qualität schlecht ist.


----------



## RONIN (30 September 2016)

miasma schrieb:


> Ich meine hier nicht die Fehler mit den Timern, sondern allgemein das es Probleme mit remanenten Daten geben kann wenn die CPU durch das Netz oder durch eine Person unkoordiniert ein uns ausgeschaltet wird.


Ja... sicher.....



miasma schrieb:


> Ja na klar, deshalb initialisiere ich immer alles meine Bausteine vor dem ersten OB1 Durchlauf.


Deshalb lass mich die Frage anders formulieren...

Wenn du einen Timer schreiben würdest und auch vollen Zugriff auf das BS hättest, würde dieser...a) Auf Grund remanenter Daten nach einem CPU-Reset mal gewöhnlich weiterarbeiten, mal aber bei negativer Zeit zu zählen beginnen?
b) Wenn ja, würdest du dieses Verhalten auch nicht dokumentieren?​
Ach ja noch was. Bei einer anderen Siemens-Schulung habe ich auch gehört das man seine Bausteine so schreiben sollte, dass diese auch bei fehlerhaften Einsatz durch den Endanwender ebenso noch in einer dokumentierten Funktion arbeiten sollen. Wieder eine Schulung die der TON-Programmierer verpassten hat...


----------



## Draco Malfoy (30 September 2016)

*Alte Hasen*



ducati schrieb:


> Warum die Standardisierung immer Praktikanten  machen und nicht die alten Hasen, welche die notwendigen Erfahrungen  besitzen, und wissen, was in dem jeweiligen Unternehmen Sinn macht, wird  mir vermutlich auch fuer immer ein Rätsel bleiben...
> Am Besten noch Praktikanten, die nie zuvor eine SPS gesehen haben... Nichts fuer ungut.



Janz  jenau so isses. Die alten Hasen wissens imma! In unserer Firma gibts  auch so ne Abteilung, wo die alten Hasen sehr zielgerichtet  standardisiert haben. Das Ergebnis dieser Standardisierung sieht dann  wie folgt aus:

- FBs oder SFBs (geschweige denn Multiinstanzen) gibts per Definition nicht;
- Lokale Daten werden nicht benutzt;
- Strukturen oder UDTs gibts keine;
- Als Datentypen gibts vorzugsweise nur BOOL und REAL;
- Alle FCs werden in AWL geschrieben;
- Es existieren nur S5 Timer;
- Kommandoanforderungen, Freigaben etc. werden an 1. Stelle gesetzt und an 20-80 nachfolgenden Stellen jeweils zurückgesetzt;
- Datenbausteine werden aus EXCEL-Listen generiert.

An dem Standard wird eisern festgehalten  (sonst werden die alten Hasen sauer). Das ganze wird dann für auch für  komplexe Servohydraulik mit  Proportionalventilen und lenrnenden Reglern und auf 417H CPUs ganz genau  so umgesetzt.
So stelle ich mir einen zukunfsfähigen Standard vor, um große, leistungsfähige Anlagen zu automatisieren.


----------



## miasma (30 September 2016)

RONIN schrieb:


> a) Auf Grund remanenter Daten nach einem CPU-Reset mal gewöhnlich weiterarbeiten, mal aber bei negativer Zeit zu zählen beginnen?​


​
Hier ist doch wirklich nicht der Timer das Problem, sondern die remanenten Daten.  
Falsche remanente Daten hätten ja auch an einer anderen Stelle für Fehler sorgen können bzw. für dessen Stillstand sorgen können. 
Ich weiß gar nicht ob man ein Remanenzproblem per OB in Classic diagnostizieren kann, um solche Probleme zu lösen oder darauf zu reagieren.


----------



## achimE (30 September 2016)

@Draco Malfoy: Oh man das kenn ich. 

Mit dieser Methode wird man NIE NIE NIE ein bestimmtes Level überschreiten. Und je komplexer die Maschinen werden um so weniger steigt man bei Merkern, fehlenden Schnittstellen und handgefertigten Schrittketten durch.


----------



## ducati (1 Oktober 2016)

Nun ja, ich kenne zwar die Hintergründe von Dracos Standard nicht, aber ich vermute, er wurde nicht erst letztes Jahr erstellt. Stammt also aus einer Zeit, als SCL und TON etc. noch nicht so "in" waren. Und wenn ein Standard erstmal in xxx Anlagen eingesetzt wurde, muss man schon sehr gute Gründe vorbringen, um ihn ueber den Haufen zu werfen. Nur mal so als Denkanstoss... Nebenbei hat der beschriebene Standard natuerlich auch Vorteile, wie hier im Forum schon oeffters diskutiert wurde...


----------



## Larry Laffer (1 Oktober 2016)

Naja ... ich denke mal, dass Draco's "alte Hasen" vielleicht auch nicht so die Super-SPS-Guru's sind. Da entsteht dann auch mal ganz schnell die Situation "never change a running System" oder "bloss nichts ändern - es könnte ja besser werden". Ich habe so etwas in der Vergangenheit auch schon mal mit erlebt und kann ihn da schon verstehen. Es hat da mal eine Zeit gegeben, wo es geheissen hat "Dokumentation und Strukturierung ist nur was für Weicheier".

Wie auch immer. Aus meiner Erfahrung ist ein gut gemachter und gelebter und weiterentwicklelter Standard eine tolle Sache.

@Draco:
Wenn ihr bei euch in der Firma solche Parolen habt dann hast du mein tiefempfundenes Mitgefühl. Ich hätte (und habe) mit so etwas auch so meine Schwierigkeiten ...

Gruß
Larry


----------



## Draco Malfoy (1 Oktober 2016)

ducati schrieb:


> Nun ja, ich kenne zwar die Hintergründe von Dracos Standard nicht, aber ich vermute, er wurde nicht erst letztes Jahr erstellt. Stammt also aus einer Zeit, als SCL und TON etc. noch nicht so "in" waren.


1982 wahrscheinlich. Schätze mal, daß sich seitdem auch nicht viel verändert hat.


> Und wenn ein Standard erstmal in xxx Anlagen eingesetzt wurde, muss man  schon sehr gute Gründe vorbringen, um ihn ueber den Haufen zu werfen.


Fortschreitender geschäftlicher Schaden für die gesamte Firma wäre da mal so ein Grund. 


> Nur mal so als Denkanstoss...


Wenn man deinen Ausführungen folgt, dann dürften wir im Serienmaschinenbau keine anderen Standards mehr vorfinden. Denn die Anfänge sind in der Regel ja nicht gestern gelegt worden.


> Nebenbei hat der beschriebene Standard  natuerlich auch Vorteile, wie hier im Forum schon oeffters diskutiert  wurde...


Das ist jetzt hoffentlich nicht dein Ernst? Es ist kein Standard, sondern ein schlechter Scherz.

Der einzige Vorteil davon ergibt sich für einen kleinen Haufen betagter Mitarbeiter, die sich kurz vor der Rente ihre Ruhe auf Kosten der gesamten Firma erkauft haben. Denn mit so einer Vorgehensweise kostet jedes Projekt locker mal das Doppelte davon, wie die Investitionen beim Einsatz von zeitgemäßen Mitteln ausfallen würden. Ich bin zwar kein Fachmann im Unternehmensconsulting, aber ich schätze das mal so. Und dieser Müll ist hinterher auch für nichts zu gebrauchen, es ist nicht migrierbar und nicht editierbar, zumindest nicht für Leute die keine S5 mehr programmiert haben.


----------



## rostiger Nagel (1 Oktober 2016)

Draco Malfoy schrieb:


> Ich bin zwar kein Fachmann im Unternehmensconsulting, aber ich schätze das mal so. Und dieser Müll ist hinterher auch für nichts zu gebrauchen, es ist nicht migrierbar und nicht editierbar, zumindest nicht für Leute die keine S5 mehr programmiert haben.



Anschließend bis du das Kücken in der Firma, dann wird es aber Zeit das du dir
von den Dinosauriern, noch ein paar Kniffe aus der S5 Zeit zeigen lässt. Ansonsten 
wird es irgendwann schwer für dich, wenn die alten in Rente gehen und ein Kunde
hat ein Problem mit einer Anlage.

Aber irgendwie verstehe ich dich, ich bekomme auch noch jedem Tag Programme
von Kollegen auf den Tisch, deren Struktur aus DB11 und DB12 für S5 Zeiten bzw.
Zählern ist, zusätzlich KOP Programm, deren Verkettung aus schlecht bzw. undokumentierten
Merkern (M 1.0 mit Symbol M 1.0) besteht, die nicht auf 2x 24" nicht darstellbar sind.

Gut das ich mit S5  aufgewachsen bin.


----------



## ducati (1 Oktober 2016)

Nunja, wie gesagt, ich kenne Euren Standard nicht und die Hintergründe und konkreten Anforderungen schon garnicht. Geh doch einfach mal zu Deinem Chef und Teile ihm Deine hier aufgeführten Argumente mit  Wenn er kein Idiot ist, sollten ihn die 50%ige Programmierzeiteinsparung schon aufhorchen lassen. Evtl. darft Du das dann im nächsten Projekt beweisen 
Zu dem beschriebenen Programmierstil, ich sagte nicht, dass er gut ist, sondern das er AUCH Vorteile besitzt. Natuerlich auch Nachteile, was man gegeneinander abwaegen sollte. Und wie RN schon anmerkte, die Altanlagen loesen sich mit dem neuen Standard nicht in Luft auf, d.h. Du musst dann 2 Programmierstile beherrschen und verstehen um auch Altanlagen warten und erweitern etc. zu koennen. Es gibt immer mehrere Sichtweisen.
Ansonsten bin ich mal davon ausgegangen, dass Deine Kollegen nicht ganz doof sind, was natürlich nicht stimmen muss


----------



## Draco Malfoy (1 Oktober 2016)

Ich habe da für mich eine Lösung gefunden und arbeite nicht nach diesem  Standard. Die Leitung drückt da ein Auge zu. Außerdem gehöre ich  offiziell nicht zu dieser Abteilung. Von den anderen Kollegen, die nicht  aus dieser speziellen Abteilung sind, ist auch kaum jemand bereit, die  Vorgehensweisen zu übernehmen.

Aber des ist zum Teil schon harter  Tobak, wenn ich sehe wie in einer Anlage mit dreistelliger Anzahl an  Proportionalventielen, einem Haufen komplexer vorgesteuerter  überlagerter Regler und hydraulischen Leistungen von mehreren Megawatt,  mit einem hochverfügbaren Rack und 417H CPU, die Software so aufgebaut  ist, daß noch nichtmals BLOCKMOVE Befehle eine Anwendun finden.  Datenblöcke werden z.B. so kopiert:


```
L DB100 DBD0
T DB200 DBD0
L DB100 DBD4
T DB200 DBD4
...
```

Ich habe für mich entschieden, dass

- Bibliotheksbausteine die ich verwende vorzugsweise in SCL geschrieben werden, 
- nur lokale Datenhaltung verwenden wird, 
- die Anzahl der DBs möglichst klein gehalten wird,
- für die Datenhaltung möglichst sinnvolle Strukturen benutzt werden,
- Schrittketten im Graph geschrieben werden,
- Komplxe Reglerstrukturen aus dem CFC kommen, um den Signalfluss grafisch nachvollziehen zu können.


----------



## ducati (1 Oktober 2016)

Wie ich das verstehe verwendest Du klassisch KOP/FUP + Graph + CFC in einem Projekt? Das KOENNTE einem Nichteingeweihtem aber auch gehöriges Grübeln bereiten. Vor allem wenn er kein Graph, SCL und CFC auf seinem PG hat  Also immer mehrere Sichtweisen...


----------



## Draco Malfoy (1 Oktober 2016)

ducati schrieb:


> Wie ich das verstehe verwendest Du klassisch KOP/FUP + Graph + CFC in einem Projekt? Das KOENNTE einem Nichteingeweihtem aber auch gehöriges Grübeln bereiten. Vor allem wenn er kein Graph, SCL und CFC auf seinem PG hat  Also immer mehrere Sichtweisen...


Bei der Kompexität der Syteme wäre es illusorisch, zu erwarten, daß man die Problemstellungen mit Mitteln von KOP/FUP alleine lösen kann. Wenns nach mir ginge, würde ich auch auch gleich in Richtung PCS7 gehen und die Programmierer verpflichten, bibliotheksfähige Bausteine so zu erstellen, daß die PCS7-fähig sind. 

Aber soweit muss man gar nicht gehen, es gibt fertigungstechnische Anlagen wo man das nicht braucht. Wichtig ist, daß man am Puls der Zeit bleibt und im Unternehmen das Bestreben existiert, möglicht die optimalen Produkte und zeitgemäße Mittel für die Umsetzung der Projekte zu bestimmen und mitzunehmen, anstatt im vorletzten Jahrhundert zu verharren.


----------



## achimE (1 Oktober 2016)

ducati schrieb:


> Nun ja, ich kenne zwar die Hintergründe von Dracos Standard nicht, aber ich vermute, er wurde nicht erst letztes Jahr erstellt. Stammt also aus einer Zeit, als SCL und TON etc. noch nicht so "in" waren. Und wenn ein Standard erstmal in xxx Anlagen eingesetzt wurde, muss man schon sehr gute Gründe vorbringen, um ihn ueber den Haufen zu werfen. Nur mal so als Denkanstoss... Nebenbei hat der beschriebene Standard natuerlich auch Vorteile, wie hier im Forum schon oeffters diskutiert wurde...



Also ich glaube das kann man nicht Standard nennen sondern Programmierstil.  Ich kann Draco voll verstehen. Bei mir wurde mit "verloren gegangener Kreativität" gegen einen Standard argumentiert.
Wie Instandhaltung, nachfolgende Kollegen damit zurechtkommen?  ..... Und alles schön mit Merkern dafür keine internen Variablen und dann noch M1.0 = "M1.0"

  Wie auch immer, ich glaube lieber einen schlechten Standard, als gar keinen.

Aber scheinbar scheint ein Nicht-Vorhanden-Sein eines Standards, mehr die Regel als die Ausnahme zu sein.  

Wobei doch alles so ähnlich ist: die meisten Maschinen bestehen aus Betriebsarten, Motoren, Zylindern, Türen, Knöpfen, einem Roboter?, einem HMI, ..... 

Unter einem Standard verstehe ich übrigens nicht was in Stein gemeißeltes, sondern eine stetige Weiterentwicklung und Erweiterung. 

Wobei es nicht nur die "alten Hasen" sind, die bremsen. Es scheint eher eine Frage zu sein wie weit der gewollte Standard dem eigenen Programmierstil entgegenkommt. Da sollte aber seit den Programmierempfehlungen von Siemens kein Diskussionsbedarf mehr bestehen.


----------



## rostiger Nagel (1 Oktober 2016)

So was ich mal hier festhalten möchte, ein guter Programierstiel oder Standard, hat nichts mit
dem Alter zu tun oder ob da die Modernsten Sprachen verwendet wird. 
Ein schlechter Programmierstil kann auch sein wenn man einfache Aufgaben, wie Binäre
Verknüpfungen, in komplexen Anlagen, unbedingt in Hochsprache machen möchte,
mit Hornbrille und Pikel im Gesicht !!!
Dann ist das Programm schlecht und Puperitäre Jüngling hat wegen seines Ausehen keinen Stil.


----------



## Larry Laffer (1 Oktober 2016)

rostiger Nagel schrieb:


> ... ein guter Programierstiel oder Standard, hat nichts mit
> dem Alter zu tun oder ob da die Modernsten Sprachen verwendet wird.
> Ein schlechter Programmierstil kann auch sein wenn man einfache Aufgaben, wie Binäre
> Verknüpfungen, in komplexen Anlagen, unbedingt in Hochsprache machen möchte ...


*ACK*

Ich würde auch sagen, das Standard heutzutage mit guter Strukturierung und guter Dokumentation zu definieren ist.
Auch dazu gehören würde m.E. z.B. das gleiche Sachen auch immer gleich heißen.
Was ich sehr gerne mache ist, dass ich mir für wiederkehrende Perepherie-Schnickeleien wie Zählerkarte, FU, Servo-Regler, Laser und und und eigene Bausteine erstelle, die so funktionieren, wie ich es brauche und setze ich dann natürlich auch immer wieder gerne ein. Oder innerhalb der Programmierung : ein FB für ein Aggregat oder eine Station hat immer den gleichen Innenaufbau und Bennung der verwendeten Strukturen.

Es gibt da viele Möglichkeiten ...

Gruß
Larry


----------



## ducati (1 Oktober 2016)

Jo... Auch wenn ich auch am liebsten immer PCS7 einsetzen wuerde, ein Standard oder ProgrammierStil ist nicht per se schlecht, nur weil er auf AWL, Merkern und Timern basiert. Wenn es wichtige Gründe dafür gibt, und er gut gemacht ist kann er im speziellen Fall sogar besser sein als was auch immer...


----------



## ducati (1 Oktober 2016)

rostiger Nagel schrieb:


> So was ich mal hier festhalten möchte, ein guter Programierstiel oder Standard, hat nichts mit
> dem Alter zu tun


Jo,
Wobei ich aber trotzdem den meisten Praktikanten die nötige Erfahrung absprechen wuerde um einen ordentlichen und auf die konkreten Bedürfnisse angepassten Standard zu erstellen...


----------



## miasma (4 Oktober 2016)

ducati schrieb:


> Jo,
> Wobei ich aber trotzdem den meisten Praktikanten die nötige Erfahrung absprechen wuerde um einen ordentlichen und auf die konkreten Bedürfnisse angepassten Standard zu erstellen...



Naja, so manchen Kollegen der seit 20 Jahren dabei ist lässt sich genauso gut mangelnde Objektivität und Flexibilität vorhalten.

Letztendlich profitieren Programmierer davon das nahezu niemand im Unternehmen ihre Arbeit bewerten kann. So das es im Grunde genommen nur zwei Arten von Programmierern gibt.

- Die die seit 20 Jahren das gleiche Programm zum laufen bringen bis es irgendwann funktioniert.
- Die die immer wieder mal an ihrem Wissen und ihrem Programm arbeiten um es einfacher zu haben.

Ich glaube der unterscheide der beiden Typen macht mehr aus als der Unterschied alt oder jung.


----------



## RobiHerb (4 Oktober 2016)

*Die zeiten ändern sich...*



rostiger Nagel schrieb:


> Ein schlechter Programmierstil kann auch sein wenn man einfache Aufgaben, wie Binäre
> Verknüpfungen, in komplexen Anlagen, unbedingt in Hochsprache machen möchte,
> mit Hornbrille und Pikel im Gesicht !!!
> Dann ist das Programm schlecht und Puperitäre Jüngling hat wegen seines Ausehen keinen Stil.



Die heutigen Prozessoren sind so schnell, dass Du im Prinzip so umständlich programmieren darfst, wie Du willst.

Die Übersicht und Struktur entscheidet, ob das System gut ist, in 10 Jahren auch von einem Aussenstehenden gewartet und modifiziert werden kann ohne dass es erst einmal tausend Tricks + Nebeneffekte erforschen muss.

Ich habe einmal in einem Software Projekt mitgearbeitet, wo einzelne Bits verboten waren! Du musstest einen Integer nehmen, um zu sagen, ein oder aus und IF und Kollegen, um Verknüpfungen zu behandeln. 

Das Projekt wurde erfolgreich abgeschlossen, war im Budget gebieben, hatte 150 Millionen in der Software gekostet und lief fast am ersten Tag der Inbetriebnahme schon problemlos, dank einer strengen Einhaltung von Normen und einer 10 Mann starken Testmannschaft, die den Source auch auf Normverstösse überwachten und zurück an den Entwickler gaben.


----------



## de vliegende hollander (4 Oktober 2016)

RobiHerb schrieb:


> Die heutigen Prozessoren sind so schnell, dass Du im Prinzip so umständlich programmieren darfst, wie Du willst.



Mann sollte aber nicht...
Im Classic, im FUP kannst du z.b.  eine riese menge an unnötige extra Code bekommen. Sicher wenn mann das umständig machst


----------



## miasma (4 Oktober 2016)

RobiHerb schrieb:


> Die heutigen Prozessoren sind so schnell, dass Du im Prinzip so umständlich programmieren darfst, wie Du willst.
> 
> ... dank einer strengen Einhaltung von Normen und einer 10 Mann starken Testmannschaft, die den Source auch auf Normverstösse überwachten und zurück an den Entwickler gaben.



Das sehe ich genauso. Leider gibt es bei Siemens nicht die Möglichkeit der statischen Code Analyse. Würde es diese Funktion geben würde Standardisierung in der SPS ein ganz neues Level erreichen.


----------



## Draco Malfoy (6 Oktober 2016)

miasma schrieb:


> Letztendlich profitieren Programmierer davon das nahezu niemand im Unternehmen ihre Arbeit bewerten kann.


 So richtig cool wird es, wenn die Leitung der eigenen Abteilung nicht mehr in der Lage ist, Deine Arbeit zu bewerten.


----------

