Messfehler von Drehzahlerfassungen filtern

julianpe

Level-1
Beiträge
61
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich lese mit einer Task zwei Drezahlen ein. Ich erwarte dort Werte von [0...16] Hz.
Durch Fehlmessungen kommt es manchmal vor, dass im Programm der Drehzahlwert über diesen Wertebereich springt.
Wie kann ich eine schnelle Überprüfung zwischen dem Auslesen und dem Weiterverarbeiten zwischenschalten,
die einfach schaut ob der eingelesene Wert valide ist.

Ich hatte mir das folgendermaßen vorgestellt:

[PSEUDOCODE]

Code:
IF AKTUELLE_RPM > 1.01*TEMP_RPM THEN
    // Fehlmessung:
    // Letzter gespeicherte Wert wird ausgegeben

ELSIF AKTUELLE_RPM < 0.99*TEMP_RPM THEN
    // Fehlmessung:
    // Letzter gespeicherte Wert wird ausgegeben
ELSE
    // Aktuelle Drehzahl ist im 10% Bereich des vorherigen Wertes
    TEMP_RPM := AKTUELLE_RPM;
END_IF

AUSGANG := TEMP_RPM;

Wie kann ich das vielleicht einfacher mit einem Baustein realisieren?
Ich bekomme leider durch die o.g. Lösung beim Aufstarten
eine 0 in TEMP_RPM geschrieben. Und dann werden alle folgenden (validen)
Drehzahlen nicht mehr in den Ausgang geschrieben.

Gibt es eine schönere Lösung?
 
1. Kleinigkeit: bei 10% solltest Du mit 1.1 multiplizieren und nicht mit 1.01
2. Eventuell ist beim Starten des Antriebes die Differenz der Drehzahlen zu groß-> Anlaufüberbrückung einbauen. Man muss nur aufpassen, dass Dir nicht das gleiche Schicksal im Betrieb bei Sollwertänderungen passiert.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wodurch werden denn die Fehlmessungen erzeugt? Ich meine eine stabile Messwerterfassung ist wichtiger als ein Workaround um damit umzugehen.
Unter 10Hz favorisiere ich in der Regel eine Periodendauermessung.

Edit: Abhängig von den rechnerischen Impuls/Pause-Verhältnissen bei digitaler Signalerfassung kann der Einsatz von Zählerkarten sinnvoll sein.
Noch ein edit: Wie oft kommen die Messfehler vor? Eine gleitende Mittelwertbildung oder/und ein Tiefpass (PT1) könnten Ausreisser glätten.
 
Zuletzt bearbeitet:
Ich hab bei einem ähnlichen Problem einen Counter mitlaufen lassen. Wenn mehr als X-mal in Folge korrigiert wurde, dann übernimm direkt den neuen Wert.
 
Hallo,

ich habe mal ein PT1 Glied zwischen Drehzahlerfassung und Drezahlverarbeitung eingefügt.
Habe mich dazu von der Oscat Bibliothek bedient: FT_PT1

Jedoch bekomme ich bei höheren Drehzahlen eher mal Fehlmessungen, die der Tiefpass nicht abdecken kann.
Gibt es eine weitere Möglichkeit, Spitzen zu filtern?

19-08-_2016_10-30-37.jpg
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Darf ich nochmal die Frage wiederholen: Wie erfasst Du die Drehzahl?
16Hz klingt nach einem 6poligen Motor mit einem Impuls pro Umdrehung.
Wie sieht der Nocken aus? Was für einen Eingang benutzt Du an der SPS?
Wie äußert sich der Fehler? Drehzahlsignal zu hoch --> Doppelauslösung
Drehzahlsignal zu niedrig? Impulse zu kurz
Nur mal so frei von der Leber weg...

Als Lektüre: http://www.sps-forum.de/sensorik/83...laenge-bei-induktiven-naeherungssensoren.html
 
Zuletzt bearbeitet:
Hallo weißnix_,

ich erfasse die Drehzahl mit induktiven Näherungssensoren.
Habe eine Antriebswelle mit einer Schaltnocke drauf.
Die Spannungsflanken erfasse ich mit einer Wago 750-411 Eingangskarte.

Ich habe einen Task in Codesys definiert, der das Einlesen der digitalen Eingänge übernimmt.
Dort wird dann auch die aktuelle Drehzahl in Abhängigkeit der gezählten steigenen Flanken gemessen (verwendeter Baustein M_TX von Oscat)

