11. juli 2006 - 14:00Der er
21 kommentarer og 1 løsning
Hjælp til at forstå dette
Hejsa....
jeg har lavet et program som komm. med en lille hardware dims...via en dll som producenten har skrevet i C. Det virker meget fint... Dog er der opstået en lille fejl, efter de har rette en fejl i deres firmware....ja, det burde jo ikke give fejl i min app. men det gør det...:/
Det er når jeg henter data som indeholder en dato fra dimsen at det nu går galt...
jeg omregner manuelt int-værdien som kommer fra dimsen interne memory til et DateTime objekt i C#...og det virker fint...men nu hvor de har rette noget i firmwaren, så bliver den modtaget dato ét år for gammel i hht. det nuværende år!
jeg omregner UInt værdien til et DateTime objekt således:
public string ConvertTime_t(uint time_t) { long win32FileTime = (10000000*(long)time_t) + 116444736000000000; string format = "dd-MM-yyyy hh:mm:ss"; DateTime dt = DateTime.FromFileTime(win32FileTime); return dato; }
Jeg skrev til producenten, for at finde ud af hvad de præcis har ændret...
og svaret lød som følgende:
The realtime clock hardware in the device stores the year as a 2 digit value (00-99) and performs automatic leap year correction whenever this value is a multiple of 4 (0, 4, 8, 12, 16, etc). To produce a full 4 digit year the firmware adds a base year to this 2 digit value. Originally the base year was 1999 but unfortunately this caused leap year correction to occur one year early and was not detected until March of 2003 (1999+04=2003). To correct this problem the base year was changed to 2000.
Sådan som jeg forstår overståede er, at hvis året er 2006, så er der gemt '06' i memory'en og for at lave det om til 4 cifre, så lægges NU taller '2000' til og dermed får man 2006... Men det underlige er, at min app. genererede det korrekte årstal INDEN at firmware blev rettet og først NU bliver årstallet ét for for lidt...dvs. nu omregner årstallet til fx. 2005 i stedet for 2006.
Det er især denne linie, jeg ikke helt er med på: "...performs automatic leap year correction whenever this value is a multiple of 4 (0, 4, 8, 12, 16, etc)..."
Jeg håber meget I kan hjælpe mig! Jeg kan godt selv løse det med et hack (blot ved at lægge et ekstra år til, men det virker jo underligt at man skal være et hack nu hvor det hele burde passe sammen??)
> "...performs automatic leap year correction whenever this value is a multiple of 4 (0, 4, 8, 12, 16, etc)..."
Den skal forstås sådan:
Før var deres baseår lig med 1999 og når de lagde et multipla af 4 til (dvs. værdierne 0, 4, 8, 12, 16 og derudaf) så korregerede de for skudår. Den oprindelige software troede med andre ord at det var skudår i 1999+0=1999, i 1999+4=2003, i 1999+8=2007, osv. osv.
Det er selvfølgeligt forkert, og jeg er enig med arnbe_v i at deres rettelese lyder som den korrekte måde at rette fejlen på.
Der er lidt uforståligt at de ikke fangede den svipser da de lavede deres Y2K test i sin tid, men måske er programmet udviklet efter 2000.
Ja okay...det giver jo fin mening...men det jeg undrer mig mest over, er at nedenstående metode konvertere UInt værdien fra den interne memory til et år for tidligt i C#...nu hvor jeg modtager data fra den nye firmware, hvori de HAR rettet base year til 2000...?
public string ConvertTime_t(uint time_t) { long win32FileTime = (10000000*(long)time_t) + 116444736000000000; string format = "dd-MM-yyyy hh:mm:ss"; DateTime dt = DateTime.FromFileTime(win32FileTime); return dato; }
Umiddelbart er der noget som tyder på at de ikke helt har styr på deres testproces...
Indledningsvis skal det påpeges at din funktion er helt ok. Det er ikke der at fejlen er. Noget helt andet er så at forstå den, og det er ikke helt trivielt. Problemet er at der findes en god snes forskellige tidsformater i computerverden, og din algoritme konvertere imellem to af disse: fra ”unixtime” (godt nok kaldet Windows-time i dette tilfælde) til filetime.
Som sagt er din kode ok, og siden der altså alligevel er en fejl, så må den ligge et andet sted. Som jeg umiddelbart læser din oprindelige post, så ser arkitekturen sådan her ud:
"lille hardware dims" m/ firmware <-> deres DLL <-> dit program
Der er altså to andre steder det kan gå galt...
De har som sagt rettet en fejl i deres firmware. Denne gik på at de fik regnet forkert på hvornår at det er skudår (ellers en helt elementær ting at få testet for!). Denne rettede de ved at ændre et base year fra 1999 til 2000. Det fiksede skudårs-fejlen.
Nu lader det imidlertid til at dette base year også indgår i andre beregninger i firmwaren, og mindst en af disse beregninger skyder nu som konsekvens forbi med +1 år. Denne beregning er formentlig synlig udefra som et funktionskald. Du kalder ikke selv denne funktion direkte, det foregår i stedet via et kald til deres DLL: Du kalder funktionen i DLL’en, og den kalder videre til funktionen i firmwaren.
Og det er så her at jeg gætter på at fejlen er:
1) Enten har de ikke rettet den tilsvarende funktion i DLL’en (den som du kalder). Den returnerer nu et resultat som er +1 år galt.
eller
2) Du har ikke fået opdateret DLL’en sammen med firmware opdateringen. De kan have korrigeret for fejlrettelsen i deres DLL, men hvis du stadig bruger den gamle, så hjælper det jo ikke noget.
Jeg er ikke helt klar over hvilken der den rigtige. Umiddelbart hælder jeg mest til 2), men siden at de ikke selv har foreslået at du skulle opdatere deres DLL, så hælder jeg også lidt til 1).
En tredje mulighed er selvfølgelig at jeg tager helt og aldeles fejl. :^)
Arkitekturen er korrekt forstået! De har KUN rettet i firmwaren! Så 2'eren er udelukket... Det passer meget godt med det Arne v skrev : 12/07-2006 02:20:09... For den dato min metode genererer nu er -1 år ihht. det nuværende årstal...men forstår bare stadig ikke...hvad de reelt sender...altså hvad det tal de sender afsted fra dll'en reelt indeholder...
Memoryen i firmwaren, ja den indeholder et tal imellem 0-99....men hvad sender dll'en afsted... Sender den blot et 6-tal afsted for at indikere året 2006 (2000+6)...Men den metode, jeg bruge regner jo fra 1970....så hvordan jeg får 2005 (i år 2006) når jeg bruge metoden som den står her (dvs. uden at lægge et aktra år til) ja, det forstå jeg stadig ikke...så jeg er sgu lidt forvirret...står det klart for jer??
You are correct. For firmware V1.22 and earlier 1999+7=2006. For firmware V1.23 and later 2000+6=2006.
The dll applies only to V1.23 and later. The 2 digit year value read from the result data is adjusted by adding 2000 and is then converted to a C local time value which is reported in time_t format.
Det virker ikke at ovenstående svar, bekræfter at det er en ny fejl, som vi har snakker om...anyways...
Det sidste jeg ikke forstå...er sammenhængen imellem den modtaget UInt værdi, min C# metode og outputtet af denne metode...HVIS de sender år 2006 i en long, hvorfor skal jeg så konvertere via den metode som app. bruger lige nu og lægge et år til, for at det spiller...? Enten er jeg bare lidt tykhovedet...eller også, giver det bare ikke mening de info jeg sidder med...?
Det læser jeg nu som at man netop skal til at bruge en ny DLL når man opdatere firmwaren til "V1.23 and later".
Med mindre at det skal forstås som om at du brugte en forkert DLL inden at du opgraderede firmwaren? Som sagt så er der ikke noget i vejen med din kode, og siden at det virkede før rettelsen, så er jeg ret sikker på at fejlen skyldes at du stadig bruger den gamle DLL fra før. Hvis du opdatere den, så burde problemet løse sig selv uden nogen kodeændringer eller hacks fra din side.
1.22 , 1.23 er versioner af firmwaren...det står i displayet på dimsen når man tænder den....så det ér den samme dll...men fejlen ang. skudår blev rettet i version 1.23...
Men det må jo så bare være, som du selv har nævnt tidligere...at den rettelse af base year, har påvirket mere end den ene specifikke ting...anyways...det er åbenbart ikke til at blive helt klog på...?
Det sidste, jeg bare godt kunne tænke mig at du prøvede at svare på er...
hvis dll gerne vil sende året 2006 til min app. hvad sender den så egentligt, for at det passer med min metode...den må jo så sende antal ticks fra 1970 til 2006 og ikke bare 06, ikke sandt...eller?
DLL'en ligger jo ikke på dimsen ... den ligger i din Windows et eller andet sted. Det er derfor lidt irellevant at firmwaren fortæller at den er 1.23 - det vigtige er hvad DLL'en selv fortæller.
Har du prøvet at finde den, højreklikke, vælge egenskaber og så aflæse hvad versionen er der?
Det skal siges, at jeg godt kán følge dig i at der burde være frigivet en ny dll...men har skrevet med producenten flere gange...og han burde have oplyst det på nuværende tidspunkt...efter så meget besvær...men nu har jeg skrevet til ham igen og kun spurgt om, der er frigivet en ny dll...såå :)
Det er skam ikke fordi at jeg prøver at disse dig :^)
Men jeg har jo kun det du skriver at forholde mig til. Og der er helt ærligt nogle huller som jeg ikke kan få til at stemme:
Fra 12/07-2006 14:37:53> ”The dll applies only to V1.23 and later.”
Ergo må der have eksisteret en gammel DLL for firmeware før V1.23, og en ny for V1.23 og derefter. Dette stemmer ikke med at du fortæller at de ikke har opdateret deres DLL.
Du skriver, 13/07-2006 00:53:46), at din nuværende firmware er 1.23, Derfor kræver den den nye DLL som blev beskrevet i 12/07-2006 14:37:53. Siden at du ikke selv har opdateret din DLL samtidig med at du opdaterede firmwaren til 1.23, så må den nødvendigvis være for gammel.
Eller... Det er selvfølgeligt muligt at programmet som opdaterede firmwaren til 1.23 samtidigt opdaterede DLL'en. Det burde du nemt kunne finde ud af ved at finde DLL'en og aflæse versionsnummeret direkte fra den.
Men det er jo altså stadig et faktum at det virkede før at du opdaterede firmwaren, og at det ikke virker bageefter. Personligt synes jeg at alle indicierne peger på at du stadig køre med den gamle før-1.23 DLL.
ja det ville jeg også mene...men har skrevet til producenten igen..om der er udgivet en ny dll siden den første jeg har modtaget...og svaret lyder:
"You are correct. V1.00 is the last and only release of the dll."
Sååå, der ér altså kun en version af dll'en...strange...men that's it...? Så jeg har nu langt det på hylden og blot langt en år til regnestykket...det må være det...idet jeg ikke kan komme tættere på noget mere fornuftigt...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
