Discussion in 'Opencharge' started by Dominik, Oct 9, 2006.

  1. Dominik

    Dominik Administrator Staff Member

    Moin Thomas!

    Wo jetzt hier langsam ein paar mehr Fragen / Antworten zusammen kommen stellt sich mir natürlich die Frage ...
    Wie sollen wir den Lader in LV einbinden? Vorrausgesetzt du willst das :p

    Ich denke es ist keine gute und saubere Lösung, wenn man dort ein bestehendes Datenformat verwendet. Das funktioniert zwar, verwirrt aber manchen User.

    Hast du beim Datenformat schon eine Vorstellung? Wenn ich mich recht entsinne nutzt du ja irgendein vorhandenes Format. Wir könnten da aber auch was angepasstes und vielleicht auch erweitertes Format einbringen wie es z.B. beim Akkumatik gemacht wurde.
    Hast du auch mal daran gedacht, dass man das System vom PC aus steuern könnte? Ist sicherlich auch eine nicht uninteressante Sache.

    Vielleicht kannst du dich ja mal äussern wie im Hinblick auf die serielle Kommunikation deine Ideen sind.

    Greetz & keep up the really good work :grin:
  2. Space

    Space New Member

    Nabend Dominik,

    es ist richtig, im Moment verwende ich das Pulsar Format, mit einem angepassten INI File und ausgetauschten Pulsar 2.jpg.

    Von den Logmöglichkeiten halte ich das schon (fast) für ausreichend. Statt der Temperatur logge ich im Moment den Wert des Ri des Akkus. Schön währen aber schon noch 2 Datenkanäle mehr, für die Innen/Akku-Temperatur.
    Kannst du das was zaubern? :love:

    Die Idee das Ladegerät fernzu"programmieren" hat was. Noch mehr Charme hätte es, die 14 Speicherplätze (es sind nur noch 14 :{ Flashmangel) komfortabel zu programmieren. Besonders die Texteingabe ist über den Drehknopf etwas zeitraubend.

    Für einen Ladevorgang, bzw. für eine Flashspeicherplatz sind folgende Variablen zu füllen:


    'Sicherheitsvariable ----100--->
    Dim Maxah As Word At 100 'Sicherheitswerte maximal einzuladende Kapazitaet volle Ah
    Dim Maxmah As Word At 102 'Sicherheitswerte maximal einzuladende Kapazitaet mAh werte
    Dim Temperaturakku_max As Integer At 104 ' Maximale Akkutemperatur (Uservorgabe)
    Dim Maxladezeit_minute As Byte At 106
    Dim Maxladezeit_stunde As Byte At 107
    Dim Deltapeaktime As Byte At 108 'Im Moment für Deltapeakrauschunterdrückung verwendet
    ''<-----------108

    'Ladeparameter -------109----->
    Dim Chargecurrent As Word At 109 'Ladestrom Uservorgabe bzw. korrigierte Uservorgabe
    Dim Chargemode As Byte At 111 'nixxMneue de/Ch dech. char.
    Dim Chargecutemode As Byte At 112 'nixx Abschaltmethode
    'nixx
    Dim Currentmode As Byte At 113 ' konstanstrom, aut, max rflx
    'Ni +Li
    Dim Deltapeak As Word At 114 'Deltapeakwert, gesetzt über die im Setup gesetzten Konstanten nicd_low, middel, high nimh_low, ec.. Bei Lpoladung steht hier die Zellenspannung drinne
    'lipo
    Dim Lipoanzahl As Byte At 116
    Dim Werthauptmenue As Byte At 117 'Mussnicht
    Dim Akkutyp As String * 4 At 118
    '<-----------122

    'Entladeparameter ------123---->
    Dim Minmv As Word At 123 'Entladeabschaltspannung Nachkommawert
    Dim Minv As Word At 125 ' Entladeabschaltspannung Oberer Wert
    Dim Count As Byte At 127 'Counter für EntladeLadevorgaenge
    Dim Decurrent As Word At 128 'Entladestrom
    '<---------129

    'Flags------130------>
    Dim Nimhflag As Bit
    Dim Lipoflag As Bit
    Dim Entladeflag As Bit 'Flag für Entladung im Loop
    Dim Lipo36flag As Bit 'Flag fürLiMG mit 4,1V Ladeeendspannung
    Dim Lipoabsenkung As Bit
    Dim Lipo30flag As Bit 'Flag für LiFePo
    '<-------------130


    Das ganze könnte man als Block übertragen oder für jede Variable einen Kennbuchstaben oder Kennwort vergeben.

    Z.B.(dez.):
    G 0 2
    Kennbuchstabe byte1 byte2
    G=Kennung für die Variable MaxAH
    0 2 = wert 2 (dez)

    Dazu müssen natürlich auch Steuerbefehle ( z.B. Ladestart oder Speicher unter Speicherplatz 2) in dem Protokoll definiert werden.

    Wie sind deine Vorstellungen?

    Thomas
  3. Dominik

    Dominik Administrator Staff Member

    Moin Thomas!

    Das ist kein Massstab für LogView :D

    Nuja, dafür ist LogView ja gedacht ... Jeder so wie er mag. Klar können wir dir da ein angepasstes Format "zaubern" bzw. dieses in LV einbinden. 18 Kurven sind im Moment machbar in LV. Das ist aber ausbaufähig :p

    Ich denke das sollte kein grosses Problem darstellen. Habe da auch eine Idee wie man das umsetzen könnte. Mit den neuen ToolPanels die in 1.15 kommen werden kann man das recht elegant erledigen.

    Stellt kein grosses Problem dar.

    Nuja ... Ich hätte da eine Frage und 2 Ideen ...

    1) Man sollte in Schritt 1 erstmal ein angepasstes Datenformat für den Lader kreieren. Dazu villeicht folgende folgende Überlegung:
    Welche Parameter/Variablen bietet der Lader intern, die auch für den User interessant sein könnten? einfach mal alles zusammenschreiben. Wegstreichen kann man immer noch.
    Aus diesen Daten dann halt das Datenformat generieren. Was aus LV Sicht immer sehr nützlich ist, sind die Stati des Laders. Diese können ruhig sehr ausführlich ausgegeben werden. Weil daran erkennen wir in den meisten Fällen die unterschiedlichen Datensätze.

    2) Wenn das Format soweit steht ... Hättest du dann mal einen Lader für ein paar Tage über? Das würde die Einbindung drastisch beschleunigen und vor allem vereinfachen.
    Wo wohnst du? Vielleicht kann man sich ja auch mal treffen zu dem Thema?

    3) Wenn das normale Datenformat soweit steht, dann könnte man mit der Fernsteuerung beginnen. Wie das letztlich aufgebaut ist, ist aus LV Sicht egal. Für mich sind das alles nur ein paar Zahlen und Strings :p
    Es hat sich nur gezeigt, dass es nicht verkehrt ist, wenn diese Daten kurz gehalten werden. Denn bei langen Befehlssequenzen kommt so manches Gerät ab und an aus dem Tritt. Hatte da erst so einen Fall mit dem Feigao Power Analyzer.

    Soweit meine Infos / Ideen. :beer:
  4. Space

    Space New Member

    Huhu Dominik,

    ... ist durchaus nicht schlecht. Meine ehemaligen Lehrer haben es mir ausreichend häufig in das Zeugnis geschrieben [schild=10 fontcolor=000000 shadowcolor=C0C0C0 shieldshadow=1]ausreichend[/schild]

    Dein vorgeschlagenes Vorgehen gehe ich mit (<- Achtung Wortspiel):

    Zu 1)
    Ich entferne mich in der Software gerade von den Statiflags. Ist mir zu unflexibel, bei der Anpassung von neuen Faeters.

    Neben den bereits oben erwähnten Human gesetzten Variablen, sind für einige vielleicht folgende noch von Interesse:

    Dim Wandlerspannung As Word 'Sapnnung des Stepupwandlers (mV)
    Dim Deltapeakcount As Byte 'Counter für Deltapeakereignisse(max3)
    Dim Entladeflag as BIT ' 1=Entladung
    Dim Spannungabschalt As Word ' Abschaltspannung für deltaPeak (errechnet)
    Dim Spannunghigh As Word 'Höchster Spannugswert während der Ladung (Deltapeak)
    Dim Sektic As Long 'vergangene Sekunden seit Ladebeginn
    pwm1a Word und PWM1b 'Stromvorgabe und Stepdownwert


    Die Klassiker:
    Dim Kapazitaet As Long ' = Interner Kapazitätszähler mAh
    Dim Spannung As Word 'in mV
    Dim Strom As Word 'in mA
    Dim Temperaturakku As Integer 'Temperatur des externen Fühler
    Dim Temperaturintern As Integer 'Temperatur des interne Fühler
    Dim Innenwiderstand As Word 'errechneter Ri des Akkus mOhm


    Gibt es noch nicht, könnte aber leicht errechnet werden:
    Gradientenwert ' Wert der FIR Kurve ( bei < 0 wird die Ladung beendet)

    Für wichtig halte ich es im Zeitalter neuer Akkutechnologien, den Akkutyp nicht als hardkodiertes Zeichen zu übermittel, sondern universeller als String ( Dim Akkutyp As String * 4 )


    Zu 2) Überlassen lässt sich machen, aber treffen ist schlecht, wir wohnen etwa 400km auseinander. Bist du sonst beim RC-N Treffen am Hahnmoos mal dabei??

    Zu 3)
    Jep, ist doof zu händeln in den kleinen Atmels. Kleine Pakete werden besser verdaut. Mein grober Vorschlag steht bereits oben.

    So, ich muss zum Squash....

    Thomas
  5. Dominik

    Dominik Administrator Staff Member

    Moin !

    Was zum Henker sind Faeters :D :D :dontknow:

    zu deinem 1) ...
    Die Werte die du liefern willst sind schon mal ok. Hinzufügen könnte man noch Leistung und Energie. Das kann ich aber zur Not auch mit LV berechnen lassen. Machen wir bei vielen Ladern so.

    Was mir aber def. fehlt ist eine richtige Statusmeldung. Also 1 oder 2 Byte wo drinsteckt was der Lader gerade tut. Also z.B.
    - Laden
    - Entladen
    - Laden bzw. Entladen im Zyklenmodus
    - Kein Akku angeklemmt
    - letzter Vorgang beendet
    - Akku voll
    - Akku leer
    - Pause

    So in etwa. Also etwas anhand dessen ich gut erkennen kann, wann in LV neue Datensätze anfangen - z:b. ein Wechsel von Ladan nach Entladen ...
    Kannst du sowas mit einbauen?

    Ja habe ich auch schon festgestellt :(

    Wann isn das ?
  6. Space

    Space New Member

    Jep Moin,


    Beherrschung der 102 Tasten ausreichend :teach:

    Faeters = features= (eingedeutscht) Featers = Fähigkeiten, Merkmale


    Zum Thema Statusmeldungen:

    Der Status steckt in 2 Variablen, dem Entladeflag(Bit) und dem Count (Byte). Das Entladeflag ist gesetzt, wenn entladen wird. Der Count wird von max 9 auf 0 pro Lade/Entlade-Vorgang heruntergezählt.

    - Laden => entladeflag=0
    - Entladen => entladeflag=1
    - Laden bzw. Entladen im Zyklenmodus => count > 0
    - Kein Akku angeklemmt => keine Datensätze
    - letzter Vorgang beendet => toggle des Entladeflags beim Starten eines neuen Vorgangs
    - Akku voll => siehe "Vorgang beendet"
    - Akku leer => Daten werden gesendet
    - Pause => Programm läuft in der Schleife und sendet keine Datensätze


    Wenn es erforderlich ist, kann nach dem Beenden oder Starten eines Vorganges, ein zu definierendes Statusbyte gesendet werden.

    Hast du schon mal ein Blick in die Bascomsourcen, speziell die Subroutine Datenlog, angeschaut?

    Hahnmoss kommt wohl etas spät, etwa Juni nächsten Jahres.

    Thomas
  7. Dominik

    Dominik Administrator Staff Member

    Moin !

    Hmm .. Manmerkt schon beim Lesen des Textes dass das irgendwie etwas "holperig" ist. Klar würde das mitunter ausreichen wenn man die Stati so ermittelt, aber sche is des ned ;) Versteh mich nicht falsch ...

    Wenn du / wir doch eh am Datenformat (also das was der Lader sendet) rumdoktern, dann könnte man doch 1-2 Byte senden, wo die Stati sauber aufgedröselt sind, oder nicht?

    Ich poste hier mal ein Stück des Akkumatik Formats. Nur damit du mal ne Vorstellung bekommst wie man das machen könnte:
    Man kann leicht erkennen das man hier schön von LV Sicht aus alle Stati erfassen kann ... ;)
    Wäre so etwas in der Art bei dem neuen Datenformat auch machbar?

    Ach ja und dann noch die Sache mit der Pause ...
    Willst du da auch die gesendeten Daten pausieren? Muss eigentlich nicht sein. Lass ihn doch einfach weitersenden. Dann kann man in der Echtzeitanzeige von LV schön die Daten weiter verfolgen.
  8. Space

    Space New Member

    Hy Dominik,

    wir haben beide unterschiedliche Sichtweisen auf das Logging.
    Die Resourcen im Atmega32, speziell der Flashprogrammspeicher, sind endlich. Aus diesem Grunde versuche ich die Programmgrösse im Rahmen zu halten.
    Das Datenlogging hat bei mir eine niedrigere Prio, als z.B. noch zukünftig geplante Optionen wie z.B. eine Kommunikation über irgendeinen Datenbus (z.B. I2C ) mit einem externen/internen Balancer eines Fremdherstellers oder einer Eigentwicklung.
    Hierfür Resourcen vorzuhalten ist mir wichtiger, als das "perfekte Logging" zu implementieren.

    Im Moment wird das Pulsar logging emuliert. Auch alle für mich wichtigen Stati wie Laden oder Entladen und der Akkutyp werden von LV erkannt und angezeigt.
    Das Starten des Loggings kann auch erst bei laufenden Ladevorgang gestartet werden, LV zeichnet dann eben erst ab diesem Zeitpunkt die Kurven auf.
    Aus meiner Sicht ist das schon ausreichend ( <- da war es wieder ;) ).
    Um gut zu erreichen würde ich gerne 2 Datenkanäle mehr haben (Temp intern/extern) und das Datenformat würde ich universeller gestalten wollen.

    Beispiele für universelle Ansätze:

    Senden eines universellen Strings für den Akkutyp statt dem hartverdrahteten Akkumatik Format: 0=NICD, 1=NIMH, 2=BLEI, 3=BGEL, 4=LIIO, 5=LIPO, 6=RAM . So sind keine Anpassungen in LV notwendig, wenn eben der LiFePo im Lader implementiert wurde.
    Das selbe ist für den Stati möglich, String statt Staticode. Wechsel des StatiStrings = Neuer Datensatz. Die Daten welche in einer Pause zwischen 2 Stati gesendet werden, halte ich nicht für interessant.

    Auch könnte man beim/vor dem Logging LV mitteilen, wieviel Datenkanäle von LV ausgewertet werden sollen. Das heisst ein einfaches Thermometer benutzt nur einen Datenkanal, Opencharge als Beispiel 6 und Akkumatik 10.

    Zusätzlich könnte man darüber nachdenken, zu jedem übertragenen Datenkanal auch die Angaben welche in den INI Files definiert sind, zu LV zu übertragen (Einheit, Symbol, ec.) oder eben die Ladegerätverwaltung um ein Geräte wie Openformat1, Openformat2, Openformat3 ... zu erweitern. Für jedes OpenformatX kann dann ein eigenes INI File vom User angelegt werden.

    So sollte ein universelles Logformat möglich sein, ohne Abhängigkeiten zu einer LV Version.


    Zu den Akkumatkdaten habe ich mal die dazugehörenden Variablöen in OC geschrieben:

    A Ladephase (0=stop, 1...n, siehe Bedienungsanleitung) = interner Programmablauf, das Ergebnis ist in der Strom/Spannungskurve zu sehen (Phase 1-3)
    B aktuelle Zyklus-Nr beim Formieren (1...9) = count
    C aktive Akkuspeicher-Nr (1...9) =EEpromadresse (0-13)
    D Akkutyp (0=NICD, 1=NIMH, 2=BLEI, 3=BGEL, 4=LIIO, 5=LIPO, 6=RAM) = String AKKUTYP
    E Programm (0=LADE, 1=ENTL, 2=ENTL/LADE, 3=KAPTEST, 4=FORMIER 5=SENDER) = Chargemode (0=Laden, 1= Entl, 2= Entl/Laden, 3 = Form (gepl.))
    F Ladeart (0=Normal, 1=Puls, 2=Reflex) = nur 0
    G Stromwahl (0=Auto, 1=Limit, 2=Fest, 3=Externer Lastwiderstand) = currentmode ( 0= konst, 1=auto, 2=Limit)
    H Stopmethode (0=Lademenge, 1=Gradient, 2=Delta-peak-1, 3=Delta-peak-2, 4=Delta-peak-3) = deltapeak (1=Gradient, >1 = DeltaU / mV Zelle)
    I Entladestromreduzierung (0=NEIN, 1=JA) NA, geplant
    J Erhaltungsladen (0=NEIN, 1=JA) = halte ich generell nicht für sinnvoll, da Großkristallbildung forciert wird



    Thomas

Share This Page