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

[JP-76]

Saatko DIS:stä ulos öljynlämpötilaa ? Kyllähän se hyvinkin voi olla, ettei tuolta öljynlämpötilaa erikseen saa. Täytyy varmaan poistaa tuo mittari, jos se DDE 6.2 ei näytä sitä oikein.

DDE 6.0:ssa, jossa yksi ahdin, saa ulos tuon öljynlämmön, ks. kuvassa muutama postaus ylempänä.

Unohtui mainita tossa edellisessä postauksessa että en tosiaan löytänyt DISsistäkään tuota öljyn lämpötilaa.

Huomasin kyllä tuon 330d:n näytön ja siksi piti oikein tarkistaa Realoem:stä että miten nuo anturit menee.

330d:ssä veden lämpötila: osa numero 13627797957, öljyn lämpötila-anturin osanumeroa en löytänyt?

Kannattaa vielä kysyä joltain toiselta jolla sama moottori että miten öljyn lämpötila näkyy ennen kuin poistaa mitään ohjelmasta.

[kalevi67]

Hei

En ole vielä ladannut tätä softaa, mutta täytyy kokeilla. Muutama kysymys:
- vaatii ilmeisesti Ediabaksen pyörimään taustalle?
- onko väliä mikä Inpa on asenettu (vai vaatiko ollenkaan)?
- vaatiko jotain muuta (polkuja, ympäristömuuttujia yms., ilmeisesti tuon yhden dll:n ainakin)?
- onko väliä mihin asentaa. En nähnyt aloitussivulla mitään asennus/käyttöohjetta (onko jossain). Vai mennäänkö vaan kokeilun kautta

[pheno]

Hei

En ole vielä ladannut tätä softaa, mutta täytyy kokeilla. Muutama kysymys:
- vaatii ilmeisesti Ediabaksen pyörimään taustalle?
- onko väliä mikä Inpa on asenettu (vai vaatiko ollenkaan)?
- vaatiko jotain muuta (polkuja, ympäristömuuttujia yms., ilmeisesti tuon yhden dll:n ainakin)?
- onko väliä mihin asentaa. En nähnyt aloitussivulla mitään asennus/käyttöohjetta (onko jossain). Vai mennäänkö vaan kokeilun kautta

Periaatteessa pelkkä Ediabas riittää, mutta ecu- kansiossa pitää löytyä ecu (.prg- päätteinen tiedosto) sinun autoosi. Aika usein INPA-päivityksien mukana tulee myös päivitetty ecu-kansio, jossa läjä uusia tiedostoja.

Ja tuossa pitää olla toimiva konffi, eli ediabas.ini / obd.ini kunnossa.

Purat vaan tuon zip-paketin jonnekin levylle ja aja testo.exe. Ja se msvcrt100 dll pitää löytyä samasta hakemistosta tai jostain windowsin polusta.

Mikäs automalli on kyseessä?

[kalevi67]

Auto on e61/2004 530dA. Kokeilin nopeasti tuota (kopsasin tuon msvcr100.dll samaan kansioon) ja kun käynistää teston niin tulee herja:

"The procedure entry point DecodePointer could not be located in the dynamic link library KERNEL32.dll"

Kokeilin siis käynnistää ohjelman ilman mitään kaapelia ja kytkemistä autoon (en juuri nyt viitsi lähteä talliin kokeilemaan). Inpa on 5.02 ja se toimii. Täytyy kokeilla huomenna toden teolla...

[JP-76]

Bugeja?

- Suuttimien korjausarvot ei näytä mitään (D62M57A0) jobeissa ainakaan (eikä siten tietysti myöskään mittarinäytössä). Inpalla toimii kuitenkin.

- Boostin kertoimen korjasin ja mittarin viisari näyttää nyt oikein mutta mittarin alla oleva luku pysyy 0.00:ssa, jobissa näkyy kyllä oikein.

Pystytkö vielä tyhmälle selventämään että miten noita omia jobeja saa lisättyä olemassa olevaan ryhmään, esim. Values#1:een. Mittareita kyllä pystyn lisäämään ja poistamaan mutta ne ei tietenkään toimi koska ei ole kyseisessä jobissa...

Pitääkö Tool32:nen olla autoon kytkettynä että toimii? Mulla herjaa jotain initialite erroria kun yritän avata prg-tiedostoa?

