Hallo !

Ich möchte die Zeit zwischen zwei Impulsen eines Wechselstromzählers

in Millisekunden messen.

D.h. im Programm bekomme ich fortlaufend die Impulse des Zählers

über einen Frequenzeingang als Counter.

Das ist alles da. nur wie kann ich die Zeit zwischen zwei Impulsen messen ?

Danke für die Hilfe !

Martin

Hallo Martin

Kuck dir mal den FREQ_MEASURE aus der Util.lib an.

Der misst eigentlich die Frequenz eines Signals, hat aber eine interne Variable, die sich DIFF (DWORD) nennt. Das könnte evtl. die Zeit zwischen den Signalen in ms sein.

Sieht dann so aus:

VAR

 fqm:   FREQ_MEASURE;

END_VAR

( ----------------------------------------------------------------------------)

fqm.IN := bWechselstromzaehlereingang;

fqm.PERIODS := 2;

fqm();

tZeitInMs := fqm.DIFF;

Gruss Erik

Hi

IF R_TRIG( puls)  THEN
     last := tx;
     tx := TIME_TCK();
     Zeit_ms :=  tx - last;
END_IF

P.S. Es gibt auch Moule von Hugo, die diese Aufgabe lösen können.

w www.oscat.de w

P.P.S. Ups, schon cool was diese Lib schon kann.

Vielen Dank für eure schnellen Antworten !!!

Werde es nachher mal probieren.

Ähm, Erik... Jetzt sag nicht Du bist immer noch auf der Arbeit...

Du bist ja fast ein 24 h - Server in Person !

Nee,nee, wenns Dich niocht gäbe...

Also Danke euch beiden noch mal.

MfG

Martin

Hallo nochmal Erik und Karl !

An Erik: Ich habe keine Util.lib gefunden...

An Karl: Den Aufruf TIME_TCK() finde ich nicht, in welcher

Bibliothek muß ich den suchen ?

Könnte alles viel einfacher sein, wenn man im Garten Unkraut

ziehen würde, da gibt solche Probleme nicht !

Bey

Martin

Hi

Den Aufruf TIME_TCK() finde ich nicht

Sorry, Time_tck ist der Kompatibilitäts-Aufruf von Hugo.

Nimm bitte den Time() .

Einfach reintippen und starten.

PROGRAM PLC_PRG
VAR
   tx:TIME;
END_VAR
tx := TIME();

Zitat:
An Erik: Ich habe keine Util.lib gefunden...

Welche Hardware hast du ?

Such doch mal mit Windows --> Dateien suchen. und gib util. ein.

Hi Karl,

ich arbeite mit einem Fred P300 mit ESP-BUS.

Ich habe auch im Codesys Verzeichnis eine Bibliothek Namens

Pult.lib gefunden. Darin gibt es aber keine Funktion

FREQ_MEASURE. Handelt es sich vielleicht um eine

ältere Version der Bibliothek ?

Mit Deiner Variante, also dem Aufruf Time bekomme ich nun

eine Zeitdifferenz in Millisekunden, aber je nach Zeitabstand

zwischen den Impulse fällt diese natürlich unterschiedlich aus.

D.h. einmal ist der Wert z.B. T#40S ein anderes Mal

T#39s579ms.

Mit diesem Format kann ich so aber nicht arbeiten da ich

das Ergebnis nicht als reinen Millisekundenwert habe, also z.B.

39579 ms.

Ein umrechnen über Time_to_STR und anschliessende Umwandlung

in einen INT-Wet ist aufgrund des wechselnden Formats ebenfalls

sehr schwierig, da die Stringlänge je nach Zeit ja variiert.

Wie komme ich also am besten auf einen reinen Millisekundenwert ?

Hintergrund ist, das je Impuls eine Wh verbraucht wird.

Anhand der Zeit zwischen zwei Impulsen könnte ich dann die

Momentane Leistung des Verbrauchers ermitteln (bzw. den momentanen Verbrauch)

MfG

Martin

TIME_TO_DWORD sollte helfen, ergibt Millisekunden. Auszug aus der Onlinehilfe:

Zitat:
Intern wird die Zeit in einem DWORD in Millisekunden abgespeichert (bei TIME_OF_DAY seit 00:00 Uhr). Dieser Wert wird konvertiert.
Bei der Typkonvertierung von größere auf kleinere Typen können Informationen verloren gehen .

Hi

Zitat:
Ein umrechnen über Time_to_STR und anschliessende Umwandlung
in einen INT-Wet ist aufgrund des wechselnden Formats ebenfalls
sehr schwierig, da die Stringlänge je nach Zeit ja variiert.
Wie komme ich also am besten auf einen reinen Millisekundenwert ?

Was hälts du vom TIME_TO_DWORD.

Wertebereich bis 4294967295 sollte reichen

Hi Oberchefe

War 50 ms schneller

Zu beachten ist zudem, dass es 1x pro Tag einen "Überlauf" gibt.

