Download Report

Dataingenjör 180 hp, Mekatronikingenjör 180 hp
EXAMENSARBETE
Bottender
Drinkblandarmaskin
Camilla Lenfors & Mattias Sjögren
Examensarbete 15 hp
Halmstad 2015-07-08
Bottender
i
SAMMANFATTNING
Denna rapport beskriver framtagningen av en drinkblandarmaskin samt utvecklingen av
en applikation för att styra den. Syftet med projektet är att se om en billigare och mer
modulär produkt kan tas fram än de liknande produkterna som idag finns på marknaden.
Målet var att ta fram en fungerande prototyp, och utifrån den beräkna om en produkt
kan tas fram med en materialkostnad på under 5000 kr.
Vi ville göra en drinkblandarmaskin som skiljer sig mot liknande produkter i det avseende att den ska vara tillräckligt billig för att vara attraktiv för såväl företag som
privatpersoner. Den ska även utmärka sig genom att vara modulärt uppbyggd, d.v.s.
inte sitta ihop med hjälp av ett stort ramverk. Detta eftersom det ger större möjlighet
att anpassa den till små ytor. Det går även att hänga den upp på väggen för att spara
på så mycket utrymme som möjligt.
En applikation är framtagen för att fungera som användargränssnitt mot maskinen.
Applikationen kan köras på Android och PC, men kan endast kommunicera trådlöst från
en PC. Allt i applikationen är kompatibelt med android, utom just kommunikationen.
Det konstaterades att någon form av databas behövdes, och en lokal databas valdes på
grund av att det då ej krävs internetåtkomst.
Prototypen är klar till den grad att man i applikationen kan ange vilken drink som ska
göras, och en vagn kör då till rätt position i rätt tid. Ventilerna har på grund av tidsbrist
inte hunnits få fungerande, och de simuleras därför av lysdioder.
Slutsatser från detta arbete är att det är möjligt att göra en produkt under 5000 kr.
ii
Bottender
iii
ABSTRACT
This report describes the development of a drink mixing machine and the development
of an application to control it. The aim of the project is to see whether a cheaper and
more modular product can be produced than similar products currently on the market.
The goal was to develop a working prototype, and based on it decide whether a product
can be produced with a material cost of less than 5000 SEK.
We wanted to make a drink mixing machine which differs from similar products in the
sense that it must be cheap enough to be attractive to both companies and individuals.
It shall also distinguish itself by being modular, ie, not sit together using a large frame.
This because it provides a greater opportunity to adapt to small areas. You can also
hang it on the wall to save as much space as possible.
An application is designed to function as a user interface to the machine. The application
can run on Android and PC, but can only communicate wirelessly from a PC. Everything
in the applikation is compatible with Android, except for the communication.
It was found that some form of database needed, and a local database was chosen because
it does not need Internet access.
The prototype is complete to the extent that the application can specify the drink to be
made, and a carriage then moves to the right position for the right amount of time. The
valves have due to lack of time not been implemented, and is therefor simulated with
LEDs.
Conclusions from this work is that it is possible to make a product under the componentkost of 5000 SEK.
iv
Bottender
v
Innehåll
1 INLEDNING
1
1.1
Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Mål . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Problemställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.4
Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.5
Krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2 BAKGRUND
5
2.1
Grundsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Teoretiska lösningar & komponenter . . . . . . . . . . . . . . . . . . . . .
6
2.2.1
Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.2
Styrenhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.3
Mekatronik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3
Liknande produkter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1
The Inebriator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2
Barobot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.3
Bartendro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 METOD
17
3.1
Systemöversikt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2
Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1
Hantering av data . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3
Styrenhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4
Mekatronik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5
3.4.1
Transportering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4.2
Flödesreglage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.3
Plattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Systemspecifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 RESULTAT
4.1
27
Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.1
Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
vi
INNEHÅLL
INNEHÅLL
4.1.2
Applikationens formulär . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.3
Kommunikation- Applikation till Styrenhet . . . . . . . . . . . . . 32
4.1.4
Databas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1.5
Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2
Styrenhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3
Mekatronik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.1
Transportering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.2
Flödesreglage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.3
Plattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4
Systemdesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.5
Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.6
Test och utvärdering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.6.1
Generellt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.6.2
Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.6.3
Styrenhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.6.4
Mekatronik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.6.5
Övriga krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5 DISKUSSION
51
6 SLUTSATS
55
7 BILAGOR
61
Bottender
vii
Figurer
1.1
Exempel på coctailmixande robot, Barobot [1]. . . . . . . . . . . . . . . .
1
2.1
Systembild över grundsystemet för projektet. . . . . . . . . . . . . . . . .
5
2.2
Exempel på hur en stationär lösning på produkten kan se ut. Vätskan
transporteras via t.ex. slangar till glaset. . . . . . . . . . . . . . . . . . . .
8
Exempel på hur en vagnlösning kan se ut. Glaset transporteras på en vagn
eller plattform med hjälp av en transportanordning. . . . . . . . . . . . .
8
Bild på en likströmsmotor, och dess delar statorn och rotorn. För att byta
rotationsriktning på en likströmsmotor så byter man strömriktningen [15].
9
2.5
Ett schema på hur en H-brygga kan se ut [19].
9
2.6
Ventiler i genomskärning. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7
Lastcellen ändrar sin utspänning när en kraft appliceras på dess ena sida
[21]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.8
Bild på en glidskena (Grå) med en glidkoss (Grön) i. . . . . . . . . . . . . 11
2.9
Bild på The Inebriator, en liknande produkt [23]. . . . . . . . . . . . . . . 12
2.3
2.4
. . . . . . . . . . . . . . .
2.10 Bild på Barobot, en liknande produkt [1]. . . . . . . . . . . . . . . . . . . 13
2.11 Barobots system [1]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.12 Bild på Bartendro, en liknande produkt [24]. . . . . . . . . . . . . . . . . 15
3.1
Enkel översikt över projektets delsystem.
3.2
Översikt över Delsystem 1- Applikation. . . . . . . . . . . . . . . . . . . . 20
3.3
Översikt över Delsystem 2- Styrenhet. . . . . . . . . . . . . . . . . . . . . 21
3.4
Skiss på hur transportsystemet är tänkt att se ut. . . . . . . . . . . . . . . 22
3.5
Översikt över Delsystem 3- Transportering. . . . . . . . . . . . . . . . . . 23
3.6
Bild över hyllkonstruktionen. . . . . . . . . . . . . . . . . . . . . . . . . . 24
viii
. . . . . . . . . . . . . . . . . . 18
FIGURER
FIGURER
3.7
Översikt över Delsystem 4- Flödesreglage. . . . . . . . . . . . . . . . . . . 24
3.8
Översikt över Delsystem 5- Plattform. . . . . . . . . . . . . . . . . . . . . 25
3.9
Sammanfattande systemspecifikation där samtliga delsystem ingår. . . . . 26
4.1
Bild på applikationens struktur. För att undvika att alla formulär är beroende av varandra sätter ett formulär värden i nästa formulär och visar
det, istället för att även hämta värden från det formuläret. . . . . . . . . 28
4.2
Karta över huvudmenyn och inställningsmenyn. . . . . . . . . . . . . . . . 28
4.3
Bild på formuläret BaseForm. BaseForm är ett formulär vilket alla andra
formulär (som visas i applikationen) ärver av. Det innebär att när ett nytt
formulär skapas som TBaseForm istället för som vanligtvis, TForm, så
kommer formuläret redan från början att se ut som BaseForm samt ha alla
dess funktioner utan att behöva dess kod. Till vänster syns huvudmenyn,
och till höger inställningsmenyn. Dessa är vanligtvis dolda tills klick på
iconerna ovanför dem. Endast en syns åt gången. . . . . . . . . . . . . . . 29
4.4
Bild på formuläret Drinkform. Drinkform visar en lista över drinkrecept
(vilka recept som visas bestäms av vilken flik man är inne på). Till höger
visas den valda drinkens information. Härifrån man kan skapa/ändra och
ta bort ett drinkrecept, (Skickas då till EditDrinkForm) samt starta tillverkningen av drinken (sker i MakeDrinkForm). . . . . . . . . . . . . . . . 30
4.5
Bild på formuläret BottlesForm. BottlesForm visar en lista över upphängda
ingredienser. Det går att ändra ingredienserna och klicka på ok för att
utföra ändringen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.6
Bild på formuläret InCabinetForm. I InCabinetForm kan man lägga till
vilka ingredienser som finns hemma/ i baren. Här kan man även skapa/ändra eller ta bort ingredienser (man skickas då till EditIngredienceForm). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.7
Applikationen skickar starttecken, kommandotecken och eventuell data till
styrenheten via en Com-Port. Sedan väntar den på svar från styrenheten
i form av Ack eller Nack. Om Ack skickas tillbaka så väntar den på all
eventuell data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.8
Bilden visar de kommandotecken som anger vilket kommando som ska
utföras. Både applikationen och styrenheten har samma kod för detta, då
de måste ha samma tecken för samma kommandon för att fungera. . . . . 33
4.9
En enkel modell över databasstrukturen. För mer detaljerad modell, se
Appendix B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.10 Exempel på en fråga till databasen- I funktionen formuleras en fråga via
queryn med hjälp av FDQuery.Add(’Ett kommando, i detta fall Delete och
From position’); När hela frågan är klar, ofta av flera Add(), exekveras
den. Gick allt bra retuneras True. . . . . . . . . . . . . . . . . . . . . . . . 35
Bottender
ix
FIGURER
FIGURER
4.11 Exempel på hur koden ser ut då en ny ingrediens ska sparas. . . . . . . . 35
4.12 En bild på simulatorn när den blandar en drink som beställts via applikationen. Glaset förflyttar sig till rätt flaska och en animering av vätska
visas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.13 Via var sin UDPServer broadcastar båda applikationerna ut ett meddelande. Först bottender-applikationen, sedan simulator-applikationen.
Via svaret från simulatorn kan dess IP-adress maskas ut och sättas som
TCPClientens Host. På så sätt kan kommunikation via TCP upprättas. . 37
4.14 Resultat Delsystem 1- Applikation. . . . . . . . . . . . . . . . . . . . . . . 37
4.15 Bild på hur koden i styrenheten ser ut för att hantera inkommande tecken. 38
4.16 Översikt över Delsystem 2- Styrenhet. . . . . . . . . . . . . . . . . . . . . 39
4.17 Hur konstruktionen av ramverket är uppbyggt. . . . . . . . . . . . . . . . 39
4.18 Elschema på stegmotor styrningen byggt från L298 IC krets [34]. . . . . . 40
4.19 Systembild på hur transportsystemet fungerar. . . . . . . . . . . . . . . . 41
4.20 Bild på hyllan där flaskorna sitter fast med kardborreband och lysdioder
används för att simulera vätskeflöde. . . . . . . . . . . . . . . . . . . . . . 41
4.22 Elschema på styrning av magnetventil. . . . . . . . . . . . . . . . . . . . . 42
4.23 Elschema på förstärkning från lastcell till styrenhet via en OP- förstärkare. 43
4.24 Översikt över flödesreglaget. Systemet visar att en lysdiod får en digital
signal för att öppna sig. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.25 Bild på hur plattformen ser ut i Catia. . . . . . . . . . . . . . . . . . . . . 44
4.26 Bilden visar hur konstruktionen är uppbyggd mellan vagn och plattform
med lastcell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.27 Översikt över Delsystem 5- Plattform. . . . . . . . . . . . . . . . . . . . . 44
4.28 Bilden visar resultatet av prototypen. . . . . . . . . . . . . . . . . . . . . 45
4.29 Bild på den klara prototypen. . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.1
Skriven av Mattias Sjögren, Mekatronikingenjör och Camilla Lenfors, Dataingenjör. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Bottender
x
FIGURER
Bottender
FIGURER
xi
Tabeller
3.1
För- och nackdelar med databas. . . . . . . . . . . . . . . . . . . . . . . . 19
3.2
Arduino Mega 2560 jämförd med Raspberry Pi B. . . . . . . . . . . . . . 20
3.3
De olika lösningarna för transportering jämförda mot varandra. . . . . . . 21
3.4
Jämförelse mellan mekaniska och magnetiska ventiler. Priser varierar mycket beroende på kvalité. Ofta är mekaniska ventiler billigare[29] än magnetventiler[30]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1
Tabellen visar hur signalen ser ut till motorstyrningen. . . . . . . . . . . . 40
4.2
Tabellen visar vad kostnaden för prototypen kostar med dess olika komponenter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
xii
TABELLER
Bottender
TABELLER
xiii
Kapitel 1
INLEDNING
Denna rapport redogör för en prototyp som ska kunna blanda drinkar enligt önskemål,
med andra ord en drinkblandarmaskin. Prototypen ska kunna användas som ett redskap
för bartenders eller som underhållning samt redskap för privatpersoner.
Idén till detta projekt kommer framförallt från diskussioner om att det tar alldeles för
lång tid att beställa en drink i barer och på krogar. Om man dessutom sätter sig i
bartenderns situation så kan det vara väldigt stressigt i vissa situationer.
Det finns redan ett par varianter av en sådan produkt (se Figur 1.1), men det är sällan,
om ens någonsin, man faktiskt ser en sådan användas i vardagen. Detta kan bero på att
de ofta är väldigt stora och otympliga, men framförallt eftersom de kan vara dyra att
producera.
Figur 1.1: Exempel på coctailmixande robot, Barobot [1].
Tanken med denna produkt är att den till skillnad från många av de redan existerande
liknande produkterna ska vara så billig som möjligt att producera, samt att den ska vara
modulbaserad. Den ska vara modulbaserad eftersom den då kommer att vara enklare att
1
1.1. SYFTE
KAPITEL 1. INLEDNING
integrera i barer och liknande. Även i de barer med lite utrymme ska det gå att enkelt
finna utrymme åt maskinen.
1.1
Syfte
Projektets syfte är framförallt att undersöka om en billigare och smidigare produkt kan
göras än de liknande produkter som idag finns ute på marknaden. I detta projekt kommer
endast en prototyp tillverkas, för att kunna svara på ovanstående fråga. Ett annat syfte
är att hitta ett sätt att underlätta arbetet för bartenders, samt minska kötider på barer
och restauranger. Produkten är även tänkt att fungera som underhållning för gäster. Det
är även tänkt att produkten ska kunna införskaffas av privatpersoner som ett redskap
såväl som underhållning.
1.2
Mål
Målet med projektet är att skapa en fungerande prototyp som kan blanda minst två
drinkar. Ett annat mål är att prototypen ska vara så modulär som möjligt samt vara
enkel att vidareutveckla. En stor del av målet är även att produktens komponenter ska
kosta under 5000 kr att köpa in, utifrån beräkningar på prototypen.
1.3
Problemställning
Här redogörs de frågor som behöver tas ställning till i projektet.
• Vad kan göras annorlunda i förhållande till liknande projekt för att få produkten
billigare?
• Vilken hårdvara är lämplig som styrenheter?
• Hur ska recept och ingredienser hanteras i applikationen?
• Vilket är det bästa sättet att få vätskan i glaset?
• Hur ska flödesreglaget utformas och fungera?
1.4
Avgränsningar
Nedan skrivs de tankar och idéer som inte kommer att tas hänsyn till i detta projekt.
• Stor mängd möjliga drinkar- Då denna rapport avser prototypen begränsas antalet
möjliga drinkar till minst två, men detta bör naturligtvis ökas vid produktion av
klar produkt.
Bottender
2
1.5. KRAV
KAPITEL 1. INLEDNING
• Ismaskin- Bra tillägg till maskinen om köparen var villig att betala en större summa
pengar, men detta kommer inte implementeras i prototypen då detta skulle höja
kostnaden avsevärt.
• Inloggningssystem- För en mer personlig upplevelse med favoritrecept och egna
recept.
• Mixer- För möjlighet till mixade drinkar.
• Effektkontoll-I projektet kommer det inte tas hänsyn till hur mycket energi som
krävs för att driva prototypen eller produkten, men detta är något som är viktigt
vid vidareutveckling och produktion.
• ID-kontroll- För självbemanning.
• Extern kylbehållare- För att hålla framförallt alkoholfria drycker kylda för längre
hållbarhet och godare drinkar.
• Fler vagnar- För snabbare resultat.
• Enklare påbyggnadsansatser- Speciella sammankopplingsansatser skulle kunna implementeras på produkten för enklare utbyggnad.
• Hyllansats till transportsystem- För uppsättning på vägg.
• Loggning av förbrukning och produktion- För att kunna sammanställa statistik
över t.ex. vilka drinkar som har störst resp. minst efterfrågan. Ett sätt att i förväg
kunna beräkna vad som behövs köpas in.
• Automatkalibrering- Maskinen kan automatiskt synka position eller liknande.
1.5
Krav
För att kunna utforma en prototyp behövs det riktlinjer att gå efter. Därför framtas
krav som används till motivation för de val av komponenter och metoder som väljs till
projektet. Nedan punktas de viktigaste och mest generella kraven:
• Inget spill av vätska utanför glaset ska förekomma.
• Användaren ska i applikationen kunna välja mellan de drinkar där ingredienser
finns för tillverkning.
• Prototypen ska kunna göra minst två olika drinkar.
• Modulbaserad (Delsystem 1, 3 och 4 kommer inte att sitta ihop med varandra,
mer än via en sladd mellan Delsystem 3 och 4).
• Produktens material får inte (utifrån beräkningar på prototypen) överstiga 5000
kr.
För övriga krav se Appendix A.
Bottender
3
1.5. KRAV
Bottender
KAPITEL 1. INLEDNING
4
Kapitel 2
BAKGRUND
Den lösning som används på restauranger och barer är att personalen blandar alla drinkar. När en drink ska blandas så måttar personalen upp ingredienserna i ett centilitermått, sedan ner i glaset. Ett annat sätt som används är att de använder sig av
”freepouring”, vilket innebär att vätskan hälls upp direkt ifrån flaskan ner i glaset med
hjälp av en droppkork.
Oavsett vilken teknik som används finns det fortfarande en risk att mängden inte blir
exakt rätt. Dessutom är det tidskrävande att hälla upp i ett centilitermått, hälla över
det i ett glas, och sedan skölja ur måttet. Föresatsen är att dessa nackdelar ska undvikas
i detta projekt.
2.1
Grundsystem
Redan från början var tanken med projektet att en applikationsstyrd maskin skulle kunna
blanda drinkar till användaren. Från detta kan slutsatsen dras att ett sätt att kommunicera mellan applikationen och maskinen behövs. Även de flesta liknande produkter har
detta grundsystem. Som kommunikation mellan applikationen och maskinen, eller ”mekaniken”, behövs en styrenhet, d.v.s. en mellanhand som kan förmedla informationen
från applikationen till mekaniken på rätt sätt (se Figur 2.1).
Figur 2.1: Systembild över grundsystemet för projektet.
5
2.2. TEORETISKA LÖSNINGAR & KOMPONENTER KAPITEL 2. BAKGRUND
2.2
2.2.1
Teoretiska lösningar & komponenter
Applikation
En applikation används ofta i likande projekt för att användaren ska kunna interagera
med maskinen på ett smidigt sätt. Till exempel kan användaren i applikationen välja
vilken drink som ska skapas eller spara egna recept. En applikation kan köras från olika
plattformar beroende på hur den har utvecklats, t.ex. finns det Android-applikationer
eller Windows-applikationer. Det finns även applikationer som har stöd för flera olika
plattformar.
Databas
Ett sätt att kunna hantera alla recept, ingredienser och liknande i applikationen är
nödvändigt. Det vanligaste sättet att hantera stora mängder information på är med
hjälp av en databas.
En databas1 kan användas för att lagra större mängder data utan att behöva hårdkoda
in den i applikationen. En databas ger många fördelar, såsom tillgång till samma information från flera olika enheter samtidigt, samt att information lätt kan ändras eller
sorteras efter behov. Då databasen ligger på en server så behövs tillgång till Internet för
att få åtkomst till den.
En lokal databas fungerar i grunden som en vanlig databas, med det undantaget att
den är unik för varje enhet. D.v.s. att om någonting ändras i databasen så kommer inte
den ändringen att förkomma i en annan enhet med samma applikation, då den har sin
egen databas. En lokal databas behöver inte tillgång till Internet för att vara åtkomlig,
eftersom den ligger i enheten som är kopplad till den.
Det går att koda in all data direkt i applikationen, så att ingen databas behövs. Det går
då inte att ändra på någon information. Eller så kan all information läggas i en textfil,
som sedan itereras över för att hämta in informationen till applikationen. Dessa två sätt
är dock inte smidiga, speciellt inte om det ska sparas mycket information.
Kommunikation mot styrenhet
Kommunikation mellan applikation och styrenheten kan göras på olika sätt, t.ex. skulle
en USB-kabel kunna användas, men det beror på vilken plattform applikationen körs på.
Om den körs på Windows 32 bitars eller Windows 64 bitars plattform så fungerar det
mest sannolikt med en USB-kabel typ A hane till typ B hane. Dock är det inte säkert
att det fungerar direkt via kabel med andra plattformar. Dessutom hindrar en sladd
rörelsefriheten mer än Bluetooth eller WiFi.
Bluetooth är ett alternativ på trådlös kommunikation när situationen inte kräver snabbhet, [2], till exempel vid användande av hörlurar, högtalare, kommunikation mellan
android-enheter mm. Bluetooth är inte beroende av tillgång till Internet, dock kan inte
de kopplade enheterna vara på för långt avstånd från varandra, eftersom de då tappar
1
En samling information, organiserad så att det är lätt att söka efter, hämta och ofta även ändra
enskilda bitar information.
Bottender
6
2.2. TEORETISKA LÖSNINGAR & KOMPONENTER KAPITEL 2. BAKGRUND
kontakten. Hur långt de når beror på vilken klass enheten har. Det finns klass 1, 2 och
3, där den förstnämnda är den med längst avstånd. Den når ca 100 meter, medan klass
2 når ca 10 meter, och klass 3 endast ca 1 meter. Klass 2 är den vanligast förekommande
klassen. [3]
WiFi2 är en snabb och säker trådlös kommunikation , som dessutom fungerar på större
avstånd än Bluetooth[4]. Vanligast WiFi idag[5] är typ g som når ca 35 meter inomhus
och 95 meter utomhus[6], och typ n som når ca dubbelt så långt. Det är svårt att
uppskatta längden exakt då det finns många saker som spelar in. T.ex. påverkar det om
väggar eller andra solida objekt är mellan accesspunkten och användaren[7].
2.2.2
Styrenhet
För att kunna kommunicera mellan applikationen och maskinen behövs en styrenhet.
Styrenhetens uppgift är att ta emot instruktioner från applikationen och sedan skicka
vidare dem till maskinens olika delar. Det finns många olika komponenter att använda
som styrenhet till liknande projekt, vanligt förkommande sådana är Arduino och Raspberry Pi.
Arduino[8] är ett mikrokontrollerkort vilket använder sig av en Atmel AVR mikrokontroller. Arduino har standardiserade kopplingspunkter som även tillåter shields att kopplas
på kortet. Shields är en utbyggnad av huvudkortet som ger användaren ytterligare funktioner. Arduino erbjuder öppen källkod och en utvecklingsmiljö där program till kortet
kan skrivas[9].
Raspberry Pi är inget mikrokontrollerkort, utan en enkortsdator,[10] men den kan användas
på samma sätt som ett Arduinokort i detta projektet. Raspberry Pi är dock som sagt
en liten dator, och i och med det mycket mer komplext än ett mikrokontrollerkort. Den
kan i princip allt ett Arduinokort kan, men är inte lika simpel att använda. Arduino
rekommenderas därför ofta för de som inte är vana vid styrenheter sedan tidigare.[11]
2.2.3
Mekatronik
Själva mekaniken för projektet utgörs framförallt av ett sätt att transportera glaset till
vätskan/ vätskan till glaset, samt ett sätt att kontrollera flödet från de olika flaskorna.
Andra utmaningar är bl.a. positionering och sätt att upptäcka när en flaska är tom.
Transportering
Det finns två metoder som framförallt används vid liknande projekt för att hantera
transportering av vätskan/ glaset.
Lösning där vätskan förs till glaset
En metod är att vätskan via t.ex. slangar transporteras till glaset (se Figur 2.2). Vätskan
kan då pumpas upp ur flaskorna med hjälp av en kompressor eller pumppump. Ett annat
2
Wireless Fidelity
Bottender
7
2.2. TEORETISKA LÖSNINGAR & KOMPONENTER KAPITEL 2. BAKGRUND
sätt är att ta hjälp av gravitationskraften genom att ha flaskorna upp och ner ovanför
glaset.
Figur 2.2: Exempel på hur en stationär lösning på produkten kan se ut. Vätskan transporteras via t.ex. slangar till glaset.
Lösning där glaset förs till vätskan
Det andra alternativet är att använda en vagn/plattform eller ett rullband som transporterar glaset till rätt position. Man kan då placera t.ex. en motor på vagnen, som sedan
driver den genom att ha hjul fästa under vagnen. Ett annat alternativ är att placera
motorn vid sidan av eller under transportsträckan, koppla motorn till kuggremshjul och
kuggrem (se Figur 2.3). En plattform eller vagn fästs i remmen och förflyttas på så vis
synkront med remmen.
Figur 2.3: Exempel på hur en vagnlösning kan se ut. Glaset transporteras på en vagn
eller plattform med hjälp av en transportanordning.
Motor
För att kunna använda en vagnlösning behövs en motor. En motor är en maskin som
omvandlar en energi till mekanisk energi [12]. Till exempel så används kemisk energi i
en bilmotor för att få den mekaniska energin. Det finns även motorer som använder sig
av rörelseenergi eller elektrisk energi.
Det finns olika typer av motorer. En likströmsmotor är en motor som använder sig av
elektrisk energi i form av likriktad elektrisk ström som sedan omvandlas till rörelseenergi
[13]. Likströmsmotorn är uppbyggd av en rotor och en stator (se Figur 2.4). Rotorn är
den axel som roterar i motorn och som sedan kan kopplas till ett hjul. På rotorns axel
sitter det poler, dessa poler består av elektromagneter som matas med en likströmskälla.
Statorn är höljet som är runt om rotorn, i staton finns det en magnet som påverkar
startons poler. Statorns magnetpoler byter konstant polaritet, vilket resulterar i att de
Bottender
8
2.2. TEORETISKA LÖSNINGAR & KOMPONENTER KAPITEL 2. BAKGRUND
jagas av rotorn, och på så sätt uppstår rotation. När en likströmsmotor är spänningssatt
så rör den sig i kontinuerlig drift och slutar inte rotera fören spänningen slås av. För att
byta rotationsriktning på en likströmsmotor så byter man strömriktningen[14].
Figur 2.4: Bild på en likströmsmotor, och dess delar statorn och rotorn. För att byta
rotationsriktning på en likströmsmotor så byter man strömriktningen [15].
En annan typ av motor är stegmotor [16], eller digital-motor. De körs inte kontinuerligt
utan den tar steg för steg [17]. Stegmotorn består av en stator och en rotor. Statorn
består av ett antal olika lindningar som spänningssätts i olika tillfällen för att dra till
sig rotorn. Rotorn har “tänder” som förflyttar sig ett steg till den lindning som är
magnetiserad. När rotorn tar ett steg så förflyttar sig den ett vinkelsteg om det finns
fler tänder och lindningar så blir det ett mindre vinkelsteg som bidrar till jämnare
förflyttning. Stegmotorer används där hög precision är avgörande.
En stegmotor kan vara antingen bipolär eller unipolär. En bipolär motor använder hela
sin lindning per fas medans den unipolära har en sladd som delar upp den i två delar.
Unipolär har tunnare lindning som gör att mer metall tråd behövs och det resulterar i
att resistansen ökar. Bipolär behöver mer komplicerad styrning som gör att kostnaden
ökar för styrtekniken som ska användas [18].
Motorstyrning
För att driva en motor av någon sort från en styrenhet behövs det ofta någon typ av
motorstyrning. H-bryggan är en vanlig konstruktion för att driva likströmsmotorer och
stegmotorer i båda riktningarna. (Se Figur 2.5).
Figur 2.5: Ett schema på hur en H-brygga kan se ut [19].
H-bryggan fungerar så att om S1 och S4 är tillslagna så snurrar motorn medurs. För att
få motorn att snurra moturs så ska S3 och S2 vara tillslagna. S1 och S2 får inte vara
tillslagna samtidigt för då blir det en kortslutning, samma sak gäller för S3 och S4.
Bottender
9
2.2. TEORETISKA LÖSNINGAR & KOMPONENTER KAPITEL 2. BAKGRUND
Flödesreglage
För att kontrollera flödet ur flaskorna så behövs någon typ av reglage, som kan släppa
igenom vätskan exakt vid rätt tillfälle och i exakt rätt mängd. De sätt som nästan
uteslutande används vid liknande lösningar är med hjälp av ventiler. Det finns dock
andra lösningar för att kontrollera vätskeflödet, t.ex. med hjälp av en pump. Man pumpar
då upp vätskan från flaskorna ner i glaset.
Ventil
En ventil är en komponent som används för att reglera öppningsarean i ett system
med t.ex gas eller vätska i. Genom att öppnas helt eller stängas helt kan den reglera
genomströmningen av gasen eller vätskan.
En magnetventil använder sig av elektricitet för att bygga upp ett magnetfält som gör
att ventilen kan släppa igenom ett medium. Den körs i två olika lägen, när spänning är
påslagen eller avslagen. När det finns spänning öppnas en sluss och gas eller vätska kan
ta sig igenom. Avslagen spänning gör att slussen är stängd och varken gas eller vätska
kan inte ta sig förbi. (Se Figur 2.6a).
En mekanisk ventil behöver en yttre kraftpåverkan för att ändra sitt läge. Den mekaniska
ventilen kan anta alla lägen mellan öppen och sluten. En sluten ventil släpper inte igenom
gas eller vätska, sen när en kraft börjar vrida på hjulet som styr öppningsarean på
ventilensläpps mediet igenom (se Figur 2.6b).
(a) I en magnetventil bygger elektricitet upp
ett magnetfält som gör att ventilen kan släppa
igenom ett medium [20].
(b) En mekanisk ventil behöver en yttre
påverkan för att släppa igenom ett medium.
Figur 2.6: Ventiler i genomskärning.
Igenkänning av tom flaska
Några olika metoder man kan använd för att maskinen ska upptäcka att en flaska blir
tom. En rörelsesensor registrerar om någonting kommer ut igenom flaskorna. Om det
förväntas att det ska komma något och det inte gör det så innebär det att flaskan är
slut. En lastcell fungerar som en våg kan användas, om meningen är att vikten ska öka
med ett par gram när vätskan ska fylla på glaset och vikten inte stämmer överens med
det värdet som förvändas så indenterar det att flaskan med vätskan är slut.
Lastcell
En lastcell är en kraftgivare som mäter hur mycket kraft som trycker på änden. Den får
en inspänning som går till känsliga töjningssensorer och från töjningssensorer kommer
en utspänning som varierar beroende på hur mycket kraft som lastcellen utsätts för (se
Bottender
10
2.2. TEORETISKA LÖSNINGAR & KOMPONENTER KAPITEL 2. BAKGRUND
Figur 2.7).
Figur 2.7: Lastcellen ändrar sin utspänning när en kraft appliceras på dess ena sida [21].
Rörelsesensor
Det finns olika varianter på rörelsesensorer eller rörelsedetektorer”. Rörelsesensorerna
använder sig antingen av ljud eller ljus för att detektera rörelse. Exempel på en rörelsesensor
som använder sig av ljus för att detektera om någonting rör sig är en lasergivare. Den
ger en signal om någonting bryter strålen.
Positionering
Hur kan man veta om glaset befinner sig på rätt plats under rätt flaska vid val av vagneller rullbandslösning? Det finns flera sätt att hålla reda på positionen av glaset, där de
enklaste är med hjälp av räkning av stegmotorns steg, med en gränsbrytare eller med
sensorer.
Gränsbrytare
Gränsbrytare fungerar så att när den mekaniska armen trycks så byter switchen sitt läge
och en spänning kan passera. På så sätt kan man få en signal när ”armen” berörs.
Avståndssensor
En avståndssensor kan med hjälp av ultraljud mäta avstånd till föremål. En sensor med
upp till fyra meters räckvidd kan ha en känslighet på 3mm[22]. Detta varierar naturligtvis
beroende på komponentens kvalité.
Vagnkonstruktion
Vid lösning där glaset transporteras till vätskan kan en vagn användas som plattform
till glaset. Vagnen kan förflyttas med hjälp av hjul eller glidskenor.
Glidskenor
Glidskenor fungerar så att två skenor löper parallellt utmed varandra. I mitten av båda
skenorna sitter varsin glidkloss, som med låg friktion glider längstmed skidorna. (Se
Figur 2.8)
Figur 2.8: Bild på en glidskena (Grå) med en glidkoss (Grön) i.
Bottender
11
2.3. LIKNANDE PRODUKTER
2.3
2.3.1
KAPITEL 2. BAKGRUND
Liknande produkter
The Inebriator
Ett liknande projekt är “The Inebriator” [23] (Se Figur 2.9). Den använder en FEZ
Panda II för att lagra alla recept. Den skickar vidare informationen till ett Arduino
Mega 2560- kort som sköter styrningen av elektroniken.
Figur 2.9: Bild på The Inebriator, en liknande produkt [23].
För att driva glaset använder de en stegmotor, eftersom den underlättar acceleration
och retardation och möjliggör hög hastighet utan att spilla.
Till blanddrickan använder de en kylbox för att hålla drycken kall. Då kylboxen är
placerad på marken använder de gas för att få upp vätskan till glaset. Det går till så att
ett tryck byggs upp under vätskan, och när ett tillräckligt högt tryck uppnåtts öppnas
en elektrisk ventil och vätskan tvingas då upp till glaset.
För att förhindra oavsiktlig användning av maskinen sitter en kraftgivare på vagnen som
indikerar om ett glas finns på den eller inte. Om inte ska processen inte gå att starta. De
har olika LED-lampor inkopplade, vilka indikerar olika saker så som att programmet körs
och att programmet är färdigt. De använder sig av mekaniska ventiler för reglering av
vätskeflödet till glasflaskorna. För att öppna ventilerna använder de en likströmsmotor
med en inbyggd växellåda.
Fördelar
• Mekaniska ventiler med tryckarm ger större precision.
• Krävs ingen androidenhet för att användas.
• Ramen gör den flyttbar.
Nackdelar
• Ett inbyggt receptsystem gör det svårt att lägga till drinkar.
Bottender
12
2.3. LIKNANDE PRODUKTER
KAPITEL 2. BAKGRUND
• Mekaniska ventiler kan medföra att vätskan fortsätter rinna vid strömavbrott.
• Mekaniska knappar kan gå sönder, samt att man måste vara brevid maskinen för
att kunna starta en drink.
• Ramen hindrar utbyggnad samt gör att maskinen tar mer utrymme än nödvändigt.
2.3.2
Barobot
Denna produkt kan ha 12 flaskor samtidigt[1]. Den körs på en öppen källkod, häller upp
en drink med milliliter noggrannhet. Vanliga flaskor ska passa och vätskor som alkohol,
kolsytande drycker, mjölk ska kunna användas i den. Det behövs ingen rengöring mellan
drinkarna. En pekskärm används som användargränssnitt. LED-belysning indikerar att
en drink är klar samt används för olika funktioner. Det är smidigt att byta flaskorna,
och maskinen är lätt att transportera. (Se Figur 2.10).
Figur 2.10: Bild på Barobot, en liknande produkt [1].
Glaset förflyttas på en vagn under de olika flaskorna. Varje flaska har en dispenser, ett
vanligt redskap i barbranchen. Barobot använder sig av en 2 cl:s automat till spritsorterna och 5 cl:s för blandannat läskdrycker. Flaskorna monteras med öppningen neråt
så att gravitationen gör jobbet. Automaterna passar de flesta flaskorna. Glaset som
transponeras får max vara 17 cm högt för att det ska fungera.
Glaset rör på sig i två riktningar, X- och Y-riktning. X-axeln drivs av en stegmotor och
Y-axeln via ett servo. Ett annat servo går i Z-axeln, som ska trycka på dispenserna,
“automaterna”, under flaskorna för att släppa ner vätska i glasen.
Styrning av vagnen sköts av en ATmega328, samma mikrokontroller som Arduino UNO
Bottender
13
2.3. LIKNANDE PRODUKTER
KAPITEL 2. BAKGRUND
är baserad på. Det finns även 12 st ATmega8 mikroprocessorer. De driver i huvudsak 96
LED, där varje led styrs individuellt med PWM signaler. (Se Figur 2.11).
Figur 2.11: Barobots system [1].
Korten kommunicerar via I2 C och ISP. Fördelarna med detta är att alla LED’s kan lysa
på olika sätt, och att det är lätt att bygga ut. Avancerade funktioner körs via en android
7”.
Androidenheten är ansluten till moderkortet via PL2303 och USB / RS232. Den fungerar
som ledningscentral för alla mikrochip. Dess WiFi kan användas för att få tillgång till
Barobot-menyn på distans via en annan smartphone eller surfplatta.
Transportsystemet har magneter utsatta på olika ställen som detekteras av en hall-sensor
för att veta att positionen stämmer. Under glaset, i vagnen, finns det en viktsensor som
kollar om ett glas finns och om det kommer någon vätska från flaskorna.
Fördelar
• Mekaniska ventiler med tryckarm ger större precision.
• Ramen gör den flyttbar.
• Enkelt appliceringssystem för flaskorna.
• Minimal rengöring krävs.
Nackdelar
• Dyr (16 000-20 000).
• Mekaniska ventiler kan medföra att vätskan fortsätter rinna vid strömavbrott.
• Ramen gör att den tar onödigt mycket plats.
• Mekansika ventiler ger ingen WoW-faktor.
• Ej utbyggbar.
Bottender
14
2.3. LIKNANDE PRODUKTER
2.3.3
KAPITEL 2. BAKGRUND
Bartendro
Produkten använder sig av peristaltiska pumpar som doserar en känd volym med varje
varv som motorn snurrar[24]. Pumparna använder samma processor som Arduino och
ansluter via en RJ-45 kontakt till ett ”router board” som innehåller en Rasberry Pi (se
Figur 2.12).
Figur 2.12: Bild på Bartendro, en liknande produkt [24].
Fördelar
• Enkel att bygga.
• Lätt att byta ingredienser.
• Utbyggbar.
• Inget spill.
• Ingen motor/kompressor behövs.
• Ingen transport behövs.
• Lätt att bära.
Nackdelar
• Dyr. (Ca 1000 kr per pump).
• Rengöring av slangar.
• Ingen snygg lösning.
Bottender
15
2.3. LIKNANDE PRODUKTER
KAPITEL 2. BAKGRUND
Summering
De ovanstående produkterna har alla en förhållandevis stora stålramar vilket gör dem
otympliga att passa in i en bar. Det hindrar dessutom utbyggnad, samt utökning av flaskor. Bartendro är den enda som kan byggas ut och utöka flaskantalet, men dess slangar
medför mycket rengöring. Dessutom är det ingen snygg eller underhållande lösning.
Bottender
16
Kapitel 3
METOD
Projektet är indelat i en förfas, en utvecklingsfas och en efterfas.
Förfasen inleds med att fastställa projektets bakgrund, syfte, mål, systemöversikt, problem samt avgränsningar för projektet. Då förfasen är klar förväntas;
• Kunskap nödvändiga för projektet finnas i gruppen.
• Systemet var uppdelat i relevanta delsystem.
• En kravspecifikation vara framtagen som definierar vad som krävs av prototypen.
• En testspecifikation vara framtagen som beskriver hur det bevisas att produkten
tillgodoser de krav som ställts på den.
• En projektplan som definierar resurser, tidsplan mm finnas.
I denna rapport återfinns (med undantag av delsystem) dessa punkter under Inledning
eller Bilagor.
Under utvecklingsfasen skapas produkten med förfasens resultat som bakgrund. Mer
detaljer läggs till dokumentation, tester utförs och dokumenteras. Vid utvecklingsfasens
slut förväntas;
• Prototypen vara klar.
• Alla nödvändiga tester vara utförda och dokumenterade.
• Alla krav med hög prioritet vara uppfyllda.
• En test över hela systemet utförts och dokumenterats.
Till slut inleds efterfasen, där projektresultatet överförs till beställaren och en utvärdering
av projektet görs. Därefter avslutas projektet. Efterfasen kommer i denna dokumentation
framförallt att tas upp under Resultat, Diskussion och Slutsats.
17
3.1. SYSTEMÖVERSIKT
3.1
KAPITEL 3. METOD
Systemöversikt
Projektet är uppdelat i 5 olika delsystem;
• Delsystem 1- Applikation
• Delsystem 2- Styrenhet
• Delsystem 3- Transportering
• Delsystem 4- Flödesreglage
• Delsystem 5- Plattform
Delsystem 1 omfattar ren mjukvaruprogrammering, medan Delsystem 2 är inbyggda
system. Delsystem 3, 4 och 5 består av fysiska komponenter och hårdvara. (Se Figur
3.1).
Figur 3.1: Enkel översikt över projektets delsystem.
3.2
Applikation
Applikationen valdes att programmeras i språket och utvecklingsmiljön Delphi1 . Delphi
[25] är både ett språk och en utvecklingsmiljö som har funnits sedan 1990-talet. Det är
ett objektorienterat språk som har stöd för utveckling av applikationer till flera olika
operativsystem.
Delphi valdes eftersom det är ett enkelt objektorienterat språk med många komponenter
att välja mellan samt har ett användarvänligt grafiskt IDE2 . Biblioteket som framförallt
kommer att användas (utom vid vissa tester då VCL används) är Firemonkey. Versionen
som används är DelphiXE8.
1
2
Läs mer om valet under Diskussion
Integrated Development Environment
Bottender
18
3.2. APPLIKATION
KAPITEL 3. METOD
I Delphi finns det framförallt två stora bibliotek som är skapade för just utvecklingen
av applikationer. VCL3 är framtaget för Windowsapplikationer, medan Firemonkey är
utvecklad för mulitplattform-applikationer. Firemonkey [26] är en grafikmotor som gör
att samtliga firemonkey-komponenter kan användas på alla plattformar. Det innebär att
applikationerna som utvecklas i firemonkey direkt kan köras på bland annat Windows,
OS X, iOS och Android utan att koden behöver skrivas om. Det krävs inget extra tillägg
för att utveckla applikationer till Android eller iOS. Däremot så måste man köpa en
licens för att få programmera i Delphi.
Sammanfattningsvis kan sägas att fördelarna med Delphi är multiplattformsstöd, ett
lättanvänt grafiskt IDE och tillgång till komponent för Bluetooth. Nackdelen är att det
inte finns mycket hjälp och exempel att få till de nyare versionerna av Delphi.
3.2.1
Hantering av data
En databas underlättar hanteringen av all information, vilket ledde till slutsatsen att en
databas behövs. För att undvika behov av Internetåtkomst valdes en lokal databas. (Se
Tabell 3.1). Däremot om produkten vidareutvecklas kan en riktigt databas vara ett bra
alternativ då det ger möjlighet till delning av recept mellan användare av applikationen
och kan resultera i ett mycket större utbud av recept och ingredienser.
Tabell 3.1: För- och nackdelar med databas.
SQLite är den databas som används mest för androidapplikationer, då de flesta andra
databaser inte ännu är kompatibla med android.[27] Det är därför det självklara valet
till detta projekt.
Skiss över Delsystem 1- Applikation
Utifrån ovanstående val av metoder och komponenter kunde en mer detaljerad bild tas
fram över Delsystem 1- Applikationen (se Figur 3.2). Applikationen ska köras från en
androidenhet som trådlöst via bluetooth kommunicerar med styrenheten.
3
Visual Component Library
Bottender
19
3.3. STYRENHET
KAPITEL 3. METOD
Figur 3.2: Översikt över Delsystem 1- Applikation.
3.3
Styrenhet
Som styrenhet övervägdes en Arduino Mega 2560 och Raspberry Pi B. Arduino valdes
på grund av att den är användarvänlig för de med mindre erfarenhet av styrenheter och
liknande (se Tabell 3.2). Dessutom finns det många olika ”shields” som kan bygga ut
Arduinon för ytterligare funktionalitet. En Raspberry Pi är mer avancerad än vad som
krävs till detta projekt. Dock är den billigare än en Arduino Mega 2560, men tanken är
att efter tester av hela systemet ska en billigare Arduinomodell användas istället, när
det står klart exakt vad som behövs. T.ex. valdes Arduino Mega 2560 även pga dess 54
GPIO, men antagligen kommer inte alla dessa behövas. Det är möjligt att det i framtiden
räcker med en Arduino Uno, som endast kostar ca 260 kr.
Tabell 3.2: Arduino Mega 2560 jämförd med Raspberry Pi B.
För att kommunicera mellan applikationen och styrenheten valdes bluetooth, eftersom
prototypen ska vara så modulär som möjligt och ett trådlöst alternativ då är att föredra.
WiFi är ett annat trådlöst alternativ, men WiFi är krångligare att koppla upp mot via
en applikation, då man i koden måste ange vilket protokoll som ska användas mm. Bluetooth däremot behöver inte sättas upp från applikationen, utan kan anslutas separat
mellan enheterna. Dessutom kan enheterna då parkopplas, vilket innebär att de ”kommer ihåg” varandra i framtiden, och kopplingen däremellan behöver inte verifieras med
lösenord varje gång. Ytterligare en fördel är att Delphi har en ”Low Energy Bluetooth”
LEBT komponent, som automatiskt kan sköta sammankopplingen mellan enheterna om
så önskas. Man behöver då inte starta anslutningen manuellt från enheterna.
En Bluetooth-transceiver BTT valdes istället för en Arduino-shield BTShield då den är
billigare och mindre, och uppfyller samma krav som en shield.
Styrenheten programmeras i Arduinos eget språk och utvecklingsmiljö, då det är enkelt
och det finns mycket hjälp och exempel att få. Kommunikationen från styrenhetens sida
Bottender
20
3.4. MEKATRONIK
KAPITEL 3. METOD
ska byggas upp med hjälp av olika ”cases”, dvs med hjälp av olika ”fall’ för varje enskilt
kommando. Beroende på vilket kommando som skickas från applikationen så kommer
då olika ”fall” i koden att exekveras.
Skiss över Delsystem 2- Styrenhet
En Arduino Mega 2560 ska kommunicera seriellt via bluetooth mot applikationen. Ett
visst kommando utförs, och beroende på kommandot skickas en signal till antingen
transportsystemet eller flödesreglaget. (Se Figur3.3).
Figur 3.3: Översikt över Delsystem 2- Styrenhet.
3.4
Mekatronik
Nedan motiveras de val av komponenter och lösningar som gjorts för all mekanik i
projektet.
3.4.1
Transportering
Transponeringsmetoden som valdes var att glaset ska flytta sig till vätskan. Detta valdes av två anledningar, första anledning var att undvika rengöring som skulle behövas
om vätskan skulle transponeras till glaset, andra anledningen var från en mindre undersökning som påvisade att det var mer underhållande att se glaset flytta på sig än om
det hade stått still. (Se Tabell 3.3).
Tabell 3.3: De olika lösningarna för transportering jämförda mot varandra.
Bottender
21
3.4. MEKATRONIK
KAPITEL 3. METOD
För att få glaset att röra sig måste en motor användas. En stegmotor valdes för att
förflytta glaset. För och nackdelar som stegmotorn har jämfört mot en vanlig likströmsmotor är följande. Fördelarna stegmotorn har är att den är enkel att styra från digitala
system då det är en helt digital motor, är underhållsfri eftersom den inte använder
sig av några borstar, vid låg hastighet är det högt vridmoment, kan inte överbelastas
mekaniskt. Nackdelarna stegmotorn har mot en likströmsmotor, om det blir en förstor
mekanisk belastning kan stegmotorn kugga över och tappa sin position, inte lika snabb
rotationshastighet, ljud nivån kan bli hög.
För att veta vilken storlek det ska vara på motorn görs en uträkning. Uträkning på
kraften som motorn måste kunna utföra finns i Appendix C. Kraften som räknats ut
är från uppskattade värden. Massan som ska flyttas har värdet 500g, accelerationen
1, 1m/s2 , friktion på 100, tyngdacceleration 9.82m/s2 och draghjul med radien 2 cm.
För att få motorn att röra på sig från signalerna som kommer från Styrenheten valdes
det att använda en IC drivkrets L298[28]. L298 är en motordrivare som är uppbyggd av
en dubbel H-brygga. Möjlighet att styra motorn på andra sett finns men L298 var den
vanligaste lösningen som hittades vid styrning av stegmotorer. Ett program i styrenheten
behövs för att styra/köra stegmotorn. I koden sätts fyra utgångar på styrenheten sätts
till låg. För att stegmotorn sedan ska börja ta sina steg ska en av utgångarna bli hög.
När nästa steg ska tas så byter den höga signalen till en annan utgång. I en viss sekvens
så går motorn medurs. Hastigheten beror på vilken delay som sätts mellan stegen.
En gränslägesbrytare valdes också att användas till systemet då den kan ha olika funktioner. Den kommer användas för att ha kunna nollställa stegmotorn om den skulle
kugga över. En annan funktion man skulle kunna använda sig av om man integrerar
fler gränslägesbrytare till systemet är som en säkerhetsbrytare. För att inte systemet
ska komma till någon skada kan man montera in gränslägesbrytare i vadera ända av
transportsystemet. Om ett fel skulle inträffa och glaset vill fortsätta att röra sig till ett
håll även om det inte finns mer bana åt glaset så kommer gränslägesbrytaren göra att
motorn slutar snurra och glaset stannar.
Konstruktionen av transportsystemet(se Figur 3.4) är tänkt att glaset ska komma precis
ovanför ramen. Två kugghjul ska placeras på samma höjd så att kuggremmen är rak
där vagnen ska fästas. Stegmotorn är då tänkt att sitta bredvid vagnen, på ena sidan
av transportsystemet, eftersom vagnen då blir mindre och motorn blir mer skyddad mot
spill. Dessutom påverkas inte plattformen lika mycket av stegmotorns vibrationer.
Figur 3.4: Skiss på hur transportsystemet är tänkt att se ut.
Bottender
22
3.4. MEKATRONIK
KAPITEL 3. METOD
Skiss över Delsystem 3- Transportering
Från styrenheten ska en digital signal komma in till motorstyrningen (dubbel H-brygga),
som sedan ska skickas vidare till stegmotorn. Stegmotorn kör då åt vänster- respektive höger håll beroende på sekvensen signalerna skickades i. I motorns axel fästs ett
kugghjul som tillsammans med ytterligare två kugghjul ska driva runt en kuggrem.
Gränslägensbrytare ska placeras ut vid sidorna av transportsträckan för att kunna köra
plattformen till en ”startposition”. (Se Figur D3).
Figur 3.5: Översikt över Delsystem 3- Transportering.
3.4.2
Flödesreglage
För att få flöde från flaskorna behövs någon slags ventil. Det skulle även kunna fungera
med hjälp av en pump, men då krävs slangar från flaskorna till rätt position, vilket
medför rengöring. Därav uteslöts denna lösning. Valet av ventil stod mellan mekaniska
och magnetiska ventiler (se Tabell 3.4). Ventilen som valdes var magnetventilen detta
underlättar styrningen då produkten ska göras så modulär som möjligt. Den andra anledningen var att dessa ventiler inger en större ”WOW-faktor” enligt ett mindre antal
tillfrågade personer.
Tabell 3.4: Jämförelse mellan mekaniska och magnetiska ventiler. Priser varierar mycket
beroende på kvalité. Ofta är mekaniska ventiler billigare[29] än magnetventiler[30].
Styrningen av magnetventilerna ska skötas av transistorer4 . Styrenheten ger signalen
om ventilen ska vara öppen eller stängt med en hög eller låg signal. Transistorn styr en
matningsspänning som behövs för att driva ventilen. När transistorn får en hög signal
kan matningsspänningen öppna ventilen och när transistorn får en låg signal så kommer
matningsspänningen kapas och ventilen stängs. Transistorstyrning valdes för att det är
en simpel koppling och eftersom komponenterna fanns tillgängliga.
4
Transistor är en halvledarkomponent
spänningsreglerare, signalmodulering.
Bottender
som
23
används
som
signalförstärkare,
strömbrytare,
3.4. MEKATRONIK
KAPITEL 3. METOD
För att upptäcka om en flaska är tom valdes det att använda en lastcell för att jämföra om
vikten stämmer överens med uppskattad vikt. Lastcellen valdes över rörelesensorn av den
anledning att man med lastcellen kan veta hur mycket av en viss ingrediens som saknas
om vätskan skulle ta slut under processen. För att lastcellen ska kunna skicka läsbara
värden till styrenheten behövs en signalförstärkare av någon form. Signalförstärkningen
sker med en OP-förstärkare5 .
För att hänga upp flaskorna ska en hylla byggas där flaskorna kan fästas upp och ner.
(Se Figur 3.6) Detta eftersom det då inte behövs någon pump eller kompressor för att
få upp vätskan ur flaskorna. Flödet igenom ventilerna kommer då ske med hjälp av
gravitationen.
Figur 3.6: Bild över hyllkonstruktionen.
Skiss över Delsystem 4- Flödesreglage
Reglering av vätskeutsläpp från flaskorna ska kontrolleras med hjälp av magnetventiler.
En ventil ska finnas per flaska, och ska vara enkel att ta av och sätta på. När en ventil får
en signal från styrenhetens ska denna öppnas i en viss tid (tiden beräknas i applikationen,
som skickar med denna informationen till styrenheten, som i sin tur sätter en delay efter
det inkomna värdet). När tiden är slut ska ventilen stängas igen och strypa vätskeflödet.
(Se Figur 3.7).
Figur 3.7: Översikt över Delsystem 4- Flödesreglage.
5
En operationsförstärkare kan förstora upp en insignal flera tusen gånger för att få en bättre in signal.
Bottender
24
3.5. SYSTEMSPECIFIKATION
3.4.3
KAPITEL 3. METOD
Plattform
En plattform kommer skrivas ut med hjälp av en 3D-skrivare, eftersom detta ger bästa
möjlighet till en plattform som enkelt och snyggt kan integreras på transportramen.
För att hålla koll på plattformens position ska stegräkning av stegmotorns steg användas,
då detta inte medför någon extra kostnad och är ett enkelt sätt att göra detta på. Ett
annat sätt för att veta om positionen stämmer överens hade varit med en avståndsensor.
Man skulle kunna använda avståndsensorn som ett extra skydd om motorn skulle fastna.
En gränslägesbrytare ska också användas för att kunna nollställa stegmotorn om den
skulle kugga över.
Lastcellen som används för att ha koll på om en flaska skulle ta slut har även en annan
funktion. För att undvika processen av att skapa en drink utan att ett glas finns så kan
lastcellen kontrollera om glaset står på plattformen eller inte.
Efter att ha rådfrågat Kabetex AB[31] om bästa val av förflyttning av plattformen
valdes glidskenor, framförallt eftersom de inte måste vara noga centrerat för att undvika
friktion, till skillnad mot hjul.
Skiss över Delsystem 5- Plattform
En 3D-utskriven plattorm ska placeras över en lastcell, och sedan på transportsystemet.
Lastcellen ska kunna väga vätska med ett grams noggrannhet och skicka värdena till
styrenheten. (Se Figur 3.8). Glidskenor placeras utmed transportramens insida, mitt
emot varandra. De ska placeras så långt upp som möjligt. I varje glidskena placeras en
glidkloss. En liten metallplatta fästs mellan glidklossarna, så att en liten anordning för
att fästa plattformen kan fästas och gå upp ur ramverket.
Figur 3.8: Översikt över Delsystem 5- Plattform.
3.5
Systemspecifikation
Utifrån de valda metoderna och komponenterna kan en systemsspecifikation tas fram.
Prototypen ska vara delvis moduluppbyggd, dvs. enheten som applikationen körs från,
transportramen och ventilerna ska inte sitta ihop med varandra, mer än via en sladd melBottender
25
3.5. SYSTEMSPECIFIKATION
KAPITEL 3. METOD
lan transportramverket och ventilerna. Detta eftersom det gör det lättare att integrera
maskinen på önskat ställe. Dessutom underlättar detta för utbyggnad av produkten.
Det ska tack vare detta även gå att hänga produkten rakt på väggen, utan stöd från
bänk eller liknande. Styrenheten kan placeras i transportramverket eller bakom hyllan
flaskorna sitter på.
Applikationen ska skicka kommandon till styrenheten, som skickar signaler till motorn
och ventilerna. Lastcellen ska skicka information till styrenheten. (Se Figur 3.9). I applikationen kan man välja vilken drink man vill ha. Efter att en drink har valts så ska
systemet sätta igång. Ett glas ska förflyttas mellan olika flaskor med hjälp av transportsystemet. Då rätt ventil öppnas ska glaset fyllas på med olika vätskor enligt receptet för
den drinken.
Figur 3.9: Sammanfattande systemspecifikation där samtliga delsystem ingår.
Bottender
26
Kapitel 4
RESULTAT
4.1
Applikation
En applikation är framtagen för att användaren ska kunna interagera med maskinen.
Applikationen är programmerad i språket och utvecklingsmiljön Delphi XE8. Applikationen består av ett antal formulär/units, vilka kan liknas med klasser bestående av ett
grafiskt fönster och ett kod-fönster.
4.1.1
Design
Ett formulär kallat BaseForm (se Figur 4.3) ligger till grund för hela projektets mall,
dvs. menyer, toolbar, navigation mellan formulären vid menyklick samt popupfönster
för sparande av ändringar. Alla övriga formulär ärver BaseForm, d.v.s. de skapas som
en TBaseForm istället för som vanligtvis, en TForm. De får då samma utseende och
funktionalitet som BaseForm direkt, utan all dess kod. Detta är väldigt smidigt ifall
applikationen önskas byggas ut eller ändras. Nackdelen är dock att för att applikationen
ska kunna fungera så krävs det att BaseForm fungerar.
För att undvika att formulär är beroende av varandra sätter alltid ett formulär A värden
i formulär B utan att formulär B hämtar värden från formulär A. På så sätt är de bara
beroende åt ett håll. (Se Figur 4.1).
27
4.1. APPLIKATION
KAPITEL 4. RESULTAT
Figur 4.1: Bild på applikationens struktur. För att undvika att alla formulär är beroende
av varandra sätter ett formulär värden i nästa formulär och visar det, istället för att även
hämta värden från det formuläret.
Vid start av applikationen visas alltid BottlesForm1 (se Figur 4.5) först för att användaren
ska kontrollera att de ingredienser som sitter i maskinen stämmer överens med de som
är inskrivna i applikationen. Sedan öppnas HomeForm2 , och man kan därifrån navigera
fritt i applikationen. Längst upp finns en toolbar med två menyknappar (Se Figur 4.2a
och 4.2b).
Menyknappen till höger vänster drar in huvudmenyn, varifrån man kan klicka på det
formulär man vill gå till. Menyknappen till höger drar in en inställningsmeny, där man
kan gå till inställningar, Om oss, Kontakt eller avsluta programmet. Båda menyknapparna och toolbaren ligger i BaseForm men kan användas från alla synliga formulär. (Se
Figur 4.3).
(a) Genom huvudmenyn kan man förflytta sig
mellan de sex formulären i mitten. Från DrinkForm kan man även komma till EditDrinkForm (b) Genom inställningsmenyn kan man navigera
och MakeDrinkForm, och från InCabinetForm till de tre översta formulären, samt stänga av
till EditIngredienceForm.
programmet.
Figur 4.2: Karta över huvudmenyn och inställningsmenyn.
1
2
Mer information finns längre ner under Applikationens formulär.
Mer information finns längre ner under Applikationens formulär.
Bottender
28
4.1. APPLIKATION
4.1.2
KAPITEL 4. RESULTAT
Applikationens formulär
Nedan följer en kort beskrivning av varje formulär i applikationen
BaseForm
Basformuläret som ligger till grund för alla formulär. Använder en style, ”JET”, för en
snygg layout på hela applikationen. (Se Figur 4.3).
Figur 4.3: Bild på formuläret BaseForm. BaseForm är ett formulär vilket alla andra
formulär (som visas i applikationen) ärver av. Det innebär att när ett nytt formulär
skapas som TBaseForm istället för som vanligtvis, TForm, så kommer formuläret redan
från början att se ut som BaseForm samt ha alla dess funktioner utan att behöva dess
kod. Till vänster syns huvudmenyn, och till höger inställningsmenyn. Dessa är vanligtvis
dolda tills klick på iconerna ovanför dem. Endast en syns åt gången.
HomeForm
Visar bilder på maskinen, slumpar bilder på drinkar och förklarar kortfattat vad som kan
göras i applikationen. Hit kommer man vid start, efter konfirmation av flaskpositioner i
BottlesForm.
DrinkForm
Drinkform visar en lista över alla drinkrecept till vänster, och den just nu markerade drinkens information till höger. Där finns information som drinknamn, ingredienser,
styrka och bild. Längst upp finns flikar som bestämmer vilka drinkrecepts som kommer
visas i listan. Antingen alla, de som går att starta direkt med de upphängda ingredienserna, de som går att göra med ingredienser som finns hemma men inte nödvändigtvis
är upphängda, eller sparade favoriter. (Se Figur 4.4).
Det finns även fyra knappar längst ner, Skapa drink, Ändra drink, Ta bort Drink och
Starta drink. De två förstnämnda navigerar till EditDrinkForm, och den sista till MakeDrinkForm.
Bottender
29
4.1. APPLIKATION
KAPITEL 4. RESULTAT
Figur 4.4: Bild på formuläret Drinkform. Drinkform visar en lista över drinkrecept (vilka
recept som visas bestäms av vilken flik man är inne på). Till höger visas den valda drinkens information. Härifrån man kan skapa/ändra och ta bort ett drinkrecept, (Skickas
då till EditDrinkForm) samt starta tillverkningen av drinken (sker i MakeDrinkForm).
EditDrinkForm
Här kan man skapa eller ändra ett drinkrecept. Det går även att lägga till en bild till
receptet genom att ta kort med androidenhetens kamera. Om programmet körs på en
enhet utan kamera så döljs automatiskt knappen för att ta bild.
BottlesForm
BottlesForm är det första formuläret (förrutom en splashscreen) som visas när applikationen startas. (Se Figur 4.5). Det går även att navigera till BottlesForm i huvudmenyn
om man skulle byta flaskor under användandet av maskinen/applikationen. I formuläret
finns en lista över alla tillgängliga flaskpositioner i hyllan. Vid start av applikationen
visas alla ingredienser som varit inställda vid föregående användning av maskinen. Efter
att ha ställt in alla positioner till rätt ingrediens sparas de nya värdena genom OK klick.
Figur 4.5: Bild på formuläret BottlesForm. BottlesForm visar en lista över upphängda
ingredienser. Det går att ändra ingredienserna och klicka på ok för att utföra ändringen.
Bottender
30
4.1. APPLIKATION
KAPITEL 4. RESULTAT
InCabinetForm
I detta formulär finns 3 listor: En för alla ingredienser, en för ingredienser man har
hemma/ i baren, och en som visar vilka ingredienser som just nu sitter i hyllan. (Se
Figur 4.6). Den sistnämnda går inte att ändra. Genom pilarna mellan listorna kan man
lägga till eller ta bort en ingrediens från sina ”tillgängliga ingredienser”. Det finns även
knappar för att skapa, ändra eller ta bort en ingrediens. När man skapar eller ändrar en
ingrediens skickas man till EditIngredienceForm.
Figur 4.6: Bild på formuläret InCabinetForm. I InCabinetForm kan man lägga till vilka
ingredienser som finns hemma/ i baren. Här kan man även skapa/ändra eller ta bort
ingredienser (man skickas då till EditIngredienceForm).
EditIngredienceForm
I EditIngredienceForm skapar man en ny ingrediens. Man skriver då in namn, alkoholhalt, information och väljer en huvudgrupp (t.ex. blanddricka om ingrediensen är
apelsinjuice).
MakeDrinkForm
När man tryckt ”Starta drink” i DrinkForm så visas MakeDrinkForm, där instruktioner
om hur drinken görs visas steg för steg. T.ex. kan startinstruktioner som ”Fyll glaset
med is och sätt det på vagnen” visas, eller slutinstruktioner, ”Lägg i två limeklyftor”.
HistoryForm
Här loggas alla skapade drinkar i en lista, där tid, datum och drinkens namn visas.
Detta sparas även i databasen, vilket gör att informationen sparas även mellan att
applikationen stängs av.
StatisticsForm
StatisticsForm visar statistik över populäraste drinkarna.
SettingsForm
Här finns alla inställningar för applikationen, under olika flikar. Det finns inställningar
för att ange hur många flaskpositioner som finns på hyllan och inställning för kalibrering
av position under en flik, Flaskpositioner. Under nästa flik, Databas, kan man tömma
eller återställa databasen till ursrungsdatabasen som följer med applikationen. Den sista
fliken är Nätverkinställningar, där man kan välja om man vill koppla mot en speciell
Bottender
31
4.1. APPLIKATION
KAPITEL 4. RESULTAT
COM-port eller mot simulatorn.
AboutUsForm
Beskriver vilka som skapat applikationen och maskinen. Bakgrund till idén.
ContactForm
Visar kontaktinformation.
DBForm
Detta formulär innehåller all kod för skapande av och kummunikation med den lokala
databasen.
CommunicationForm
Sköter kommunikationen med styrenheten och simulatorn.
ParametersUnit
Innehåller definitionen av alla nödvändiga parametrar såsom TRecipe, TIngredience och
många fler.
4.1.3
Kommunikation- Applikation till Styrenhet
Applikationen kommunicerar med styrenheten med hjälp av en USB-kabel.
All kod för kommunikation mot styrenheten (och simulatorn) finns i CommunicationForm.
Med hjälp av en variabel kan sättas om applikationen ska kommunicera mot simulatorn
eller styrenheten (som kommunicerar vidare mot maskinen). För att kommunicera mot
styrenheten används seriell kommunikation.
För att kommunicera mellan applikationen och styrenheten används virtuella COMPortar3 . För att kunna använda en komponent som hanterar COM-porten så har ett
bibliotek kallat TurboPower AsynchProffessional implementerats. Dock så är det endast
kompatibelt med VCL, så enbart den nödvändiga Uniten för att kunna använda COMportar används. (På så sätt behöver inte hela biblioteket kompileras, och de delar som
inte är kompatibelt med FireMonkey ger inga fel vid kompilering av programmet.)
När programmet körs skapas först en COM-Port-komponent i koden. Sedan kollas i
CommunicationForm om en COM-port är öppen, om inte så öppnas en. (I detta fall
COM-port 3, då styrenheten dyker upp som COM3 när den kopplas in i PC:n.) Egentligen borde programmet upptäcka vilken COM-port enheten använder och sedan koppla
mot den, men för att göra det enkelt hårdkodas COM3.
I ett kommando GenericCommandMachine i CommunicationForm kollas återigen om
COM-porten är öppen, om inte så försöker den öppna den. Om den är öppen så skickas
ett starttecken (en byte som ansichar) via funktionen ComPort.PutChar(1). Detta ska
tas emot av styrenheten och säger åt den att ett kommando kommer. Därefter skickas
från applikationen ett kommandotecken på samma sätt, som säger vilket kommando som
ska utföras. Det är viktigt att både applikationen och styrenheten har samma värden för
de olika kommandona, så att rätt kommando utförs. Om kommandot som skickats även
ska överföra någon data som ska hanteras så skickas den därefter. (Se Figur 4.7)
3
Se Bakgrund/Seriell Kommunikation
Bottender
32
4.1. APPLIKATION
KAPITEL 4. RESULTAT
Figur 4.7: Applikationen skickar starttecken, kommandotecken och eventuell data till
styrenheten via en Com-Port. Sedan väntar den på svar från styrenheten i form av Ack
eller Nack. Om Ack skickas tillbaka så väntar den på all eventuell data.
Därefter ligger applikationen och lyssnar efter svarstecker från styrenheten i form av Ack
eller Nack. Detta gör den tills ett svarstecken kommer in, eller maxväntetiden går ut.
Om Ack fås så väntar sig applikationen ett svar med en viss längd på svaret. (Beroende
på vilket kommando som skickades. Funktionen väntar tills svarslängden är uppfylld,
sedan sparas svaret i en idBytes-array.
I CommunicationForm finns funktioner som ”Gå till vänster”, ”Gå till höger”, ”Hämta
position” och ”Gå till position()”. Vi kommandot ”Hämta position” förväntas ett värde
tillbaka. Vid ”Gå till position” skickas ett värde med för att tala om för styrenheten vart
vagnen ska köras.
Figur 4.8: Bilden visar de kommandotecken som anger vilket kommando som ska utföras.
Både applikationen och styrenheten har samma kod för detta, då de måste ha samma
tecken för samma kommandon för att fungera.
Bottender
33
4.1. APPLIKATION
4.1.4
KAPITEL 4. RESULTAT
Databas
En modell över databasen är framtagen. Den ligger till grund för databasens struktur.
(Se Figur 4.9). I DBForm ligger en FDConnection-komponent samt två FDQuerys, som
hanterar alla frågor mot databasen. Den ena används endast för att kunna hämta bilder
samtidigt som den andra loopar över recepten och läser in dem.
Figur 4.9: En enkel modell över databasstrukturen. För mer detaljerad modell, se Appendix B.
Om ingen databas redan finns när applikationen startas så används en redan skapad
databas med ca 30 recept i och ca 60 ingredienser från DBForm. Applikationen föreslår
själv en passande plats/ mapp att lägga databasen på. Sedan försöker applikationen
öppna en koppling mot databasen via FDConnection.
Databasen kan från applikationen tömmas om användaren inte vill ha standarddatabasen
som medföljer, och den kan dessutom återskapas till grunddatabasen om så önskas.
Om databasen töms eller återställs så raderas alla egna recept och ingredienser som
användaren lagt till.
I DBForm finns alla funktioner för att kommunicera med databasen via frågor i FDQueryn. (Se Figur 4.10). Funktionerna anropas t.ex. när man trycker på ”spara” i EditDrinkUnit för att spara en ny eller ändrad drink. (Se Figur 4.11).
Bottender
34
4.1. APPLIKATION
KAPITEL 4. RESULTAT
Figur 4.10: Exempel på en fråga till databasen- I funktionen formuleras en fråga via queryn med hjälp av FDQuery.Add(’Ett kommando, i detta fall Delete och From position’);
När hela frågan är klar, ofta av flera Add(), exekveras den. Gick allt bra retuneras True.
Figur 4.11: Exempel på hur koden ser ut då en ny ingrediens ska sparas.
Bottender
35
4.1. APPLIKATION
4.1.5
KAPITEL 4. RESULTAT
Simulator
För att kunna testa funktionaliteten på CommunicationForm finns en simulator i ett
nytt projekt. Simulatorns kod är liknande den kod som ska finnas i styrenheten. (Se Figur 4.12). Dock så skiljer sig kommunikationen åt. För att kommunicera med simulatorn
används TCP/IP4 . Simulatorn har en TCPServer, och applikationen har en motsvarande
TCPClient. För att applikationen ska kunna veta simulatorns IP-adress så har både simulatorn och applikationen en UDPServer5 Applikationens UDPServer broadcastar[32]
ut ett meddelande”Bottender” på en viss port, och simulatorns UDPServer lyssnar efter
meddelanden på samma port som börjar på ”B.o.” När den får in ”Bottender” broadcastar simulatorns UDPServer ett meddelande ”Simulator” tillbaka ut på samma port.
Figur 4.12: En bild på simulatorn när den blandar en drink som beställts via applikationen. Glaset förflyttar sig till rätt flaska och en animering av vätska visas.
UDPServern på applikationen som skickade ut ”Bottender” ligger samtidigt och lyssnar
efter meddelanden som börjar på ”s.i”. Den får tillbaka både meddelandet ”Bottender”
från sig själv och ”simulator” från simulatorn, men ignorerar den första eftersom den
bara lyssnar efter meddelande som börjar på ”s.i”. Simulatorns IP-adress maskas ut
från svarsmeddelandet, och sätts till TCPClientens IP-adress. På så sätt kan sedan
TCPClienten i applikationen kommunicera med simulatorn via TCP. (Se Figur 4.13) Om
ingen IP-adress erhålles antar applikationen att simulatorns applikation körs från samma
enhet som Bottender-applikationen, och sätter då TCPClientens Host till LokalHost.
Med hjälp av simulatorn kan man se hur maskinen skulle betett sig om applikationen
istället hade kopplats till styrenheten. Simulatorn kan köras från en android-enhet, och
kan då kommunicera trådlöst med hjälp av WiFi.
4
5
Transmission Control Protocol, ett dataöverföringsprotokoll / Internet Protocol.
UDP- User Datagram Protocol
Bottender
36
4.1. APPLIKATION
KAPITEL 4. RESULTAT
Figur 4.13: Via var sin UDPServer broadcastar båda applikationerna ut ett meddelande.
Först bottender-applikationen, sedan simulator-applikationen. Via svaret från simulatorn kan dess IP-adress maskas ut och sättas som TCPClientens Host. På så sätt kan
kommunikation via TCP upprättas.
Design av Delsystem 1- Applikation
Applikationen körs på en Windows-plattform och kommunicerar via en USB-kabel med
styrenheten. Applikationen kan även köras på en android-enhet och kommunicera trådlöst
via WiFi med simulatorn, som körs från en PC. All kommunikationen sker seriellt med
hjälp av virtuella com-portar (utom simulatorn som kommunicerar via TCP/IP). (Se
Figur 4.14).
I applikationen går det att välja mellan drinkar vars ingredienser sitter monterade på
maskinen, samt lägga till/ta bort och ändra recept och ingredienser. Det finns historik
över alla drinkar som någonsin startats i enheten, och statistik över populäraste drinken
just nu. Från applikationen kan com-port ändras, databasen kan tömmas eller återskapas,
och antal flaskpositioner kan ändras.
Figur 4.14: Resultat Delsystem 1- Applikation.
Bottender
37
4.2. STYRENHET
4.2
KAPITEL 4. RESULTAT
Styrenhet
Som styrenhet används ett Arduino Mega 2560- kort. Det skickar PWM-signaler till
transporteringen, strömsignaler till flödesreglaget, och tar emot kommandon från applikationen via en USB-kabel.
Kommunikation- Applikation och Styrenhet
I styrenhetens kod sköts kommunikationen via ett event kallat serialEvent(). Det triggas
för varje varv i huvudloopen. Där finns en whileloop som körs så länge Serial.available()
får in data. I whileloopen kollas det om tecknet som kommer in är ett starttecken, i så
fall väntar programmet på kommandotecknet som kommer därefter. Efter det kommer
eventuell data. Beroende på vilket kommandotecken som kommer in så hoppar programmet in i rätt ”case”. I ”caset” anropas funktionen för det som ska hända där. (Se Figur
4.15).
Figur 4.15: Bild på hur koden i styrenheten ser ut för att hantera inkommande tecken.
Bottender
38
4.3. MEKATRONIK
KAPITEL 4. RESULTAT
Design av Delsystem 2- Styrenhet
Styrenheten fungerar som ”mellanhand” mellan applikationen och maskinens olika delar
(motor, ventiler, våg). (Se Figur 4.16).
Figur 4.16: Översikt över Delsystem 2- Styrenhet.
4.3
4.3.1
Mekatronik
Transportering
Konstruktionen för transportsystemet är framtagen utifrån två aspekter, storleken på
motorn och plattformens storlek utifrån glasets bottendiameter. (Se Figur 4.17a och
4.17b).
(a) Ritning på ramverket utifrån.
(b) Bild på hur lådan ser ut inuti. Nr1 är ramverket, Nr2 är glidskenan som sitter på ramverket,
Nr3 är gildklossen som åker i gildskenan och Nr4 är var kugghjulen är placerade. Motorn driver
det kugghjul som är på botten.
Figur 4.17: Hur konstruktionen av ramverket är uppbyggt.
Motorn som används är stegmotorn 2BYGHM809 [33], vilken har en tillräcklig dragkraft
för att kunna transportera glaset. Stegmotorn är bipolär, har 400 steg/varv som gör att
den går smidigt. Stegmotor styrs lätt från styrenheten eftersom det är en digitalmotor.
Bottender
39
4.3. MEKATRONIK
KAPITEL 4. RESULTAT
Stegmotorn styrs via ett styrkort som är uppbyggt av en dubbel H-brygga. Kretsen får
sina signaler via fyra sladdar som kommer från styrenheten. (Se Figur 4.18). Styrningen
är byggt på ett L298 IC krets. Kretsen används för att stegmotorn drar mycket ström
och för att skydda styrenheten.
Figur 4.18: Elschema på stegmotor styrningen byggt från L298 IC krets [34].
Ingångarna A, B, C och D ska ha signal i form av att en är hög och resten är låga. (Se
Tabell (4.1).
Mellan varje steg är ett visst tidsintervall, ju mindre tidsintervall desto snabbare går
motorn. Om motorn går medurs med signalerna så byter den riktning om man kör
sekvensen baklänges.
Tabell 4.1: Tabellen visar hur signalen ser ut till motorstyrningen.
Bottender
40
4.3. MEKATRONIK
KAPITEL 4. RESULTAT
Design av Delsystem 3- Transportering
Transportsystemet består av ett ramverk i stål som omsluter ett system av motor, kugghjul och en kuggrem. Transportsystemet kan transportera glaset fram och tillbaka till
olika positioner. Till det används en stegmotor. Motorn är kopplad till ett av kugghjulen, som i sin tur driver runt kuggremmen. På remmen fästs en plattform där glaset kan
placeras. (Se Figur 4.19).
Figur 4.19: Systembild på hur transportsystemet fungerar.
4.3.2
Flödesreglage
För att inte behöva någon pump eller kompressor är flaskorna monterade upp och ner
på en hylla med hjälp av kardborreband. Den viktiga funktionen med hyllan är att det
ska vara lätt att byta flaskor som sitter uppe. Man ska dessutom kunna se vilka flaskor
som är uppsatta. Hyllan är konstruerad så att den är ihålig, med ett djup på ca 5 cm.
Detta för att sladdar ska kunna dras där utan att de syns. (Se Figur 4.20).
Figur 4.20: Bild på hyllan där flaskorna sitter fast med kardborreband och lysdioder
används för att simulera vätskeflöde.
Magnetventiler är inköpta och testade. Då vätska ska rinna igenom vid spänningssättning
släpps inte vätska igenom tillräckligt mycket för att det ska kunna rinna igenom i en
fin jämn stråle utan tryck i flaskan, vilket resulterar i droppande/bruten stråle. För att
kunna få ett bra resultat med hjälp av tidsmätning krävs en väldigt jämn och exakt
stråle, vilket är varför ventilerna inte är implementerade i systemet. Dessutom krävs
någon form av luftslang för att luft ska kunna komma in i flaskan när den släpper ut
vätska. Ett sätt att göra detta på utan att rengöring av slangen krävs behövs.
För att kunna demonstrera maskinen simuleras ventilerna av lysdioder. Lysdioderna
sitter på flasköppningarna likt ventilerna skulle ha gjort. De får en spänning när de ska
lysa, samt ingen spänning när de ska släckas. Då de är tända simulerar detta att en
ventil skulle ha släppt igenom vätska.
En lastcell sitter på plattformen för att kunna väga glaset med dryck i. Då vätskan har
fyllts på från en flaska vägs innehållet och värdet ska skickas till styrenheten. Lastcellen är
Bottender
41
4.3. MEKATRONIK
KAPITEL 4. RESULTAT
testad och implementerad i plattformen, men är ännu inte ihopkopplad med styrenheten.
Mellan ventilen och flaskan går det ett plaströr och i mitten av det plaströret går det
ett mindre plast rör upp i flaskan som ger luft för att det inte ska bildas något vakuum
i flaskan. (Se Figur 4.21a och 4.21b).
(a) Bild på en flaska som har en
ventil påkopplad.
(b) Bild på konstruktionen med ventil och flaska.
Styrning
Ventilen som valdes drivs av 12V och styrenheten kan bara ge en hög etta med 5V. Den
digitala signalen går igenom en transistor (Se Figur 4.22) för att styra ventilen.
Figur 4.22: Elschema på styrning av magnetventil.
Bottender
42
4.3. MEKATRONIK
KAPITEL 4. RESULTAT
Lastcell
En förstärkningskrets finns mellan lastcellen och styrenheten (Se Figur 4.23). Förstärkningen
behövs för att styrenheten ska kunna känna skillnaden mellan värdena. Lastcellen fungerar mellan 5 - 12V DC.
Figur 4.23: Elschema på förstärkning från lastcell till styrenhet via en OP- förstärkare.
Design av Delsystem 4- Flödesreglage
För att simulera hur ventilerna skulle betett sig om de var implementerade i systemet
används lysdioder som sitter på varje flasköppning. (Se Figur 4.24). Dioderna lyser/släcks
precis som ventilerna skulle ha öppnats/stängts.
En lastcell är inköpt och testad, och sitter integrerad i plattformen. Den är dock inte
ihopkopplad med styrenheten.
Figur 4.24: Översikt över flödesreglaget. Systemet visar att en lysdiod får en digital
signal för att öppna sig.
4.3.3
Plattform
En plattform är utskriven med hjälp av en 3D-skrivare. Ritningen har först tagits fram
i Catia, ett 3D-moduleringsprogram. (Se Figur 4.25).
Under plattformen sitter en lastcell som ska kontrollera vätskan i glaset när den fyllts
på. Plattformen som glaset står på och transponeras på är utskriven i en 3D-skrivare.
Den har en rektangulär yta och en tunn cirkel centrerad i mitten för att glaset ska stå
bra i mitten av plattan.
Bottender
43
4.3. MEKATRONIK
KAPITEL 4. RESULTAT
Figur 4.25: Bild på hur plattformen ser ut i Catia.
Flera små delar är utskrivna med 3D-skrivaren för att tillsammans bilda en sammankopplingsenhet mellan plattan och transportsystemet. (Se Figur 4.26).
Figur 4.26: Bilden visar hur konstruktionen är uppbyggd mellan vagn och plattform med
lastcell.
Design av Delsystem 5- Plattform
En plattform eller ”vagn” sitter fast i kuggremmen från transporteringen, och rör sig på
så sätt längst med transportsystemet. (Se Figur 4.27).
Figur 4.27: Översikt över Delsystem 5- Plattform.
Bottender
44
4.4. SYSTEMDESIGN
4.4
KAPITEL 4. RESULTAT
Systemdesign
En systemdesign har tagits fram över den färdiga prototypen. I Figur 4.28 kan man
se vissa avvikelser i jämförelse mot den ursprungliga systemskissen (se Figur 3.9 under
Metod ). Applikationen kan ange till vilken flaska glaset ska transponeras till för att rätt
drink ska framställas. Applikationen kan köras från en PC och kan kommunicera med
styrenheten via USB. Styrenheten skickar signaler till motorn och lysdioder. Den får inget
värde från lastcellen då denna ej är implementerad. Motorn transporterar plattformen
till rätt position under rätt flaska, och stannar där tills ”ventilen” är klar. Ett glas kan
transponeras mellan flaskorna utan att spilla. Ventilerna är inte implementerade utan
simuleras istället av lysdioder. Lysdioderna lyser när ventilerna skulle öppnats, och släcks
när ventilerna skulle stängts.
Prototypen är delvis moduluppbyggd, dvs. applikationen, transporteringen, flödesreglaget
och styrenheten sitter inte ihop med varandra mer än med de sladdar som kommer från
styrenheten vilka ger signaler till resterande system, samt en USB-kabel mellan PC:n
och styrenheten. (Se Figur 4.29).
Figur 4.28: Bilden visar resultatet av prototypen.
Figur 4.29: Bild på den klara prototypen.
Bottender
45
4.5. BUDGET
4.5
KAPITEL 4. RESULTAT
Budget
Här visas en tabell över den uppnådda budgeten. Det som projektet blivit sponsrat med
har uppskattats och räknats in i beräkningarna. (Se Tabell 4.2 nedan).
Tabell 4.2: Tabellen visar vad kostnaden för prototypen kostar med dess olika komponenter.
Bottender
46
4.6. TEST OCH UTVÄRDERING
4.6
KAPITEL 4. RESULTAT
Test och utvärdering
Här tas det upp hur kraven är testade, och om kraven efter testerna ansetts uppfyllda
eller inte. Siffrorna framför kraven och testerna är desamma som i Kravspecifikationen
(Appendix A).
4.6.1
Generellt
Krav/Mål- En liten uppsättning av prototypen med 5-6 flaskor ska inte kosta
mer än 5000 kr: Kontrollera budget. Kravet/målet är uppnått.
1. Prototypen ska kunna transportera en färdig drink utan att spilla: Ett glas
fyllt med vätska upp till ett finger under kanten kördes fram och tillbaka på vagnen i 5
min. Spill kontrollerades med hjälp av papper runtom. Kravet är testat och uppfyllt.
2. Användaren ska i applikationen kunna välja mellan de drinkar där ingredienser finns för tillverkning: Skapar 20 drinkar och 30 ingredienser och tilldelar
slumpmässigt drinkarna ingredienser. Kontrollerar sedan drinkarna i “Redo att startas”listan och ser så att alla dess ingredienser är monterade. Kravet är testat och uppfyllt.
3. Prototypen ska kunna göra minst två olika drinkar: Skapa ca 20 drinkar och
mäta dess ingredienser var för sig och se så att de stämmer (mängd och sort). Detta har
ej ännu kunnat testas, och är ej uppfyllt.
4. En drink ska göras under tiden: 120 sek: Testas genom att skapa 20 drinkar och
tima dem. Detta har testas utan vätska, och är uppfyllt.
4.6.2
Applikation
5. Applikationen ska kunna kommunicera med styrenheten via bluetooth:
En bluetooth-modul kopplades in i en PC, varpå en bluetooth-transceiver koppladens
in i styrenheten mot pinnarna Ground, VCC, RXD och TXD (Read och Transmitt).
Bluetooth-transceivern dök upp på PC:n som HC-06, och ett tecken testades att skickas
mellan styrenheten och PC:n. Tecknet kunde skickas fram och tillbaka. Kravet är testat
och uppfyllt (endast för PC).
6. Designen ska vara enligt standard för androidapplikationer: Applikationen
använder sig av en standardstyle för androider, samt använder standardknappar och
menyupplägg för android style. Kravet är uppfyllt.
7. Applikationens kod skriven på engelska: Applikationens kod är skriven på engelska, utom på de ställen där texten syns i applikationen. Kravet är uppfyllt.
8. Applikationen ska meddela om en flaska ska bytas: Då lastcellen ännu inte är
implementerad finns det inget sätt att veta om en flaska är tom. Kravet är inte testat
eller uppfyllt.
9. Applikationen ska meddela vid paus, fel, start, klar: Applikationen meddelar
när en drink startas och när den är klar, samt vid fel. Applikationen kan inte pausas
Bottender
47
4.6. TEST OCH UTVÄRDERING
KAPITEL 4. RESULTAT
i drinktillverkning. Detta testades genom att starta ca 20 drinkar och se att rätt kommando visades, vilket det gjorde. är testat och uppfyllt.
10. Visa valbara drinkar i en lista: Applikationen visar valbara drinkar i en lista.
Testades genom att kontrollera att drinkarnas ingredienser verkligen satt monterade.
Applikationen startades om emellan och kontrollerades igen ca 5 gånger. Kravet är testat
och uppfyllt.
11. Applikationen ska vara kompatibel med Samsung Galaxy 4 tab: Applikationen går att köra på Samsung Galaxy 4 Tab. Detta har testats genom att ladda in
programmet på en Samsung Galaxy 4 Tab, coh kontrollera så att alla funktioner fungerar
normalt. Kravet är testat och uppfyllt.
4.6.3
Styrenhet
12. Kommunicera med applikationen. (Skicka och ta emot): Kommunikation
mellan styrenheten och applikationen testades genom att skapa ett enkelt testprogram
som skickade ett tecken till applikationen, som då skulle skriva ut det tecknet i en
lista. Ett svarstecken skickades då från applikationen och skrevs ut i styrenhetens ”serial
monitor” som ingår i arduinos utvecklingsmiljö. Kravet är testat och uppfyllt.
13. PWM till transportsystemet: Testades att skicka PWM-signaler till motorn i
transportsystemet, som då körde åt ena hållet. Vid byte av sekvensen på signalerna
körde motorn åt andra hållet. Kravet är testat och uppfyllt.
14. Spänning till flödesreglage: Från styrenheten skickas spänningsignaler till de
olika flaskornas lysdioder. Detta är testat genom att kontrollera att dioderna lyser vid
rätt tillfällen när en drink skapas. Kravet är testat och uppfyllt.
15. Ta emot information från plattform: Kravet är ej testat och ej uppfyllt.
16. Omvandla värde från lastcell: Kravet är ej testat och ej uppfyllt.
4.6.4
Mekatronik
Transportering
17. Mekaniskt ihopkopplad med plattformen: Vagnen monterades på kuggremmen.
Vagnen förflyttades när remmen rörde sig. Kravet är uppfyllt.
18. Delsystem 3 ska kunna kopplas till styrenheten: Motorn som används till
transponering har testas att kopplas mot styrenheten och det fungerar. Kravet är testat
och uppfyllt.
19. Sladdar och elektronik hålls dolda: Elektronik förvaras i transportsystemet och
styrenheten med förbindelse med en kabel. Kravet är uppfyllt.
20. Plattformen ska flytta sig synkront med stegmotorn: Motorn som roterar ett
kugghjul som driver kuggremmen gör att vagnen flyttas synkront när motorn roterar.
Kravet är testat och uppfyllt.
Bottender
48
4.6. TEST OCH UTVÄRDERING
KAPITEL 4. RESULTAT
21. Motorn ska kunna rotera i både fram och backriktning: Insingnalerna till
motorstyrningen matades med olika sekvenser och motorn kunde rotera i både fram och
backriktning. Kravet är testat och uppfyllt.
22. Motorn ska kunna variera i hastighet: Motorns hastighet har testat att ändras
genom att sätta olika delays mellan signalerna som skickas till den. Ju högre delay desto
snabbare kör motorn. Kravet är testat och uppfyllt.
Flödesreglage
23. Flödesreglaget ska kunna kopplas till styrenheten: De inköpta ventilerna har
testas att kopplas mot styrenheten och de kan öppnas och stängas. Kravet är testat och
uppfyllt.
24. Systemet ska kunna kopplas till flaskor med standardstorlek på flasköppningen
(20-30 mm i diameter): Det köptes in droppkorkar som ventilen monterades på.
Droppkorken som används har testats på 5 olika tomflaskor med stor form och storleksvariation och har passat. Kravet är uppfyllt.
25. Öppna ventil vid signal: Transistor koppling på en kopplingsplatta gjordes. Ett
testprogram från Arduinokoret programmerades för att sköta styrningen. När programmet kördes öppnades och stängdes ventilerna när de skulle. Kravet är uppfyllt.
Plattform
26. Skickar information om uppmätta värden till applikationen via styrenheten: Kravet är ej testat och ej uppfyllt.
27. På plattformen ska ett vanligt dricksglas (höjd: 250mm, botten: 80mm i
diameter) kunna ställas utan att falla av under drift: Kravet har testats genom
att köra ett glas fram och tillbaka över 20 gånger. Glaset föll ej av utan stod stadigt.
Kravet är testat och uppfyllt.
28. Vagnens yta ska vara plan och “halkfri”: Kravet är uppfyllt.
4.6.5
Övriga krav
30. Modulär: Systemen sitter inte ihop med varandra förutom med olika sladdar som
går in i styrenheten. Kravet är uppfyllt.
31. Att projektet har godkänts på samtliga punkter med prioritering 1: Kravet
är ej uppfyllt.
33. Inkapslingen av elektroniken ska skydda mot direkt beröring “minst 12,5
mm”: Kontrollerat största öppningen är springan i transportsystemet på 10 mm Kravet
är uppfyllt.
34. Vid korrekt uppsättning ska inte flaskorna kunna falla ur upphängningssystemet:
Bottender
49
4.6. TEST OCH UTVÄRDERING
KAPITEL 4. RESULTAT
Flaskorna på upphängningssystemet har bytt plats och hängt flera dagar på samma plats
utan att falla. Kravet är uppfyllt.
43. Minimalt med vätskekontakt för enkelt underhåll: Metoden som valdes har
gjort att det inte finns mycket kontakt med vätska och slang eller liknande. Kravet är
uppfyllt.
44. Enkel att ta isär och sätta ihop för enkel rengöring: Om spill skulle inträffa
är det bara skruva på en skruv som sitter lättillgängligt på plattformen. För att sedan
lyfta bort locket och göra rent inuti. Kravet är uppfyllt.
Bottender
50
Kapitel 5
DISKUSSION
Analys av resultat
Prototypen är inte helt färdig då ventilerna inte är implementerade så en fullständig
slutsats kan inte lämnas. De resultat som finns ser lovande ut. Testkörning av transportsystemet ser bra ut, och de flesta av applikationens funktioner är klara. Alla funktioner
som krävs för tillverkning av en drink är helt klara.
Valet att programmera i Delphi var i princip redan bestämt vid starten av projektet,
då dataingenjören i projektteamet önskade vidareutveckla sina kunskaper i Delphi. En
diskussion uppstod då opponenter menade på att detta är ett förlegat och utdöende
språk. Vi mailade därför Embarcadero och frågade dem om detta var sant, och fick ett
långt mail som svar på detta. Svarsmailet finns att läsa i Appendix D.
Fördelar med vår prototyp gentemot de liknande produkter som tagits upp i rapporten
är framförallt att vår produkt inte har någon stor ram runt sig, vilken innebär att den
är lättare att passa in på ställen som inte har mycket utrymme. Det går dessutom att
hänga upp den på väggen, så att ingen bar eller bänkutrymme behövs över huvud taget.
Detta är något som ingen liknande produkt kan.
En annan stor fördel är att antalet flaskor kan varieras. Strukturen på applikationen ger
vidareutvecklare stor möjlighet till att bygga ut och ändra programmet. Allt i koden är
skrivet för att underlätta vidareutveckling. Att användaren direkt i applikationen kan
utöka eller minska antalet flaskor som kan ingå i systemet är något nytt. Detta öppnar
dessutom upp för möjligheten att produkten i framtiden skulle kunna säljas som en
utbyggbar produkt, d.v.s. att användaren kan köpa till tilläggsdelar såsom fler ventiler,
längre eller böjt transportsystem, mixer, ismaskin eller liknande.
Till skillnad från många andra produkter använder vi oss av magnetiska ventiler där de
flesta andra använder mekaniska ventiler. Detta är antagligen eftersom mekaniska ventiler ofta är billigare, och, vilket vi upptäckt nyligen, enklare att få att fungera korrekt. Mekaniska ventiler kanske hade varit ett bättre val, då de som sagt kan bli förhållandevis billiga och det nog hade varit lättare att sälja dem som tillägg till maskinen om användaren
vill utöka produkten. Dock så hade det sett bättre ut med magnetventiler.
Ett stort misstag var att inte beställa ventilerna tidigare in i projektet, då leveransen
tog väldigt lång tid, och första gången var ventilerna som kom inte särskilt bra för vårt
51
KAPITEL 5. DISKUSSION
ändamål. Detsamma gäller egentligen alla komponenter, beställningar borde gjorts så
fort som möjligt för att vara säkra på att det blir som man tänkt sig.
Det var svårare att införskaffa magnetventiler än vi hade trott från början. Vi försökte
hitta billiga magnetventiler att köpa i Sverige men de vi hittade kostade runt 1000 kr st
och om de hade använts hade prototypens pris gått upp avsevärt. Ventilerna beställdes
därför från Kina, vilket resulterade i en lång leveranstid.
För att kunna få en fungerade produkt även utan helt fungerande ventiler användes lysdioder för att simulera ventiler. Detta gjorde det möjligt att mer utförligt testa systemet
trots avsaknaden av ventilerna.
Resultatet landade inte långt ifrån hur tanken var från början att det skulle bli. Ett
misstag var att inte avgränsa prototypen mer, då det var väldigt många delar som skulle
göras samtidigt enligt ganttschemat (Se Appendix E).
Tidsuppfattning
Tiderna har inte stämt helt med uppskattade tider, t.ex. drog motorstyrningen ut mycket
på tiden, och applikationen tog längre tid än förväntat att göra, då ingen av oss har
hanterat databaser innan. Det tog mycket tid att få grepp om hantering av databasen
samt hur den skapas från applikationen. Mer tid än planerat har lagts på projektet, ca
100 timmar extra.
Många saker i projektet påverkades av den tidsbrist som uppstod drygt i mitten av
projektet. Då motorstyrningen tog väldigt mycket oväntad tid bestämde vi oss för att
”avgränsa” oss från trådlös kommunikation mellan applikation och styrenhet, samt från
att använda en lastcell för vägning av vätskan, då maskinen kan fungera även utan dessa.
Analys av budgeten
Priset har hållits nere utan att påverka kvalitén på prototypen för mycket. Från början
kopplades en egen H-brygga ihop för att spara pengar, men då vi led av tidsbrist och
kortet inte skulle hinna etsas ut köptes istället en färdig shield in som enkelt kopplades
ihop med Arduinon. Kortet kostade därför ca 150 kr mer än vad det hade gjort med det
egna kortet.
Det hade behövts tittas mer på olika sätt att tillverka ramverket på. Kanske finns det ett
ännu billigare alternativ vad gäller material. Den ram som användes användes framförallt
eftersom Berghems Mekaniska AB sponsrade med den.
Om vi hade fått ventilerna att fungera som tänkt hade en helt fungerande prototyp
funnits med en total kostnad under 5000 SEK. Projektgruppen är nöjd med hur pass
modulär prototypen blev, då detta förmodligen kommer hjälpa till med vidareutveckling
av prototypen.
För att lyckas med att göra en bättre prototyp ville gruppen från början ha en till medlem eftersom projektet var stort. Tanken var att den medlemmen skulle fokusera mer
på de olika elektriska lösningarna som gruppen nu har lagat mycket tid på. Exempel var
när motorstyrningen skulle tas fram. Alla komponenter köptes in för att sedan lödas fast
på ett kretskort som skulle konstrueras av gruppen själv. Vid uppkoppling mot en kopp-
Bottender
52
KAPITEL 5. DISKUSSION
lingsplatta blev det fel och motorn betedde sig inte som den skulle. När problemet var
fixat var det försent att göra kretskortet och en färdig shield var tvungen att införskaffas.
Efter att kursen är färdig så kommer vi forsätta med att arbeta för att få ihop en riktigt
bra prototyp. Det finns en del pengar kvar som vi kan utnyttja från Almi för att testa
andra idéer och få prototypen snyggare och ännu bättre. Vi är dock nöjda med resultatet
och är motiverade att fortsätta med dess utveckling!
Bottender
53
KAPITEL 5. DISKUSSION
Bottender
54
Kapitel 6
SLUTSATS
Projektet har visat att det går att ta fram en drinkplandarmaskin som kostar mindre
än 5000 kr för komponenter. Detta då den har möjlighet till sex stycken olika flaskor.
Prototypen som har tagits fram har uppskattats till en komponentkostnad runt 3000 kr.
Applikationen som har utvecklats till maskinen har funktionalitet för att starta en drink,
lägga till recept och ingredienser samt tömma eller återskapa databasen. Det finns funktioner för att välja mot vilken COM-port applikationen ska kopplas, samt om den istället
ska kopplas till en tillhörande simulator. Antalet flaskpositioner kan utökas/minskas i
applikationen.
Maskinen är modulär på det sättet att den består av olika delar som inte sitter ihop
med varandra förutom de spänning- och signalsladdar som går in i styrenheten. Maskinen består av fyra stora delar. Mekatronik delen som består av ett transportsystem, en
upphängnongsanordning och ett flödesreglage bestående av en ventil per flaska. Styrenheten innefattar ett arduinokort som fungerar som mellanhand mellan applikation och
resten av maskinen. En applikationen fungerar som användargränssnitt.
Eftersom det är uppbyggt på detta sätt så är det relativt enkelt att byta ut olika delar
och lägga till nya om man skulle vilja.
Tre stora saker som gör att maskinen skiljer sig mot andra produkter som gruppen har
jämfört med är att den inte är i någon ram, utan mer modulär. Den använder sig av
elektriska ventiler istället för mekaniska, en applikation som gör att användaren kan
bestämma hur många flaskor som finns monterade om man skulle vilja lägga till fler.
Uppbyggnaden av en hel maskin från grunden har gett mycket lärdom. Från applikation
till rörliga delar med mikrokontrollerstyrning. Det har ingått många nya komponenter
som gruppen inte har arbetat med innan.
Från alla avgränsningar som gjorts så kan man alltid bygga vidare på de för att få
en mer avancerad maskin. Priset kommer öka med fler funktioner och hjälpmedel. Det
gäller då att hitta en balans för pris och funktion. Exempel på vidareutveckling är bl.a.
att maskinen skulle kunna använda fler vagnar för att göra flera drinkar samtidigt. En
station som lägger is i glaset och en annan station som lägger till lime i glaset skulle
kunna implementeras. Applikationen kan också vidareutvecklas genom en databas som
55
KAPITEL 6. SLUTSATS
möjliggör för olika användare och delning av recept på nätet. En funktion som hjälper
en genom att säga vilka flaskor som ska bytas för att göra en viss drink hade varit bra
att ha.
Figur 6.1: Skriven av Mattias Sjögren, Mekatronikingenjör och Camilla Lenfors, Dataingenjör.
Bottender
56
Litteratur
[1]
Barobot. Barobot source repository. Kontrollerad: 2015-06-03. code.google.com.
url: https://code.google.com/p/barobot/.
[2]
Diffen. Bluetooth vs. Wi-Fi. Kontrollerad: 2015-06-03. www.diffen.com. url: http:
//www.diffen.com/difference/Bluetooth_vs_Wifi/.
[3]
Karl Nikka Emil. Hur funkar det? 408-409. 2013.
[4]
Diffen. Bluetooth vs. Wif. Kontrollerad: 2015-06-03. www.diffen.com. url: http:
//www.diffen.com/difference/Bluetooth_vs_Wif.
[5]
OmWLAN. Vad alla borde veta om WiFi. Kontrollerad: 2015-06-03. omWLAN.se.
url: http://www.omwlan.se/artiklar/wifi.aspx.
[6]
Bradley Mitchell. What is the Range of a Typical Wi-Fi Network? Kontrollerad: 2015-06-03. About.com. url: http : / / compnetworking . about . com / cs /
wirelessproducts/f/wifirange.htm.
[7]
Phil Belanger. 802.11n Delivers Better Range. Kontrollerad: 2015-06-03. WiFiPlanet, Quinstreet Enterprise. Maj 2007. url: http://www.wi-fiplanet.com/
tutorials/article.php/3680781.
[8]
Arduino. What is Arduino? Kontrollerad: 2015-06-03. Arduino. url: http://www.
arduino.cc/.
[9]
Electro:kit. Arduino. Kontrollerad: 2015-06-03. Electrokit Sweden AB. url: http:
//www.electrokit.com/arduino.html.
[10]
James Bruce. Arduino vs Raspberry Pi: Which Is The Mini Computer For You?
Kontrollerad: 2015-06-03. MakeUseOf. Maj 2013. url: http://www.makeuseof.
com/tag/arduino- vs- raspberry- pi- which- is- the- mini- computer- foryou/.
[11]
Brad Bourque. Arduino vs. Raspberry Pi: Mortal enemies, or best friends? Kontrollerad: 2015-06-03. Digital Trends. Mars 2015. url: http://www.digitaltrends.
com/computing/arduino-vs-raspberry-pi/.
[12]
Merriam-webster. engine. Kontrollerad: 2015-06-03. Merriam-Webster, Incorporated. url: http://www.merriam-webster.com/dictionary/engine.
[13]
Learn Engineering. DC Motor, How it works? Kontrollerad: 2015-06-03. LearnEngineering.org. Sept. 2014. url: https : / / www . youtube . com / watch ? v =
LAtPHANEfQo.
[14]
Mario Salutskij. Elmotorn – så fungerar den. Kontrollerad: 2015-06-03. Bonnier
Tidskrifter AB. Febr. 2014. url: http://teknikensvarld.se/elmotorn- safungerar-den-116707/.
57
LITTERATUR
LITTERATUR
[15]
biowiki. The Boyer Hypothesis. Kontrollerad: 2015-06-05. biowiki.ucdavis.edu. url:
http://biowiki.ucdavis.edu/@api/deki/files/313/A02rotorstator.gif.
[16]
The free encyclopedia Wikipedia. Stepper motor. Kontrollerad: 2015-06-03. en.wikipedia.org.
Maj 2015. url: http://en.wikipedia.org/wiki/Stepper_motor.
[17]
Drivteknik.nu. PRINCIP - STEGMOTOR. Kontrollerad: 2015-06-03. Drivteknik.nu.
url: http://www.drivteknik.nu/skolan/motor/stegmotor.
[18]
Alexan e. How do I know whether a circuit (originally for 5 wire) will work for four
wire stepper motor? Kontrollerad: 2015-06-03. electronics.stackexchange.com. Dec.
2013. url: http://electronics.stackexchange.com/questions/94734/howdo- i- know- whether- a- circuit- originally- for- 5- wire- will- work- forfour-wire.
[19]
wikipedia. H-brygga. Kontrollerad: 2015-06-05. sv.wikipedia.org. April 2014. url:
http://sv.wikipedia.org/wiki/H-brygga.
[20]
bmanishap. Solenoid Valves. Kontrollerad: 2015-06-05. oktober 2012. url: https:
//www.youtube.com/watch?v=9dqpmg7mz44.
[21]
LAUMAS Elettronica. Single-point load cell / aluminum. Kontrollerad: 2015-06-05.
www.directindustry.com. url: http://www.directindustry.com/prod/laumaselettronica/product-39615-964223.html.
[22]
Kjell Company. Avståndssensor. Kontrollerad: 2015-06-03. Kjell Company. url:
http://www.kjell.com/sortiment/el/elektronik/mikrokontroller/arduino/
avstandssensor-p87891#ProductDetailedInformation.
[23]
The Inebriator - Jake. The Inebriator- Arduino powered cocktail machine. Kontrollerad: 2015-06-03. www.theinebriator.com. Maj 2014. url: http://www.theinebriator.
com/.
[24]
Party Robotics. Kontrollerad: 2015-06-03. Party Robotics Store. 2015. url: http:
//partyrobotics.com/.
[25]
Embarcadero. The Fastest Connected App Platform for Windows and Beyond.
Kontrollerad: 2015-06-03. Embarcadero Technologies, Inc. url: http : / / www .
embarcadero.com/products/delphi.
[26]
Embarcadero. The FireMonkey Framework in RAD Studio- The multi-device, true
native app platform. Kontrollerad: 2015-06-03. Embarcadero Technologies, Inc.
url: https://www.embarcadero.com/products/rad-studio/firemonkey.
[27]
Developer.android.com. Saving Data in SQL Databases. Kontrollerad: 2015-06-03.
developer.android. url: http://developer.android.com/training/basics/
data-storage/databases.html.
[28]
Mikael Antonsson. Martin Lindahl. Anders Lundström. Patrik Rodstedt. Byggnation och programmering av ett datorstyrt bordshockeyspel. Kontrollerad: 2015-0708. http://smarp.zoomy.org/bordshockey/rapport.pdf. pp. 16-17. 2008.
[29]
vega. Dosör standard. Kontrollerad: 2015-06-04. www.vega-direkt.se. url: http://
www.vega-direkt.se/glas/allt-for-baren/dosorer/dosor-standard.html.
[30]
ESSKA. 2/2-vägs magnetventil - vatten hydraulolja - 0 till 35 bar - mässing. Kontrollerad: 2015-06-04. www.esska.se. url: http://www.esska.se/esska_se_s/
2/2-vaegs-magnetventil-vatten-hydraulolja-0-till-35-bar-maessing207219101003-13420.html.
Bottender
58
LITTERATUR
LITTERATUR
[31]
Kabetex AB. Kabetex kunskap - din trygghet! Kontrollerad: 2015-06-03. Kabetex
AB. url: http://www.kabetex.se/.
[32]
W. Richard Stevens. TCP/IP Illustrated. Kontrollerad: 2015-07-06. 16:de upplagan. Reading : Addison-Wesley. pp. 169-173. Vol. 1 2000.
[33]
Elektro:kit. Stegmotor 400 steg/varv bipolär. Kontrollerad: 2015-06-03. Electrokit
Sweden AB. url: http://www.electrokit.com/stegmotor- 400- steg- varvbipolar.49047.
[34]
Lewis Loflina. Connecting the Arduino to a L298N H-Bridge. Kontrollerad: 201506-05. www.bristolwatch.com. url: http : / / www . bristolwatch . com / L298N /
L298N_arduino.htm.
Bottender
59
LITTERATUR
Bottender
LITTERATUR
60
Kapitel 7
BILAGOR
Appendix A- Kravspecifikation
Appendix B- Databas
Appendix C- Kraftuträkning
Appendix D- Brev från Embarcadero
Appendix E- Ganttschema
61
Bottender
1
Bottender
APPENDIX A
KRAVSPECIFIKATION Bottender
Version 1.1
Status
Granskad
Godkänd
2
Bottender
PROJEKTIDENTITET
VT2015
Bottender
Högskolan i Halmstad, IDE
Namn
Ansvar
Telefon
E-post
Mattias Sjögren
076-1705269
Sjomat10@student.hh.se
Camilla Lenfors
070-358 96 68
camlen12@student.hh.se
Kursansvarig
: Björn Åstrand, Björn.astrand @hh.se
Handledare:
Stefan Byttner, Hassan Mashad Nemati.
DOKUMENTHISTORIK
Version
Datum
Utförd förändring
Utföra av
1.0
2015.02.17
Första utkastet
Grupp
1.1
2015.05.09
Andra utkastet
Grupp
Granskad
3
Bottender
1
INLEDNING
Denna kravspecifikation redogör för en
prototyp
som ska kunna blanda drinkar enligt önskemål,
med andra ord en drinkblandarmaskin.
Prototypen
ska kunna användas som ett redskap för
bartenders eller som underhållning samt redskap för privatpersoner.
Prototypen
är en maskin som via kommandon från en applikation blandar en färdig drink åt
användaren. Id
én
till detta projekt kommer framförallt från diskussioner om att det tar alldeles för
lång tid att beställa sin drink i barer och på krogar. Om man dessutom sätter sig i bartenderns
situation så kan det vara väldigt stressigt i vissa situationer.
Det finns redan många varianter
av
en sådan produkt, men det är sällan, om ens någonsin, man
faktiskt ser en sådan användas i vardagen. Detta kan bero på att de ofta är väldigt stora och
otympliga, men framförallt eftersom de kan vara dyra att producera.
Tanken med denna produkt är att den till skillnad från många av de redan existerande liknande
produkterna ska vara så billig som möjligt att producera, samt att den ska vara modulbaserad.
Detta eftersom den då kommer att vara enklare att integrera i barer och liknande. Även i de barer
med lite utrymme ska det gå att enkelt finna utrymme åt maskinen.
Kraven i detta dokumentet beskrivs enligt tabellen nedan. Den första rutan beskriver kravets
nummer. Den andra rutan beskriver kravets status, den kan vara original, reviderad och utgånget.
Den tredje rutan ger en kort beskrivning av kravet. I den sista rutan ges en prioritet mellan 1-5, där
1 har högst prioritet.
Krav nr.
Förändring
Kravtext för krav
Prioritet.
1.1 Parter
Projektet är en egen idé och det finns därför ingen kund eller beställare. Handledare för projektet
är Stefan Byttner och Hassan Mashad Nemati. Utförare av projektet är Camilla och Mattias från
IDE-sektionen med inriktningarna data- och mekatrionikingenjör.
1.2 Syfte och mål
Syftet med produkten är att minska kötider i barer och restauranger samt underhålla väntande
kunder. Produkten ska fungera som ett hjälpmedel till bartendern, genom att blanda simplare
drinkar medans bartendern fokuserar på annat.
Målet är att få fram en fungerande prototyp som kan blanda minst 2 olika drinkar i tid till Utexpo.
4
Bottender
1.3 Användning
Produkten ska användas av bartenders, restaurangpersonal eller privatpersoner för att underlätta
arbetet att göra en drink.
2
ÖVERSIKT AV SYSTEMET
2.1 Grov beskrivning av produkten
P
rototypen
är
en drinkmaskin som ska vara moduluppbyggd. Alla delar i systemet styrs från en
styrenhet. Kortet får kommandon från en applikation. I applikationen ska man kunna välja vilken
slags drink man vill ha. Efter att en drinks ha valts så sätts systemet igång. Ett glas förflyttas mellan
olika flaskor med ett transportsystem. Glaset fylls på med de olika vätskor som receptet från
drinken säger därefter är programmet färdigt. Se Figur 1.
Figur 1.
Översikt över hela systemet. Via en applikation på en androidenhet skickas instruktioner till ett mikrokontrollerkort som
sedan skickar vidare nödvändig information till ventiler, motor och övriga delar såsom lampor, våg mm.
5
Bottender
2.2 Produktkomponenter
Till prototypen kommer följande komponenter behövas:
○
○
○
○
○
○
○
○
Applikation som gränssnitt mot användaren.
Bluetoothtransciever för kommunikation mellan applikation och mikrokontrollerkort.
Styrenhet som gränssnitt mellan applikation och övriga delsystem.
Transporteringssystem för glas eller vätska.
Ventiler samt kork-konstruktion för kontroll avflödesgenomströmningen.
(Våg för kontroll av vätskemängd i glas.)
Belysning.
Upphängningssystem för flaskor.
2.3 Beroende till andra system
○ 50 Hz 230V standard svenskt eluttag.
○ En Androidenhet.
2.4 Ingående delsystem
1.
APPLIKATION
2. STYRENHET
3. TRANSPORTERING
4. FLÖDESREGLA
GE
5. PLATTFORM
2.5 Avgränsningar
o
Ismaskin
.
o
D
atabas för lagring av recept.
o
Effektkontoll.
o
Mixer.
o
ID-kontroll
o
Extern kylbehållare för alkoholfria drycker.
o
Fler vagnar för snabbare resultat.
o
Inloggning för personlig sida.
6
Bottender
o
Enklare påbyggnadsansatser.
2.6 Designfilosofi
P
rototypen ska vara lätt att sätta upp och en liten uppsättning med 5-6 flaskor ska inte kosta mer
än
50
00 kr. Det ska vara lätt att byta och fylla på en existerande flaska.
Systemet ska var modulärt,
och bestå av separata delar som är enkla att byta ut
.
2.7 Generella krav på hela systemet
1
Utgått
2015.05.09
Prototypen ska kunna transportera en färdig drink utan
att spilla.
1
1
Reviderat
Prototypen ska kunna transportera en färdig drink utan
att spilla.
2
2
Original
Användaren ska i applikationen kunna välja mellan de
drinkar där ingredienser finns för tillverkning.
4
3
Original
Prototypen ska kunna göra minst två olika drinkar.
1
4
Utgått
En drink ska göras under tiden: 60 sek
3
4
Reviderat
2015.05.09
En drink ska göras under tiden: 120 sek
3
3
DELSYSTEM 1 - APPLIKATION
För att kommunicera med själva maskinen behövs en applikation som kan "prata" med
styrenheten. Applikationen öppnas och hanteras av en användare, som då kan ange vilken drink
som ska produceras, eller ställa in vilka flaskor som för tillfället finns i flaskstället. Se Figur 2.
Figur 2.
Översiktsbild över Delsystem 1, Applikation. En användare startar applikationen från en androidenhet (alternativt en dator),
och kan sedan i applikationen välja önskad dryck. Instruktioner skickas sedan vidare till Delsystem 2, Arduinokortet.
7
Bottender
3.1 Inledande beskrivning av delsystem
Delsystem 1 består av en Android-applikation
.
Applikationens syfte är att visa användaren en lista
med alla drinkrecept, så att användaren kan välja vilken drink som ska göras. Olika listor över
recept ska kunna visas och tillverkningsprocessen ska kunna startas från applikationen.
3.2 Gränssnitt
5
Original
Applikationen ska kunna kommunicera med delsystem 2 via
bluetooth.
1
3.3 Designkrav
6
Original
Designen ska vara enligt standard för androi
d
applikationer.
2
7
Original
Applikationens kod skriven på engelska.
1
3.4 Funktionella krav för delsystem
8
Original
Applikationen ska meddela om en flaska ska bytas.
3
9
Original
Applikationen ska meddela vid paus, fel, start, klar.
1
10
Original
Visa valbara drinkar i en lista.
1
11
Original
Applikationen ska vara kompatibel med samsung 4 tab.
1
8
Bottender
4
DELSYSTEM 2 - MIKROKONTROLLERKORT
Skickar signaler till Delsystem 3 och 4. Tar emot en signal från Delsystem 5. Se Fi
gur 3.
Figur 3.
Delsystem får via trådlös kommunikation instruktioner från en applikation. Beroende på instruktionerna skickar sedan
styrenheten PWM-signaler till Delsystem 3, en signal till Delsystem 4 eller en strömsignal till Delsystem 5.
4.1 Inledande beskrivning av delsystem
Styrenheten i Delsystem 1 ska skicka PWM-signaler till Delsystem
3.
Det ska även skicka en
strömsignal till Delsystem 4. Styrenheten ansluter till Delsystem 1 via trådlös kommunikation.
4.2 Gränssnitt
12
Original
Kommunicera med
D

elsystem 1. (Skicka och ta emot)
1
13
Original
PWM till
Delsystem
3

.
1
14
Original
Spänning till
Delsystem
4.
1
15
Original
Ta emot information från
Delsystem
5.
5
4.3 Funktionella krav för delsystem
16
Original
Omvandla värde från lastcell.
5
9
Bottender
5
DELSYSTEM 3 - TRANSPORTERING
Transportsystemet ska transportera glaset till vätskan eller vätskan till glaset. Delsystemet
tar emot
signaler
från Delsystem 2. Se Figur 4.
Figur 4.
Delsystem 3 får en signal från styrenheten.
5.1 Inledande beskrivning av delsystem
Delsystemet tar emot PWM signaler från Delsystem 2.
5.2 Gränssnitt
17
Original
Mekaniskt ihopkopplad med Delsystem 5.
1
18
Original
Delsystem 3 ska kunna kopplas till Delsystem 2.
1
Sladdar och elektronik hålls dolda.
3
5.3 Designkrav
19
Original
5.4 Funktionella krav för delsystem
20
Original
Delsystem 5 ska flytta sig synkront med stegmotorn.
1
21
Original
Motorn ska kunna rotera i både fram och backriktning.
1
22
Original
Motorn ska kunna variera i hastighet.
2
10
Bottender
6
DELSYSTEM 4 - FLÖDESREGLAGE
Flödesregla
g
et ska öppna och stänga flödet av vätska från en flaska.
Figur 5.
Delsystem 4 får en konstant spänningssignal från Delsystem 2, vilket får ventilen att öppnas för vätskegenomströmmning.
6.1 Inledande beskrivning av delsystem
Delsystemet får signal ifrån Delsystem 2 i f
or
m av on/off. Medan signalen är på on ska vätska
flödas igenom. När signalen slås om till o
ff
ska vätskeflödet strypas.
6.2 Gränssnitt
23
Original
Kopplas till Delsystem 2.
1
Systemet ska kunna kopplas till flaskor med standardstorlek
på flasköppningen(
20-30
mm i diameter).
1
6.3 Designkrav
24
Original
6.4 Funktionella krav för delsystem
25
Original
Öppna ventil vid signal.
1
11
Bottender
7
DELSYSTEM 5 - PLATTFORM
Detta Delsystem ska monteras på Delsystem 3. Systemet ska vara en “vagn” där ett glas ska
placeras. Med hjälp av delsystem 3 ska glaset åka mellan olika positioner och samla upp vätskor.
På transportplattformen ska eventuellt en våg vara integrerad så att den uppsamlade vätskan kan
vägas och kontrolleras. Se Figur 5.
Figur 6
. Delsystem 3 transporterar Delsystem 5 till olika positioner. En lastcell i Delsystem 5 tar emot från och skickar information till
Delsystem 2.
7.1 Inledande beskrivning av delsystem
När ett glas är placerad på transport plattformen så kan plattformen föras till en position med
hjälp av Delsystem 3. Positionen den ställs på ska vara under en flaska så att glaset kan ta emot
vätskan som kommer därifrån. Vågen på plattformen ska kontrollera om den vätska som kommer
ner i glaset överensstämmer med det förväntade resultatet från Delsystem 2.
7.2 Gränssnitt
26
Original
Skickar information om uppmätta värden till Delsystem 1 via
Delsystem 2.
5
På delsystemet ska ett vanligt dricksglas (höjd: 250mm, botten:
80mm i diameter) kunna ställas utan att falla av under drift.
1
7.3 Designkrav
27
Original
7.4 Funktionella krav för delsystem
28
Original
Vagnens yta ska vara plan och “halkfri”.
1
12
Bottender
8
KRAV PÅ VIDAREUTVECKLING
29
Original
Dokumentation, källkod, produktskisser, komponentlista ska finnas.
1
30
Original
Modulär.
3
9
31
TILLFÖRLITLIGHET
Original
Att projektet har godkänts på samtliga punkter med prioritering 1.
1
Varje student skall lägga minst 20h/vecka.
1
10 EKONOMI
32
Original
11 KRAV PÅ SÄKERHET
33
Original
Inkapslingen av elektroniken ska skydda mot direkt beröring “minst
12,5 mm”.
1
34
Original
Vid korrekt uppsättning ska inte flaskorna kunna falla ur
upphängningssystemet.
2
12 LEVERANSKRAV OCH DELLEVERANSER
35
Original
Samtliga punkter med prioritering 1 ska vara uppfyllda vid leverans.
1
13 DOKUMENTATION
36
Original
Projektet dokumenteras under arbetets gång och skall underlätta för
framtida projekt och vidareutveckling.
1
13
Bottender
14 UTBILDNING
37
Original
Ingen specifik utbildning krävs för användaren.
38
Original
Ingen specifik utbildning krävs för installeraren.
39
Original
För utvecklaren krävs goda programmeringskunskaper.
1
40
Original
För utvecklaren krävs goda kunskaper inom elektronik
och mekatronik.
1
15 KVALITETSKRAV
41
Original
Slutlig produkt testas enligt testplan.
2
42
Original
Varje delsystem testas enligt testplan.
2
16 UNDERHÅLLSBARHET
43
Original
Minimalt med vätskekontakt för enkelt underhåll.
2
44
Original
Enkel att ta isär och sätta ihop för enkel rengöring.
1
14
APPENDIX B- DATABASMODELL
APPENDIX C- KRAFTRÄKNING
APPENDIX DBREV FRÅN EMBARCADERO
Brev från Embarcadero
Från: Malin Lagerquist [mailto:malin@alfasoft.se]
Skickat: den 9 april 2015 15:02
Till: Camilla Lenfors
Ämne: Delphi på skolorna
Hej Camilla,
Det verkar som att det tagit fart på Embarcadero med dina frågor, de är i full färd med att
försöka ta fram ett whitepaper men det lär ju ta lite tid innan det är klart.
De har tipsat om dessa böcker så länge.
Sen skriver Stephen så här
We certainly have a large number of delphi developers globally.
Despite the lack of focus around education Glenn and I have managed to get a deal done
with the schools in South Africa where we provide free Delphi (even if it is an older
version) to enable the language to be learned by what we would see as GCSE level
computer science students. This is seen 10,000+ students in the last 2 years work with
Delphi. We also have a big presence in Russia and Brazil in the education areas.
Object Pascal is a fantastic teaching language, recognised world over for its fit in
education. However we are “fighting” against Microsoft (C#) in this space who are pumping
more money than we earn probably as a company in education alone, also joining that
fight is Google (python). While neither language are as suited for education, the free
training and help that teachers are getting is making them the choice to go for. In addition,
C# developers are easy to find, thus making the jobs out there targeted to those people,
which means it seems like there are fewer jobs and thus becomes a downward spiral.
Interestingly C# and Delphi are from the same original “farther” so to speak, a Dane,
Anders Hejlsberg. There are a lot of similarities in the languages, its just Delphi / Object
Pascal is a better teaching language than C#. C# however is a lot easier than C/C++ to
learn.
In terms of the development team, we have a bigger team now than when Delphi 1 was
launched, (that’s not a dying language) we have year over year growth in developer
numbers since Embarcadero purchased the tools from Borland (again, that’s not a dying
language!)
Hoppas att det är till någon nytta!
Mvh Malin
Med vänliga hälsningar / Kind regards,
Malin Lagerquist
License Specialist
APPENDIX E
GANTTSCHEMA Camilla Lenfors & Mattias Sjögren
Besöksadress: Kristian IV:s väg 3
Postadress: Box 823, 301 18 Halmstad
Telefon: 035-16 71 00
E-mail: registrator@hh.se
www.hh.se