[pheno]

Auto on e61/2004 530dA. Kokeilin nopeasti tuota (kopsasin tuon msvcr100.dll samaan kansioon) ja kun käynistää teston niin tulee herja:

"The procedure entry point DecodePointer could not be located in the dynamic link library KERNEL32.dll"

Kokeilin siis käynnistää ohjelman ilman mitään kaapelia ja kytkemistä autoon (en juuri nyt viitsi lähteä talliin kokeilemaan). Inpa on 5.02 ja se toimii. Täytyy kokeilla huomenna toden teolla...

Elikkä tuo virhe tulee siitä, jos sulla on liian vanha windows. Pitää olla vähintään XP ja SP3 - voi olla että SP2:kin käy.

Tämä vaatimus tulee siitä kun käännän softan VC++ 10:llä, joka käyttää uudempaa kerneliä. MinGw- käännöskin saattaisi toimia vanhemmissakin, muttei ole aikaa ollut kokeilla.

[pheno]

Auto on e61/2004 530dA. Kokeilin nopeasti tuota (kopsasin tuon msvcr100.dll samaan kansioon) ja kun käynistää teston niin tulee herja:

"The procedure entry point DecodePointer could not be located in the dynamic link library KERNEL32.dll"

Kokeilin siis käynnistää ohjelman ilman mitään kaapelia ja kytkemistä autoon (en juuri nyt viitsi lähteä talliin kokeilemaan). Inpa on 5.02 ja se toimii. Täytyy kokeilla huomenna toden teolla...

Bugeja?

- Suuttimien korjausarvot ei näytä mitään (D62M57A0) jobeissa ainakaan (eikä siten tietysti myöskään mittarinäytössä). Inpalla toimii kuitenkin.

- Boostin kertoimen korjasin ja mittarin viisari näyttää nyt oikein mutta mittarin alla oleva luku pysyy 0.00:ssa, jobissa näkyy kyllä oikein.

Pystytkö vielä tyhmälle selventämään että miten noita omia jobeja saa lisättyä olemassa olevaan ryhmään, esim. Values#1:een. Mittareita kyllä pystyn lisäämään ja poistamaan mutta ne ei tietenkään toimi koska ei ole kyseisessä jobissa...

Pitääkö Tool32:nen olla autoon kytkettynä että toimii? Mulla herjaa jotain initialite erroria kun yritän avata prg-tiedostoa?

Piti oikein kaivella mitä INPA tekee... tämä on muistaakseni testattu toimivaksi DDE6.0:lla,

Näköjään tämmöinen jobi START_SYSTEMCHECK_ZYL pitää laittaa ajoon ennen sitä 'injector values #1':stä. Eli kaksi jobia ajoon tuo START_SYSTEMCHECK_ZYL ja sitten 'injector values #1'. Jos haluaa 'roughnessia' katsoa niin pitää laittaa vielä START_SYSTEMCHECK_ZYL:n job parametriksi:LLR_AUS

Joo, katsoin koodin ja siellä on valitettavasti bugi, joka vaikuttaa tuohon boostiin, koska se käyttää tuota conversionfactoria.. jos tässä muutaman päivän sisään ehtisi tuon korjaamaan. Se saattaa toimia, jos jättää conversionfactorin pois konffista, sekä muuttaa min ja max arvot semmoisiksi mitä ne tulee tuolta jobista. eli yleensä n. 1000-3000 . vai mitkä tässä vakiona max ahdot olikaan ?

Jotta prg aukeaa, pitää olla kaapeli autossa kiinni.

Jobeja voi lisätä mutta tässä vaiheessa se on manuaalista käsityötä... :/ Eli sun eculle tarvii editoida fileä: D62M57A0_CUSTOMJOBS.BIV

Tässä on määritelty yksi "job":

JOBNAME:MW_SELECT_LESEN_NORM
VIRTUALNAME:SET_3
JOBCOMMENT:Values #3
JOBARGUMENT:002f007a002c14b6004a005b00c200c3003400 55005000880052003a18a514c20036009b00da0066000c

Tuo JOBARGUMENT lista on otettu excelistä ADR sarakkeesta, ne on laitettu peräkkäin ilman 0x:ää. VIRTUALNAME pitää olla yksilöllinen per tiedosto.

