ich habe mal zwei Fragen zur Arbeitsweise des Bausteins FREQ_MEASURE aus der Bibliothek util.lib.
Und zwar steht in der Hilfe, daß der Ausgang VALID dann FALSE ist, wenn noch keine komplette Meßreihe vorhanden ist, also wenn noch nicht die Anzahl der Messungen wie am PERIOD-Eingang vorgegeben, erreicht wurde, richtig?
Allerdings habe ich beobachtet, daß VALID abhängig von der Eingangsfrequenz entweder immer TRUE bleibt, oder (bei niedrigen Frequenzen) zwischen TRUE und FALSE hin und her toggelt. Woran liegt das?
Dann die zweite Frage:
VALID wird auch dann FALSE, wenn die gemessene Periodendauer größer als das Dreifache des Ausgangs OUT ist.
Der Ausgang OUT gibt aber die Frequenz an. Was macht es dann also für einen Sinn, das Dreifache der Frequenz als Vergleichswert für die Periodendauer zu nehmen?
Entschuldigung, wenn sich die Fragen dumm anhören, aber ich arbeite noch nicht lange mit CodeSys, und bin mit Details nicht vertraut. Ich schreibe lediglich einfache Testprogramme für die Funktionsbausteine.
An FREQ_MEASURWE beiße ich mir allerdings gerade die Zähne aus, da ich die Arbeitsweise nicht verstehe.
Vielen Dank für Antworten
Gruß, Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ich arbeite bei Bosch Rexroth, und muß für die Funktionsbausteine von CoDeSys (bei uns heißt es IndraLogic) Programme schreiben, die austesten, ob die Bausteine so funktionieren, wie sie sollen, und das Ergebnis dann in eine Protokolldatei schreiben. Aus dem Protokoll soll dann ersichtlich sein, ob alles Ok ist, oder ob etwas schief gelaufen ist.
Diese Testprogramme sollen immer dann benutzt werden, wenn es einen neue Version oder Änderungen an IndraLogic gibt, und es evtl sein könnte, daß ein Baustein nicht mehr richtig funktioniert.
Und im Moment geht es eben speziell darum, einen Testmechanismus für den Baustein FREQ_MEASURE zu finden. Aber den kann ich nicht schreiben, wenn ich die Arbeitsweise nicht genau verstehe.
Es geht also nicht darum, irgendwelche Funktionen zu realisieren, für die ich auch die OSCAT.lib benutzen könnte, sondern es geht eigentlich um die Funktionsbausteine selbst.
Gruß
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also ich speise den FREQ_MEASURE mit einem Signal, das der BLINK-Baustein generiert. Bitte nicht wundern, daß die Frequenzen so extrem niedrig sind, aber ich will die Funktion mit der Traceaufzeichnung beobachten, und habe deswegen alles so langsam eingestellt.
Als TIMELOW nehme ich 2s und als TIMEHIGH 1s. PERIODS setze ich auf 7. Dann ist es so, daß FREQ_MEASURE.V immer wieder neu bis 7 zählt, und VALID nur dann HIGH ist, wenn V=7. Außerdem wird der Frequenzwert am Ausgang nur dann aktualisiert, wenn VALID=TRUE.
Als TIMELOW nehme ich jetzt 1s und als TIMEHIGH 500ms. PERIODS setze ich wieder auf 7. In diesem Falle bleibt V=7, und VALID bleibt immer TRUE. Der Freuquenzwert wird mit jeder steigenden Flanke aktualisiert.
Warum wird V im ersten Beispiel immer wieder auf null gesetzt, obwohl das Eingangssignal OK ist?
Und welche Funktion hat diese Quelltextzeile:
B:=(B+1)MODPERIODS;
Danke für die Hilfe!!
Gruß
Robert
P.S. Habe gerade erst "ausgelernt" und bin noch nicht lange hier. Daher arbeite ich auch erst seit kurzer Zeit mit CoDeSys.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Zitat:
1. Als TIMELOW nehme ich 2s und als TIMEHIGH 1s. PERIODS setze ich auf 7. Dann ist es so, daß FREQ_MEASURE.V immer wieder neu bis 7 zählt, und VALID nur dann HIGH ist, wenn V=7. Außerdem wird der Frequenzwert am Ausgang nur dann aktualisiert, wenn VALID=TRUE.
Zitat:
Und welche Funktion hat diese Quelltextzeile:
B := (B+1) MOD PERIODS;
Sorgt dafür, dass "B" eine Zahl zwischen 0 und "PERIODS-1" hat.
(Indexierung)
Bleibt nur die Frage:
Wenn Permenent gleichbleibende Eingangssignale kommen bleibt "V" bei dir auf z.b. 7.
Irgendwie muss bei "VALID" = TRUE ein "RESET" Signal gegeben werden.
Dann fängt "V" auch bei 1 an, bei 7 hast du dann erst das "VALID" = TRUE
Zitat:
2. Als TIMELOW nehme ich jetzt 1s und als TIMEHIGH 500ms. PERIODS setze ich wieder auf 7. In diesem Falle bleibt V=7, und VALID bleibt immer TRUE. Der Freuquenzwert wird mit jeder steigenden Flanke aktualisiert.
Das erklärt auch das Verhalten bei deinem Test.
Vieleicht hat CoDeSys ein Beispielprogramm für dich ?
Kurzum, ein "Bedienfehler".
DESHALB ist es auch WICHTIG, dass Bibliotheken Quelltext-Offen sind.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Zitat:
Bleibt nur die Frage:
Wenn Permenent gleichbleibende Eingangssignale kommen bleibt "V" bei dir auf z.b. 7.
Irgendwie muss bei "VALID" = TRUE ein "RESET" Signal gegeben werden.
Dann fängt "V" auch bei 1 an, bei 7 hast du dann erst das "VALID" = TRUE
Ich verstehe nicht ganz, denn genau das Verhalten, das Du da beschreibst, macht der Baustein ja abhängig von der Eingangsfrequenz.Er macht es mal so, mal so, und genau das irritiert mich ja. (siehe meine obigen Beispiele)
Es scheint so zu sein, daß die Eingangssignale manchmal als fehlerhaft erkannt werden, so daß dieser Codeteil durchlaufen wird:
Hier wird V auf null gesetzt.
Bei hohen Frequenzen wird der Codeabschnitt - warum auch immer - nicht durchlaufen.
Zitat:
Sorgt dafür, dass "B" eine Zahl zwischen 0 und "PERIODS-1" hat.
(Indexierung)
Ja, B wird mit dieser Funktion offensichtilich immer wieder neu hochgezählt, aber wie die "MOD"-Funktion mit reinspielt, habe ich nicht verstanden.
Zitat:
Ich würde eine Funktion nehmen, die Permenent die Frequenz misst.
Z.b. w www.oscat.de w Funktion "M_T", die hat jedoch KEINE "Mittelwertbildung".
Das nützt mir leider nichts, denn meine Aufgabe ist es ja gerade, den FREQ_MEASURE auf Herz und Nieren zu testen.
Gruß
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Zitat:
Ja, B wird mit dieser Funktion offensichtilich immer wieder neu hochgezählt, aber wie die "MOD"-Funktion mit reinspielt, habe ich nicht verstanden.
Mit "MOD" wird der REST einer Ganzzahl-Division errechnet.
Zitat:
Hier wird V auf null gesetzt.
Bei hohen Frequenzen wird der Codeabschnitt - warum auch immer - nicht durchlaufen.
Wie hoch sind die Frequenzen ?
Bei Zykluszeit-überschreitungen / Zykluszeitgrenzen werden die wechselnden Eingänge nicht/falsch gelesen und somit ausgewertet.
Ich würde mal sagen:
Zykluszeit 10ms --> Low-High-Wechsel --> 50 Hz sind schon die "Grenze"
Zitat:
Ich verstehe nicht ganz, denn genau das Verhalten, das Du da beschreibst, macht der Baustein ja abhängig von der Eingangsfrequenz.Er macht es mal so, mal so, und genau das irritiert mich ja. (siehe meine obigen Beispiele)
Ich denke, du testet den Baustein mit 1 Programm.
Zuerst mit der kleinen Frequenz.
Nachfolgen mit der grossen Frequenz.
Vor dem Testen des 2. Bausteins musst du den Baustein reseten !
Falls nicht --> bleibt V=7 und VALID=TRUE
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Zitat:
Das nützt mir leider nichts, denn meine Aufgabe ist es ja gerade, den FREQ_MEASURE auf Herz und Nieren zu testen.
Soll ich dir mal meine Einstellung dazu sagen:
Der Aufwand, um festzustellen und zu Protokolieren wie und DASS die Funktion so funktioniert wie diese gewünscht ist, ist wesentlich höher als die Funktion selber zu schreiben/anzupassen.
Passe dir doch die Funktion an, so wie dein Bedarf ist.
Ernenne diese zum "Standard" für euere Firma.
Gebe der Funktion einen neuen Namen z.b. R_FREQ_MEASURE
( R von Robert )
Zudem könnte mann sich diese so anpassen, dass diese OHNE RESET mit Mittelwertbildung arbeitet. Z.b. mit einer FIFO, du "alte" Werte rauswirft oder so, somit brauchtst du NICHT immer warten, bis die Anzahl der Durchläufe erreicht ist/wird.
Denk doch mal nach, wie diese Funktion in der Praxis zu Fehlern führen kann. Eine genaue Beschreibung und Funktionsweise ist UNUMLÄSSIG notwendig. Auch ein Example hierzu ist sinnvoll.
Ich hoffe dir geholfen zu haben
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Zitat:
Mit "MOD" wird der REST einer Ganzzahl-Division errechnet
Ja, so steht es in der Hilfe. Ich glaube, ich weiß jetzt, wie es funktioniert:
B:=(B+1)MODPERIODS;
Beispiel B=2 und PERIODS=7
B= (2+1) MOD 7 -->
B= 3 MOD 7 -->
B= Rest von 3/7 --> 3/7=0 Rest 3
So dürfte es funktionieren!? Bei 7 folgt Rücksetzen auf null.
Jetzt bin ich schon ein kleines Stück weiter.
Zitat:
Wie hoch sind die Frequenzen ?
Bei Zykluszeit-überschreitungen / Zykluszeitgrenzen werden die wechselnden Eingänge nicht/falsch gelesen und somit ausgewertet.
Ich würde mal sagen:
Zykluszeit 10ms --> Low-High-Wechsel --> 50 Hz sind schon die "Grenze"
Momentan ist die Zykluszeit auf 4ms gestellt. Bei der Periodendauer bewege ich mich (siehe Beispiele in meinem 4.Post) im Bereich von über 1,5s. Von daher dürfte es in dem Bereich nicht kritisch werden.
Zitat:
Ich denke, du testet den Baustein mit 1 Programm.
Zuerst mit der kleinen Frequenz.
Nachfolgen mit der grossen Frequenz.
Vor dem Testen des 2. Bausteins musst du den Baustein reseten !
Bis jetzt habe ich noch kein selbstständiges Testprogramm geschrieben, sondern nur per Hand versch. Eingangssignale angelegt, die der "BLINK"-Generator erzeugt. Und dann habe ich eben die Reaktion von FREQ_MEASURE beobachtet. Dabei sind dann meine ganzen Fragen aufgetaucht.
Aber mit Deiner Hilfe bin ich nun schon ein ganzes Stück weiter gekommen.
Gruß
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
gravieren hat geschrieben:
Hi
Soll ich dir mal meine Einstellung dazu sagen:
Der Aufwand, um festzustellen und zu Protokolieren wie und DASS die Funktion so funktioniert wie diese gewünscht ist, ist wesentlich höher als die Funktion selber zu schreiben/anzupassen.
Passe dir doch die Funktion an, so wie dein Bedarf ist.
Ernenne diese zum "Standard" für euere Firma.
Gebe der Funktion einen neuen Namen z.b. R_FREQ_MEASURE
( R von Robert )
Zudem könnte mann sich diese so anpassen, dass diese OHNE RESET mit Mittelwertbildung arbeitet. Z.b. mit einer FIFO, du "alte" Werte rauswirft oder so, somit brauchtst du NICHT immer warten, bis die Anzahl der Durchläufe erreicht ist/wird.
Denk doch mal nach, wie diese Funktion in der Praxis zu Fehlern führen kann. Eine genaue Beschreibung und Funktionsweise ist UNUMLÄSSIG notwendig. Auch ein Example hierzu ist sinnvoll.
Ich hoffe dir geholfen zu haben
Das war jetzt ein dickes Ding.
Selbstständig kann und darf ich nicht darüber entscheiden, wie und ob die Funktion geändert werden darf. Darüber entscheiden andere.
Außerdem ist unser IndraLogic ja nach diesem IEC61131-3 genormt, und da kann man nicht einfach was abändern, oder?
Zur Info:
Unsere Firma verkauft Steuerungssysteme, und IndraLogic ist ein Teil unseres Angebots, und in unsere Software integriert. Wir verkaufen CoDeSys sozusagen selber nur weiter. Und wir müssen nur dafür sorgen, daß alles einwandfrei funktioniert, denn unsere Kunden arbeiten ja mit unseren Produkten.
Gruß
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Zitat:
Beispiel B=2 und PERIODS=7
B= (2+1) MOD 7 -->
B= 3 MOD 7 -->
B= Rest von 3/7 --> 3/7=0 Rest 3
So dürfte es funktionieren!? Bei 7 folgt Rücksetzen auf null.
Jetzt bin ich schon ein kleines Stück weiter.
Korrekt.
Jedoch wird bei "7" NUR die Variable "B" auf 0 gesetzt.
Die Variable "V" bleibt auf "7" bis "Fehler" ODER "RESET" !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Zitat:
1. Als TIMELOW nehme ich 2s und als TIMEHIGH 1s. PERIODS setze ich auf 7. Dann ist es so, daß FREQ_MEASURE.V immer wieder neu bis 7 zählt, und VALID nur dann HIGH ist, wenn V=7. Außerdem wird der Frequenzwert am Ausgang nur dann aktualisiert, wenn VALID=TRUE.
2. Als TIMELOW nehme ich jetzt 1s und als TIMEHIGH 500ms. PERIODS setze ich wieder auf 7. In diesem Falle bleibt V=7, und VALID bleibt immer TRUE. Der Freuquenzwert wird mit jeder steigenden Flanke aktualisiert.
Beispiel 1: Periodendauer=3s, Frequenz=0,333Hz !
Frequenz*3000 = 1000 -->
Periodendauer 3000ms > 1000ms ---> daher wird Signal als fehlerhaft erkannt.
Beispiel 2: Periodendauer=1,5s, Frequenz=0,666Hz !
Frequenz*3000 = 2000 -->
Periodendauer 1500ms < 2000ms ---> daher wird Signal als OK erkannt.
So, jetzt ist mir klar, warum der Baustein das so macht!
Die Funktion ist soweit geklärt.
Warum man aber anhand der 3000-fachen Frequenz entscheidet, ob das Eingangssignal fehlerhaft ist, oder nicht, bleibt mir schleierhaft.
Gruß, Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
gravieren hat geschrieben:
Korrekt.
Jedoch wird bei "7" NUR die Variable "B" auf 0 gesetzt.
Die Variable "V" bleibt auf "7" bis "Fehler" ODER "RESET" !
Genau!
Das habe ich verstanden.
Nur, warum man die Entscheidungsbedingung für "Fehler" ausgerechnet SO (3000-fache Frequenz) festgelegt hat, erschließt sich mir nicht.
Gruß
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Zitat:
So, jetzt ist mir klar, warum der Baustein das so macht!
Die Funktion ist soweit geklärt.
Deiner "Abhandlung" kann ich NICHT folgen
Zitat:
Warum man aber anhand der 3000-fachen Frequenz entscheidet, ob das Eingangssignal fehlerhaft ist, oder nicht, bleibt mir schleierhaft.
Ich würde sagen --> 3-fache Abweichung der momentan errechneten Frequenz ( Zeiteinheiten in ms)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Zitat:
1. Als TIMELOW nehme ich 2s und als TIMEHIGH 1s. PERIODS setze ich auf 7. Dann ist es so, daß FREQ_MEASURE.V immer wieder neu bis 7 zählt, und VALID nur dann HIGH ist, wenn V=7. Außerdem wird der Frequenzwert am Ausgang nur dann aktualisiert, wenn VALID=TRUE.
In diesem Beispiel war es ja so, daß V immer wieder zurückgesetzt wurde, und neu hochzählte. Hab ich ja auch geschrieben.
Das Eingangssignal hat eine Periodendauer von 2s+1s=3s. Dies ergibt eine Frequenz von 0.666Hz. Die liegt auch am Ausgang OUT an.
Die Fehlerbedingung lautet:
Gemessene Periodendauer DIFF > 3000Frequenz OUT
Soweit klar?
Und jetzt rechne ich nach:
Periodendauer DIFF=3000ms;
3000Frequenz OUT=2000;
Somit ist die Fehlerbedingung erfüllt. Der entsprechende Programmteil wird durchlaufen, und V wird deshalb immer wieder zurückgesetzt. Soweit, so gut.
Jetzt das zweite Beispiel:
Zitat:
2. Als TIMELOW nehme ich jetzt 1s und als TIMEHIGH 500ms. PERIODS setze ich wieder auf 7. In diesem Falle bleibt V=7, und VALID bleibt immer TRUE. Der Freuquenzwert wird mit jeder steigenden Flanke aktualisiert.
Wenn Du hier nachrechnest, kommst Du auf:
Periodendauer DIFF=1500ms;
3000*Frequenz OUT=2000;
Die Fehlerbedingung ist damit nicht erfüllt. Also bleibt immer V=7 und VALID bleibt durchgehend TRUE.
Die Frequenz wird deshalb auch bei jeder Flanke neu berechnet, so wie es sein soll.
Hoffe, ich konnte das so rüberbringen. Ich habe jetzt jedenfalls verstanden, warum sich der Baustein in beiden Fällen unterschiedlich verhalten hat.
Zitat:
Ich würde sagen --> 3-fache Abweichung der momentan errechneten Frequenz ( Zeiteinheiten in ms)
Hier liegt der Hund begraben. Die Frequenz OUT ist eine Angabe in Hertz. Und die Periodendauer ist eine Angabe in sek bzw. ms.
Es wird die dreifache Frequenz mit der Periodendauer verglichen. Und warum man das macht, verstehe ich nicht.
Sinnvoller wäre es aus meiner Sicht, meinetwegen die durchschnittliche Periodendauer der letzten 3 Messungen mit der aktuellen Periodendauer zu vergleichen. Und wenn diese signifikant darüberliegt, kann man sagen, es ist ein Fehler.
Aber eine Frequenz mit einer Periodendauer zu vergleichen, macht in meinen Augen keinen Sinn.
Gruß
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo,
ich habe mal zwei Fragen zur Arbeitsweise des Bausteins FREQ_MEASURE aus der Bibliothek util.lib.
Und zwar steht in der Hilfe, daß der Ausgang VALID dann FALSE ist, wenn noch keine komplette Meßreihe vorhanden ist, also wenn noch nicht die Anzahl der Messungen wie am PERIOD-Eingang vorgegeben, erreicht wurde, richtig?
Allerdings habe ich beobachtet, daß VALID abhängig von der Eingangsfrequenz entweder immer TRUE bleibt, oder (bei niedrigen Frequenzen) zwischen TRUE und FALSE hin und her toggelt. Woran liegt das?
Dann die zweite Frage:
VALID wird auch dann FALSE, wenn die gemessene Periodendauer größer als das Dreifache des Ausgangs OUT ist.
Der Ausgang OUT gibt aber die Frequenz an. Was macht es dann also für einen Sinn, das Dreifache der Frequenz als Vergleichswert für die Periodendauer zu nehmen?
Entschuldigung, wenn sich die Fragen dumm anhören, aber ich arbeite noch nicht lange mit CodeSys, und bin mit Details nicht vertraut. Ich schreibe lediglich einfache Testprogramme für die Funktionsbausteine.
An FREQ_MEASURWE beiße ich mir allerdings gerade die Zähne aus, da ich die Arbeitsweise nicht verstehe.
Vielen Dank für Antworten
Gruß, Robert
Hi
Schau dir den Quellcode dazu an
Ist auch Quelltextoffen wie die w www.OSCAT.de w Lib.
Hallo,
danke für die Antwort.
Den Quellcode hab ich mir auch schon angeschaut, aber auch damit komme ich nicht weiter. Leider ist so gut wie gar nichts kommentiert.
Ich habe mir auch die Signalverläufe mit der Traceaufzeichniung angeschaut, aber bis jetzt komme ich nicht weiter.
Ich werde es aber weiter probieren.
Gruß
Robert
Hi
Was willst du eigentlich machen.
Wofür brauchst du es ?
Schau dir doch mal die w www.oscat.lib w an.
Diese ist kostenlos und MIT Quellcodes.
Zusätzlich gibt es ein Handbuch für die einzelnen Funktionen.
Ab Seite 233 des OSCAT-Handbuches findest du etliche Bausteine, die für dich passen könnten.
(Ich weiss ja nicht mal genau was du suchst/brauchst )
Ich arbeite bei Bosch Rexroth, und muß für die Funktionsbausteine von CoDeSys (bei uns heißt es IndraLogic) Programme schreiben, die austesten, ob die Bausteine so funktionieren, wie sie sollen, und das Ergebnis dann in eine Protokolldatei schreiben. Aus dem Protokoll soll dann ersichtlich sein, ob alles Ok ist, oder ob etwas schief gelaufen ist.
Diese Testprogramme sollen immer dann benutzt werden, wenn es einen neue Version oder Änderungen an IndraLogic gibt, und es evtl sein könnte, daß ein Baustein nicht mehr richtig funktioniert.
Und im Moment geht es eben speziell darum, einen Testmechanismus für den Baustein FREQ_MEASURE zu finden. Aber den kann ich nicht schreiben, wenn ich die Arbeitsweise nicht genau verstehe.
Es geht also nicht darum, irgendwelche Funktionen zu realisieren, für die ich auch die OSCAT.lib benutzen könnte, sondern es geht eigentlich um die Funktionsbausteine selbst.
Gruß
Robert
Ach so.
Definiere doch mal, welche min. und max. Frequenzen du messen willst ?
Welchen Wert setzt du für "PERIODS" ?
Also ich speise den FREQ_MEASURE mit einem Signal, das der BLINK-Baustein generiert. Bitte nicht wundern, daß die Frequenzen so extrem niedrig sind, aber ich will die Funktion mit der Traceaufzeichnung beobachten, und habe deswegen alles so langsam eingestellt.
Als TIMELOW nehme ich 2s und als TIMEHIGH 1s. PERIODS setze ich auf 7. Dann ist es so, daß FREQ_MEASURE.V immer wieder neu bis 7 zählt, und VALID nur dann HIGH ist, wenn V=7. Außerdem wird der Frequenzwert am Ausgang nur dann aktualisiert, wenn VALID=TRUE.
Als TIMELOW nehme ich jetzt 1s und als TIMEHIGH 500ms. PERIODS setze ich wieder auf 7. In diesem Falle bleibt V=7, und VALID bleibt immer TRUE. Der Freuquenzwert wird mit jeder steigenden Flanke aktualisiert.
Warum wird V im ersten Beispiel immer wieder auf null gesetzt, obwohl das Eingangssignal OK ist?
Und welche Funktion hat diese Quelltextzeile:
Danke für die Hilfe!!
Gruß
Robert
P.S. Habe gerade erst "ausgelernt" und bin noch nicht lange hier. Daher arbeite ich auch erst seit kurzer Zeit mit CoDeSys.
Hi
Laut Code O.K !
Sorgt dafür, dass "B" eine Zahl zwischen 0 und "PERIODS-1" hat.
(Indexierung)
Bleibt nur die Frage:
Wenn Permenent gleichbleibende Eingangssignale kommen bleibt "V" bei dir auf z.b. 7.
Irgendwie muss bei "VALID" = TRUE ein "RESET" Signal gegeben werden.
Dann fängt "V" auch bei 1 an, bei 7 hast du dann erst das "VALID" = TRUE
Das erklärt auch das Verhalten bei deinem Test.
Vieleicht hat CoDeSys ein Beispielprogramm für dich ?
Kurzum, ein "Bedienfehler".
DESHALB ist es auch WICHTIG, dass Bibliotheken Quelltext-Offen sind.
Ich würde eine Funktion nehmen, die Permenent die Frequenz misst.
Z.b. w www.oscat.de w Funktion "M_T", die hat jedoch KEINE "Mittelwertbildung".
Hallo Karl,
Ich verstehe nicht ganz, denn genau das Verhalten, das Du da beschreibst, macht der Baustein ja abhängig von der Eingangsfrequenz.Er macht es mal so, mal so, und genau das irritiert mich ja. (siehe meine obigen Beispiele)
Es scheint so zu sein, daß die Eingangssignale manchmal als fehlerhaft erkannt werden, so daß dieser Codeteil durchlaufen wird:
Hier wird V auf null gesetzt.
Bei hohen Frequenzen wird der Codeabschnitt - warum auch immer - nicht durchlaufen.
Ja, B wird mit dieser Funktion offensichtilich immer wieder neu hochgezählt, aber wie die "MOD"-Funktion mit reinspielt, habe ich nicht verstanden.
Das nützt mir leider nichts, denn meine Aufgabe ist es ja gerade, den FREQ_MEASURE auf Herz und Nieren zu testen.
Gruß
Robert
Hi
Ich würde mal sagen:
Zykluszeit 10ms --> Low-High-Wechsel --> 50 Hz sind schon die "Grenze"
Zuerst mit der kleinen Frequenz.
Nachfolgen mit der grossen Frequenz.
Vor dem Testen des 2. Bausteins musst du den Baustein reseten !
Falls nicht --> bleibt V=7 und VALID=TRUE
Hi
Soll ich dir mal meine Einstellung dazu sagen:
Der Aufwand, um festzustellen und zu Protokolieren wie und DASS die Funktion so funktioniert wie diese gewünscht ist, ist wesentlich höher als die Funktion selber zu schreiben/anzupassen.
Passe dir doch die Funktion an, so wie dein Bedarf ist.
Ernenne diese zum "Standard" für euere Firma.
Gebe der Funktion einen neuen Namen z.b. R_FREQ_MEASURE
( R von Robert )
Zudem könnte mann sich diese so anpassen, dass diese OHNE RESET mit Mittelwertbildung arbeitet. Z.b. mit einer FIFO, du "alte" Werte rauswirft oder so, somit brauchtst du NICHT immer warten, bis die Anzahl der Durchläufe erreicht ist/wird.
Denk doch mal nach, wie diese Funktion in der Praxis zu Fehlern führen kann. Eine genaue Beschreibung und Funktionsweise ist UNUMLÄSSIG notwendig. Auch ein Example hierzu ist sinnvoll.
Ich hoffe dir geholfen zu haben
Hallo,
Ja, so steht es in der Hilfe. Ich glaube, ich weiß jetzt, wie es funktioniert:
Beispiel B=2 und PERIODS=7
B= (2+1) MOD 7 -->
B= 3 MOD 7 -->
B= Rest von 3/7 --> 3/7=0 Rest 3
So dürfte es funktionieren!? Bei 7 folgt Rücksetzen auf null.
Jetzt bin ich schon ein kleines Stück weiter.
Momentan ist die Zykluszeit auf 4ms gestellt. Bei der Periodendauer bewege ich mich (siehe Beispiele in meinem 4.Post) im Bereich von über 1,5s. Von daher dürfte es in dem Bereich nicht kritisch werden.
Bis jetzt habe ich noch kein selbstständiges Testprogramm geschrieben, sondern nur per Hand versch. Eingangssignale angelegt, die der "BLINK"-Generator erzeugt. Und dann habe ich eben die Reaktion von FREQ_MEASURE beobachtet. Dabei sind dann meine ganzen Fragen aufgetaucht.
Aber mit Deiner Hilfe bin ich nun schon ein ganzes Stück weiter gekommen.
Gruß
Robert
Das war jetzt ein dickes Ding.
Selbstständig kann und darf ich nicht darüber entscheiden, wie und ob die Funktion geändert werden darf. Darüber entscheiden andere.
Außerdem ist unser IndraLogic ja nach diesem IEC61131-3 genormt, und da kann man nicht einfach was abändern, oder?
Zur Info:
Unsere Firma verkauft Steuerungssysteme, und IndraLogic ist ein Teil unseres Angebots, und in unsere Software integriert. Wir verkaufen CoDeSys sozusagen selber nur weiter. Und wir müssen nur dafür sorgen, daß alles einwandfrei funktioniert, denn unsere Kunden arbeiten ja mit unseren Produkten.
Gruß
Robert
Jedoch wird bei "7" NUR die Variable "B" auf 0 gesetzt.
Die Variable "V" bleibt auf "7" bis "Fehler" ODER "RESET" !
Hallo,
erinnerst Du Dich noch an meine zwei Beispiele?
Beispiel 1: Periodendauer=3s, Frequenz=0,333Hz !
Frequenz*3000 = 1000 -->
Periodendauer 3000ms > 1000ms ---> daher wird Signal als fehlerhaft erkannt.
Beispiel 2: Periodendauer=1,5s, Frequenz=0,666Hz !
Frequenz*3000 = 2000 -->
Periodendauer 1500ms < 2000ms ---> daher wird Signal als OK erkannt.
So, jetzt ist mir klar, warum der Baustein das so macht!
Die Funktion ist soweit geklärt.
Warum man aber anhand der 3000-fachen Frequenz entscheidet, ob das Eingangssignal fehlerhaft ist, oder nicht, bleibt mir schleierhaft.
Gruß, Robert
Genau!
Das habe ich verstanden.
Nur, warum man die Entscheidungsbedingung für "Fehler" ausgerechnet SO (3000-fache Frequenz) festgelegt hat, erschließt sich mir nicht.
Gruß
Robert
Deiner "Abhandlung" kann ich NICHT folgen
Macht nichts, ich erkläre es nocheinmal.
Erstes Beispiel:
In diesem Beispiel war es ja so, daß V immer wieder zurückgesetzt wurde, und neu hochzählte. Hab ich ja auch geschrieben.
Das Eingangssignal hat eine Periodendauer von 2s+1s=3s. Dies ergibt eine Frequenz von 0.666Hz. Die liegt auch am Ausgang OUT an.
Die Fehlerbedingung lautet:
Gemessene Periodendauer DIFF > 3000Frequenz OUT
Soweit klar?
Und jetzt rechne ich nach:
Periodendauer DIFF=3000ms;
3000Frequenz OUT=2000;
Somit ist die Fehlerbedingung erfüllt. Der entsprechende Programmteil wird durchlaufen, und V wird deshalb immer wieder zurückgesetzt. Soweit, so gut.
Jetzt das zweite Beispiel:
Wenn Du hier nachrechnest, kommst Du auf:
Periodendauer DIFF=1500ms;
3000*Frequenz OUT=2000;
Die Fehlerbedingung ist damit nicht erfüllt. Also bleibt immer V=7 und VALID bleibt durchgehend TRUE.
Die Frequenz wird deshalb auch bei jeder Flanke neu berechnet, so wie es sein soll.
Hoffe, ich konnte das so rüberbringen. Ich habe jetzt jedenfalls verstanden, warum sich der Baustein in beiden Fällen unterschiedlich verhalten hat.
Hier liegt der Hund begraben. Die Frequenz OUT ist eine Angabe in Hertz. Und die Periodendauer ist eine Angabe in sek bzw. ms.
Es wird die dreifache Frequenz mit der Periodendauer verglichen. Und warum man das macht, verstehe ich nicht.
Sinnvoller wäre es aus meiner Sicht, meinetwegen die durchschnittliche Periodendauer der letzten 3 Messungen mit der aktuellen Periodendauer zu vergleichen. Und wenn diese signifikant darüberliegt, kann man sagen, es ist ein Fehler.
Aber eine Frequenz mit einer Periodendauer zu vergleichen, macht in meinen Augen keinen Sinn.
Gruß
Robert