Svenska ElektronikForumet

Tecno's Pelletsövervakning, ett miniprojekt.

Har funderat att få ihop detta bra länge nu (ett par år) och det börjar bli dags ( svårt att få tummen ur mao ). Steg 1 blir att få till ett KISS projekt av detta.

- Arduino Duemilanove som bas
- en induktiv givare på matarskruven för avkänning pulser/varv = X gram
- Presentation via en panel med LCD 2x16 tecken/4st manöver knappar/3st LED för indikering (säljs av sodjan)
...Rad 1 |Antal mag: XX.xx|
...Rad 2 |Antal lager: XXX |
- I2C eeprom för lagring av data ***
- spänningsmatning fm via en väggvårta

Har ett veckomagasin som rymmer ca 10 säckar dvs ca 160kg.
Tanken är att ha en enkel inmatning av antalet säckar för att få en förrådsnivå.
Fler knapps inmatning för att inte av misstag skapa fel lagringsnivå på respektive ställe.

Lagernivån förändras med -X gram/varv på matarskruven, detta ger ett hyfsat medelvärde av kvarvarande pellets i veckomagasinet. Presentation av kvarvarande mängd i form av antal säckar i veckomagasinet. Klurar lite på om jag skall ha en inmatningsfunktion av inkommande pellets leverans som i mitt fall för det mesta består av 2 pallar och ha en nedräkning av 'lagret' vid påfyllning av veckomagasinet.

*** här uppkommer då frågeställningen om hur stort minne som kan behövas. Har 24LC16B att tillgå som ju rimligen borde räcka till.

Knappfunktioner
1+4 = Inmatning av antalet säckar i veckomagasinet. Hålla ner 1 och ange antalet säckar med 4.
1+2+4 = Inleverans = 104 säckar. Hålla ner 1+2 och tryck 4 en gång för inleverans av två pallar till lagret.
1+2+3+4 = Manuell korrigering av lager. Hålla ner 1+2+3 och förändra antalet säckar med 4 dvs. -1 säck/tryckning.

Kan man ha någon sorts enkel klocka för att kunna utläsa dygnsförbrukningen? Ledord KISS.

Knapparna 2+3 för att presentera dygnsförbrukning

LED's
Röd Led1= Nivå varning veckomagasin
Röd Led2= Nivåvarning lager
Gul Led3= Blink/kvittens på inmatning
Kommentera gärna och har du tips om programmeringen så tar jag gärna emot tips.

2kB EEPROM räcker mycket långt faktisk!
* Det behövs ett 16 bitars värde för kalibreringen, kanske ett 32-bit. (alltså xx,xxxg/varv värdet)
* Ett 32-bitars för antal inmatade kg i g. (enkelt att jobba med sedan)
* Ett 32 bit för räkning av åtgången pellets. (Samma upplösning som talen ovan)
* Ett densitetsvärde för kalibrering av de ovanstående värden. Orsaken är att skruven matar volym och du vill se vikt.
Sedan finns det fortfarande en jäkla massa plats till övers... Kan ju användas till dygnsstatistik i kombination med en RTC.

En sak du måste tänka på vid mätningen av varv är att vissa kärnlösa skruvar fjädrar tillbaka lite om det går lite trögt. Om det vill sig illa (och det vill det ju konsekvent här i livet) kommer den då precis att passera sensorn, sedan stängs motorn av och den fjädrar tillbaka. Detta ger alltså två pulser där det skulle vara noll. Därför förordar jag två sensorer som ska komma i sekvens på rätt sätt - men fortfarande bara en pigg på axeln.

En RTC kan väl vara kul att ha men är det så viktigt? Fördelen är att du kan fylla resterande RAM-minne med statistik så att du kan få ut kurvor, det kan även bara vara dygnsförbrukningen som behövs och det finns ju ganska enkla SPI/I²C RTC-kretsar att köpa...

Tips: Spara antal pulser med kanske 5 minuters mellanrum, vid 1M skrivningar (enl. databladet) ger det en garanterat levtid på EEPROM'en på ~9,5 år och du kan som högst förlora 5 minuters pelletsförbrukning. Och om 9 år bygger du en ny eller byter ut EEPROM'et till FRAM. Eller spara var 10'de minut och det är om 19 år du ska fundera på det.

Såklart ska du bara spara om det har skett någon ändring - vilket då ger än längre levtid på EEPROM'et, det är ju inte så våldsamt på sommaren t.ex.

Tack för informationen.

32-bits värden OK
Densitets kalibrering, men jag vet ju i stort vad 1/varv ger i vikt. Matar skruven i X antal varav och dividerar den mängden som matats fram med X. Bör inte detta vara tillräckligt för att få fram ett hyfsat medelvärde för beräkning? Kan det skilja så mycket att jag skall behöva omkalibrera en leverans av pellets? Samma lokala leverantör så det bör ju inte skilja så värst mycket annat än ev. fuktkvoten. Frågan är hur mycket detta gör till eller ifrån?

