Automatisk krutdispenser

[Large]

Vill bara nämna att det här är trågen som fått mig att registrera mig på detta forum (har varit "hangaround" länge men aldrig orkat registrera mig).

Ett otroligt imponerande bygge. Därtill väldokumenterat och mycket bra skrivet.

Jag ska försöka mig på att klona detta. Även jag är skeptisk till digitala vågar.

Tack Öskar!

// Johan

[TokHenke]

Hittat och plöjt genom hela tråden idag (skvallra inte för chefen..) och ställer mig i kören som berömmer ditt projekt, långt från alla projekt man följer har denna uppdateringsfrekvensen om de ens blir färdigställda.

En tanke som slog mig för v2.0 är om inte en liten "beeper" kunde användas för att signalera att en nyligen uppmätt laddning är klar och ligger inom godkänd tolerans?
Visst, allt står ju på displayen men du pillar säkert med annat laddrelaterat under tiden det tar för en ny laddning att vägas upp och då kunde kanske ett "beep" indikera att det ligger en ny godkänd laddvikt i skålen och väntar.
Om den går över den valda toleransen kan ett "beeeeeep" eller liknande indikera att den laddningen går i retur.
Bara ett litet förslag i all vänlighet.

//H

[Öskar]

Vill bara nämna att det här är trågen som fått mig att registrera mig på detta forum (har varit "hangaround" länge men aldrig orkat registrera mig).

Ett otroligt imponerande bygge. Därtill väldokumenterat och mycket bra skrivet.

Jag ska försöka mig på att klona detta. Även jag är skeptisk till digitala vågar.

Det var roligt att höra. Meddela gärna hur det går.

[Öskar]

En tanke som slog mig för v2.0 är om inte en liten "beeper" kunde användas för att signalera att en nyligen uppmätt laddning är klar och ligger inom godkänd tolerans?
Visst, allt står ju på displayen men du pillar säkert med annat laddrelaterat under tiden det tar för en ny laddning att vägas upp och då kunde kanske ett "beep" indikera att det ligger en ny godkänd laddvikt i skålen och väntar.
Om den går över den valda toleransen kan ett "beeeeeep" eller liknande indikera att den laddningen går i retur.

Tack för beröm och uppslag till förbättringar. Jag har funderat på en grön (laddning klar och acceptabel) och en röd (overcharge) lysdiod. Är inte särskilt förtjust i pip och andra elektroniska ljud.

Nästa förändring (om det blir någon) kommer att bli att konfigurera en ”web server” som publicerar en enkel webbsida. Tanken är att man ska kunna ansluta till och styra BSIRAD med vilken dator/smarttelefon/surfplatta som helst. Då kan man lägga in olika ljud där, så kan användaren själv göra inställningar hur färdig laddning ska påannonseras. Det vore grymt även ur andra aspekter.

Det skulle vara väldigt enkelt att justera, lägga till och ta bort laddningar. Därtill skulle man kunna spara obegränsat med laddningar och ge varje laddning ett talande namn. Yttermera skulle det vara enkelt att komma åt statistik, loggar, mm. Dessutom skulle det bli mycket enklare att klona BSIRAD.

Det blir dock tidigast till nästa vinter.

[Öskar]

F.K.

Jag har fått in en rapport om att BSIRAD inte går att installera under Raspbian 10 (Buster). Själv slutade jag uppgradera operativsystemet när jag fick BSIRAD att fungera. Det behövs ju inte eftersom BSIRAD normalt inte är ansluten till internet.

Jag kör Raspbian 9.6 (stretch). Användaren som inte kunde installera under R-10 (Buster) kunde installera under R-9.X (Stretch).

Jag har inte haft tid att försöka replikera felet, men ska försöka till helgen.

Kul med återkoppling i alla fall

[Öskar]

Det var ett tag sedan jag skrev i tråden. Det beror mestadels på att BSIRAD fungerar utmärkt och att jag följaktligen inte utfört några förändringar. BSIRAD har portionerat krut till tusentals patroner utan att framföra några som helst synpunkter. Använder henne till allt laddande, förutom stegar.

Hur som helst så finns det åtminstone ett fåtal personer som gett sig på försöket att bygga en klon. Från dem har jag fått in synpunkter och idéer. Ett stort förtret är att BSIRADs mjukvara inte fungerar på Raspbian 10.X (Buster) utan endast på Raspbian 9.X (Strech).

