TIA S7 - 1200: Drehzahlmessung über Impulse

Lars_S

Level-1
Beiträge
8
Reaktionspunkte
3
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin liebe Leute,

Es gibt ja schon einige Themen zu meiner Fragestellung, dort hatte ich es auch versucht, aber vielleicht ist meine Frage da einfach untergegangen, weil das Thema schon "abgearbeitet" war. Deswegen versuch ich es mal in einem neuen Thema.
Iich bin relativ neu in der SPS Programmierung und versuche mich grade an einer Drehzahlmessung. Habe hier die S7-1200 (CPU 1215C) zur Verfügung, bisher aber noch keine weiteren Steckkarten.

Eigentlich habe ich meine Drehzahlmessung so wie bereits in anderen Themen vorgeschlagen realisiert. Ich will Drehzahlen von 0-200 U/min erfassen. An meiner Welle habe ich einen Impulsgeber, der halt einmal pro Umdrehung einen Impuls auf einen Digitaleingang %I0.0 der CPU gibt.

In meinem Programm wird im Main-OB durch diesen Impuls ein Funktionsbaustein ("Drehzahlmessung") aktiviert. aIn diesem wird der Digitale Eingang %I0.0 auf positive Signalflanke abgefragt. Bei positiver Flanke wird die Systemzeit eingelesen (RD_SYS_T) und als "neue Zeit" abgespeichert (mit Datentyp DTL, das geht irgendwie bei der 1200 nur als DTL?). Die vorherige "neue Zeit" wurde davor aber noch als "alte Zeit" abgespeichert (MOVE) (eventuell sollte ich die alte Zeit erst ganz am Ende mit der neuen überschreiben, bisher mache ich das halt bevor ich die neue Zeit einlese am Anfang des FCs.)

Danach wird eine Zeitdifferenz = neue Zeit - alte Zeit (T_DIFF) gebildet und als Datentyp Time abgespeichert. Diese Zeitdifferenz wird dann in den Int-Datentyp konvertiert (T_CONV). Am Schluss teile ich dann noch 60 / Zeitdifferenz (DIV) und speichere das Ergebnis "Drehzahl" dann im Datentyp real ab.

Leider funktioniert das nicht so, wie ich es mir vorgestellt habe. Ich validiere das ganze im Moment so, dass ich per Hand Impulse auf meinen Digitaleingang gebe. Der FC wird dadurch auch aktiviert, die Zeiten werden ausgelesen, Differenz berechnet und so weiter. Nur passen die Werte zum einen nicht (Zeitdifferenz wäre irgendwas mit 14 Tagen usw,obwohl ich etwa einmal pro Sekunde einen Impuls gebe) und außerdem habe ich das Gefühl, nicht jeder Impuls wird erkannt (aber das ist erstmal zweitrangig).

Wenn ich meine Zeitdifferenz von Time in Int konvertiere, muss ich den Int-wert danach noch skalieren? Bzw ist mein Programm so vom Prinzip her dnen überhaupt richtig, also lese ich die Systemzeit richtig aus und ist es richtig die so voneinander abzuziehen etc?

Für ein paar Tipps wäre ich sehr dankbar!

Anbei noch Screenshots vom Programm (Netwerk 1-5), damit ihr wisst wovon ich rede =D

Anhang 23767
Anhang 23768
Anhang 23769
Anhang 23770
Anhang 23771

Vielen Dank und viele Grüße,
Lars
 
Also ich würde nur die Impulse zählen, im Sekundentakt (oder x Sekunden) auswerten, abnullen und weiterzählen...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi Lars