Die Fehlmessungen werden häufiger, bzw. stärker, je höher die Drehzahl ist. Bei Drehzahlen von 7 Hz gibt es so gut wie keine Spitzen.
 
Wie schnell ist die Task? (Zykluszeit)
Fest oder freilaufend?
Also ab 7Hz fehlen Impulse? Bei der 0.2ms Eingangskarte bleibt dann die Zykluszeit. Der Impuls des Gebers muss ja anstehen, wenn das PAE aktualisiert wird.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Task wird mit 2ms fest zyklisch aufgerufen.
Habe mal aus Interesse einen CyleTimer Baustein eingefügt.
Durchschnittlich läuft die Task mit 2 ms.

Ich denke auch, dass in den oberen Drehzahlen wahrscheinlich Fehlmessungen aufgrund der Zykluslaufzeit der Task häufiger auftreten.
 
Eine andere Frage mal :
Wie sieht denn deine Drehzahl-Erfassungs-Routine (als Code) aus ?
Vielleicht wäre das Problem eher dort zu suchen ...

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn die Task eine durchschnittliche Laufzeit von 2ms hat und im Zyklusraster von 2ms aufgerufen wird, hast Du Zykluszeitüberschreitungen - oder?
Eine zyklische Task sollte eine maximale Laufzeit (einschließlich Taskunterbrechungen durch höherpriore Tasks + PAE + PAA) von höchstens der Zykluszeit haben.
Die rechnerische Impulslänge des Ini sollte dann mindestens 4ms betragen. Beachte den oben verlinkten Thread, der beleuchtet genau diese Zusammenhänge.
 
Hallo Larry,

meine Routine welche im Task ausgelagert ist sieht folgendermaßen aus:
Drehzahl.jpg

Im Prinzip bekomme ich über die beiden digitalen Eingänge _DI_2_1 und _DI_2_2 die Impulse vom Näherungssensor. Gebe diese Signale in den Baustein M_D der die Zeit zwischen den Pulsen misst (brauche die Info an anderer Stelle). Und das wesentliche passiert eigentlich im M_TX Baustein. Gebe dort die Pulse rein und der Baustein berechnet mir die resultierende Frequenz.
 
Was ist denn "M_D" ? Eine Art Timer ?
Ich würde so etwas grundsätzlich über die Systemzeit machen - also mit dem Nocken die Systemzeit (die ist ja in Millisekunden) einlesen und speichern und dann immer die Differenz zwischen dem aktuellen und dem letzten verrechnen ...

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Misst Du mit 2 Eingängen?
M_TX gibt direkt eine Frequenz aus mit einem Eingangssignal.
Edit: wer lesen kann ist klar im Vorteil, sry

@Larry
Die Bausteine sind aus Oscat und beziehen sich intern auf eine Systemtimerauswertung.

@julianpe
Nochmal zur Zykluszeit und eventuellem Multitasking:
Hast Du mehrere Tasks? Für mich sind Fehler bei höheren Frequenzen bei nicht erfassten Impulsen zu suchen. Schalte doch mal alle anderen Bearbeitungen aus und beobachte dann die Werte und die Ausführungszeiten.
 
Zuletzt bearbeitet:
Was ist denn "M_D" ? Eine Art Timer ?
M_D stammt, wie M_TX, aus OSCAT-BASIC und ne simple Stoppuhr.
OSCATBASIC:LIBRARYDokumentation schrieb:
M_D misst die Zeit zwischen einer steigenden Flanke an START und einer steigenden Flanke an STOP

WIe der TE schon angedeutet hat hat der M_D hier aber nix mit der Frequenzbestimmung zu tun.
Die Frequenz macht er unten mit M_TX wo er die positive Flanke eines Eingangs aufgeschalten hat.
Kenn die Codesys-Variante aber nicht, der Baustein misst aber die Zeit zwischen Impulsen und ist sicher irgendwie Syxstemzeit- oder Timer-basiert.
Sollte für die Anwendung also passen.

Ich schätze, wie die Vorredner auch, dass irgendwas mit den Task-Aufrufen, Zykluszeiten, Eingangsvezögerungen, Nockengröße, also der Abtastung nicht passen wird.
Kann mir nicht vorstellen dass der Baustein bei kontanter Drehzahl und 16Hz Messschwankungen im +/-10%-Bereich liefert.
 
Zuletzt bearbeitet:
Zurück
Oben