Fick ett ryck så här i Coronatider och började se över varför BSIRAD-mjukvaran inte fungerar på Raspbian 10. Insåg då att jag samtidigt borde migrera från Python2/Cython2 till Python3/Cython3. Sagt och gjort så skrev jag ihop ett program som automatiskt konverterade koden till Python3. Det gick både fort och lätt. Dock så visade det sig att man under Python3 inte kan utföra aritmetiska jämförelser mot 'null', något som fungerar under Python2:

Kod: Markera allt

A = 7
B = None (dvs null)
if A > B: 
Python2 ger svaret "sant"
Python3 kraschar

Detta ställer till stora problem då jag utför tusentals aritmetiska tester där detta potentiellt kan inträffa. Om BSIRAD misslyckas med att tolka en bild, så sätts alla dess mätvärden till 'None' (dvs null). Det är ju rimligt, då värdena inte kan sägas existera. Nu måste jag gå igenom koden för att lägga till felhantering på alla ställe där detta kan uppstå. Har inte kommit på något bra systematiskt sätt att identifiera alla dessa ställen. I de flesta fall kan ingen berörd variabel ha värdet ’None’, och då föreligger inget problem.

Testning av detta kräver att mjukvaran exekveras på den riktiga hårdvaran, så provkörning i molnet eller på PC'n är uteslutet. För att underlätta testarbetet har jag monterat i en Raspberry Pi 3 i BSIRAD. Den är betydligt snabbare och mer responsiv. För att säkerställa att programkoden även fortsättningsvis är effektiv med tillräckligt hög prestanda, så provkör jag regelbundet koden på den lååångsama Raspberry Pi Zero'n. Detta har i sin tur medfört att jag regelbundet måste koppla om Dupontsladdarna . . . vilket i sin tur medfört att jag tröttnat på råttboet med sladdar och bestämde mig för att snygga till det hela.

Jag införskaffade en löjligt dyr krimptång, så nu kan jag göra egna Dupontsladdar.

cables.jpg

Fick tag på ett stort utvecklingskretskort av vilket jag tillverkade ett ’mellankopplingskort’. Det ger en ren och snygg lösning som också underlättar i- och urkoppling av displayenheten utan risk att anslutningssladdar kopplas ut oavsiktligt. Därmed är det enkelt att byta mellan olika Raspberry’s. Den högra potentiometern reglerar ljusstyrkan på displayen. Den vänstra justerar kontrasten.

display_bacside_plain.jpg

Displayenheten uppgraderad från hel-amatörmässig till halv-amatörmässig.

före.jpg

display_backside_1.jpg

För att vara helt tydlig: uppgraderingen av mjukvara (för Raspbian 10) är bara påbörjad.

[sevehem]

Yes, en av mina favorittrådar har vaknat från de döda. Snart är det dags at massproducera, det är ju så sjukt häftigt detta!

[andersvestlund]

Detta är otroligt intressant att följa! Har en Raspberry Pi liggandes.... Hmm... Spännande!

[Öskar]

När man rör om i skiten . . .

Började kludda i koden och fattade snabbt beslut om att börja om från scratch. Jag biter i det sura äpplet ock skriver om allt från början.

Jag kunde ju inte programmera när jag påbörjade detta projekt och det har satt sina spår i koden . . . En hel del kod är riktigt amatörmässig. Stuprörs-kod utan vettigt utbrutna/isolerade funktioner och klasser. Ordentligt grisigt informationsutbyte mellan alla asynkrona trådar. Loggningen är apdålig. Koden som fattar alla beslut är av så låg kvalitet att den är omöjlig att underhålla, trots att den är väldokumenterad.

Jag har börjat med att fundera på riktlinjer för helhetsstrukturen. Vilka klasser och moduler ska jag ha? Vad ska de ansvara för? Hur ska de kommunicera med varandra? Vad ska loggas och varför? Hur ska fel som uppstår (bild går ej att tolka, kameran pluggas ur, mm) hanteras?

Ska skriva programkrav och dokumentera innan jag börjar programmera.

Har lite svårt att låta bli att fundera på hur dålig den kod jag nu skriver är? Sannolikt är jag fortfarande en äkta amatör, men på en något högre nivå.

[lasse-a]

Bara så att du vet så är den dyrköpta visdomen att man aldrig skall skriva om från början!

https://www.joelonsoftware.com/2000/04/ ... do-part-i/

Men situationen är ju lite annorlunda om man precis har börjat sin bana. Då har man säkert lärt sig ett och annat som bäst kommer till sin rätt om man kastar allt och börjar om. Även det är dyrköpta erfarenheter; som Fred Brooks skrev: "Plan to throw one away. You will anyhow":

