Step 7 S0 Impulse von Energiezähler i. d. S7 in akt. Wirkleistung umrechnen u. visualisieren

Zuviel Werbung?
-> Hier kostenlos registrieren
Also wenn dich den ersten Impuls aufnehme und warte bis die positive Flanke des zweiten Impuls kommt, dann hab ich normal doch die ganze Impulslänge des ersten Impulses in der Messung dachte ich?

Naja, nein, das missverstehst du jetzt.
Ein Zähler der Impulse ausgibt, gibt ja immer nur dann einen Impuls aus wenn eine Einheit gemessen wurde.
Das heißt, die Zeit zwischen die gemessenen Einheiten, über die man dann auf einen durchschnittlichen rückschließen kann, ist genau die Zeit zwischen den beiden positiven Flanken.

Die Impulsdauer selber ist eigentlich für die Messung nicht sonderlich erheblich. Sie muss nur so gewählt sein
dass das Messgerät (deine SPS) die Impuls-Spitzen und die Impuls-Täler einwandfrei detektieren kann.

Zeichne dir doch mal ein Impulssignal auf ein Stück Papier hin und sieh's dir noch mal genauer an.
 
Zuletzt bearbeitet:
Das ist die Granularität bzw. die Auflösung. De Systemzeit zählt(e) bei den S7300 also nur in Schritten von 10ms. Aber das betrifft nur ältere CPUs. Heutige und gestrige CPUs zählen alle im 1ms-Raster.
Hahaha, jetzt kann ich das auch bestätigen.
Ich habe hier gerade mit dem DCF77-Baustein aus der OSCAT-lib herum-experimentiert und hab ihn nicht zum Laufen bekommen. DCF-Signal war OK, ich hatte auch schon ein kleines AWL-Programm das den Minutenwert dekodierte. Am Ende lags daran dass die Zeit-Grenzen für die logische 1 bzw. 0 im OSCAT-Baustein ein wenig knapp bemessen waren und siehe da,
die alte S7314 (v205) die ich Zuhause zum Testen habe (ist aus einer alten Anlage "verschwunden" :cool:) zählt mit dem SFC64 doch tatsächlich nur im 10ms Raster...

Danke nochmal Onkel!
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Das ist die Granularität bzw. die Auflösung. De Systemzeit zählt(e) bei den S7300 also nur in Schritten von 10ms. Aber das betrifft nur ältere CPUs. Heutige und gestrige CPUs zählen alle im 1ms-Raster.
Hilf mir doch mal einer beim Suchen, wo das offiziell dokumentiert ist. Ich meine, in der Step7-Hilfe V5... steht bis heute, daß alle S7-300 nur auf 10ms auflösen. (außer CPU 318)

Harald
 
Hilf mir doch mal einer beim Suchen, wo das offiziell dokumentiert ist.
Kram... such...
Tja, anscheinend nirgens, da waren die Siemens-Jungs anscheinend wieder nachlässig

Ich hab's hier aber grad definitiv getestet.
Bei meiner alten 314 ist die letzte Ziffer des SFC64-Ergebnisses immer 0, bei einer neueren IM151-8 ET200S-CPU bewegt sich auch diese. :cool:
 
SFC64 "TIME_TCK" Granularität 1ms bei S7-300 ab Firmware V2.6

Ich habe es gefunden:
Die Änderung der Granularität der SFC64 "TIME_TCK" zu 1ms bei S7-300 und C7 wurde schon 2007 mit der Firmware V2.6 eingeführt.

Neue Firmware Version V2.6 für S7-300 CPUs (2007-08-14)
Siehe auch die Betriebssystem-Update-Downloads: im Siemens Produkt Support suchen nach "Betriebssystem-Update S7-300 TIME_TCK"

Im Referenzhandbuch System- und Standardfunktionen für S7-300/400 Ausgabe 05/2010 wurde das dann eingepflegt - und zwar entfiel der Hinweis auf die 10ms bei (alten) S7-300 komplett.

Im Referenzhandbuch System- und Standardfunktionen für S7-300/400 (03/2006) stand noch
6.6 Systemzeit lesen mit der SFC 64 "TIME_TCK" schrieb:
Das Zeitraster und die Genauigkeit der Systemzeit betragen bei S7-400 und bei der CPU 318 1 ms, bei allen anderen CPUs der S7-300 10 ms.

Dieser FAQ von August 2011 (!) behauptet aber immer noch undifferenziert "S7-300: 10 ms"
Wie wird in STEP 7 V5.x die Laufzeit eines Endgerätes (z.B. Pumpe) berechnet?

Die Hilfe von Step7 V5.4 und V5.5 enthält keinen Hinweis mehr auf die 10ms bei alten CPUs bzw. CPUs mit Firmware vor V2.6

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich meine, es hätte vor Jahren dazu mal eine FAQ oder so etwas gegeben, finde jetzt aber auch nichts mehr. Zumindest ist aber im aktuellen Handbuch zu den Systemfunktionen generell nur noch von 1ms die Rede.

.. da waren die Siemens-Jungs anscheinend wieder nachlässig ..
Was ja auch irgendwo verständlich ist. Tausende von Beiträgen bei jeder Änderung zu überarbeiten ist ein Ding der Unmöglichkeit. In der Onlinehilfe ist es natürlich schon etwas nachlässig. Naja, was soll's, ihr habt ja mich :ROFLMAO: .


Da war mal wieder einer schneller ;) .
 
PN/DP... das wandelnde Lexikon. :s1:

Ja, wie schon gesagt, ich war von Anfang an immer der Meinung das es 1ms war da ich's von den aktuellen CPU's nicht anders gewohnt war. Mir war die Diskussion um 10ms daher ein wenig suspekt. Bis ich heute eine alte CPU probiert habe..

q.e.d
 
Haben die Oscatianer den Überlauf der Systemzeit berücksichtigt? Das war anfangs bei OSCAT gerne vernachlässigt worden.
Nein haben sie nicht. Ist aber nicht so schlimm, man verliert höchstens eine Minute alle 25 Tage. Dann synct man halt wieder nach den nächsten beiden gültigen Minuten.
Je nachdem wie gut der Empfang ist verliert man den Sync sowieso ständig.
Fehlerprüfungen werden bei OSCAT ganz allgemein gerne vernachlässigt...
Sonst gar nicht so schlimm auf den ersten Blick. Die ganzen Paritäten und Timeouts werden eigentlich geprüft.

Hintergrund: Bin beim Durchstöbern der OSCAT auf den Baustein gestoßen. Sonst hab ich mit der Lib bis jetzt noch nix gemacht.
Da ich in meinen 8-Bit Mikrocontroller-Zeiten öfter mit DCF-Empfängern gearbeitet hab (Decoder selbst geschrieben) bin ich neugierig geworden, hab das alte
Elektronik-Bastelzeugs hervorgeholt und einen Empfänger (fertiges Modul) gebastelt. Funktioniert jetzt eigentlich ganz gut, das Problem war wie schon gesagt das meine
S7-314 beim Zeitmessen ein wenig ungenau ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nein haben sie nicht...
Hab' ich's mir doch gedacht.

..das Problem war wie schon gesagt das meine S7-314 beim Zeitmessen ein wenig ungenau ist.
Falls du einen Schaltplan für eine Funkuhr in TTL-Technik (ohne Prozessor) brauchst, dann müsste ich mal in meinem Archiv nachsehen. Ich habe so etwas in meiner Jugendzeit gebastelt. Schön war's.
 
Zurück
Oben