Tipps zur Standardisierung der Programmierung

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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

 

[RONIN]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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.

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...

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.

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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.....

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]

Alte Hasen

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

@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]

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]

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