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.
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 .
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
END_VAR
( ----------------------------------------------------------------------------)
fqm.IN := bWechselstromzaehlereingang;
fqm.PERIODS := 2;
fqm();
tZeitInMs := fqm.DIFF;
Gruss Erik
Hi
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
Sorry, Time_tck ist der Kompatibilitäts-Aufruf von Hugo.
Nimm bitte den Time() .
Einfach reintippen und starten.
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:
Hi
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
Formel:
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.
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
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.
HAllo
@Martin,
Gibt es das unter Wago ?
Hast du Informationen hierzu.
Danke Karl
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