Oma proggis: graafista live-dataa TestO:lla. *Päivitys 26.06.2017*

[pheno]

Esimerkki Testo:n loggauksesta ja tiedosto avattuna Megalogviewerissä. Moottorina E60 530D, DDE 6.0. ECU: D60M57A0

1. ahtopaine (sininen), ja vääntö (keltainen).

2. lambda (kelt)
pakokaasun lämmöt,ennen kattia (valk.)
ilmamassa/cyl (pun)
ilmamassa (vihr)

3. pakokaasun paine ennen DPF:ää (kelt.)
RPM (vihr.)
TPS (pun.)

4. Rail paine todellinen (pun)
Rail paine tavoite (vihr)

[pheno]

En ole vielä tähän puoleen ehtinyt pahemmin tutustua mutta saa sieltä pyydettyä dpf:n yli vallitsevan paine-eron.

aivan, mietin tässä softan muokkaajia. Tuo pakopaine olisi aika hyvä lisätieto.

[böntti]

onko näissä uudemmissa dieseleissä pakopaineanturia? Jossain dpf:n tienoilla lienee joku jotta osaa dpf:n polton tehdä?

En ole vielä tähän puoleen ehtinyt pahemmin tutustua mutta saa sieltä pyydettyä dpf:n yli vallitsevan paine-eron.

[pheno]

onko näissä uudemmissa dieseleissä pakopaineanturia? Jossain dpf:n tienoilla lienee joku jotta osaa dpf:n polton tehdä?

[JP-76]

Järjestystä pystyy muuttamaan, en osannut arvata että tällekin olisi käyttöä

järjestys menee aakkosjärjestyksessä definitions.txt:ssä määritettyjen gaugejen "id":n perusteella.

Jos vaihtaa siis:
[BPSCD_POUTVAL] --> [1BPSCD_POUTVAL] niin sen pitäisi tulla ensimmäiseksi listalla.

Vastaavat gauge-konffit pitää muuttaa myös. AJatus tässä onkin ollut että voi haluamiaan gauge- näkymiä tehdä itse. Lisäämällä määrittelyjä definitions.txt:hen ja tekemällä uusia gauge-näkymiä..

Järjestyksen muuttaminen onnistui, kiitos

[böntti]

Tuohon viimeiseen kohtaan sain tehtyä pikaisen korjauksen. Eli nyt pitäisi esim. kaksi ihkan jobiakin toimia keskenään. Jos tämä toimisi paremmin... Testiversio täältä: http://phenoboy.kapsi.fi/testo/testo-27-Jan-2014.zip

Tästä vähän kun olo paranee, niin luon nuo mittaristot D72:lle myös.

Se tuli samalla huomattua, että siihen Testo ei taida taipua, että kahdesta eri ecusta olisi samanniminen job päällä, olen sen näköjään joskus vuonna miekka ja kivi suuressa viisaudessani niin ajatellut Paitsi jos luo omia customjobeja. Alussa ajattelin, että tuskin kukaan käyttää kahta ecua samaan aikaan. Sun ecussa siitä onkin hyötyä, kun sieltä saa niin paljon dataa ulos eri ecuista.

Nopeaa toimintaa, kiitos siitä. Nyt toimi status_lesen useamman argumentin kans yhtäaikaa sekä saman ecun sisällä että useamman ecun kanssa. Customjobin kautta tuo pitää tehdä joka tapauksessa kun status_lesen ei toimi ilman argumenttia.

Tuosta mun moottorinohjauksen moduliista ei muuten saa status_lesenillä mitään dataa ulos, istasta kattelin lokeja ja se näytti hakevan ainakin laturin kuormituksen status_block_lesen-jobin avulla ks. mun aikaisempi posti missä customjobit. Tietty sieltä löytyy ne perusjobit millä saa jotain ulos. Tutkin asiaa lisää. Tool32 siis tässä testailussa käytössä, ei liity testoon ohjelmana. Edit: Saattaa se status_ lesen toki toimiaaki mun dde:n kanssa, niitä argumentteja on 1500 kpl ja ei toimivaa sattunu kohdalle kun randomilla koitin.

Tuolla on muuten pari graafia, data kerätty testolla ja kuvaajat piirretty excelillä:

https://drive.google.com/folderview?id=0B7LUAhTbmskIV2N4UGF3LXNhSnc&usp=sharing

[pheno]

Kiitos ensinnäkin ohjelmasta! Toiseksi olen aloittelija tässä auton tietoteknisessä maailmassa.