D.h. Dein Messwert entspricht einmal einen ganzen "Tagesverbrauch"

Nur zur Info, falls dein Program läuft und macht gelegentliche Anzeige-Fehler.

Hi Karl und Oberchefe !

Was, so einfach ist das ?

Probiere es morgen aus.

1000 Dank !

Übrigens sollte es nicht zu einem Überlauf kommen,

da die Differenz nach jedem Impuls rückgesetzt und neu berechnet wird.

Aber danke für den Hinweis !

bye

Martin

Hi

Zitat:
Übrigens sollte es nicht zu einem Überlauf kommen,
da die Differenz nach jedem Impuls rückgesetzt und neu berechnet wird.

Formel:

 last := tx;

 tx := TIME_TCK();

 Zeit_ms :=  tx - last;

tx - last --> normalerweise tx > last --> 1 x am Tag kleiner !

in der freien lib von oscat findest du entsprechende module unter measurement.

zum download auf w www.oscat.de w

du musst aber beachten das der messfehler je nach zykluszeit beträchtlich sein kann.

bei 5ms zykluszeit ist der maximale fehler 10ms.

genauer gehts dann nur mit einem entsprechenden hardware meßmodul.

in unserer lib ist auch ein baustein der automatisch die zykluszeit ermittelt und damit kannst dur den fehler auf eine zykluszeit anstelle von 2 reduzieren.

indem du bei jder messung die hälfte der letzten zykluszeit abziehst.

Zitat:
und damit kannst dur den fehler auf eine zykluszeit anstelle von 2 reduzieren.
indem du bei jder messung die hälfte der letzten zykluszeit abziehst.

wie soll denn das funktionieren? DU kannst doch nicht wissen, wann zwischen zwei Programmzyklen der Eingang seinen Zustand wechselt, wenn der erste Impuls kurz vor dem Programmzyklus seinen Zustand wechselt und der zweite Impuls kurz nach dem vorangegangenen Programzyklus, dann mußt Du sogar was draufaddieren statt abziehen.

Oberchefe hat geschrieben:
wie soll denn das funktionieren? DU kannst doch nicht wissen, wann zwischen zwei Programmzyklen der Eingang seinen Zustand wechselt, wenn der erste Impuls kurz vor dem Programmzyklus seinen Zustand wechselt und der zweite Impuls kurz nach dem vorangegangenen Programzyklus, dann mußt Du sogar was draufaddieren statt abziehen.

nehmen wir an die zykluszeit beträgt 5ms.

dann kann die flanke irgendwann in diesen 5 ms gekommen sein. wir messen von einer flanke zur nächsten, das bedeutet das 2 mal der maximale fehler von 5ms (zusammen 10ms = 2 * Zykluszeit) auftreten kann.

genau wie du oben sagst, man kann nicht wissen wann in der zykluszeit irgendwas passiert ist.

wenn ich allerdings die zykluszeit selber messe dann kamm ich mir die halbe zykluszeit vom per software ermittelten wert abziehen, und dadurch den fehler auf 1/2 zykluszeit reduzieren.

hallo Martin,

hast du mit deiner hardware die möglichkeit, den counter-eingang direkt interrupt-gesteuert einlesen zu lassen? das wäre am genauesten, wenn deine impulse im ms bereich liegen.

anders kann ich allerdings ebenfalls die oscat.lib empfehlen

Hallo Martin

Hatte jetzt mal 1,5 Tage Wochenende...

Samstagsarbeit ist bei uns eher die Regel, als die Ausnahme.

'Schaffa Schaffa Häusle baua' heisst das in Schwaben...

Die Util lib findest du unter

C:\Programme\3S Software\CoDeSys V2.3\Library\Util.lib.

Aber mit den Bausteinen aus der Oscat.lib funktionierts natürlich auch.

Gruss Erik

Zitat:
nehmen wir an die zykluszeit beträgt 5ms.
dann kann die flanke irgendwann in diesen 5 ms gekommen sein. wir messen von einer flanke zur nächsten, das bedeutet das 2 mal der maximale fehler von 5ms (zusammen 10ms = 2 * Zykluszeit) auftreten kann.

Soweit stimme ich (fast) zu, das fast wegen dem unerklärlichen Faktor 2, es kann in diesem Fall nur zum maximalen Fehler von 5ms kommen.

Zitat:
wenn ich allerdings die zykluszeit selber messe dann kamm ich mir die halbe zykluszeit vom per software ermittelten wert abziehen, und dadurch den fehler auf 1/2 zykluszeit reduzieren.

und hier stimme ich auf keinen Fall zu

Der Fehler kann nämlich in beiden Richtungen sein. Wenn beim ermitteln der Flanke des ersten Impulses die maximale Verzögerung auftritt (im Beispiel 5ms) und beim ermitteln des zweiten Impulses fast gar keine Verzögerung, dann mißt Du 5ms zu wenig, der erste Puls wird in diesem Fall 5ms zu spät erfaßt, der zweite Puls mehr oder weniger richtig, ergibt 5ms Differenz (und zwar ist die gemessene Zeit zu gering, DU mußt die 5ms aufaddieren!)