https://course.ccs.neu.edu/cs5500f14/No ... eAway.html (Fred Brooks nu klassiska "The mythical man-month" är fö fortfarande värd att läsa. Det är mycket som inte förändrats sedan 1963).

Och det verkar ju vara precis så du arbetat. Dvs lärt dig på den första prototypen, och nu kan du göra den riktigt.

(Ett tips; Tänk objekt inte klasser. Tyvärr så lurade UML in en hel generation programmerare på fel väg. Vi håller så sakteliga på att ta oss ur den gropen.)

[Öskar]

Tack för länkar! Intressant och lärorik läsning!

Klass och objekt blandar jag nog ihop, trots att jag inser skillnaden. Det är bara det att jag inte har några klasser som instansieras till mer än ett objekt. Kamera: en klass, ett objekt. Samma gäller stegmotor, knappsats, LCD och våg. För klassen loggfil har har jag faktisk under utvecklingen skrivit två loggfiler parallellt och därmed instansierat två objekt från samma klass.

Har också insett hur komplicerad mjukvaran faktiskt är. Det är inte helt lätt att dra upp riktlinjer för helhetsstrukturen.

• Högsta prioritet är som tidigare beräkningseffektivitet. Det håller inte att slösa på resurserna om mjukvaran ska gå runt på en Raspberry Pi Zero. Nuvarande lösning är fullgod. Nya koden ska vara minst lika effektiv.
• Näst högsta prioritet är underhållbarhet. Målet är att man lätt ska förstå konsekvenserna av en ändring i koden. Struktur, inkapsling, avgränsade ansvarsområden, mm behöver ses över. Dagens lösning är under all kritik.
• Tredje hösta prioritet är användarvänlighet. Användarvänligheten är idag god.

Edit: stavfel.

[lasse-a]

Tack för länkar! Intressant och lärorik läsning!

Ingen orsak!

Klass och objekt blandar jag nog ihop, trots att jag inser skillnaden. Det är bara det att jag inte har några klasser som instansieras till mer än ett objekt. Kamera: en klass, ett objekt. Samma gäller stegmotor, knappsats, LCD och våg. För klassen loggfil har har jag faktisk under utvecklingen skrivit två loggfiler parallellt och därmed instansierat två objekt från samma klass.

Precis. Det brukar bli så. Och då är ju nyttan med objektorienterad programmering (som den implementeras idag, dvs som tunn fernissa på vanlig imperativ dito) begränsad. Då kan man ju lika gärna ha en datastruktur plus koden som arbetar på den utan hela OO-maskineriet.

(För att det ens skall vara OO så måste man ju dessutom tänka i arv och hierarkier. Och det blir ju också överflödigt här, och, har det visat sig, dessutom en tillkrånglande faktor. Så tipset är att undvika så långt det går.)

Har också insett hur komplicerad mjukvaran faktiskt är. Det är inte helt lätt att riktlinjer för helhetsstrukturen.

• Högsta prioritet är som tidigare beräkningseffektivitet. Det håller inte att slösa på resurserna om mjukvaran ska gå runt på en Raspberry Pi Zero. Nuvarande lösning är fullgod. Nya koden ska vara minst lika effektiv.
• Näst högsta prioritet är underhållbarhet. Målet är att man lätt ska förstå konsekvenserna av en ändring i koden. Struktur, inkapsling, avgränsade ansvarsområden, mm behöver ses över. Dagens lösning är under all kritik.
• Tredje hösta prioritet är användarvänlighet. Användarvänligheten är idag god.