Törmäsin yhteen ongelmaan. Ensinnäkin Auto Detectillä tunnistui ecuksi DDE 606 fuer M57TUE2uL (autona 525d E61, 2006 (se 177hv versio)) ja kaikki arvot mitä tuohon saa esille tuntuisi olevan ihan kunnossa. Jobseista kun valitsee esimerkiksi Values #2 niin ks. arvot piirtyvät nätisti.

Koetinkin saada nuo mittarit näkyviin(F3) ja sieltä ecuksi D60M57A0, mutta mitään arvoja ei päivity mittareihin asti. Kokeilin kyllä muitakin Ecuja. Ehkä ymmärsin tai tein jotain väärin? Vai mitä tuohon pitäisi valita?

Juu, eli tuo toimii tällä hetkellä niin, että täytyy olla molemmat sekä gauge, että vastaavanniminen job käynnissä samanaikaisesti. Eli ensin valitsee jobseista esim. 'Values #1' ja sitten mittaristo päälle: Gauges -> D60M57A0 -> 'Values #1'. Tuo on tosiaan vähän epälooginen, joten pahoittelut siitä. Toivottavasti saat mittariston pelittämään!

[conde]

Kiitos ensinnäkin ohjelmasta! Toiseksi olen aloittelija tässä auton tietoteknisessä maailmassa.

Törmäsin yhteen ongelmaan. Ensinnäkin Auto Detectillä tunnistui ecuksi DDE 606 fuer M57TUE2uL (autona 525d E61, 2006 (se 177hv versio)) ja kaikki arvot mitä tuohon saa esille tuntuisi olevan ihan kunnossa. Jobseista kun valitsee esimerkiksi Values #2 niin ks. arvot piirtyvät nätisti.

Koetinkin saada nuo mittarit näkyviin(F3) ja sieltä ecuksi D60M57A0, mutta mitään arvoja ei päivity mittareihin asti. Kokeilin kyllä muitakin Ecuja. Ehkä ymmärsin tai tein jotain väärin? Vai mitä tuohon pitäisi valita?

[pheno]

Juuri näin. Lisäksi siinä olis syytä olla mahdollisuus syöttää oma kerroin kun aika on sekunteina ja esim akun varaus on ampeeritunteina. Ei tule heti esimerkkiä mieleen mutta x-akselin alapuoleiset pinta-alat olis mahdollisesti hyvä pystyä valitsemaan joko negatiiviseksi tai positiiviseksi eli lisätäänkö vai vähennetäänkö ne kokonaispinta-alasta.



D-canilla sai vähän järkeä päivitysnopeutee, se imi noin 5 arvoa sekunnissa. Enetillä tuli 8/s.

D-can:

aika(ms)  arvo
78        679,5
266       677,5
469       678,5
688       683
891       678
1078      681,5

Enet:

aika(ms)  arvo
1109      675,5
1219      681,5
1344      679
1469      680
1578      684
1703      678
1828      683
1937      679

Tässä nämä mun customjobit:

Ihka:

JOBNAME:STATUS_LESEN
VIRTUALNAME:omajobi1
JOBCOMMENT:PTC virta ja jännite
JOBARGUMENT:ID;0xD983
JOBNAME:STATUS_LESEN
VIRTUALNAME:omajobi2
JOBCOMMENT:PTC lämpötila
JOBARGUMENT:ID;0xD984

Dde:

JOBNAME:STATUS_BLOCK_LESEN
VIRTUALNAME:laturikuorma
JOBCOMMENT:Laturin kuormitus
JOBARGUMENT:3;JA;ARG;IGENL

Nuo molemmat ihkan jobit toimii yksinään mutta jos laitan kummankin päälle yrittää testo ajaa molemmissa ikkunoissa, mun mielestä synkassa, tuota jobia vaihdellen argumenttia ID;0xD983 ja ID;0xD984. Eli kummassakin ikkunassa välkkyy vuorotellen ptc lämpötila ja ptc virta/jännite. Ohjelma jumii tuossa tilassa aika nopeasti. Ei myöskään saa graafia piirrettyä kun ikkuna nollautuu jatkuvasti. Tuon dde-jobin kanssa jompi kumpi ihkan jobi toimii niin kuin pitääkin. Ongelma varmaankin liittyy tuohon että kummassakin custom-jobissa on sama oikea jobi eri argumentilla. Yhteen status_lesen-jobiin ei muuten voi laittaa kun yhden argumentin, tästä ei siis ole apua.

