-
Min reprap begynner å ta form. Den er nå kommet så langt at den er
-blitt en kubisk ramme. Z-aksen er montert men ikke kalibrert, og det
-hele er klart for litt enkel testing. Har møtt på to problemer som
-blokkerer videre montering, men har oppnått kontakt med Audun Vaaler
-ved Høgskolen i Ãstfold som forteller at de er nesten ferdig med et
-tilsvarende byggesett som det jeg tar utgangspunkt i, og håper de kan
-forklare hvordan de kom rundt problemene. De to problemene er
-relatert til Z-aksen og Y-aksen.
-
-
For Z-aksen, er det et stjernehjul som festes på motoraksen ved
-tannjulet som driver z-aksebåndet og som skal holde båndet på plass.
-Problemet med det nederste stjernejulet er at det er helt løst, og
-blir liggende på motoren 5 mm nedenfor tannjulet, i stedet for å ligge
-inntil tannjulet slik det skal. Mulig løsningen er å borre i
-stjernehjulet, eller lime det fast.
-
-
For Y-aksen, er det en plastdel som ser ut til å mangle som skulle
-dekket to skruver som kommer i veien for kraftoverføringsmekanismen
-fra motoren til selve aksen, slik at mekanismen kan snurre fritt.
-
-
Når det gjelder elektronikken til min reprap, så er min gode venn
-Anders Rosnes igang med å lodde sammen delene og han forteller at
-koblingsbordet for Arduino er klart, og en temperatursensor og en
-optoswitch er også klar. Gleder meg til å teste dem. Må bare finne
-ut hvordan jeg laster opp firmware i Arduino-en. :)
-
-
Når det gjelder NUUGs reprap-prosjekt, så er det framgang og Ole
-Kristian, Tollef og Ketil besøke IFI for å få fortgang i produksjon av
-plastdeler, og Ole Kristian forteller at han har funnet en kilde til
-de fleste metalldelene. Gleder meg til å se resultaten av det
-arbeidet.
+
There are two software projects that have had huge influence on the
+quality of free software, and I wanted to mention both in case someone
+do not yet know them.
+
+
The first one is valgrind, a
+tool to detect and expose errors in the memory handling of programs.
+It is easy to use, all one need to do is to run 'valgrind program',
+and it will report any problems on stdout. It is even better if the
+program include debug information. With debug information, it is able
+to report the source file name and line number where the problem
+occurs. It can report things like 'reading past memory block in file
+X line N, the memory block was allocated in file Y, line M', and
+'using uninitialised value in control logic'. This tool has made it
+trivial to investigate reproducible crash bugs in programs, and have
+reduced the number of this kind of bugs in free software a lot.
+
+
The second one is
+Coverity which is
+a source code checker. It is able to process the source of a program
+and find problems in the logic without running the program. It
+started out as the Stanford Checker and became well known when it was
+used to find bugs in the Linux kernel. It is now a commercial tool
+and the company behind it is running
+a community service for the
+free software community, where a lot of free software projects get
+their source checked for free. Several thousand defects have been
+found and fixed so far. It can find errors like 'lock L taken in file
+X line N is never released if exiting in line M', or 'the code in file
+Y lines O to P can never be executed'. The projects included in the
+community service project have managed to get rid of a lot of
+reliability problems thanks to Coverity.
+
+
I believe tools like this, that are able to automatically find
+errors in the source, are vital to improve the quality of software and
+make sure we can get rid of the crashing and failing software we are
+surrounded by today.