Ett regler-program som utför något utan att det skiter sej har ett tydligt och genomtänkt flöde av händelser där man i ett antal punkter utför något som ett resultat av indata och som i varje läge kan hantera när något går fel.
Punkterna i flödet symboliserar den programkod som måste skrivas för att göra just detta, varken mer eller mindre.
Att rita ett flödes-schema har den fördelen att program-skrivandet har en stomme att följa och logiska missar blir enklare att undvika redan innan någon programkod skrivits.
Se detta flödesshema:
conditions-loops.jpg
Detta schema är en katastrof, bl.a därför att man inte tar hand om felfallen på ett synligt sätt.
Redan första funktions-rutan är troligen fel-tänkt. Innan man värmer kannan bör nivå-villkoret vara ett minvärde, lämpligen motsvarandestorleken på en kopp vatten. Level==0 betyder på datorspråk "är kannan tom". Här finns risken att kokning startar bara kannan inte är absolut tom. Risk för torrkokning.
Rutan "fill kettle". Den rutan bör brytas ned till fler flöden.
Rimligen bör man börja med att kolla om det finns vatten att fylla med och kontrollera om fyll-nivån blir den rätta.
Som en enkel subfunktion bör man kolla om fylltiden ligger inom rimligt span. Fel tid kan tyda på alla möjliga fel, läcka i kannan, uteblivet kranflöde, trasig nivågivare mm.
Om inte alla villkor uppfylls bör hela processen avbrytas och ge någon form av larm. Larm är då en egen funktions-ruta, till vilken en linje ska dras.
Larm-funktionen kan vara samma ruta för flera funktioner för att spara kodande och ge samlad felfunktion.
Detta flödes-schema är trots allt bra och fyller sin funktion då det visar var evt. logikbrister finns. Att hitta brister i redan skriven programkod är betydligt svårare.
Schemat skulle kunna var ett del-schema för ditt akvarie för t.ex. töm-vatten-operationen som inte ska blandas med fyll-vatten-funktionen.
Däremot kan bägge dela liknande funktioner, t.ex. övervaka med en timer så att operationen tog förväntat lång tid. För lång eller kort tid bör utlösa larm.
Antag att timern gått i 10 timmar vid påfyllning och nivå-flottören fortfarande säjer att det är låg vatten-nivå, bör man nog avbryta funktionen och utlösa larm.
Vid de olika rutorna i flödet kommer ingivarna, samt dina manuella val, att påverka valet om t.ex vilka pumpar och ventiler som ska öppnas på ett tydligt sätt.
Om det inte är tydligt eller logiskt hållbart, så blir det inte bättre när man ska knåpa ihop programkoden och inte har en stomme att hålla sej till.
Man kan bygga hus på det sättet, se den tjusiga villan i huvudet och börja bygga utan ritning. Garanterad katastrof.
Även inläsningen/sparandet av manuell indata bör ges ett eget sub-flöde.
Förmodligen vill du ha en hel del saker inställbara såsom sätta en klocka, manuellt eller automatiskt välja/styra processer osv.
Slutligen vill man ofta ha en ytterligare säkerhets-nivå i form av extern övervakning t.ex. så att inte arduinon hänger sej när den precis innan den tänkt ge order om att avbryta påfyllningen.
Om flödes-schema känns komplicerat, så är det inget mot komplikationerna att programmera det man bara har en grumlig föreställning om i huvudet i samma takt som man plitar ned programkoden.
Saker går att lösa efterhand, korrigera osv. Ingen katastrof skedd om man gjort funktion för att läsa utomhus-vädret och den rapporterar -99 grader på grund av att kabeln till en givare gått av och man inte har satt gränser i koden på vad som är rimligt.
Flytta vatten inomhus känns däremot som att det bör ske med lite mera "tänka före" än att vara efterklok.
Man kan göra det så enkelt som i flödesschemat ovan, men risken för fel såsom att man torrkokar pga för lite vatten är uppenbar, men då har man trots allt flödesschemat att se på och förstå varför det blev så.
Koka vatten är trots allt en förhållandevis enkel sak jämfört med akvarie-problemet som innehåller så många fler parametrar.
Vore jag guldfisk i ditt akvarium så hade jag ansett det högst befogat med trippla säkerhets-nivåer när en nybörjare på programmering tänker automatisera vattenbytet.