Detta med kärnlös skruv känner man ju till och dess beteende om man råkat köra tomt i veckoförrådet men sköter man sig och ser till att det finns nåt att mata så är medelvärdet ganska så jämn.
Nu är det ju nåt år sedan jag gjorde mätningar så jag bör nog göra om dessa då jag har bytt leverantör.

1 alt 2 givare, har inte tänk på detta som du påpekar. Tror du att det i stora hela skulle göra någon stor diff om det nu skulle bli dubbel avläsning någon gång?
Har 2 stoppskruvar på axeln till skruven vilka är 90° förskjutna till varandra, finns en till stoppskruv som inte ligger axiellt på samma som dessa två.
Här kunde man väl kunna lägga upp börvärden i tid mellan de två stoppskruvarna för att räknas som en puls, dvs är det < än en viss tid så = 1 puls.
Men 90° är förmodligen för mycket så två givare som ställs in på den ensamma stoppskruven kan nog vara en bra idé.

RTC, tja det kunde ju vara trevligt men som sagt inget måste. Kostar ju inga extra pinnar på Arduinon på I²C linorna finns till Eepromet.
Statistik ja, då ska det till nåt sätt att tanka ur dessa. Via USB till laptop, sparas på SD kort, nätverk, seriellt trådlöst osv och då börjar KISS att naggas i kanten men visst vore det kul att få lite kurvor att glana på det måste erkännas.

Densiteten (g/L) varierar mellan tillverkare och rent faktisk från pall till pall...

Har du alltså fått kalibrerat din skruvmätning är det ju otroligt smartare att ändra vikten per volymenhet när det i realiteten är den som ändras vid byte - och då hålla kvar kalibreringen.

Effekten är att kalibreringen multipliceras med en variabel faktor som direkt gör om t.ex. mm³ till gram. Byter du leverantör är det bara att väga 10L pellets o räkna lite och mata in det värde (mellan 625g/L och 910g/L), sedan är allt kalibrerat igen.

Det är iaf. så jag har gjort då det blev beställd så.

Det verkar ju inte vara så svårt att hantera så det bör jag implementera i detta.

Jag vet att vissa brännaremärken har testat med "envarvsmatning" för att kärnlösa skruvar är skit, det försök varvade förvisso rimligt nära ett varv på skruven men det blev lite väl kraftig dosering så det var inte vällyckad. Så dubbel räkning ist. för noll kommer att ses i mätningen! Och du kan vara helt säker på att det kommer att vara en betydande faktor om du inte säkrar dig - och ingenting om du säkrar dig!

Regeln är ju att det som kan jävlas gör det! Och ska du ändå göra jobbet kan du likaväl göra det skottsäkert med en gång.

MrMurphy känner man ju till

http://www.ebay.com/itm/Arduino-Tiny-RT ... 3f0cc9bc0a



Denna bör väl fungera för sina 9 dolares, har både RTC och 32K minne. Börjar banne mig inte att rita eget kort och köpa lösa delar.

32kbit minne = 4kByte...

Men definitivt enkelt och redo att använda, faktorer man inte ska underskatta!

http://www.atmel.com/dyn/resources/prod ... oc0336.pdf

The AT24C32/64 provides 32,768/65,536 bits of serial electrically erasable and programmable read only memory (EEPROM) organized as 4096/8192 words of 8 bits each.

Det är nog kinesens spec som är felskriven, eller har jag fått detta om bakfoten?

Det är väl precis som beskrivit eller?

"Feature :

1、Power supply: 5V DC and Button Battery

2、Interface: IIC

3、Size: 16mm * 22mm * 23mm （Almost same size as CR2032 Button Battery）

4、Memory Capacity : 32K bit <- Bemärk detta

5、IC: DS1307,AT24C32 ; DS1307 and AT24C32 can be used separately

6、Have the automatic adjustment function of second、minute、day、month and year

7、Take alarm output function and cut off power protection function"

Jag har missuppfattat detta med bits och bytes.

Så denna på 32Kbit är ju dubbelt så stor som den 24LC16B jag har liggandes med sina 16Kbit. 32/8=4Kbyte resp 16/8=2Kbyte.
Med andra ord så borde jag vara hemma med denna RTC modul och minnet på den, är det rätt uppfattat?

Det verkar abs. så för mig!

Då har RTC:n landat i brevlådan idag, ½hyfsat snabbt från HongKong

Jag har aldrig sett en pellets panna, inte ens på vykort
(så ni får gärna skratta åt min dumma fråga)

varför ska man veta hur många gram som går åt ?
om det är nivån i "tanken" (eller heter det magasinet) borde ju en säck
motsvara ett visst antal varv på matarskruven oavsett fukthalt?