TIA S7 - 1200: Drehzahlmessung über Impulse

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja, den Überlauf herausrechnen muss man bei TIME_TCK. Aber wie so siehst du darin einen Vorteil gegenüber RUNTIME, wo so etwas gar nicht notwendig ist?

Nicht notwendig? Ich meine, es ist notwendig, aber nicht möglich, weil Siemens nicht dokumentiert, wie groß der negative Sprung beim Überlauf ist. Warum wohl schreibt Siemens, daß es bei RUNTIME zu negativen Werten kommen kann, die man einfach ignorieren soll? Wenn Siemens einfach den ganzzahligen Zählerstand des Systemtimers liefern würde (wie bei TIME_TCK), dann wäre das Herausrechnen des Überlaufs recht simpel. RUNTIME liefert aber LREAL.

Ich habe RUNTIME noch nie auf einer echten S7-1500 ausprobiert, nur in PLCSIM V15.1, und da hatte das PLCSIM ständig Fehlfunktionen. Ich meine, ich hatte mal auf einer echten S7-1200 unter TIA V15.1 getestet, da war das noch ziemlich buggy. Im Zusammenhang mit dem Siemens-LGF-Integral-Baustein hatten wir auch mal einen Thread, wo ein User das RUNTIME mit einer echten SPS getestet hat, da kam auch nur Müll bei raus. Wie sich RUNTIME seit V16 verhält, weiß ich nicht.

Beim Fragesteller hier wäre es aber nicht so schlimm, wenn RUNTIME tatsächlich auch mal negative Werte liefern würde - da wäre es tatsächlich am einfachsten, das negative Ergebnis zu ignorieren und die Drehzahl einfach vom Messzyklus vorher weiter anzuzeigen.

 

[DCDCDC]

Wie sich RUNTIME seit V16 verhält, weiß ich nicht.

Generell - wäre das nicht eher ein Firmware Thema als ein IDE Thema? Man kann ja in bestimmten TIA Portal Versionen nur bis zur Firmware x projektieren.. deswegen denke ich, dass sowas nicht am Portal liegt, sondern eher in der Firmware der CPU. Aber das übersteigt das Thema der Diskussion hier

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Man kann ja in bestimmten TIA Portal Versionen nur bis zur Firmware x projektieren.. deswegen denke ich, dass sowas nicht am Portal liegt, sondern eher in der Firmware der CPU. Aber das übersteigt das Thema der Diskussion hier

Klar ist das ein Firmware-Thema. Es geht hier um eine von der CPU-Uhr unabhängige Zeitmessung zur Laufzeit des SPS-Programms mit der Anweisung RUNTIME. Ich verstehe nicht, was das mit der IDE des TIA-Portals zu tun hat? Die korrekte/ungestörte Zeitmessung ist essentiell für das Thema hier.

Die Anweisung RUNTIME wurde für S7-1200/1500 neu erfunden als Ersatz für die legacy Anweisung TIME_TCK, damit die Anwender nicht selbst subtrahieren und auf Sekunden skalieren müssen. Grundsätzlich keine schlechte Idee. Aber wieso kann die Anweisung dabei nicht selbst den Überlauf des Systemzeitgebers herausrechnen? Wieso schreibt Siemens, daß der gelieferte Wert der Zeit-Differenz auch mal negativ werden kann? Für mich ist das ein Fehler in der Implementation der RUNTIME-Anweisung, den die TIA-Entwickler anscheinend hartnäckig ignorieren (oder die Dokumentation ist falsch).

 

[Onkel Dagobert]

.. Warum wohl schreibt Siemens, daß es bei RUNTIME zu negativen Werten kommen kann, die man einfach ignorieren soll? ..

Wo schreibt Siemens denn das? In der Online-Hilfe finde ich diese Aussage nicht, jedenfalls nicht beim Überfliegen. Die Aussage von Tschoke in #17 betrifft vermutlich eine Fehlerbeschreibung der 1200er in der Firmware kleiner 4.2. Der Fehler ist inzwischen hoffentlich behoben.

.. Ich habe RUNTIME noch nie auf einer echten S7-1500 ausprobiert ..

