- 12V Akku mit 280 Ah bauen         
Ergebnis 1 bis 10 von 33

Thema: Unruhige Anzeige bei Drehzahlmesser für Zweitaktmotor

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.899
    Zitat Zitat von Searcher Beitrag anzeigen
    Im Anhang noch 256 Zündimpulsabstände (Einheit = µs) mit Ordnungsnummer, die bei noch kalter Maschine über etwa 5 Sekunden aufgezeichnet wurden. In einem Graph dargestellt ergab sich ein echt unerwartet interessantes Bild
    Das ist tatsächlich interessant. Das könnte sowohl aus der Messung kommen als auch einen Effekt des Motors (läuft unrund) darstellen.

    Leider sind in der Tabelle die schon verrechneten Werte. Schöner wäre es gewesen, wenn du einfach die Werte des Capture Register aufgezeichnet hättest. Die Differenz, die Zeit kann man auf dem PC leicht daraus berechnen und man könnte sehen, wann ein Overflow auftritt und ob er einen Einluß hat (ich vermute mal nicht, aber sicher ist sicher). Man könnte dann auch die Messwerte über der Zeitachse zeigen. Alle Rechnungen eingeschlossen den Tiefpass kann an dann am PC z.B. mit Excel machen ohne den Motor anzuwerfen. Da kann man auch alle Berechnungen in float machen und Probleme mit Overflow oder Underflow vermeiden. Dann kann man später entscheiden, ob man für den µC auf Integer umsteigt und wie man dafür die Formeln aufbaut, um das zu vermeiden.

    MfG Klebwax
    Strom fließt auch durch krumme Drähte !

  2. #2
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    40
    Beiträge
    3.416
    Also wenn ich mir die Daten ansehe, wäre ein Extremwertfilter eine bessere Lösung!

    Außerdem sollte man Timerüberläufe mit aufzeichnen um mehr Konsistenz in die Daten zu bekommen!

    Ich komme im Schnitt auf 800 Digits wenn ich die Extremwerte ignoriere

    Das Bild das mir der Graph in Excel über deine Daten zeigt, sagt mir dass du einen systematischen Fehler bei der Messung hast, alle ~10 Samples hast du einen systematischen Ausreißer + ein paar zufällige, welche aber auch das Problem hindeuten!

    Ich vermute dein Problem immernoch beim Messaufnehmer oder eventuell im "debounce"

    Wenn du nochmal Daten sammeln kannst und zusätzlich eine Info ob und wieviel Überläufe zwischen den Samples liegen? (eventuell einfach den Zeitwert nehmen und die unteren beiden Bits maskieren und überschreiben, Bit 1 für timer einmal übergelaufen und Bit 0 für Timer mehr als einmal übergelaufen)

    Dann kann man zumindest schonmal einschränken dass wir ganze dekaden an signalen verpassen (das vermute ich nämlich aktuell)

    Ungewöhnlich ist auch dass der Timerwert immer relativ stabil um die 20k herum eiert und es sprünge gibt sobald man <13k oder >27k im timer hat, eventuell haben wir eine Schwebung!?

    auch wenn ich jetzt 2700 rpm nehme machen 5 Sekunden eher 225 Samples .. bei 3000rpm mit 250 schon eher wahrscheinlich (aber wäre auch logisch wenn er kalt ist)
    Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
    nicht.

  3. #3
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.899
    Zitat Zitat von Ceos Beitrag anzeigen
    Ich vermute dein Problem immernoch beim Messaufnehmer oder eventuell im "debounce"
    ACK

    MfG Klebwax
    Strom fließt auch durch krumme Drähte !

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.715
    Blog-Einträge
    133
    Zitat Zitat von Klebwax Beitrag anzeigen
    Leider sind in der Tabelle die schon verrechneten Werte. Schöner wäre es gewesen, wenn du einfach die Werte des Capture Register aufgezeichnet hättest
    Hab ich jetzt gemacht. Die ISR "Isr_get_icr" zum Sichern des ICR-Werte verändert, so daß jetzt der echte Inhalt aufgezeichnet wird. siehe Code. Der Rest des Simulatorprogramms von weiter oben im thread ist unverändert. Samples wieder im Anhang.
    Code:
    Isr_get_icr:
      Incr Ignition_seq
      Firing_interval(ignition_seq) = Icr1
      If Ignition_seq >= Sample_count Then                      'array full, stop recording
        Disable Icp1                                            'disable ICP1
        Tccr1b = 0                                              'init, stop timer1
        Flag_rec_complete = 1
        Ignition_seq = 0
      End If
    Return
    Zitat Zitat von Ceos Beitrag anzeigen
    Ich vermute dein Problem immernoch beim Messaufnehmer oder eventuell im "debounce"
    Wenn du nochmal Daten sammeln kannst und zusätzlich eine Info ob und wieviel Überläufe zwischen den Samples liegen? (eventuell einfach den Zeitwert nehmen und die unteren beiden Bits maskieren und überschreiben, Bit 1 für timer einmal übergelaufen und Bit 0 für Timer mehr als einmal übergelaufen)
    Es sollten eigentlich kein Meßfehler vorliegen. Der Debounce Befehl in Bascom nutzt keinen Interrupt. Wenn die Hauptschleife dort vorbeikommt, wird erst nur der Pin auf gedrückte Taste, in diesem Fall nur einmal auf LOW-Pegel getestet. Wenn kein Tastendruck, also kein Low-Pegel erkannt wird, wird sofort in der Haupschleife weitergemacht. Während der Aufzeichnung ist keine Taste gedrückt. Wenn auf gedrückte Taste erkannt wurde, kann die Hauptschleife, wenn nichts anderes konfiguriert wurde, bis zu 25ms aufgehalten werden. Sprung zu Interrupts würden dadurch aber nicht behindert werden. Im Dateianhang "icr_werte.txt" sind die ICR Werte abgelegt. Man kann dort die Überläufe erkennen wenn nach einem hohen Wert ein kleinerer auftaucht. Falls noch mehr Daten gebraucht werden - kein Problem ...

    An der Impulsaufnahme zweifle ich auch nicht, da mehrfach direkt am Abnahmedraht und mehreren Stellen in der CD4093 Schaltung mit Oszi überprüft. Halte meine Augen aber trotzdem auch in der Richtung noch offen.

    Ich denke, der Motor läuft wirklich so wie die Daten es zeigen. Das Laufgeräusch im Leerlauf bei Standgas ist alles andere als rund und "schnurrend". Typisches Zweitaktergeräusch; scheint normal zu sein. Ganz am Anfang vom Video https://youtu.be/d9_J9TI6dx8 läuft auch eine im Standgas. Anwerfen und Laufgeräusch meiner Säge als MP3 mit 7zip in der zip Datei im Anhang.

    Gruß
    Searcher
    Angehängte Dateien Angehängte Dateien
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  5. #5
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    40
    Beiträge
    3.416
    mhhh ... ändert leider nicht viel am ergebnis

    kannst du mal ein paar bits opfern um den timerüberlauf mit zu erfassen wie ich es oben beschrieben habe?!
    Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
    nicht.

  6. #6
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.899
    Zitat Zitat von Ceos Beitrag anzeigen
    mhhh ... ändert leider nicht viel am ergebnis

    kannst du mal ein paar bits opfern um den timerüberlauf mit zu erfassen wie ich es oben beschrieben habe?!
    Die kann man doch aus den Werten rauslesen. Wenn der neue Wert kleiner als der vorherige Wert ist, ist der Timer übergelaufen. Anders kann das der Interupthandler auch nicht rausfinden.

    MfG Klebwax
    Strom fließt auch durch krumme Drähte !

  7. #7
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    40
    Beiträge
    3.416
    Anders kann das der Interupthandler auch nicht rausfinden
    Overflow sollte einen eigenen interrupt haben

    nur vom vorherigen wert auszugehen birgt das risiko einen vollen durchlauf zu verpassen

    (ich bin nicht firm in Bascom und versteh den code nur ansatzweise!!!)

    Worum es mir geht ist eine inkonsistenz deiner werte alle ~10 messungen, irgendwas passiert da dass das timing durcheinanderbringt!

    Kannst du mir mal aufschlüsseln wie dein capture timer konfiguriert hast?! 8Mhz F_CPU sehe ich ja aber bei der timer init komm ich ins schleudern
    Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
    nicht.

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.715
    Blog-Einträge
    133
    Zitat Zitat von Ceos Beitrag anzeigen
    Overflow sollte einen eigenen interrupt haben
    Hat Timer1. Erklärung s.u.

    Zitat Zitat von Ceos Beitrag anzeigen
    kannst du mal ein paar bits opfern um den timerüberlauf mit zu erfassen wie ich es oben beschrieben habe?!
    Kannst du mir mal aufschlüsseln wie dein capture timer konfiguriert hast?! 8Mhz F_CPU sehe ich ja aber bei der timer init komm ich ins schleudern
    Die Programmteile stammen aus dem Simulator Programm.
    Code:
    On Timer1 Check_icp_alive                                   'on timer1 overflow -> ISR Check_icp_alive
    On Icp1 Isr_get_icr                                         'on icp1 interrupt -> ISR isr_get_isr
    
    
    Start_record:
      Tccr1a = 0                                                'init timer1
      Tcnt1 = 0
      Ignition_seq = 0
      Flag_rec_complete = 0
      Tifr1.tov1 = 1                                            'reset eventually set TOV1 Flag
      Enable Timer1                                             'enable timer1 overflow interrupt
      Icr_old = Icr1                                            'not nessecary. artifact ?
      Enable Icp1                                               'enable ICP1 Interrupt
      Tccr1b = Bits(cs11 , Ices1)                               'prescaler=8 timer1 clocked with 1MHz, ICP Interrupt on rising edge
      Portc.pc4 = 1                                             'rec LED on
    Return
    
    
    
    Isr_get_icr:
      Incr Ignition_seq
      Word_variable = Icr1 / 10
      Firing_interval(ignition_seq) = Word_variable * 10        'letzte Dezimalstelle auf Null
      If Ignition_seq >= Sample_count Then                      'array full, stop recording
        Disable Icp1                                            'disable ICP1
        Tccr1b = 0                                              'init, stop timer1
        Flag_rec_complete = 1
        Ignition_seq = 0
      End If
    Return
    
    
    
    Check_icp_alive:
      Firing_interval(ignition_seq) = Firing_interval(ignition_seq) + 1       'bei timer1 überlauf wird zum letzten gespeicherten ICR wert Eins addiert
      If Ignition_seq_old = Ignition_seq Then
          Flag_icp_dead = 1
        Else
          Ignition_seq_old = Ignition_seq
      End If
    Return
    Mit zB "on timer1 check_icp_alive" werden die Interrupt Vektoren initialisiert

    Die "Start_record" ist ein Unterprogramm und wird mit Drücken der Record Taste aufgerufen.
    Dort wird der Timer1 initialisiert und mit Vorteiler 8 gestartet. Läuft bei Systemtakt von 8MHz dann mit 1MHz, Periodendauer = 1µs. Vorteil: Den ausgelesenen Wert aus ICR1 kann man mit Einheit µs versehen. Hab noch ein paar Remarks im Code eingefügt. Mit den Interrupts scharf machen (enable) und Starten des Timers beginnt die Meßwertaufnahme.

    Die ISR_get_icr ist eine ISR und wird durch den ICP Interrupt aufgerufen. Dort wird jetzt die letzte Dezimalstelle auf Null gesetzt. Wenn 256 Werte aufgenommen sind wird Timer1 gestoppt mit tccr1b=0 und der ICP Interrupt wieder disabled.

    Die ISR Check_icp_alive wurde und wird bei Timer1 Überlauf aufgerufen und dient eigentlich dazu festzustellen, ob überhaupt ICP Interrupts (Zündimpulse) auftreten. Aussetzen kann passieren, wenn zB das Impulsabnehmerkabel nichts liefert. In dieser ISR wird jetzt zusätzlich dem letzten, vor dem Overflow gespeicherten ICR Wert, Eins aufaddiert. Falls sich da was verschluckt müßte an der letzten Stelle mal eine Zwei auftauchen. Eine Eins immer dann, wenn nach einer großen Zahl eine kleinere auftauscht.

    Im Anhang die Werte mit diesem Programm.

    Worum es mir geht ist eine inkonsistenz deiner werte alle ~10 messungen, irgendwas passiert da dass das timing durcheinanderbringt!
    Ich glaube, daß die Meßwerte stimmen. Die Ausreißer könnten von der Drehzahlregelung der Maschine kommen: Die Drehzahl sinkt langsam ab. Dann wird schnell auf höhere Drehzahl geregelt. Ein Ausreißer ist die Zündung auf dem Weg nach "oben". Dann sinkt die schnelle Drehzahl wieder langsam ab bis das Spiel von vorne beginnt.

    Gruß
    Searcher
    Angehängte Dateien Angehängte Dateien
    Geändert von Searcher (12.06.2019 um 16:24 Uhr)
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  9. #9
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.715
    Blog-Einträge
    133
    Hallo,
    nach einer Pause habe ich mir heute wieder den Drehzahlmesser vorgenommen. Um ein paar neue Daten für den Simulator zu bekommen wurde der Zweitakter mal auf ca. 4500Upm mit Hochdrehen der Standgasschraube eingestellt. Mitteln der Drehzahl per Auge am PC Bildschirm mit den hüpfenden Ausgaben.

    256 Meßwerte mit Simulator aufgenommen und über den eigentlichen Drehzahlmesser gemessen. Gegenwärtige Glättung noch durch Aufaddieren der ICR Meßwerte in einem Anzeigeinterval (etwa eine Sekunde). Im Anzeige-Interrupt wird die Summe zusammen mit der zugehörigen Anzahl der Summanden in einem Array abgespeichert. Im Augenblick gibt es nur zwei Arrayelemente, die zyklisch überschrieben werden. Aus diesen Elementen wird dann noch ein einfacher Mittelwert gebildet und die Einerstelle auf Null gesetzt. Also wird der Wert aus dem vorherigen Anzeigeinterval mit dem aktuell auszugebenden verrechnet. In diesem Drehzahlbereich von ca. 4500Upm laufen etwa 160 Werte pro Anzeigeinterval auf. Das reicht um eine relativ ruhige Anzeige hinzubekommen. Der Motor läuft hier auch viel runder wie man in der grafischen Darstellung der einzelnen Zeiten zwischen den Zündungen sehen kann. Das Muster wie bei 2700Upm gibt es nicht mehr; die Meßpunkte sind viel zufälliger wie es scheint. Allerdings greift die Kupplung in diesem Drehzahlbereich, was auch wieder eine Störung hervorrufen könnte.

    Ich wollte noch weitere Glättungen ausprobieren aber irgendwie hatte ich zwischen den umgerechneten Werten des Simulators im Excel und der gemessenen Drehzahl mit dem Drehzahlmesser immer etwa 60, 70 Upm zu wenig. Die Fehlersuche hat mich fast den ganzen Nachmittag beschäftigt. Oszi zeigte richtige Pulslänge vom Simulatorausgang an. Letzten Endes kam heraus, daß der Quarz am Drehzahlmesser um 100kHz zu schnell lief, also 8,1Mhz statt 8,0MHz. Das Ding hatte ich zuletzt ohne zu überprüfen ausgetauscht. Einen anderen 8.0MHz Quarz rein und alles war gut. Die RS232 zum PC hatte nichts gemerkt.

    Gruß
    Searcher
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

Ähnliche Themen

  1. Drehzahlmesser
    Von -Hurricane- im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 2
    Letzter Beitrag: 18.08.2014, 22:33
  2. Drehzahlmesser
    Von highcom im Forum Elektronik
    Antworten: 4
    Letzter Beitrag: 05.05.2010, 10:58
  3. Drehzahlmesser
    Von vohopri im Forum Vorstellungen+Bilder von fertigen Projekten/Bots
    Antworten: 24
    Letzter Beitrag: 14.03.2010, 08:08
  4. Drehzahlmesser
    Von derdaswar im Forum Controller- und Roboterboards von Conrad.de
    Antworten: 10
    Letzter Beitrag: 17.07.2009, 16:45
  5. Drehzahlmesser
    Von TheHawk im Forum Elektronik
    Antworten: 13
    Letzter Beitrag: 14.12.2007, 20:04

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

fchao-Sinus-Wechselrichter AliExpress