dein Anhänge funktionieren nicht :-(
Aber trotzdem ein paar Tipps.

T_DIFF liefert dir eine TIME. Das sind Millisekunden. Wenn diff = T#25ms ist, dann bedeutet das, dass da ein DINT#25 drin steht. Um da jetzt U/min draus zu machen musst du wie du schon vermutest 60/diff_in_sekunden rechnen. Aber diff is ms. D.h. 60/(diff/1000) und dann möchtest du das auch noch in REAL, also erst nach REAL wandeln, dann rechnen -->

Code:
#rpm := 60000.0/DINT_TO_REAL(TIME_TO_DINT(#diff)).

200/min = 3,333/s => 300ms pro Takt. Bedenke, damit eine steigende Flanke erkannt werden kann muss der Eingang auch mal 0 sein. Wenn die Zykluszeit größer wird als 150ms, dann besteht die Gefahr, dass dir Takte verloren gehen.

'n schön' Tach auch
HB
 
Hi,

danke für die Antworten, es funktioniert jetzt tatsächlich auch. Bin gestern selber noch darauf gekommen, dass es in Milisekunden ist. Habe dann meine Rechnung angepasst (60.0 auf 60.000.0) und siehe da, es scheint zu funktionieren. "Scheint", weil ich noch keine wirkliche Drehzahl gemessen habe. Werde das demnächst überprüfen.

Falls es noch jemanden interessiert, hier noch einmal die Anhänge:

Drehzahlmessung 01.PNG
Drehzahlmessung 02.PNG
Drehzahlmessung 03.PNG
Drehzahlmessung 04.PNG
Drehzahlmessung 05.PNG (hier wurde die 60.0 inzwischen auf 60000.0 geändert, wegen Angabe in Milisekunden)

Danke nochmal für eure Hilfe!
 
Sorry für das hochholen des uralten Themas. Verwende auch gerade die Bausteine wie hier im Beispiel. Allerding schiebt die Pos. Flanke ja gleichzeitig die Neue auf die Alte Zeit sodass immer identische Werte miteinander verglichen werden. Wie habt ihr das gelöst?
 
Sitze Live vor der Anlage, muss es allerdings mit einem Taktmerker probieren da Sensor noch nicht angeschloßen. Liegt hier eventuell der Fehler? Habe es jetzt gelöst, aber etwas unschön. Schiebe mit Neg. Flanke des Impulses, die Neue auf die Alte Zeit. Dann habe ich immer eine Periode den Wert und eine Periode eine 0. Den aktuellen Wert übertrage ich dann aber nur wenn Istwert größer 0.

Geht erstmal so aber gefällt mir natürlich nicht, möchte es so schlank wie möglich machen ohne wilde SR Glieder etc.
 
Code:
Erstes Netzwerk:
currentTimestamp:= currentTime // Aktuelle Zeit einholen

Irgendwo dazwischen:
timestampDifference:= currentTimestamp - oldTimestamp // Differenz zwischen aktueller Zeit und letzter aktiven Zeit

Letztes Netzwerk:
oldTimestamp:= currentTimestamp // Da Funktion abgearbeitet, aktuelle Zeit in alte Zeit umladen

eventuell so? Hab's jetzt kurz so niedergschrieben, dann muss ich TIA nicht aufmachen
 
Code:
Erstes Netzwerk:
currentTimestamp:= currentTime // Aktuelle Zeit einholen

Irgendwo dazwischen:
timestampDifference:= currentTimestamp - oldTimestamp // Differenz zwischen aktueller Zeit und letzter aktiven Zeit

Letztes Netzwerk:
oldTimestamp:= currentTimestamp // Da Funktion abgearbeitet, aktuelle Zeit in alte Zeit umladen

eventuell so? Hab's jetzt kurz so niedergschrieben, dann muss ich TIA nicht aufmachen
Ja so war auch mein Gedanke, das ich erst im letzten Netzwerk die "alte" Zeit überschreibe. Allerdings macht er das sofort und der Uhrzeitvergleich ist dann natürlich 0. Hier vermute ich, das es am Systemmerker Taktmerker liegt und dieser nicht dem PEW unterliegt. (Reine Vermutung steinigt micht nicht).


Messtechnische Berechnungen würde ich nicht unter Verwendung der Uhrzeit machen. Dafür gibt es z.B. den Systemzeitgeber (RUNTIME).
Vielen Dank für deinen Input, es handelt sich hier um eine stupide Anzeige die mehr ein Schätzeisen ist. Daher reicht mir die Uhrzeitlösung. Denoch werde ich das mit der Runtime googeln. Danke!
 
Ja so war auch mein Gedanke, das ich erst im letzten Netzwerk die "alte" Zeit überschreibe. Allerdings macht er das sofort und der Uhrzeitvergleich ist dann natürlich 0. Hier vermute ich, das es am Systemmerker Taktmerker liegt und dieser nicht dem PEW unterliegt. (Reine Vermutung steinigt micht nicht).
Machst du denn eine Auswertung auf eine positive Flanke für den Taktmerker? Hast du deinen Taktmerker so kurz gewählt, dass eventuell der Baustein nicht komplett abgearbeitet wird? Falls ja => schon mal mit 1s Takt bzw 2s Takt probiert, dann hat man eventuell eine Chance die Abarbeitung zu beobachten
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bei Uhrzeit als Basis für Zeitdifferenz-/Zeitdauer-Messungen kann es zu Sprüngen und auch negativen Differenzen kommen.

Die System-Taktmerker ändern sich asynchron zum OB1 und können sich im Verlauf des OB1 ändern. Mehrmaliges Abfragen/Verwenden eines Taktmerkers kann verschiedene Zustände ergeben. Will man Taktmerker mehrmals im Zyklus verarbeiten, dann sollte man sich für den Zyklus eine Kopie ("Prozessabbild") der Taktmerker am Anfang des Zyklus erstellen.
 
Man kann langsame Drehzahlen ganz gut mit einer SPS berechnen, wenn man einen interruptfähigen Eingang hat und die Zeitmessung nicht zyklisch, sondern interruptabhängig startet. Hat die 1200er so etwas an Bord?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe eine 1517 ein HSC mit TO wäre mir auch am liebsten. Aber leider nicht vorhanden.
Machst du denn eine Auswertung auf eine positive Flanke für den Taktmerker? Hast du deinen Taktmerker so kurz gewählt, dass eventuell der Baustein nicht komplett abgearbeitet wird? Falls ja => schon mal mit 1s Takt bzw 2s Takt probiert, dann hat man eventuell eine Chance die Abarbeitung zu beobachten
ich habe den längsten Taktmerker genommen mit 2 sec. (mx.7)
 
Welche DI-Baugruppen hast Du? Die DI 32x24VDC HF (6ES7521-1BL00-0AB0) kann Prozessalarm an jedem Eingang. DI0 und DI1 können auch zählen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Fragesteller hat eine S7-1500, da kann er zum Glück auf TIME_TCK ausweichen, was so gut dokumentiert ist, daß man den Überlauf problemlos herausrechnen kann. (ist ja auch legacy S7-300/400, und nicht von dem TIA-Team erfunden)
Bei S7-1500 kann man den Überlauf vermutlich auch bei RUNTIME herausrechnen, habe ich aber noch nie gebraucht. Ich hoffe noch, daß Siemens selber diese Baustelle fachmännisch schließt.

Ist das RUNTIME in TIA V18 immer noch sooo schlecht dokumentiert, daß man befürchten muß, daß in jeder neuen CPU-Firmware die Überläufe zu anderen Zeiten stattfinden? Ich frage mich, wie man einen Standard-Systemzeitgeber so unsinnig wie RUNTIME() implementieren kann... und die ausgereifte technische Lösung des 21. Jahrhunderts ist immer noch "negative Werte sind zu ignorieren"?

Harald
 
es handelt sich hier um eine stupide Anzeige die mehr ein Schätzeisen ist.
Da kannst Du die Zeitmessung vermutlich auch einfach mit TON/TOF machen.

Gehe einfach mal planvoll vor: zunächst ermittle, wie die zu erfassenden Impulse aussehen (wie lang ist ein Puls mindestens, wie lang ist die Pause zwischen zwei Pulsen mindestens, welche Frequenz?). Dann schau, ob Deine Hardware diese Pulse überhaupt erfassen kann. Dann schau, welche Auflösung/wieviele Ziffern Dein Anzeigewert haben soll und alle wieviel Sekunden ein neuer Messwert vorliegen soll. Da wird sich dann ergeben, ob/wie eventuelle Software-Spezialitäten nötig werden, oder ob naive oder gar stupide Programmierung ausreicht.
 
Ich kann RUNTIME nur empfehlen!
Harald, woher kommen deine schlechten Erfahrungen?

Der Fragesteller hat eine S7-1500, da kann er zum Glück auf TIME_TCK ausweichen, was so gut dokumentiert ist, daß man den Überlauf problemlos herausrechnen kann. (ist ja auch legacy S7-300/400, und nicht von dem TIA-Team erfunden) ...
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?

.. Bei S7-1500 kann man den Überlauf vermutlich auch bei RUNTIME herausrechnen, habe ich aber noch nie gebraucht. Ich hoffe noch, daß Siemens selber diese Baustelle fachmännisch schließt...
Du hast RUNTIME noch nie gebraucht? RUNTIME liefert dir ganz einfach die Zeit-Differenz zum verherigem Aufruf. Du selbst musst so weit erst einmal gar nichts berechnen.

.. Ist das RUNTIME in TIA V18 immer noch sooo schlecht dokumentiert, ...
Auch hier muss ich widersprechen. RUNTIME ist doch ganz gut beschrieben und zudem sehr einfach anzuwenden. Ich wüsste nicht, was man hier noch verinfachen könnte.

... Ich frage mich, wie man einen Standard-Systemzeitgeber so unsinnig wie RUNTIME() implementieren kann... und die ausgereifte technische Lösung des 21. Jahrhunderts ist immer noch "negative Werte sind zu ignorieren"? ..
Das ist heute hoffentlich Geschichte. Vermutlich wollte Siemens hier an alte Tradition anknüpfen, um uns den Umstieg von der S7-300 zu erleichtern :LOL:.
 
Zurück
Oben