Ich hundertmillionenfach . Ich verwende RUNTIME seit meinem Umstieg auf TIA V14 überall in meinen Standard-Bausteinen. Das sind PID-Regler, PTn-Glieder, Zähler, Universaltimer etc. Es gibt keinen Messwert, keinen Energiezähler, der bei mir nicht von RUNTIME beeinflusst wird. Ich habe absolut keine Probleme mit RUNTIME. Daher kann ich deine schlechten Erfahrungen nicht nach vollziehen. Allerdings, und das habe ich eben gerade noch einmal in den wichtigsten meiner Bausteine überprüft, führe auch ich eine Plausibilitätsprüfung durch. Wenn die ermittelte Abtastzeit nicht im erwartetem Bereich liegt, wird sie verworfen, d.h. es wird mit der letzten gültigen Abtastzeit weiter gerechnet, was i.d.R. kaum ins Gewicht fällt, sofern es überhaupt auftreten sollte. Ich bin mir jetzt nicht sicher, ob ich das wirklich nur als Vorsichtsmaßnahme tue, oder ob ich das auch irgend wo mal gelesen habe. Auf jeden Fall behalte ich das so bei. Bei der S7-Classic bin ich mit der durch TIME_TCK ermittelten Abtastzeit genau so verfahren. Dort natürlch bekanntermaßen mit vorheriger Berechnung und mit Korrektur bei Überlauf. Ich weiß jetzt auch nicht aus dem Hut, was mit TIME_TCK oder mit RUNTIME bei Neustart oder bei Netzwiederkehr passiert. Solche Fälle werden durch eine Plausibilitätsprüfung ja dann auch weitestgehend erschlagen.

Ich werde demnächst mal einen kleinen Testbaustein mitlaufen lassen, der derartige Fehler-Fälle zumindest erkennt und zählt.

Vor allem möchte ich aber andere ermutigen, RUNTIME zu verwenden.

 

[PN/DP]

Ja Onkel. Es wäre schön, wenn sich mal jemand findet, der RUNTIME auf einer echten 1500-CPU etwas testet. Ich habe leide keine 1500 zum spielen zur Verfügung. Also am einfachsten, einen Zähler programmieren, wie oft RUNTIME einen negativen Wert ( < 0.0 ) oder extrem/unplausibel groß liefert und das ganze mal 1..3 Monate laufen lassen.
Ich kann mir ehrlich gesagt nicht vorstellen, wo bei RUNTIME ein negativer Wert entstehen könnte, wenn es korrekt implementiert ist.

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

.. Ich werde demnächst mal einen kleinen Testbaustein mitlaufen lassen, der derartige Fehler-Fälle zumindest erkennt und zählt...

Dieses "demnächst" war gerade eben jetzt. Es läuft auf einer 6ES7 512-1DK01-0AB0 V2.8 beim Kunden.

 

[Speedevil]

Vielen Dank für eure Tipps, das Signal kommt ca. 1-2mal pro Sekunde also unkritisch.

Ich muss korrigieren habe eine 1517 als Controller aber der EIngang geht auf eine ET200Sp Standard DI. Dort kann ich keine HSC konfigurieren.

Wahrscheinlich kann ich es einfach über einen Zähler realiesieren, ich fande die Lösung mit dem TimeStamp allerdings ganz nett. Und funktioniert ja eigentlich auch. Werde es nächste Woch mal mit dem richtigen Eingang testen ohne Taktmerker.

Danke nochmal an alle. Den Baustein Runtime werde ich mir auch mal anschauen, der Überlauf wäre mir egal da der Motor immer ca. 20sec dreht innerhalb der Schrittkette und dann wieder neu gestartet und der Zeitwert neu beschrieben wird.

 

[PN/DP]

Den Baustein Runtime werde ich mir auch mal anschauen, der Überlauf wäre mir egal da der Motor immer ca. 20sec dreht ...

Wenn es wirklich zu einem Überlauf des Systemzeitgebers kommt, dann ist der nicht davon abhängig, wie lang oder kurz der zu messende Zeitraum ist, sondern wie lange die SPS schon eingeschaltet und in RUN ist. Der Überlauf kann dann auch in deinen 20s passieren. Also einfach "ist mir egal" ist keine Lösung. Aktiv feststellen, daß ein Überlauf war und dann den Wert ignorieren/überspringen, ist aber eine gangbare Lösung.

 

[Speedevil]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kurze Rückmeldung, es wurde ein Ini montiert der bei jeder Umdrehung einen Impuls reingibt. Der Baustein funktioniert, Danke an den Ersteller für den Baustein. Und allen anderen auch für die Hilfe.

 

[Onkel Dagobert]

... Ich werde demnächst mal einen kleinen Testbaustein mitlaufen lassen, der derartige Fehler-Fälle zumindest erkennt und zählt...

Ein kurzer Zwischenbericht für Interessierte, ich hatte am 31.08.2023 den Überlauf-Test auf zwei Steuerungen eines Kunden eingerichtet.
Bisher waren Null Korrekturen notwendig.

• 6ES7 211-1HE40-0XB0, V4.4
• 6ES7 512-1DK01-0AB0, V2.8

Beide Steuerungen wurden seit dem nicht neu gestartet.