Fejlfinding
Fejlfinding af produktets hardware og software er ofte nødvendigt for at rette de fejl, der enten er kommet, eller fordi der er ting man har glemt at tage højde for.
Fejlfinding i hardware
Der er flere forskellige fejl man kan finde. For eksempel kan man finde fejl på et kredsløb fordi der er at kobberet er ridset væk, eller der er en fejl med ledningerne. Man kan bruge et multimeter til at finde disse fejl ved at se om der er spænding i kredsløbet, eller evt. til at måle strømme og om der er forbindelse. Nogle former for fejlfinding kræver at man kan se tidsforløbet af spændingen, så her skal man bruge et oscilloscop. Man kan læse mere konkret om disse instrumenter under Målinger.
Grundlæggende principper i fejlfinding
De fleste elektroniske produkter består af flere forskellige blokke, eller kan nedbrydes i mange dele, hvor et simpel eksempel kan illustreres som vist her:
Eksempel på et blokdiagram over et kredsløb
Hvis man forestiller sig et fejlramt apparat som kan illustreres med ovenstående blokdiagram, så vil man med et korrekt input ikke få det korrekte output.
For at fejlfinde apparatet, så vil taktikken være at man sætter det korrekte signal på inputtet, og så måler man mellem del 4 og 5. Måler man det korrekte signal her, så kan man konkludere at del 1-4 fungerer korrekt, og fejlen må ligge i del 5-8. Hvis det er tilfældet, så vil man måle mellem del 6 og 7. Hvis man ikke kan måle det korrekte signal her, så har man indsnævret fejlen til at ligge i del 5-6. Man vil så måle mellem del 5 og 6, og måler man det korrekte signal, så har man lokaliseret fejlen til at ligge i del 6.
Denne teknik kaldes halverings-princippet, fordi man hele tiden halverer det område hvor man har analyseret sig frem til at fejlen ligger i.
På denne måde får man hurtigt sporet sig ind på hvilken del af apparatet man skal fejlfinde i. Der skal så selvfølgelig fejlfindes i den aktuelle del, hvor man igen kan forsøge at opdele lidt på samme måde inde i den fejlramte del, indtil man kan komme helt ned og fejlfinde på komponent-niveau.
Fejlfinding på komponent-niveau
Hvis man forestiller sig at lysdioden i kredsløbet vist til højre ikke lyser, så skal man selvfølgelig måle på kredsløbet, men lidt ligesom halverings-princippet vist i de grundlæggende principper, så taktikken vil være at måle mellem modstanden og lysdioden, det kan fx. være ved at man starter med at måle på modstandsbenet der har forbindelse til lysdioden. Med en supply på 5V, så vil man sikkert måle enten 5V eller 0V på det sted. Alle målinger omtalt her et foretaget i forhold til stel.
Måler man 5V så kan man analysere sig frem til at der ligger 0V over modstanden, og ud fra ohms lov kan man se at der ikke løber strøm i modstanden, så det betyder at den halvdel op mod forsyningen (supply) ser ud til at fungere. Man vil så fortsætte fejlfindingen ved at måle på lysdioden fx. det ben der går til stel. Her vil man igen kunne måle 5V eller 0V, hvis man måler 0V, så er der forbindelse til stel, altså er der her forbindelse til stel, så fejlen ligger omkring lysdioden. Man vil så måle på det andet ben af lysdioden, hvor man også kan måle enten 5V eller 0V. Måler man her 0V, så burde der have været 5V, da det kredsløbsmæssigt er samme punkt som modstanden, så fejlen skal findes i den forbindelse der er mellem de to komponenter - der det på print, så kan det være en afbrydelse af printbanen.
Hvis man målte 5V på det andet ben af lysdioden, så vil man sidde med at der er 5V over lysdioden, hvilket der ikke kan passe. Her kan der være to muligheder, enten at lysdioden er brændt af, eller at den vender forkert, så strømmen ikke løber den rigtige vej gennem den for at den skal kunne lyse.
Fejlfinding i software
Når man skal fejlfinde i sine programmer, så er det vigtigt at man gør sig klart hvilket niveau man fejlfinder på.
For det første skal man kunne oversætte sit program. Det kræver at det er skrevet med den korrekte syntaks, ellers vil Arduinoen IDE ikke oversætte det til maskinkode, og når det er lykkedes, så skal der være hul igennem til Arduinoen som beskrevet på siden Software og Udviklingsmiljø[1] for man kan komme videre med sin fejlfinding.
For det andet skal programmet udføre de algoritmer man har fastlagt under sin dokumentation af koden, hvis det for eksempel er eksemplet med termostaten, så kan algoritmen være at der skal tændes for varmen hvis temperaturen er under setpunktet og der skal slukkes for varmen hvis temperaturen er over setpunktet. Hvis den gør det modsatte, så vil programmet fungere uhensigtsmæssigt, og man skal have fundet ud af hvor man har lavet en fejl.
Hvis programmet udfører de algoritmer som det skal, men koden stadig ikke fungerer, så kan det være fordi der ligger fejl i det elektriske kredsløb - det kan være at programmet tænder for varmelegemet, men at det faktisk ikke varmer - det kan skyldes at man ikke har sat benet op til at være output, eller det kan være en elektrisk fejl i kredsløbet omkring varmelegemet.
En fjerde fejltype er at man kan have sat de forkerte algoritmer op i sin dokumentation, så programmet overholder algoritmerne, men at de ikke løser den Kravspecifikation man har sat op. Så må man tilbage til tegnebrættet og finde nogle algoritmer der kan leve op til kravene.
Et godt værktøj til at udføre fejlfinding med er Serial Monitor hvor man kan skrive værdier ud, efterhånden som programmet afvikles. Dette kan give noget ide om hvad der sker "inde" i programmet, så man kan spore fejl, underligt input, eller hvad problemet er. Det svære i den form for fejlfinding er, at finde ud af hvad der skal skrives ud.
Erfaringsmæssigt er det vigtigt at skelne i mellem hvilken af de 4 typer fejl man arbejder med, når man skal fejlfinde, da det ellers kan blive uoverskueligt at lede efter fejlene. Det er også god praksis at teste dele af koden for sig, ved at man anvender Stepwise Improvement i sin udvikling, i stedet for at man laver en “big bang” test, hvor man kan have flere forskellige fejl at arbejde med på samme tid, så man har svært ved at skille dem fra hinanden.
Tager man eksemplet med termostaten kan man starte med at måle temperaturen, og registrere om man faktisk kan registrere en temperaturændring. Så kan man koble varmelegemet på, og teste om det faktisk kan varme ved at man kan tænde og slukke det manuelt eller i nogle lange intervaller. Så kan man koble regulering på med et fast programmeret setpunkt, og så til slut lave styringen med et variabelt setpunkt, så man kan indstille den ønskede temperatur. På den måde kan man minimere hvor mange forskellige fejl man arbejder med ad gangen, og dermed lette sin fejlfinding.
Referencer
| Måleudstyr Holstebro HTX | |
|---|---|
| Måleudstyr | Frekvenstæller - Logik-analysator - Multimeter - Oscilloscop - RCL-meter - Skilletransformator - Strømforsyning - Tonegenerator - K-type |
| Begreber | Præcision - Nøjagtighed - Måleteknik - Målinger - Fejlfinding |