Discussion in 'Bugs' started by joergl, Dec 25, 2006.

  1. joergl

    joergl New Member

    Keine Ursache. Ich hab', glaube ich, noch nicht den allerletzten Stand. Der letzte Fix, den ich von Dir bekommen habe, datiert vom 05.01.2007.

    Wenn Du Herrn Sommer anrufst, kannst Du ihn freundlich von mir grüßen (wenn Du ihm sagst, daß ich meinen Lader am 22.12.2006 bei ihm persönlich abgeholt habe, erinnert er sich vielleicht an mich) und ihn darüber informieren, daß er durch meine Empfehlung mittlerweile wenigstens einen weiteren MEGARON verkauft hat. Also soll er mal einen Lader zum Testen 'rausrücken ... ;)

    Sollte das nicht klappen, gibt es mindestens noch eine dritte Möglichkeit: Du könntest einen Besitzer eines MEGARON zur testweisen Hergabe seines Laders bitten - alleine in diesem Thread sind davon mindestens zwei unterwegs. :eek: Das klappt bestimmt.

    Kein Problem. Wenn wir das gemeinsam geschafft haben, wird die Freude dafür umso größer sein.

    Gruss
    Jörg
  2. Dominik

    Dominik Administrator Staff Member

    Moin !

    Soderle, ging schneller als gedacht. Ich habe mal einen Sommer Simulator geschrieben der mir alle erdenklichen Situationen provozieren kann. Wenn der Prophet nicht zum Berg kommt, muss der Berg ebend ... :D

    Ich habe zwar noch nicht an LogView weitermachen können (wie auch, hatte ja nix was den Fehler hervorruft), aber nun kann ich den Mist halt nachstellen. Is auch was wert und sollte bald in einem neuen Fix enden :cool:

    Anbei noch ein kleines Bild. Nicht das ihr denkt ich erzähle nur was daher ... Oben der Simulator, unten mein Serial Port Terminal. Die sind über einen virtuellen Comport gekoppelt und schon kann man hin und hersenden.

    Attached Files:

  3. Dominik

    Dominik Administrator Staff Member

    neuer Fix

    Moin !

    Der Simulator war Gold wert. Ich wollte mir das nur kirz ansehen und dabei ist der neue Fix schon entstanden. Es wird jetzt generell erstmal vor dem Telegramm alles weggefiltert was <NUL> oder <CR> ist. Damit soltlen die Hänger schon mal vermieden werden.
    So, dann werden jetzt aich zerhackte Telegramme wieder richtig zusammengesetzt. Das geht zumindest solange wie keine Telegrammteile vom Lader verschluckt / nicht gesendet werden.

    So, und dank des Simulators konnte ich jetzt folgende Szenarien durchtesten:
    1. Vor dem Telegramm ein <NUL><CR>
    Kommt doch recht oft vor. Wurde vorher auch schon gefiltert. Ist jetzt aber in dem globalen Filter mit eingeflossen:
    [23:31:11,553][L3 ][RxChar Daten ] <NUL><CR>01:06522:04042:00000:06229:15249:1:1:4:00:01:01:10000:003:00:08:1:12808:00205:00314:00000:000:05844:5:2:03655:0:00000<LF><CR> | Länge: 121
    [23:31:11,563][L3 ][RxChar correct ] Cut <NUL> !!
    [23:31:11,573][L3 ][RxChar correct ] Cut Start <CR> !!
    [23:31:11,573][L4 ][SommerLader ] `-> DatenGueltig --> Daten gültig
    [23:31:11,593][L4 ][SommerLader ] `-> GetDatenKanal --> Kanal 4
    [23:31:11,593][L4 ][SommerLader ] `-> IsLogData --> Daten werden aufgezeichnet


    2. Telegramme mit vielen <NUL> davor
    Das ist die Funktion des neuen Filters. Alles an <NUL> wird elemeniert. Und auch das unnütze <CR> wird weggefiltert ...
    [23:31:56,127][L3 ][RxChar Daten ] <NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><CR>01:06522:04042:00000:06229:15249:1:1:4:00:01:01:10000:003:00:08:1:12808:00205:00314:00000:000:05844:5:2:03655:0:00000<LF><CR> | Länge: 160
    [23:31:56,127][L3 ][RxChar correct ] Cut <NUL> !!
    [23:31:56,127][L3 ][RxChar correct ] Cut Start <CR> !!
    [23:31:56,127][L4 ][SommerLader ] `-> DatenGueltig --> Daten gültig
    [23:31:56,137][L4 ][SommerLader ] `-> GetDatenKanal --> Kanal 4
    [23:31:56,137][L4 ][SommerLader ] `-> IsLogData --> Daten werden aufgezeichnet


    3. zerhackte Telegramme mit <NUL><CR> davor
    Dabei werden sogar Telegramme berücksichtigt die mehrfach zerhackt sind. Wie hier im Beispiel 3x ...
    [23:33:33,838][L3 ][RxChar Daten ] <NUL><CR>01:06522:04042:00000:06229:15249:1:1:4: | Länge: 41
    [23:33:33,838][L3 ][RxChar correct ] Cut <NUL> !!
    [23:33:33,838][L3 ][RxChar correct ] Cut Start <CR> !!
    [23:33:34,338][L3 ][RxChar Daten ] 00:01:01:10000:003:00:08:1:12808:00205: | Länge: 39
    [23:33:34,799][L3 ][RxChar Daten ] 00314:00000:000:05844:5:2:03655:0:00000<LF><CR> | Länge: 41
    [23:33:34,799][L3 ][RxChar correct ] 01:06522:04042:00000:06229:15249:1:1:4:00:01:01:10000:003:00:08:1:12808:00205:00314:00000:000:05844:5:2:03655:0:00000<LF><CR> | Länge: 119
    [23:33:34,809][L4 ][SommerLader ] `-> DatenGueltig --> Daten gültig
    [23:33:34,809][L4 ][SommerLader ] `-> GetDatenKanal --> Kanal 4
    [23:33:34,819][L4 ][SommerLader ] `-> IsLogData --> Daten werden aufgezeichnet


    4. zerhackte Telegramme mit vielen <NUL> davor
    Geht auch ...
    [23:34:26,053][L3 ][RxChar Daten ] <NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><NUL><CR>01:06522:04042:00000:06229:15249:1:1:4:00:01:01:10000:003:00:08:1:12808:00205:00314:00000: | Länge: 131
    [23:34:26,053][L3 ][RxChar correct ] Cut <NUL> !!
    [23:34:26,063][L3 ][RxChar correct ] Cut Start <CR> !!
    [23:34:27,044][L3 ][RxChar Daten ] 000:05844:5:2:03655:0:00000<LF><CR> | Länge: 29
    [23:34:27,044][L3 ][RxChar correct ] 01:06522:04042:00000:06229:15249:1:1:4:00:01:01:10000:003:00:08:1:12808:00205:00314:00000:000:05844:5:2:03655:0:00000<LF><CR> | Länge: 119
    [23:34:27,054][L4 ][SommerLader ] `-> DatenGueltig --> Daten gültig
    [23:34:27,064][L4 ][SommerLader ] `-> GetDatenKanal --> Kanal 4
    [23:34:27,064][L4 ][SommerLader ] `-> IsLogData --> Daten werden aufgezeichnet


    5. korrekte, aber zerhackte Telegramme
    Auch die werden sauber wieder zusammengeflickt ...
    [23:36:17,042][L3 ][RxChar Daten ] 01:06522:04042:0 | Länge: 16
    [23:36:17,553][L3 ][RxChar Daten ] 0000:06229:15249:1:1:4:00:01:01:10000:003:00:08:1: | Länge: 50
    [23:36:18,024][L3 ][RxChar Daten ] 12808:00205:00314:00000:000:05844:5:2:03655:0:00000<LF><CR> | Länge: 53
    [23:36:18,024][L3 ][RxChar correct ] 01:06522:04042:00000:06229:15249:1:1:4:00:01:01:10000:003:00:08:1:12808:00205:00314:00000:000:05844:5:2:03655:0:00000<LF><CR> | Länge: 119
    [23:36:18,034][L4 ][SommerLader ] `-> DatenGueltig --> Daten gültig
    [23:36:18,044][L4 ][SommerLader ] `-> GetDatenKanal --> Kanal 4
    [23:36:18,044][L4 ][SommerLader ] `-> IsLogData --> Daten werden aufgezeichnet


    Insgesamt sollte also dieser Fix eigentlich alle bekannten Fehler beheben. Wenn noch jemand etwas weiss bezüglich Problemen, dann sagt es mir noch. Ansonsten könnte ich morgen mal ne gefixte Version verschicken in der Hoffnung das es tut .... :rolleyes:
  4. joergl

    joergl New Member

    Wahnsinn! Das klingt sehr gut und ich kann die Mail mit dem Bugfix kaum erwarten ... freue mich schon darauf, das auszuprobieren. Und da bei mir in den nächsten Tagen einiges an Akkus zu laden sein wird (ich lade mittlerweile auch für Modelltruck-Freunde), gibt es auch reichlich Gelegenheit zum Testen!
    :cool:
    Gruss
    Jörg
  5. c_s

    c_s New Member

    Hurra !

    @Dominik

    Herzlichen Glückwunsch !

    Freut mich das meine Logfiles und Hinweise bzgl. des <CR> als BufferClear Dir offensichtlich weiterhelfen konnten.

    Ich hoffe damit ist es geschaft.... vorausgesetzt der Test funktioniert.

    Stehe als BetaTester gerne wieder bereit .;-)

    Grüße
    Christoph
  6. Dominik

    Dominik Administrator Staff Member

    Moin !

    Naja warten wir mal ab. Ist halt die Frage ob auch alles im realen Leben greift. Ich habe es zwar 1:1 simuliert, aber man weiss ja nie.

    Ich bin da aber ganz guter Dinge. Schicke dann heute im laufe des Tages was raus an euch.
  7. c_s

    c_s New Member

    Test ... läuft

    :):)
    Danke für die Testversion an Dominik.

    Der Test mit NiCd war direkt ein positiver Erfolg. Das Löschen des RX Buffers zeigt Wirkung. Die Aufzeichnung läuft durch.

    Ich war dann so mutig und habe auf einem zweiten Kanal einen alten PB Akku dazu geklemmt.
    Also zwei Problemfälle auf einmal.

    Morgen wissen wir mehr.:D
    Bis dann ...

    Gute Nacht.
    CS.
  8. c_s

    c_s New Member

    Test erfogreich !

    Hallo Zusammen,

    der Test der beiden Kanäle war bei meinem Lader (Megaron5+ V4.04) erfolgreich.


    Kanal 4: alter NiCd 6RC2400 - Auto Laden
    Kanal 2: alter Pb Gel 6Z12500 - Auto Laden

    Bilder anbei .

    Grüße
    CS

    PS. LiIon / LiPo funktionierte schon in der Vorgängerversion.

    Attached Files:

  9. Dominik

    Dominik Administrator Staff Member

    Schweiss von der Stirn wisch ...
  10. joergl

    joergl New Member

    Bei mir hat's auch geklappt ... der erste Versuch einer Ladung eines älteren NiCd 5-Zellers ist jedenfalls ohne Probleme durchgelaufen, am Wochenende habe ich mehr Zeit zum Testen, dann sehen wir weiter.

    Grüsse :grin:
    Jörg

    Attached Files:

  11. Dominik

    Dominik Administrator Staff Member

    Nochmal Schweiss vonne Stirn wisch ;)
  12. joergl

    joergl New Member

    Hallo Dominik,

    leider habe ich schon wieder schlechte Nachrichten. Mit der Testversion scheint mein Lader das Umschalten zwischen z.B. Entladen und Laden nicht mehr mitzubekommen. Und bei einem im Laufe der Woche durchgeführten Ladevorgang hat Logview plötzlich die Aufzeichnung beendet, obwohl ich keinen entsprechenden Eingriff vorgenommen hatte (s. Grafik, Abriß der Aufzeichnung bereits nach rund 10 min - Logfile gegen 07:30 Uhr). Dass ich gleichzeitig noch an einem anderen Ladeausgang einen Akku angeschlossen hatte, hat Logview dann schon gar nicht mehr interessiert - hier erfolgte keine Aufzeichnung.

    Derartige Schwierigkeiten (außer dem plötzlichen Abriß der Aufzeichnung) hatte ich mit der Vorgängerversion nicht.

    Grüsse
    Jörg

    Attached Files:

  13. Dominik

    Dominik Administrator Staff Member

    Moin !

    Sehr merkwürdig das ganze !

    Werde dann mal dein Szenario testen.
  14. Dominik

    Dominik Administrator Staff Member

    Ok der Lader rennt mal wieder im Test.
    Mal sehen ob ich das nachstellen kann.

    Nur gut das ich hier 2 PCs habe :D
  15. joergl

    joergl New Member

    Dominik,
    prima, das ist Einsatz! Wenn ich noch irgendwie weiterhelfen kann, lass es mich bitte wissen. Bin aufgrund der Probleme zunächst noch einmal auf die Programmversion von Anfang Januar zurück gegangen, aber ganz ohne Probleme läuft er damit ja leider auch nicht. Deshalb: Wenn ich noch etwas ganz Spezielles austesten soll, sag' eben kurz Bescheid.

    Grüsse
    Jörg
  16. Dominik

    Dominik Administrator Staff Member

    Moin !

    Ich habe es mir fast gedacht ... Mein MiniRon hier rennt einfach so durch ohne Stress ... :mad: Aber das hatten wir ja eh schon mal bei den Fehlerzeichen.
    Hmm, könntest du mir mal genau beschreiben was du am Lader eingestellt hast, an welchem Ausgang der Akku war, welche Akku dran warm ..

    Halt das ich möglichst haargenau dein Szenario nachstellen kann. Wenn das auch nix bringt dann muss ich mich wirklich mal mit einem von euch treffen zwecks Analyse.
  17. joergl

    joergl New Member

    Hallo Dominik,
    genau so machen wir's: Wir versuchen es jetzt erst mal mit einer genauen Beschreibung, und falls nicht, komm ich Dich eben mal besuchen ...

    Also, fangen wir an:
    Ich habe heute extra zu diesem Zweck noch einmal die Testversion installiert. Gestartet habe ich das Programm am 14.02.07 gegen 20:03 Uhr. Zu diesem Zeitpunkt angeschlossen: ein 10-zelliger NiMH-Akkupack mit einer Nennkapazität von 2.500 mAh, der aber zuletzt nur noch etwa 1.700 mAh Kapazität gebracht hat und den ich derzeit "in Pflege" habe. Am MEGARON läuft zu diesem Zweck das Programm "TEST". Start der Aufzeichnung gegen 20:05 Uhr.

    Nach wenigen Augenblicken bereits ein Fehler, den ich so ebenfalls noch nicht kannte: Im Debug-Log sammeln sich zwar munter Datensätze, in der Anzeige (Ansicht Bigletters) wie in der Grafik (Ansicht Grafik) jedoch gibt es keine Spannung, lediglich die eingeladene Kapazität wird in mAh ausgewiesen. Fehlt die Spannung auch im Datensatz? Ich glaube nicht, aber schau selbst mal im Debug-Log nach.

    Ich starte daher den Rechner vollständig neu. Das MEGARON setzt die o.g. Ladung fort ... gegen 20:12 Uhr bin ich mit der LogView-Testversion auch wieder dabei. Start der Aufzeichnung. Für einige Minuten läuft die Aufzeichnung auch ordentlich mit - und dann passiert erneut das, was mich schon seit Monaten "auf die Palme" bringt: Die Aufzeichnung reißt nach etwa 10 min. ohne ersichtlichen Grund bei einer eingeladenen Kapazität von 48 mAh lt. Anzeige ab. Bis ich dies bemerke, zeigt das MEGARON jedoch bereits eine eingeladene Kapazität von 108 mAh.

    Für beide Vorgänge habe ich sowohl Logview-Datei, Foto der Anzeige wie auch das Debug-Log angehängt. Ich hoffe, diese ausführliche Beschreibung hilft Dir bei der Fehlersuche. Ich werde jetzt erst mal wieder auf die alte Version von Januar "zurückrüsten".
    :mad:

    Gruss
    Jörg
  18. Dominik

    Dominik Administrator Staff Member

    Moin Jörg

    Herrje, ich kriege nachwievor ein schlechtes Gewissen wenn ich deine Simlies betrachte ... :p

    Ich kann im Logging nix entdecken. Ich habe keinen Schimmer warum das einfach hängt.

    Folgender Vorschlag. Wir sollten uns mal treffen. Was hälst du von kommender Woche? Dann können wir hier mal ne kleine Prog & Debug Session machen. Weil irgendwie kommen wir so scheinbar nicht weiter. Ich kann dein Problem hier mit dem MiniRon nicht nachvollziehen. Ich vermute mal dass das Teil einen anderen Prozessor hat, oder doch eine irgendwie anders geartete Software hat.
    Ich kann mir jedenfalls diese ganzen Aussetzer nicht wirklich erklären.

    Was du vielleicht noch machen kannst ... Erstell doch mal ein Log mit dem Serial Port Terminal.
    1) Serial Port Terminal starten (das findest du bei der LogView Installation unter LogView -> Tools
    2) Den Port einstellen (9600 Baud, 8 Datenbits, No Parity, 1 Stopbit, keine Flowcontrol, DTR % RTS egal)
    3) Unter Datei -> Port Timeouts bitte prüfen ob Clustersize = 150 ist. Ggf einfach auf 150 setzen.
    4) Unter Ansicht nachsehen ob ASCII eingestellt ist.
    5) Port öffnen (das macht man mit dem Portsymbol und den grünen 010 oben im Menü)
    6) Dann mal ein problematisches Szenario loggen.

    In dem Log sollte man alles sehen was da auf der Leitung passiert. Mag ja sein das da noch ein paar ominöse Steuerzeichen gesendet werden.

    Aber wie gesagt ich bin mal für eion Treffen. Diese Woche is schlecht denn ab Freitag is hier Karneval und da muss ich ein bisserl :beer: :D
  19. c_s

    c_s New Member

    Test ...

    Hallo Zusammen,
    ich hoffe ich kann auch noch was dazu beitragen.:rolleyes:
    Also habe ich den Test auch gerade angeworfen. Alte Akkus scheinen wir wohl alle zu haben.
    Bei mir nur ein 6 Zeller, im NiMH Modus, Test, Automatische Stromeinstellung. Bis jetzt läuft der Test ohne Probleme.
    Legt auch nach dem Lademodus (auto Test (L) NiMH) ca. 3,5 Minuten,
    auch den Entladevorgang als neues Diagramm an (auto Test (E) NiMH) und läuft dort derzeit auch bereits > 25 Minuten.:)

    Was denkt Ihr Beiden ?

    @ Jörg
    Aus deinem Logfile sehe ich, dass Du ggf. mit einem USB RS232 Adapter auf Com6 arbeitest.
    Hast Du mal dran gedacht dass der USB Adapter das Problem sein könnte ? Speziell das vollkommen spontane Aussetzen der Kommunikation schürt bei mir den Verdacht. Warum ?
    Es gibt definitiv unterschiedliche Strategien bei der Implementierung dieser USB /RS232 Umsetzer die sich im schlimmsten Fall in einem Timeout in der Übertragung - und dann Datenverlust - resultieren. Speziell wenn Paketweise Daten übertragen werden und - wie hier - ein paar Sekunden Pause dazwischen sind.

    Hast Du das mit der orig. SW gegengecheckt ? Oder mit einem anderen ComPort?

    Würde mich sehr interessieren.

    mfg
    CS
  20. Dominik

    Dominik Administrator Staff Member

    Moin !

    Nö, das geht nicht mehr :D Was eine Frage :eek:

    Ist dem wirklich so? Weil das könnte in der Tat eine Erklärung sein. Denn diese Adapter tun in 99%, nur eben nicht immer. Und es ist meiner Meinung nach ganz wichtig welcher Chip verwendet wird. Und man sollte immer (!) den aktuellsten Treiber ausm Netz ziehen den man bekommen kann. Ich würde mich niemals drauf verlassen das die beigelegte CD aktuell ist !!

    @Joergl, klär uns doch mal auf was du da so verwendest.

Share This Page