Jos haluat vaikka lisätä 'Boost pressure setpoint' eli ahtopaineen pyynti/tavoitearvo, niin se löytyy exclistä riviltä 438, ja ADR- kenttä on 0x18A5

Tässä esimerkki miten tuo tehdään:

JOBNAME:MW_SELECT_LESEN_NORM
VIRTUALNAME:SET_4
JOBCOMMENT:Boost setpoint
JOBARGUMENT:18A5

Tosiaan gaugen konffiin pitäisi lisätä resultname mikä tuon jobin ajamisestä syntyy, se on yleensä tuo mikä on JOBNAME sarakkeessa ja siihen lisätään eteen: STAT_ ja perään _WERT. Mutta parempi katsoa ensin minkäniminen result sieltä tulee ja sitten lisätä se konffiin.. tässä tapauksessa arvaisin että se olisi: STAT_PCR_pBDesLP_mp_WERT . Isot ja pienet kirjaimet ei tarvitse välittää.

[kalevi67]

Kiitos vastauksesta. No siitähän se johtui, että puuttui nuo service packit. Hommasin tähän käyttöön vanhan läppärin ja en vaan tuota tajunnut/muistanut (kun en ole tuota XP:tä asentanut yli kymmeneen vuoteen), että vaatii kaikenmaaliman SP:t siihen päälle. Asentelin nuo eilen ja nyt ainakin ohjelma käynnistyy, autolle asti en vielä päässyt.

[JP-76]

Piti oikein kaivella mitä INPA tekee... tämä on muistaakseni testattu toimivaksi DDE6.0:lla,

Näköjään tämmöinen jobi START_SYSTEMCHECK_ZYL pitää laittaa ajoon ennen sitä 'injector values #1':stä. Eli kaksi jobia ajoon tuo START_SYSTEMCHECK_ZYL ja sitten 'injector values #1'. Jos haluaa 'roughnessia' katsoa niin pitää laittaa vielä START_SYSTEMCHECK_ZYL:n job parametriksi:LLR_AUS

Joo, katsoin koodin ja siellä on valitettavasti bugi, joka vaikuttaa tuohon boostiin, koska se käyttää tuota conversionfactoria.. jos tässä muutaman päivän sisään ehtisi tuon korjaamaan. Se saattaa toimia, jos jättää conversionfactorin pois konffista, sekä muuttaa min ja max arvot semmoisiksi mitä ne tulee tuolta jobista. eli yleensä n. 1000-3000 . vai mitkä tässä vakiona max ahdot olikaan ?

Jotta prg aukeaa, pitää olla kaapeli autossa kiinni.

Jobeja voi lisätä mutta tässä vaiheessa se on manuaalista käsityötä... :/ Eli sun eculle tarvii editoida fileä: D62M57A0_CUSTOMJOBS.BIV

Tässä on määritelty yksi "job":

JOBNAME:MW_SELECT_LESEN_NORM
VIRTUALNAME:SET_3
JOBCOMMENT:Values #3
JOBARGUMENT:002f007a002c14b6004a005b00c200c3003400 55005000880052003a18a514c20036009b00da0066000c

Tuo JOBARGUMENT lista on otettu excelistä ADR sarakkeesta, ne on laitettu peräkkäin ilman 0x:ää. VIRTUALNAME pitää olla yksilöllinen per tiedosto.

Jos haluat vaikka lisätä 'Boost pressure setpoint' eli ahtopaineen pyynti/tavoitearvo, niin se löytyy exclistä riviltä 438, ja ADR- kenttä on 0x18A5

Tässä esimerkki miten tuo tehdään:

JOBNAME:MW_SELECT_LESEN_NORM
VIRTUALNAME:SET_4
JOBCOMMENT:Boost setpoint
JOBARGUMENT:18A5

Tosiaan gaugen konffiin pitäisi lisätä resultname mikä tuon jobin ajamisestä syntyy, se on yleensä tuo mikä on JOBNAME sarakkeessa ja siihen lisätään eteen: STAT_ ja perään _WERT. Mutta parempi katsoa ensin minkäniminen result sieltä tulee ja sitten lisätä se konffiin.. tässä tapauksessa arvaisin että se olisi: STAT_PCR_pBDesLP_mp_WERT . Isot ja pienet kirjaimet ei tarvitse välittää.

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"

[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.

[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]

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]

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

[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.

[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.