Think City Enerdel Lithium Ion tråden

[BauDemo]

I am not 100% sure I understand your question - maybe you can post a short video?
If I understand correctly what you are seeing is the result of the battery changing the "max regen" and "max drive" current parameters.
These parameters are then used to map the dials on the dashboard.
Usually these parameters are staying relatively constant... but if the battery pack is at maximum voltage it would not allow regen and the way for it to signal that to the drive unit is to set the "max regen" to a very small value.
So suddenly the scale of the dashboard is changing and if previously 15A current was barely noticable it is now maybe 4 times the movement.
You can see some of these parameters if you build and run nikometer:

https://www.youtube.com/watch?v=N8921noBR4w
Nikolay

[worry]

Thank you Nikolay,
You describe perfectly what I see. The regen I felt was lower than what I feel when the battery is more drained, despite the higher than normal movement.

The nicometer seem really interesting. Do you sell this thing ready for installation? I don't have much spare time these days. And computer stuff is a challenge for me. 

[BauDemo]

I don't sell it - it is fully open source...
I can probably build one for you but it would be expensive... PM me and I will try to give you a quote depending on how you want to connect it to the car

[worry]

Ok, thanks. 
I see your link, "evmonitor.info" . I will check that out later. Right now I have too much other stuff going.

[worry]

I går kom jeg på en metode til å åpne toppen på batteriet uten å miste disse små plastnaglene nedi kassa. Se bildet under.

Det er altså slik at på et uåpnet batteri så er det øverste grå plastlokket naglet til lokket under. Det er på lokket under at RLEC'ene sitter. For å få løs lokket må naglene ut, og de frigjøres ved å ta ut låsepinnen i midten. Den kan egentlig kun trykks ned siden det ikke er hode på pinnen. Da forsvinner pinnen nedi kassa og noen finner man ikke igjen før alt er demontert.

Jeg brukte en skarp tollekniv og skar inn i siden på hodet. Ved å vippe kniven kom pinnen gradvis opp og naglen er løs. Fint å slippe at løse deler ligger nedi kassene. Det er fem nagler som fester de to lokkene sammen. De setter jeg ikke inn igjen etterpå. Lokket kommer jo ingen vei.

[Marsto]

I går kom jeg på en metode til å åpne toppen på batteriet uten å miste disse små plastnaglene nedi kassa. Se bildet under.

Det er altså slik at på et uåpnet batteri så er det øverste grå plastlokket naglet til lokket under. Det er på lokket under at RLEC'ene sitter. For å få løs lokket må naglene ut, og de frigjøres ved å ta ut låsepinnen i midten. Den kan egentlig kun trykks ned siden det ikke er hode på pinnen. Da forsvinner pinnen nedi kassa og noen finner man ikke igjen før alt er demontert.

Jeg brukte en skarp tollekniv og skar inn i siden på hodet. Ved å vippe kniven kom pinnen gradvis opp og naglen er løs. Fint å slippe at løse deler ligger nedi kassene. Det er fem nagler som fester de to lokkene sammen. De setter jeg ikke inn igjen etterpå. Lokket kommer jo ingen vei.

Gode tips å ta med seg når en batteri jobb skal gjøres. Jeg må nok igang med det etter sommeren engang å da er det fint å vite at det nå blir mulig å boltre seg i RLEC kort importert fra USA. 

[Marsto]

Som jeg har beskrevet i en annen tråd har jeg ett rlec kort som har mistet kontakt i Commtool. Alle andre viser gode verdier. Jeg lurer på om noen har feilsøkt et rlec kort med å kun bytte plass med et nabokort som virker? Som eksempel er det rlec med id#11 som ikke virker hos meg. Kan jeg da bare bytte plass med nabokortet eller må det omprogrammeres til den plassen det byttes med?

[worry]

Dette er vel litt mye datateknisk ift. mitt kunnskapsnivå. Men litt skjønner jeg. 

Kortene står likt plassert nettverksmessig. Så det spiller ingen rolle hvor på batteriet (dvs hvor på datakabelen) det plugges inn. Det som er viktig er at det ikke er to kort med samme adresse.

Om det går an å programmere andre adresser enn 00 til 15 vet jeg ikke. Men det er jo heller ikke noe poeng å gjøre det.

På de batteriene jeg har åpnet, så har jeg alltid kontrollert adresser på alle kort og merket de med tusj. Det kan jo ikke garanteres at forrige person har plassert kortene på rett sted. Det skal sies at jeg ikke har funnet avvik fra slik Enerdel har nummerert batteriet. Myles har også vært veldig nøye med å merke med adresse, både på kortet og på posen det ligger i.

Var det et brukbart svar? 

[Marsto]

Helt topp... Jeg tror vi kan forsøke å etablere en grei steg for steg prosedyre for å si mer om det er rlec eller battericeller som er årsaken til at Commtool rapporterer feil.

Her er en kladd til en eventuell prosedyre:

1. Koble til Commtool 3.08 som er siste versjon.
2. Velg .MSF fil, Slave_Comm.MSF
3. Hvis noen parameter viser avvik som rlec#12 i vedlagte fil er det enten rlec eller celler som er problemet. Avviket behøver ikke være akkurat likt som vedlagte fil. Det viktige er å se om noen verdier er forskjellig fra 7FFC.
4. Bytt plass internt med et rlec som viser korrekte verdier. 
5. Hvis dette nå viser korrekt verdi er det rlec som er problemet.
6. Hvis det viser samme som før bytte, er det battericeller som er problemet.