Tuohon viimeiseen kohtaan sain tehtyä pikaisen korjauksen. Eli nyt pitäisi esim. kaksi ihkan jobiakin toimia keskenään. Jos tämä toimisi paremmin... Testiversio täältä: http://phenoboy.kapsi.fi/testo/testo-27-Jan-2014.zip

Tästä vähän kun olo paranee, niin luon nuo mittaristot D72:lle myös.

Se tuli samalla huomattua, että siihen Testo ei taida taipua, että kahdesta eri ecusta olisi samanniminen job päällä, olen sen näköjään joskus vuonna miekka ja kivi suuressa viisaudessani niin ajatellut Paitsi jos luo omia customjobeja. Alussa ajattelin, että tuskin kukaan käyttää kahta ecua samaan aikaan. Sun ecussa siitä onkin hyötyä, kun sieltä saa niin paljon dataa ulos eri ecuista.

[böntti]

Ok, joo tarkoitin toki y-akselia x-akseli kuvaa tässä aina aikaa. Eli määritetään aloitusajan ja lopetusajan ja se laskisi näistä pinta-alan approksimaation?

Juuri näin. Lisäksi siinä olis syytä olla mahdollisuus syöttää oma kerroin kun aika on sekunteina ja esim akun varaus on ampeeritunteina. Ei tule heti esimerkkiä mieleen mutta x-akselin alapuoleiset pinta-alat olis mahdollisesti hyvä pystyä valitsemaan joko negatiiviseksi tai positiiviseksi eli lisätäänkö vai vähennetäänkö ne kokonaispinta-alasta.

Ei valitettavasti tällä hetkellä pysty vaihtamaan nopeutta. No, se näköjään olisikin näissä uudemmissa aika hyödyllinen, jossa dataa tulee ihan eri tahtia kuin näissä 90-luvun vehkeissä laitetaan muistiin tämä(kin). Tuo ruudun/plotin päivitysnopeus on aiemmin ollut mielessä että pitäis saada säädettäväksi.

D-canilla sai vähän järkeä päivitysnopeutee, se imi noin 5 arvoa sekunnissa. Enetillä tuli 8/s.

D-can:

aika(ms)  arvo
78        679,5
266       677,5
469       678,5
688       683
891       678
1078      681,5

Enet:

aika(ms)  arvo
1109      675,5
1219      681,5
1344      679
1469      680
1578      684
1703      678
1828      683
1937      679

Kiitos, kiva kuulla että toimii

Hmm.. mietin tuota tekemääsi status_lesen customjobia ihkaan. Että kyllä sen pitäis toimia, samoin kuin muissakin. Siis se pitää tässä huolehtia, että VIRTUALNAME on määritelty yksilölliseksi kussakin jobin määrittelyssä. JOBNAME ja VIRTUALNAME muodostaa "avaimen", johon sitten voidaan viitata eri paikoissa. Jos tämä on kunnossa, niin sitten tutkin asiaa lisää. En ihan ulkomuistista muista miten tuo meni. Voi tuo joku bugikin toki olla.

Tässä nämä mun customjobit:

Ihka:

JOBNAME:STATUS_LESEN
VIRTUALNAME:omajobi1
JOBCOMMENT:PTC virta ja jännite
JOBARGUMENT:ID;0xD983
JOBNAME:STATUS_LESEN
VIRTUALNAME:omajobi2
JOBCOMMENT:PTC lämpötila
JOBARGUMENT:ID;0xD984

Dde:

JOBNAME:STATUS_BLOCK_LESEN
VIRTUALNAME:laturikuorma
JOBCOMMENT:Laturin kuormitus
JOBARGUMENT:3;JA;ARG;IGENL

Nuo molemmat ihkan jobit toimii yksinään mutta jos laitan kummankin päälle yrittää testo ajaa molemmissa ikkunoissa, mun mielestä synkassa, tuota jobia vaihdellen argumenttia ID;0xD983 ja ID;0xD984. Eli kummassakin ikkunassa välkkyy vuorotellen ptc lämpötila ja ptc virta/jännite. Ohjelma jumii tuossa tilassa aika nopeasti. Ei myöskään saa graafia piirrettyä kun ikkuna nollautuu jatkuvasti. Tuon dde-jobin kanssa jompi kumpi ihkan jobi toimii niin kuin pitääkin. Ongelma varmaankin liittyy tuohon että kummassakin custom-jobissa on sama oikea jobi eri argumentilla. Yhteen status_lesen-jobiin ei muuten voi laittaa kun yhden argumentin, tästä ei siis ole apua.

[pheno]