Det låter som en bra prioritering. Men kom ihåg; "KISS - Keep it Simple Stupid". Där du är nu så är det lätt att falla för "the second system effect", som också den myntades av Fred Brooks efter att han fallit i samma fälla. (https://wiki.c2.com/?SecondSystemEffect). Betänk att kort och enkelt blir lättare att underhålla; kort och "vackert" dvs komplicerat blir svårare att underhålla.

[Öskar]

Nu har jag grävt, funderat och slitit mitt hår . . .

Skriva om från scratch är en ganska stor grej. Det är otroligt komplext att få en sådan här manick att fungera. Det gick väl an när jag höll på och utvecklade. Då var jag insatt i koden. Men nu, så här över ett år senare, så är det minst sagt en hög tröskel för att komma upp på banan igen. Jag lyssnar till lasse-a’s råd och ändrar strategi.

Fördelen med dagens kod är:

• Fungerar klanderfritt
• Stabil, inga krascher
• Hög prestanda

Nackdelar med dagens kod:

• Svår att underhålla
• Fungerar inte under Raspbian 10
• Baserad på Python/Cython 2 (support har upphört)
• Loggningen svår/omöjlig att anpassa (spelar ingen roll vid vanlig användning, men försvårar utveckling och underhåll)

Ny strategi:

• Först skriva om modulen/klassen för loggning samt anpassa övrig kod till den nya modulen/klassen. Det kommer att underlätta vidare utveckling. Dessutom ger det mig möjlighet att komma upp på banan igen.
• Därnäst avlusning av den nya Python/Cython 3-koden, för att göra den stabil.
• Därefter får vi se . . . eventuellt fortsatt uppdatering pö om pö . . . eventuellt skriva om allt från scratch.

[Katjing]

Får man föreslå versionshantering ännu en gång? Jag tror att det kommer att hjälpa dig mycket. I synnerhet när man refaktorerar och skriver om är det väldigt värdefullt att kunna se vilka ändringar man gjort, men också att enkelt kunna backa tillbaka till något som fungerar när man strular till det för sig.

Jag rekommenderar Git. Att lära sig detta är lite smärtsamt i början, men det är väl investerad tid om man har tänkt syssla med programmering, oavsett nivå.

[lasse-a]

Jag kan bara instämma i allt ovan. Du har mycket igen av att ta arbetet med att lära dig och att använda versionshantering.

[Öskar]

Jag kör redan med versionshantering (vis av erfarenhet ). Dock ej Git. Jag tittade på Git först men tyckte att tröskeln var för hög, så jag valde att utvecklade min egen semi-automatiska versionshantering. Det var lärorikt och gick förmodligen snabbare än att lära sig Git. Jag tar gärna tar emot synpunkter på min rutin.

Jag gör all kodning på Pythonanywhere.com. Där förvarar jag även samtlig dokumentation, samtliga dokument och samtliga ”understödjande administrativa script”. Jag har en mapp för varje programversion. Mappens namn består av ’at_’ + versionsnumret (t ex ’at_0.56.374’).

Har skrivit några enkla Python-script som hjälper mig.

Ett skript, bsirad_new_version.py, kontrollerar vilken version som är den senaste och skapar en ny mapp med nytt versionsnummer (tidigare versionsnummer + 2, dvs ’at_0.56.374’ blir ’at_0.56.376’). Därefter kopieras rekursivt samtliga filer och mappar från den tidigare versionsmappen till den nya. Jag får då en identisk kopia att jobba vidare med. Jag kan också anropa scriptet med två argument, t ex 0.33.333 0.66.666 vilket då skapar versionen ’at_0.66.666’ från versionen ’at_0.33.333’ (detta har jag ännu inte använt, men kan komma väl till pass den dag jag vill ”backa”).

Ett annat script, bsirad_deploy.py, kopierar, komprimerar och packar ihop samtliga nödvändiga filer till en (1) fil för nerladdning och flytt till Raspberry. Förutom källkodsfilerna för själva mjukvaran så bifogas även:

• licensfiler
• release notes
• change log
• to do list
• viss dokumentation
• script för att kompilera koden till binär maskinkod
• installationsprogram (för installation av kompilerad maskinkod)
• avinstallationsprogram (för avinstallation av kompilerad maskinkod)
• testprogram för att provköra viss hårdvara separat (test_buttons.py, test_camera.py, test_display.py, test_stepper.py, test_video_recording.py, mm)
• script för nollställande av GPIO-pins i händelse av programkrasch (reset_gpio.py). Jag kör detta scrip direkt efter ett okontrollerat programavbrott. Annars är risken att stegmotorn lämnas med strömmen på till en av spolarna.
• script för att installera interpreterad version (ej maskinkodsversion)

Anropas scriptet utan argument så deployar den den senaste versionen. Scriptet kan även anropas med argument för att deploya en äldre version.

På Raspberry'n: När filen (skapad av bsirad_deploy.py) är flyttad till valfri Raspberry, så behöver den bara packas upp. Därefter så kan man välja att köra scriptet för installation av interpreterad version, eller skriptet som kompilerar mjukvaran till maskinkod (skapar en (1) komprimerad fil för distribution).

Skriptet som kompilerar mjukvaran till maskinkod:

• Bifogar inte filer jag inte vill distribuera (t ex change log, to do list, viss dokumentation).
• Höjer versionsnumret med ett (1). Därmed kan alltid en maskinkodsversion alltid kopplas till motsvarande interpreterade version samt dit hörande källkod. Maskinkodsversioner har således ojämna nummer, emedan interpreteringsversoner har jämna.

Varje gång jag deployar på Pythonanywhere.com så skapar jag också en ny version, samt noterar noggrant samtliga förändringar i min change log. Jag vågar påstå att min change log håller en hög standard.

Kontentan är att jag alltid kan backa tillbaks till vilken version jag vill, samt att jag vet vilka ändringar jag genomfört i varje version. Att skapa en ny version tar bara några sekunder, så jag tillämpar det frekvent även om jag inte alltid laddar ned och provkör varje enskild version.

Synpunkter är alltid välkomna . . .

[lasse-a]

Ja, om sanningen skall fram så är det mera när man är flera, har flera releaser igång samtidigt, arbetar på flera funktionaliteter samtidigt, eller distribuerad utveckling som versionshantering blir oundvikligt.

Är man ensam så tappar man inte så mycket med ditt sätt. Det enda skulle väl vara riktiga commit messages så att man i efterhand kan se vilken ändring som gjorde vad (och införde vilka buggar, respektive fixade dem).

Men du kommer antagligen förr eller senare att växa ur ditt nuvarande system. Så du har med största sannolikhet inte undvikit smärtan, utan bara skjutit upp den. Lika bra att bita i det sura äpplet nu menas du är ung!

[Öskar]

@lasse-a: Du har med all sannolikhet rätt. Jag avvaktar dock med att bita i det sura äpplet. Man måste prioritera . . . finns för mycket annat gott att bita i . . .

[Öskar]

Nu är modulen som hanterar loggning helt omskriven. Därtill är all kod anpassad till den nya loggningsmodulen. Nu kan jag var som helst i koden enkelt lägga till loggningsposter. Detta kommer att underlätta utveckling och framför allt felsökning.

Därtill så har jag i konfigurationsfilen lagt till en variabel som reglerar loggningens omfattning, conf_extensive_logging (True/False). Jag kan därmed enkelt ändra mellan normal och omfattande loggning, vilket underlättar vid felsökning.

Självklart har jag full kontroll över när loggposterna fysiskt skrivs till fil. Det är viktigt, eftersom filskrivning tar stora systemresurser i anspråk, vilket kan förorsaka problem under pågående laddning. Rent fysiskt så skrivs loggen till fil när BSIRAD går in i ”idle mode” (efter att en färdig laddning lyfts av vågen och BSIRAD har omkalibrerat sig). Har dock en variabel i konfigurationsfilen med vilken man kan stänga av logg-buffring och forcerar fram omedelbar skrivning till fil. Det är bra vid felsökning om mjukvaran ideligen kraschar (vid mjukvarukrasch så går eventuell logg-buffert förlorad).

Nu ska jag avlusa den automatkonverterade Python/Cython 3-koden . . .

[Öskar]

Nu är den nya cython3-koden så pass avlusad att jag kan avsluta "laboratorie testandet" (hittills har jag bar provkört på kontoret genom att höja och sänka våg-bommen manuellt medelst handpåläggning). Nu ska jag plocka i pinalerna i den ordinarie kapslingen. Därefter provkörning med riktigt krut.

Fy fan vad mycket skit jag hittat i koden. Det är som om den vore skriven av en riktig nybörjare .

Förutom rena felrättningar, så har jag gjort en del förbättringar:

• Skrivit om display-modulen som hanterar LCD’n (den höll en orimligt låg nivå).
• Utökat och förbättrat felhanteringen.
• Förbättrad och utökad loggning (framför allt när något går fel).
• Om kalibreringen fallerar, så sparas automatiskt sista bilden/fotot (så man kan okulärbesiktiga vad systemet såg).
• Om systemet misslyckas att tolka en bild så sparas automatiskt den bilden (fotot) så att den kan okulärbesiktigas/analyseras i efterhand. Detta har aldrig hänt mig under ordinarie laddning. Dock händer det ofta då jag påverkar våg-bommen medelst handpåläggning.
• Hantering av config-filen har förbättrats och förenklats. Har delat upp den i två:
  • en för parametrar som är relevanta för slutanvändaren att pilla på
  • en annan för parametrar som primärt endast ska ändras av utvecklaren

Hur som helst, en ny release närmar sig . . .

Bifogar en stämningsbild för att tråden inte ska bli allt för tråkig

bsirad_kontorstest_besk.jpg