Hvis flere rlec kort viser avvik samtidig bytt med et rlec kort av gangen slik at man ikke mister kontroll på hvem har byttet med hvem. Loggbok er viktig å føre hvis flere rlec rapporterer feil samtidig i denne prosedyren.

Forslag til forandring eller nye momenter til prosedyren er veldig viktig. Bare del tanker her om hvordan vi best kan avgjøre om rlec eller celler er årsaken til Commtool feilmeldingene. 


 

[worry]

Bra forslag. Kjekt med prosedyrer, særlig hvis det følger med forklaring på hvorfor ditt og datt.

Den avlesingen (Slave_Comm) har jeg aldri skjønt noe av. Hva betyr 7FFC?

Så er jeg litt usikker på pkt 5 og 6. Er det ikke motsatt?
Eller hva mener du med "hvis dette nå viser". Hva er "dette".

ID#12-kortet rapporterer som ID#12 uansett hvor det står. Så hvis ID#12-kortet er ødelagt, så vil det være ødelagt uansett hvor det står.

[Marsto]

Jeg mener å ha lest et sted at det er signalene i tilkoblingskabelen til rlec kortet som vil vise 7FFC hvis alt er iorden med rlec kort og batteriblokka. Slave_comm viser raskt hvor problemet ligger. Ser nå at det kanskje ikke har noen hensikt å lage en prosedyre. Det er vel selvforklarende at man bytter plass med et rlec som viser riktige verdier for å avgjøre om rlec eller celler er problemet i aktuell blokk. Det er jo ingen som bare bytter rlec uten at man vet med sikkerhet at kortet er defekt.
   
 

[bcx238h]

7FFC beskriver de fire BIT grupper i et 16Bit dataord.

Her et bilde som viser hvordan tallet ser ut i de andre tallsystemer man kjenner til:



Der ser ut som at det er 13 1-er.
Det kan jo faktisk bety at det er de tolv celler pluss selve RLEC-kortet som kan gi beksjed om at "alt" er i orden - bare en teori.

Jeg hadde nok programmert noe sånt selv, for å få et kjapt "svar" fra alle komponenter.

[Marsto]

  Der satt forklaringen som et skudd. Så bra å ha elektro lærere med på laget her. Jeg var vel egentlig ikke så langt unna heller, men forklaringen min hadde nok ikke passert til eksamen
Tenker den teorien stemmer på en prikk. Tror nok man kan stole på at hvis noe er feil med kort eller celler vil det dukke opp en annen kombinasjon enn 7FFC.     

[worry]

Takk! Lærer litt hele tiden. Og glemmer mer.... 

Jeg trodde kanskje det var en forklaring i et eller annet dokument vi har.

[bcx238h]

Der satt forklaringen som et skudd. Så bra å ha elektro lærere med på laget her. Jeg var vel egentlig ikke så langt unna heller, men forklaringen min hadde nok ikke passert til eksamen
Tenker den teorien stemmer på en prikk. Tror nok man kan stole på at hvis noe er feil med kort eller celler vil det dukke opp en annen kombinasjon enn 7FFC.     

Når det gjelder "Slv_Rcv_Status" = Slave Recieve Status er det også en logisk forklaring når man ser hva F7FF betyr:



Sammenligner man det binære mønsteret med de 16 RLEC-kort status meldinger, skjønner man at "Slave 12" ikke svarer i dette tilfellet, dvs. det er signal 0 - "bryteren" forblir av.

Binære tall begynner alltid fra høyre til venstre, altså "Slave 1" er helt til høyre og "Slave 16" helt til venstre.

Når det gjelder "All_Slv_Rcv" meldingen er den også sant, siden den står på "0". Masterkortet har "ikke" fått svar fra alle RLEC-kortene.

"Slv_Rcv_Comm_Flt" er det motsatte mønsteret av "Slv_Rcv_Status".
Her i dette tilfellet er hex-verdien "08 00" - de første fire nuller er uinteressant.
Det binæret mønsteret er derfor:



Så det er "Slave 12" som ikke svarer - "Slave Recieve Communication Fault"
Det samme gjelder for den "lagrete feilen" - "Slave Recieve Historic Fault"

   Det er mye programmeringsarbeid som de har puttet inn i sånn et batteriforvaltningssystem. Kjenner godt til programmeringsoppdrag, der 90% av arbeidet var programmering av "worst case scenario" - alt som kan gå galt måtte kunne synliggjøres. Men de fleste anlegg fungerer i utallige år uten en eneste feilmelding. Likevel ... jobben må gjøres!

Har vært med på tunnelprosjekter i Norge. Man vil nesten ikke tro, hvor svære PLS-programmer som overvåker sånn en tunnel. Testing av tunneler sammen med Statens Vegvesen tar flere dager for å gå gjennom alle tenkelige situasjoner.

Det hadde vært interessant å få vite, hvordan testing foregikk og hvor lenge de holdt på, før det i det hele tatt ble godkjent å få bygget en enste av Think-bilene våre.