X-akseli on aika ja y-akselilla esim virta tai cm^3/s tai mikä vaan aikayksikköön sidottu arvo. Käyrän alle jäävä pinta-ala kuvaa toteutuneen kulutuksen. Avasin csv-tiedoston excelillä, laskin aina kahden peräkkäisen rivin aikojen erotuksen. Saadun ajan kerroin jomman kumman rivin virta-arvolla. Sitten kerroin sopivalla vakiolla että sain millisekunnit tunneiksi. Tuloksena siis yhden rivin aikana mennyt energia ampeeritunteina. Kaikki rivit summattuna sain ptc-vastuksen kokonaisuutena kuluttaman energian.

Ok, joo tarkoitin toki y-akselia x-akseli kuvaa tässä aina aikaa. Eli määritetään aloitusajan ja lopetusajan ja se laskisi näistä pinta-alan approksimaation?

Saako tuota datan pyyntiä hitaammalle? Nyt kun pyysi esim ihkalta noita arvoja niin sieltä tulee aina sama arvo kolme kertaa -> csv tiedostossa vain joka kolmas rivi sisältää uutta tietoa, 20 min lokissa on noin 15000 riviä. Täytyy ensalkuun kokeilla d-canilla, sehän on enettiä hitaampi.

Ei valitettavasti tällä hetkellä pysty vaihtamaan nopeutta. No, se näköjään olisikin näissä uudemmissa aika hyödyllinen, jossa dataa tulee ihan eri tahtia kuin näissä 90-luvun vehkeissä laitetaan muistiin tämä(kin). Tuo ruudun/plotin päivitysnopeus on aiemmin ollut mielessä että pitäis saada säädettäväksi.

Sitten tuosta status_lesen-jobista. Jos et oo vielä tutustunut niin se on näiden uudempien ecujen jobi millä pyydetään niitä sg_codierung-taulukon arvoja. Ediabaksen dokumenttien mukaan sgdb-filen koodaaja päättää että montaako arvoa ko. moduulilta voi kerrallaan pyytää, ainakaan meikäläisen ihkalta ei saa yhdellä status_lesenillä ulos kuin yhden arvon Anyways jos laitan testoon kaks erillistä status_leseniä (ihka01_customjobs.biv), molemmat omalla argumentilla, menee ohjelma jumiin. Se ikäänku yrittää samaa argumenttia molempiin avattuihin graafeihin, argumentti vaihtuu nopeaan tahtiin ja ohjelma jumii parissa sekunnissa. Sama homma jos yritä yhtä aikaa status_leseniä kahdelta eri eculta (molemmilla tietenkin oma argumentti). Tähän olis kiva joku ratkaisu saada Softa kyllä toimii muuten tosi hyvin ja on erittäin tehokas datan keräämiseen. Keep it simple

Kiitos, kiva kuulla että toimii

Hmm.. mietin tuota tekemääsi status_lesen customjobia ihkaan. Että kyllä sen pitäis toimia, samoin kuin muissakin. Siis se pitää tässä huolehtia, että VIRTUALNAME on määritelty yksilölliseksi kussakin jobin määrittelyssä. JOBNAME ja VIRTUALNAME muodostaa "avaimen", johon sitten voidaan viitata eri paikoissa. Jos tämä on kunnossa, niin sitten tutkin asiaa lisää. En ihan ulkomuistista muista miten tuo meni. Voi tuo joku bugikin toki olla.

[pheno]

Tuplat tais tulla.. alla yksi lisäkuva kehitysversiosta. Lisäsin scrollbarit, jotta voi selata historiaa, osaa seurata myös viimeistä arvoa.

[böntti]

Mielenkiintoinen idea, kyllä tuo pitäisi mahdollista olla. X-akseli kuvaa siis virrankulutusta tiettynä ajanhetkenä?

X-akseli on aika ja y-akselilla esim virta tai cm^3/s tai mikä vaan aikayksikköön sidottu arvo. Käyrän alle jäävä pinta-ala kuvaa toteutuneen kulutuksen. Avasin csv-tiedoston excelillä, laskin aina kahden peräkkäisen rivin aikojen erotuksen. Saadun ajan kerroin jomman kumman rivin virta-arvolla. Sitten kerroin sopivalla vakiolla että sain millisekunnit tunneiksi. Tuloksena siis yhden rivin aikana mennyt energia ampeeritunteina. Kaikki rivit summattuna sain ptc-vastuksen kokonaisuutena kuluttaman energian.