Im anderen Fall kann es passieren daß der erste Puls ohne Verzögerung gesehen wird und der zweite Puls mit maximaler (5ms) Verzögerung. Hier mißt Du zu viel und müßtest 5ms abziehen (und natürlich keine 10ms!)

Im dritten Fall kann es aber passieren daß die beiden Impulse mit der gleichen Verzögerung gesehen werden(egal ob mit fast keiner Verzögerung oder ob mit der maximalen von 5ms), dann mußt Du gar nichts aufaddieren oder abziehen, dann paßt die Messung sowieso.

Im Durchschnitt ist der Fehler aller möglichen Fälle gleich Null, egal wie lange die Scanzeit ist, nur die Abweichung einer einzelnen Messung vom Durchschnitt ist größer, je größer die Scanzeit ist.

Fazit: Scanzeit draufaddieren oder abziehen macht überhaupt keinen Sinn und kann im Gegeteil das Meßergebnis noch mehr verfälschen.

HAllo

@Martin,

Zitat:
hast du mit deiner hardware die möglichkeit, den counter-eingang direkt interrupt-gesteuert einlesen zu lassen?

Gibt es das unter Wago ?

Hast du Informationen hierzu.

Danke Karl

Oberchefe hat geschrieben:
Soweit stimme ich (fast) zu, das fast wegen dem unerklärlichen Faktor 2, es kann in diesem Fall nur zum maximalen Fehler von 5ms kommen.
und hier stimme ich auf keinen Fall zu
Der Fehler kann nämlich in beiden Richtungen sein. Wenn beim ermitteln der Flanke des ersten Impulses die maximale Verzögerung auftritt (im Beispiel 5ms) und beim ermitteln des zweiten Impulses fast gar keine Verzögerung, dann mißt Du 5ms zu wenig, der erste Puls wird in diesem Fall 5ms zu spät erfaßt, der zweite Puls mehr oder weniger richtig, ergibt 5ms Differenz (und zwar ist die gemessene Zeit zu gering, DU mußt die 5ms aufaddieren!)
Im anderen Fall kann es passieren daß der erste Puls ohne Verzögerung gesehen wird und der zweite Puls mit maximaler (5ms) Verzögerung. Hier mißt Du zu viel und müßtest 5ms abziehen (und natürlich keine 10ms!)
Im dritten Fall kann es aber passieren daß die beiden Impulse mit der gleichen Verzögerung gesehen werden(egal ob mit fast keiner Verzögerung oder ob mit der maximalen von 5ms), dann mußt Du gar nichts aufaddieren oder abziehen, dann paßt die Messung sowieso.
Im Durchschnitt ist der Fehler aller möglichen Fälle gleich Null, egal wie lange die Scanzeit ist, nur die Abweichung einer einzelnen Messung vom Durchschnitt ist größer, je größer die Scanzeit ist.
Fazit: Scanzeit draufaddieren oder abziehen macht überhaupt keinen Sinn und kann im Gegeteil das Meßergebnis noch mehr verfälschen.

hi oberchefe,

du hast natuerlich recht der faktor 2 ist unsinn.

das ganze macht nur dann sinn wenn die zykluszeiten bei free running tasks stark schwanken, in diesem fall kann die erste flanke in einen zyklus fallen der nur 5ms ist und die zweite in einen zyklus der 50ms ist. eine korrektur kann dann den fehler etwas einschränken auf max 30ms in diesem zugegeben extremen fall

Hallo,

das Millisekundenproblem habe ich voriges Jahr mal hier im Forum angesprochen und auch Hilfe erhalten. Auf einer Wago 750-841 funktioniert es sehr gut.

Sucht mal nach "Echtzeit in Millisekunden" in diesem Forum...

Viele Grüße

grauerwolf

Hallo Erik,

Man, 1komma5 Tage, da mußt Du ja ausgeruht sein wie andere

nach 3 Wochen Bahamas !

Frage mich nur ob Du so jemals etwas Farbe bekommst ?

Na ja, hat ja auch seine Vorteile wenn man fast immer auf einen

Erik zurückgreifen kann !

MfG Martin

Hallo,

nein, ich wüßte nicht das ich den Frequenzeingang interruptrgesteuert

auslesen kann.

Habe jedenfalls die Berechnung der Momentanleistung verworfen.

Die Ergebnisse waren mir zu ugenau.

Nun hab ich ja auch so Spaß, ohne die Momentane Leistung zu kennen,

die Kostenabrechnung über den Impuls funktioniert ja, und das

war wichtig. Wie sagt der Fußballer...

Momentanleisung ist primär, Verbrauch ist sekundär und das Wichtigste !

Was ?

MfG Martin