Saako tuota datan pyyntiä hitaammalle? Nyt kun pyysi esim ihkalta noita arvoja niin sieltä tulee aina sama arvo kolme kertaa -> csv tiedostossa vain joka kolmas rivi sisältää uutta tietoa, 20 min lokissa on noin 15000 riviä. Täytyy ensalkuun kokeilla d-canilla, sehän on enettiä hitaampi.

Sitten tuosta status_lesen-jobista. Jos et oo vielä tutustunut niin se on näiden uudempien ecujen jobi millä pyydetään niitä sg_codierung-taulukon arvoja. Ediabaksen dokumenttien mukaan sgdb-filen koodaaja päättää että montaako arvoa ko. moduulilta voi kerrallaan pyytää, ainakaan meikäläisen ihkalta ei saa yhdellä status_lesenillä ulos kuin yhden arvon Anyways jos laitan testoon kaks erillistä status_leseniä (ihka01_customjobs.biv), molemmat omalla argumentilla, menee ohjelma jumiin. Se ikäänku yrittää samaa argumenttia molempiin avattuihin graafeihin, argumentti vaihtuu nopeaan tahtiin ja ohjelma jumii parissa sekunnissa. Sama homma jos yritä yhtä aikaa status_leseniä kahdelta eri eculta (molemmilla tietenkin oma argumentti). Tähän olis kiva joku ratkaisu saada Softa kyllä toimii muuten tosi hyvin ja on erittäin tehokas datan keräämiseen. Keep it simple

[pheno]

Kuumetauti iski joten nyt kestää vähän tämän päivityksen kanssa.

Onnistuisko pinta-alaintegraaliin laskemisen lisääminen käyriin? Olis näppärä esim virrankulutuksen tutkimisessa, näissä uudemmissa kun on siihen liittyviä ongelmia. Yksinkertainen approksimaatio summa(näytteenottoaika x arvo) riittäis oletettavasti hyvin. Tuohon tyyliin: http://autsys.aalto.fi/pub/control.t...kuvat/img8.png. Jos haluaa tarkemman niin ottaa eteen- ja taaksepäin joista laskee keskiarvon.

Mielenkiintoinen idea, kyllä tuo pitäisi mahdollista olla. X-akseli kuvaa siis virrankulutusta tiettynä ajanhetkenä ?

Tuo boost target lähti toimimaan sekä arvona että mittarina näillä ohjeilla (neulana).
Lisäsin sen siis tohon values#1:een.

Taidan odotella tota sun seuraavaa päivitystä enkä rupea tuota mittarinäyttöä enempää rukkaamaa.

Tuota start systemcheck zyl-kohtaa en löytäny jobeista. Ymppäätkö nää vaikka seuraavassa päivityksessä tuohon injector valuesiin

Saakos noita mittareita järjestettyä jollain haluamaansa järjestykseen? Haluaisin esim. Boost Targetin ja Boostin vierekkäin niin ois helpompi verrata toisiinsa.

P.s. On mullekin ollut jo hyötyä tästä ohjelmasta paljon, joten "keep up the good work"

Kiitos, koitetaan aina päivitellä kun on aikaa.

START_SYSTEMCHECK_ZYL on oma jobinsa, joka löytyy siitä job listasta, ei excelistä. Sitä ei valitettavasti saa siihen samaan JOBARGUMENTS listaan ympättyä. ks. screenshotti. Eli ensin tuo job ajoon ja sitten 'injector values #1' - jos ei toimi, niin katsotaan sitten lisää..

Järjestystä pystyy muuttamaan, en osannut arvata että tällekin olisi käyttöä

järjestys menee aakkosjärjestyksessä definitions.txt:ssä määritettyjen gaugejen "id":n perusteella.

Jos vaihtaa siis:
[BPSCD_POUTVAL] --> [1BPSCD_POUTVAL] niin sen pitäisi tulla ensimmäiseksi listalla.

Vastaavat gauge-konffit pitää muuttaa myös. AJatus tässä onkin ollut että voi haluamiaan gauge- näkymiä tehdä itse. Lisäämällä määrittelyjä definitions.txt:hen ja tekemällä uusia gauge-näkymiä..

[böntti]

Onnistuisko pinta-alaintegraaliin laskemisen lisääminen käyriin? Olis näppärä esim virrankulutuksen tutkimisessa, näissä uudemmissa kun on siihen liittyviä ongelmia. Yksinkertainen approksimaatio summa(näytteenottoaika x arvo) riittäis oletettavasti hyvin. Tuohon tyyliin: http://autsys.aalto.fi/pub/control.t...kuvat/img8.png. Jos haluaa tarkemman niin ottaa eteen- ja taaksepäin joista laskee keskiarvon.