IMPLEMENTERING AV ETT PICK-TO-LIGHT SYSTEM I UTBILDNINGSMILJÖ FÖR LEAN
IMPLEMENTATION OF A PICK-TO-LIGHT SYSTEM IN A LEAN EDUCATIONAL ENVIRONMENT
Examensarbete inom huvudområdet Prodktionsteknik
Grundnivå G1E, 15 Högskolepoäng Vårtermin 2020
Axel Engblom
Handledare: Martin Birtic
Examinator: Magnus Holm
Sammanfattning
Högskolan i Skövde har köpt in ett Pick-to-Light system från Binar som skall användas i
utbildningssyfte. Pick-to-Light är ett hjälpmedel vid detaljplockning som visar operatören vilken detalj som skall plockas med hjälp av lampor. Genom användning av ett Pick-to-Light system kan
operatören minska risken för misstag och spara tid i produktionen och öka kvalité.
Information om hur implementeringen av Pick-to-Light systemet har tagits fram. Ett program för att styra lamporna och läsa av sensorerna har programmerats. PDCA (plan-do-check-act) samt en mall för projektledning har använts för att strukturera upp projektet. PDCA användes främst under programmeringen. Genom samtal med handledare har en lösning som alla parter kommit överrens om tagits fram och systemet monterades i utbildningsmiljön.
Några få körningar gjordes utan Pick-to-Light systemet för att fastställa en tid innan implementering.
Det visade sig att när Pick-to-Light systemet användes förbättrades inte tiden för monteringen men det var lättare att komma ihåg momenten då plockordningen sköttes av systemet. Även några studenter testade systemet och de ansåg att arbetet blev lättare.
Det finns fortfarande vissa förbättringar som kan göras på Pick-to-Light systemet. Till exempel finns det en verktygshållare som kan installeras. Det kan också programmeras för att hantera dynamiska plockinstruktioner med hjälp av en streckkodsläsare eller QR-koder.
Systemet som implementerades har ett fungerande felmeddelande och är konfigurerbart genom en textfil. Systemet har även ett fungerande användargränssnitt som tillåter operatören att starta, pausa, stoppa samt hoppa mellan sensorerna för att lösa diverse problem som kan upptså. Systemet kan utvecklas vidare i framtiden då alla delar som medföljde inte användes.
Abstract
The University of Skövde has purchased a Pick-to-Light system from Binar that will be used for educational purposes. Pick-to-Light is an aid in part picking that shows the operator which part to pick with the help of lights. By using a Pick-to-Light system, the operator can reduce the risk of mistakes and save time in production and increase quality.
Information on how the Pick-to-Light system was implemented has been written. A program for controlling the lights and reading the sensors has been programmed. PDCA (plan-do-check-act) and a template for project management has been used to structure the project. PDCA was mainly used during programming. Through conversations with supervisors, a solution that all parties have agreed on has been developed and the system was installed in the educational environment.
A few runs were made without the Pick-to-Light system to determine a time before implementation.
It turned out that when the Pick-to-Light system was used, the time for assembly did not improve, but it was easier to remember the steps when the picking order was handled by the system. Some students also tested the system and found it made picking parts easier.
There are still some improvements that can be made to the Pick-to-Light system. For example, there is a tool holder that can be installed. It can also be programmed to handle dynamic picking
instructions using a barcode reader or QR codes.
The system that was implemented has a working error message and is configurable through a text
file. The system also has a working user interface that allows the operator to start, pause, stop, and
jump between the sensors to solve various problems that may arise. The system can be further
developed in the future as not all parts that came with it were used.
Intyg
Denna uppsats har lämnats in av Axel Engblom till Högskolan i Skövde som uppsats för erhållande av betyg för på grundnivå G2E inom huvudområdet Produktionsteknik.
Undertecknande intygar härmed att allt material i denna uppsats som inte är resultatet av eget arbete har redovisats med källangivelse. Uppsatsen innehåller inte heller material som
undertecknande redan tidigare fått tillgodoräknat sig inom sina akademiska studier.
...
Signatur
...
Namnförtydligande
Axvall 2021-01-22
Institutionen för Ingenjörsvetenskap
Innehållsförteckning
Sammanfattning ii
Abstract ii
Intyg iv
Innehållsförteckning v
Figurlista vi
1. Inledning 1
1.1 Bakgrund 1
1.2 Problembeskrivning 1
1.3 Mål 1
1.4 Avgränsningar 1
1.5 Översikt 2
2. Teoretisk Referensram 3
2.1 LEAN Production 3
2.1.1 LEAN Bakgrund 3
2.1.2 Poka Yoke 3
2.1.3 Plan Do Check Act (PDCA) 4
2.2 PICK-Chart 5
3. Produktionssystem och Miljö 7
3.1 Montering 7
3.2 Pick-to-Light 7
4. Mjukvara Error! Bookmark not defined.
4.1 Python 8
4.2 Pascal 8
4.3 REST API 8
4.4 JSON 9
5. Metod 10
5.1 Övergripande Tillvägagångssätt 10
5.2 Tillvägagångssätt 11
5.2.1 Initieringsfasen 11
5.2.2 Planeringsfasen 11
5.2.3 Genomförandefasen 13
5.2.4 Avslutningsfasen 24
6. Resultat 25
6.1 Implementation 25
6.2 Programmet 25
6.3 Före Pick-to-Light 25
6.4 Efter Pick-to-Light 25
7. Diskussion 27
7.1 Problemlösningen 27
7.2 Teknologi, Samhälle och Miljö 27
7.3 Framtida Utveckling 28
8. Slutsats 29
Referenser 30
Bilagor 31
Bilaga 1. Arbetsgång och tidsplan 31
Bilaga 2. Kod för Pick-to-Light systemet 34
Bilaga 3. Installations Instruktioner för Pick-to-Light systemet 37
Bilaga 4. Kopplingsschema Pick-to-Light system 38
Figurlista
Figur 1 En USB kabel (Zomer 2018) ... 4
Figur 2 PDCA Cykel Fritt tolkad från Bicheno & Holweg(2016) av Axel Engblom ... 5
Figur 3 Exempel på en PICK Chart Fritt tolkad från Peterson, Johansson, Broman, Blücher & Alsterman (2009) av Axel Engblom ... 6
Figur 4 Projektmodellen som användes, baserad på Willaume Andersson & Catics(2014) modell. Fritt tolkad av Axel Engblom ... 10
Figur 5 WBS för projektets genomförande ... 13
Figur 6 PICK-Chart över olika programmeringsspråkl ... 14
Figur 7 Pascal fördelar och nackdelar ... 14
Figur 8 Python fördelar och nackdelar ... 15
Figur 9 Flödesschema för programmets gång ... 16
Figur 10 Station 4 före implementering av Pick-to-Light ... 17
Figur 11 Variabler för att skicka och ta emot JSON information ... 19
Figur 12 Användargränssnitt för Pick-to-Light Programmet. ... 20
Figur 13 Kod för att hämta information från sensorer ... 21
Figur 14 Station 4 efter Pick-to-Light systemet är implementerat ... 23
1. Inledning
Det inledande kapitlet ger en bakgrund till projektet och en problembeskrivning samt en
framläggning av arbetets syfte och mål. Inledningen innehåller också de avgränsningar som gjorts utifrån tillgång till tid samt tillgång till verktyg att arbeta med.
1.1 Bakgrund
Högskolan i Skövde (HIS) använder sig av ett trampbilslabb för att undervisa studenter som går utbildningar och kurser inom produktionsområdet. Studenter får montera ihop dessa trampbilar och det utbildningsmiljö främst undervisar studenter om är LEAN. Där kan de lära sig om hur de kan jobba bort och minska slöseri för att få en effektiv produktion genom att använda sig av olika LEAN verktyg till exempel PDCA och poka-yoke. Det finns lådor som innehåller allt montagematerial för monteringen av trampbilarna vid olika stationer. Genom att implementera ett Pick-to-Light system till vissa av dessa lådor vill HIS kunna utöka möjligheterna för lärare och studenter att lära sig och förstå mer om förbättringsverktyg och effektivisering i ett produktionsscenario.
1.2 Problembeskrivning
Fram tills nu har HIS endast använt sig av instruktioner på papper för att plocka detaljer för monteringen av trampbilar samt hur instruktioner för hur dessa detaljer skall monteras på
trampbilarna. Nu har HIS köpt in ett verktyg till en utbildningsmiljö som kallas för Pick-to-Light och det måste implementeras i utbildningsmiljön. Det finns sju stationer i utbildningsmiljön som utför montering av trampbilarna, en av stationerna kommer bli huvudfokus för det här arbetet och det är station fyra. Systemet som skall implementeras innehåller en styrlåda från Binar Elektronik, 18 sensorer med lampor samt en verktygshållare, alla sensorer kommer inte att användas. Det finns ett äldre Pick-to-Light system som kan komma att användas ifall det skulle visa sig för svårt att
implementera det nya systemet.
1.3 Mål
Målet är att implementera ett konfigurerbart Pick-to-Light system på en av stationerna i en utbildningsmiljö där studenter plockar komponenter från en materialfasad och monterar.
Instruktioner för användning och konfigurering av systemet skall skrivas.
1.4 Avgränsningar
Den fysiska implementeringen av systemet begränsas huruvida det finns en plan från lärare om hur system skall användas i utbildningssituationen. Det finns ett bestämt antal komponenter som kan utnyttjas. Dokumentationen kommer endast innehålla instruktioner om hur operatör kör
programmet samt hur operatören ställer programmet.
1.5 Översikt
Rapporten innehåller en teoretisk referensram som innehåller information om LEAN och de begrepp inom LEAN som är aktuella för projektet, en informationsdel om produktionsmiljö och system och en informationsdel om mjukvaran som kommer användas. Det går att läsa om metoden som användes samt hur projektet har gått till, specifikt beskrivs design, programmering och implementations faserna i detalj. I resultatkapitlet finns information om resultatet av programmeringen och
information om hur implementationen gick. Till sist går det att läsa diskussionen samt slutsatsen.
2. Teoretisk Referensram
Teori som är aktuell för projektet finns beskrivet i referensramen. Kapitlet innehåller teori om LEAN Production, PDCA, poka-yoke och PICK-Chart.
2.1 LEAN Production
2.1.1 LEAN Bakgrund
Utan att veta det har Henry Ford använt sig av LEAN production sedan han började tillverka bilar på löpande band. En av Fords visioner var att ha bra kvalitet från början genom flertalet kontroller utmed hela produktion. Detta gav Ford ett övertag mot sina konkurrenter. Ford använde sig även av det vi känner till idag som Just-in-Time produktion (JIT) genom att varje arbetare skulle ha färre uppgifter att göra och inte ha för stora lager. Ford lyckades minska tiden det tog att producera en bil från 728 minuter till 93 minuter. Trots att Ford använde sig av alla dessa metoder var det Toyota som skapade och gav LEAN sitt namn på 1990-talet(Peterson, Johansson, Broman, Blücher & Alsterman, 2009).
Enligt Dennis (2015) var de Problem som uppstod i masstillverkning att arbetare inte ville jobba.
Kvalitén sänktes eftersom arbetarna inte var med och organiserade produktionen och
kvalitetskontroller efter slutet av produktionen blev en standard. Maskiner blev större och dyrare och företagen ville inte att de skulle stå stilla. Detta ökade produkter-i-arbete (WIP) och stora lager med färdiga produkter. Masstillverkning ledde till ingenjörer som inte pratade med varandra. Det ledde till ökad tid för en produkt att komma från designstadiet till produktion.
Genom användning av LEAN Production kan företag arbeta sig runt dessa problem. LEAN jobbar mot kontinuerliga förbättringar i tre områden, minska slöseri, öka värde och förbättra hur människor är inblandade. Det krävs att företag använder sig av något från alla tre delar för att LEAN skall överleva.
Fokus kan variera beroende på vilken del som anses vara mest viktig (Bicheno & Holweg 2016).
2.1.2 Poka Yoke
Poka yoke är en samsättning av de japanska orden ”poka” som betyder ”oavsiktliga fel” och
”yokerie” som betyder ”att undvika” (Binar Elektronik AB 2014). Poka yoke handlar om att felsäkra, vilket innebär att hitta lösningar som gör det svårt för operatören att göra fel. Genom att använda sig av olika sätt för att varna när något har gått fel till exempel ljud och ljus blir det lättare för
operatören att uppmärksamma problem (Liker 2004). I Figur 1 går det att se ett exempel på poka
yoke, en Universal Serial Bus (USB) kabel kan endast stoppas in i ett uttag på ett sätt.
Figur 1 En USB kabel (Zomer 2018)
Ett exempel på ett Poka yoke system är Pick-to-Light som använder sig av lampor, sensorer och knappar för att instruera operatören vad som skall göras i vilken ordning. Genom att använda dessa ett system såsom Pick-to-Light kan operatören minska risken för att välja fel del under monteringen och således minska risken för att förstöra något. När operatören skall plocka en detalj lyser en lampa vid detaljen. När operatören har plockat detaljen kan en sensor känna av att operatören har plockat detaljen eller finns en tryckknapp där operatören får bekräfta att detaljen har plockats. Om
operatören skulle göra fel kan lamporna ställas in på ett sådant sätt att programmet avbryts, lamporna lyser rött och programmet felet behöver bli bekräftat innan programmet kan gå vidare till nästa instruktion.
2.1.3 Plan Do Check Act (PDCA)
Plan Do Check Act (PDCA) också känt som Demings hjul är ett verktyg för att kunna genomföra förbättringsarbeten på ett strukturerat och planerat sätt. En tolkning av Demings hjul kan studeras i Figur 2. Översatt till svenska betyder det planera, genomföra, följa upp och agera. I planeringssteget gäller det att identifiera vad det är som behöver göras och tidsplanen för att utföra detta. Det är viktigt att ställa upp klara mål för att kunna lyckas. När planeringen är slutförd går cykeln över till nästa steg vilket innebär implementering av lösningarna vilket borde vara rätt fram förutsatt att första steget utfördes korrekt.
Nästa steg är det mest kritiska, följa upp eller kontrollera. Här skall det genomförda arbetet kontrolleras för att kunna se hur det gick och om något behöver förändras. Genom att kontrollera och lära sig vad som funkade och inte funkade ökar chansen för nästa cykel av PDCA att lyckas bättre.
Sista steget som heter agera innebär att all information från de föregående stegen skall tas till vara
på och det skall bestämmas om det skall standardiseras eller justeras. Det är viktig att inte fastna i
det som standardiserats och vara kvar i det hela tiden, det gäller att vara flytande och inte vara rädd
för förändring förutsatt att det leder till något bättre.
Cykeln kan upprepas flertalet gånger för att nå det resultat som eftersträvas (Bicheno & Holweg 2016).
Figur 2 PDCA Cykel Fritt tolkad från Bicheno & Holweg(2016) av Axel Engblom
2.2 PICK-Chart
PICK chart är en modell som skapats av Martin Lockheed där PICK är en förkortning för Possible, Implement, Challange och Kill. Med hjälp av en PICK chart går det att bedöma svårighetsgraden av ett projekt jämfört med effekten av projektet (Peterson, Johansson, Broman, Blücher & Alsterman, 2009).
En PICK chart är uppbyggd av fyra rutor, Possible, Implement, Challange och Kill och kan studeras i Figur 3. En stor fördel med PICK chart är att den ger ett strukturerat stöd för att kunna diskutera fram rätt prioriteringar. Om implementationen skulle medföra hög lönsamhet och lätt svårighetsgrad bör den placeras i Implement rutan varpå det går att sätta igång arbetet med implementeringen direkt.
Däremot om implementationen skulle medföra låg lönsamhet och svår svårighetsgrad bör den
placeras i Kill rutan varpå det går att avfärda implementeringen direkt. Challange och Possible kan
båda vara möjliga implementeringar men de skall prioriteras efter Implement implementationerna är
genomförda (Peterson, Johansson, Broman, Blücher & Alsterman, 2009).
Figur 3 Exempel på en PICK Chart Fritt tolkad från Peterson, Johansson, Broman, Blücher & Alsterman (2009) av Axel Engblom
Svår Kill Challange
C/C++
Javacript
Golang Java
TypeScript Pascal
Possible Implement
Python
Lätt
Låg Fördelar Hög
PICK-Chart val av programmeringsspråk implementering av Pick-To-Light
Svårighetsgrad
3. Produktionssystem och Miljö
Kapitel 3 innehåller information om montering eftersom detta är det som utförs i utbildningsmiljön samt Pick-to-Light då arbetet handlar om att implementera ett sådant system i utbildningsmiljön.
3.1 Montering
Inom monteringsindustrin är monteringen betydande värdeadderande arbete. Montering beskrivs enligt National Encyklopedin (u.å.) som den del av processen där arbetaren sätter ihop många olika delar till en hel produkt. Ett exempel på montering kan vara utbildningsmiljön på HIS. Där finns det olika stationer där studenter får installera olika delar av trampbilarna. Vid varje station finns det detaljer, verktyg och instruktioner som studenter får följa som hjälp vid monteringen.
3.2 Pick-to-Light
Ett Pick-to-Light system även kallat Pick-by-Light, fungerar genom användning av lampor i olika färger för att ge operatören möjlighet att enkelt se vart denne skall plocka delar ifrån. Det finns en display för att visa antalet delar som operatören skall plocka. Genom att installera ett Pick-to-Light system kan ett företag försäkra sig om att det minskar risken för att operatören skall göra misstag under plockningssekvens av tillverkningen. (Murray 2018) Vissa Pick-to-Light system kräver att operatören bekräftar att delen har plockats genom att trycka på en knapp på enheten andra system har en sensor som känner av när operatören har fört in sin hand för att plocka delen (Guo et al. 2013).
Till projektet finns ett Pick-to-light system från Binar Elektronik AB som kommer används som referens för beskrivning av hur ett Pick-to-light system fungerar. I systemet finns det en
kontrollenhet (LP306) som tar emot och skickar signaler. Det finns sensorer (LP305) som bekräftar att en detalj har plockats samt en hållare för verktyg (LP115) (Binar Elektronik AB 2016).
Programmet läses in genom en dator som kör en drivrutin för kontrollenheten. Programmet säger till kontrollenheten vilka av lamporna som lyser när. När programmet har startats kommer en lampa att lysa, när lampan lyser är detaljen redo att plockas. När detaljen har plockats bekräftas det genom en sensor som släcker lampan och tänder nästa lampa. När alla detaljer har plockats startas
programmet om (Binar Elektronik AB 2016). Hur ett enkelt Pick-to-Light system ser ut kan ses på
Figur 14 i kapitel 5.2.3.3.
4. Utvecklingsmiljö
Eftersom projektet till stor del kommer handla om programmeringen av programmet för systemet kommer här kort information om programmeringsspråk och Application Programming Interface (API) som användes för att programmera.
4.1 Python
Python skapades på slutet av 1980-talet och är ett generellt programmeringsspråk och används av flera olika stora bolag för att skapa sina program. Några som är värda att nämna är Instagram, Netflix, Spotify, Facebook och Google. Python har en enkel syntax vilket gör det lättare att läsa, skriva och lära sig. Tack vare den enkla syntaxen och att det är ett universellt språk leder detta till att det går att bygga nästan vilken funktionalitet som helst och det kan göras fort. Eftersom det är ett populärt språk finns det mycket information att tillgå. (Wasilewski 2019)
4.2 Pascal
Pascal är ett procedurellt programmeringsspråk som skapades på tidigt 1970-tal av Niklaus Wirth.
Pascal har använts för att skapa applikationer såsom Skype, Total Commander och Apple Lisa. Det är ett språk som är lätt att lära sig och är strukturerat. Pascal är utvecklat för att lära ut programmering systematiskt där implementationerna kunde vara både pålitliga och effektiva. (Tutorialspoint u.å.)
4.3 REST API
REST är en förkortning av Representational State Transfer och API är en förkortning av Application Programming Interface. En API kan liknas vid en kypare på en restaurang, där du beställer något och kyparen skriver ner det och kommer tillbaka med det du beställt.
REST API är ett sätt att bygga ett API som utnyttjar de smarta funktioner som redan finns i HTTP.
REST baseras på samma grund som HTTP, det använder sig av URI (Uniform Rescource Identifier ofstast kallat webbadress.) och ett verb. Ett exempel på REST API kan vara
http://localhost:8080/rest/binar/get/modules där ”get” är verbet och ”modules” är vad som skall hämtas. Innehållet som kan läsas är oftast i formaterat i JSON eller XML. (NewSeed u.å.)
Webbadressen är det du beställer och det kyparen hämtar kan läsas nedan:
{"MacIds":[{"MacId":"8010B3","Type":"LP306",
"Inputs":[{"Idx":0,"Data":0},{"Idx":1,"Data":0},{"Idx":2,"Data":0},{"Idx":3,"Data":0}],
"Outputs":[{"Idx":0,"Data":0},{"Idx":1,"Data":0},{"Idx":2,"Data":0},{"Idx":3,"Data":0}],
"Serial":[{"Idx":0,"Data":0 }]}
4.4 JSON
JavaScript Object Notation oftast kallat JSON är ett format för att utbyta data. Formatet gör det enkelt för människor att läsa och skriva samtidigt som det är enkelt för maskiner att parsa
1och generera. JSON använder sig av en syntax som är välkänt för programmerare som har erfarenhet av C, Java, Python och många andra språk. På grund av detta är JSON ett idealt språk för syftet. (JSON u.å.)
1 ” Försvenskning av engelska parsing; to parse – att parsa – uppdelning av något i mindre delar varefter delarna sedan gås igenom systematiskt, en i taget.” (idg.se u.å.)
5. Metod
5.1 Övergripande Tillvägagångssätt
Metoden som har valts att följas är baserad på en projektmodell som skapats för Dekra(Andersson Willaume & Catic 2014). Projektmodellen bygger på att enklare utföra produktionstekniska projekt på ett strukturerat sätt genom att använda sig av fyra faser, initieringsfasen, planeringsfasen, genomförandefasen och avslutningsfasen. Metoden har valts eftersom den ansågs passa bra in på projektet och det var enkelt att ändra metoden för att passa bättre in i projektet. Några delar har tagits bort samt att design, programmering och implementering har lagts till för att metoden skall passa bra in på projektet. Dessa tre delar har lagts till i genomförandefasen. De delarna som togs bort var de som ansågs vara överflödiga för projektet, till exempel risk & lönsamhetsanalys, då skolan redan hade köpt in systemet. Projektmodellens flöde kan studeras i Figur 4.
Figur 4 Projektmodellen som användes, baserad på Willaume Andersson & Catics(2014) modell. Fritt tolkad av Axel Engblom
I initieringsfasen skapas en uppfattning på projektets omfattning, projektets mål beskrivs, kartläggning av tidigare erfarenheter, utreda projektets risker samt, utreda projektets lönsamhet (Andersson Willaume & Catic 2014). Initieringsfasen kan till den största delens överföras till projektet men kommer utelämna risk- och lönsamhetsanalyserna då dessa inte har någon påverkan på
projektet som utförs, samt kartläggningen av tidigare erfarenheter utelämnas.
I planeringsfasen utses en projektledare, intressenters behov och intresse på projektet tas fram, en tidsplan skapas med eventuella milstolpar, resursbehov utreds efter tidsplaneringen och en
projektgrupp skapas. (Andersson Willaume & Catic 2014) Från denna fas kommer intressenternas behov tas fram och en tidsplan kommer läggas upp. Eftersom projektet utförs av en person kommer denne att agera som alla delar i projektet tillsammans med hjälp från handledare.
I genomförandefasen utförs statusuppdateringar på projektet, projektets status uppföljs angående tid, ekonomi och teknik och åtgärder för eventuella avvikelser hittas (Andersson Willaume & Catic 2014). Från den här fasen kommer alla delar användas, däremot kommer kommunikationen att föras med handledare istället för projektledare.
I avslutningsfasen skall det kontrolleras att projektets information och dokumentation finnas lagrade, samt en rapport skall skrivas om hur projektet har gått (Andersson Willaume & Catic 2014). Dessa delar kommer att användas där rapporten kommer bli det läsaren kan läsa i de nästkommande delarna och dokumentation kommer delas med till ansvariga på HIS där projektet utförs.
Andersson Willaume och Catics projekt är inget som kommer föras över direkt till det här projektet.
Vissa delar kommer bli utelämnade på grund av att de inte går att tillämpa till projektet som utförs. I
genomförandefasen kommer även design, programmering och implementation att läggas till på grund av att de är avgörande för projektets resultat.
Under programmeringen kommer PDCA vara till stor hjälp för att metodiskt kunna ta projektet till nästa steg. Det kommer vara många små varv runt PDCA hjulet för att strukturerat kunna eliminera felen som kan uppstå under programmeringen.
5.2 Tillvägagångssätt
5.2.1 Initieringsfasen
Diskussioner fördes med projektets handledare om vilka mål och begränsningar som skulle finnas för projektet. Det mål som fastställdes var att ett Pick-to-Light system från Binar skulle implementeras i utbildningsmiljön för att lära studenter om Pick-to-Light samt att instruktioner för användning skulle skrivas. Detta mål togs med handledare på HIS för att utvärderas tillsammans med utrustningen som fanns tillhanda hos handledaren. Denna diskussion ledde till att målet för vad som behövde göras blev klarare och vissa avgränsningar sattes på plats. Övergripande mål kan läsas i kapitel 1.3 och avgränsningar kan läsas i kapitel 1.4. Utöver målen som ställdes upp tillsammans med handledare delades det största målet upp i mindre mål för att enklare kunna problemet.
Implementera ett Pick-to-Light system från Binar (Huvudmål) o Samla bakgrundsinformation om Pick-to-Light
o Samla information från handledare om systemets placering och funktion o Samla information om systemet
o Planera implementationen av systemet o Programmera systemet
o Testa systemet innan montering o Montera systemet
o Testa systemet på plats
Skriva en instruktionsmanual (Huvudmål)
Lämna över dokumentation och program
5.2.2 Planeringsfasen
En tidsgräns till vecka 43 sattes upp eftersom undervisning skulle bedrivas samma vecka i
utbildningsmiljön. Om programmet och implementeringen var färdig så skulle elever kunna testa systemet för att säkerställa systemets funktion.
Mål för implementeringen ställdes upp för att enklare kunna röra sig framåt i projektet. Dessa mål
kan studeras i tabell 1. Programmeringen beräknades ta sex veckor och implementationen tre
veckor. Eftersom extra sensorer fanns kunde programmeringen göras delvis samtidigt som
implementation då viss utrustning kunde monteras innan allt var färdigt, till exempel sensorer.
Tabell 1 Plan för implementeringen Plan För Implementeringen
Steg Huvudmål Delmål Planerad färdig
1 Programmera Hämta och skicka JSON information V.18 2 Programmera Tända och släcka gröna lampor V.19
3 Programmera Avläsa sensor V.20
4 Programmera Tända röda lampor vid fel V.21
5 Programmera Skapa ett användargränssnitt V.23 6 Testa Tända olika lampor och utlösa rätt sensor V.23 7 Testa Tända lampor och utlösa fel sensor V.23
8 Montera Montera lister V.22
9 Montera Montera sensorer på lister V.22
10 Montera Koppla ihop alla sensorer med kablar V.22 11 Montera Koppla ihop sensorer med styrenheten V.23 12 Montera Koppla ihop styrenhet med dator V.23 13 Montera Koppla in styrenhet i eluttag V.23 14 Testa Tända lampor och utlösa rätt sensor V.23 15 Testa Tända lampor och utlösa fel sensor V.23 16 Testa Utför en komplett montering av trampbilen V.23
En WBS ställdes upp och kan studeras i Figur 5. Där har de stora delarna av projektet lagts fram i
ordningen som de skall göras. WBS är uppställt för det nya systemet då detta har fler delmoment
som behöver göras för att bli klar med projektet.
Figur 5 WBS för projektets genomförande
5.2.3 Genomförandefasen 5.2.3.1 Design
I Tabell 2 kan en matris över alla delar som ingick till systemet studeras. Ingen dokumentation som förklarar hur systemet skall programmeras och hur det kommunicerar fanns med. Genom kontakt med Binar skickades dokumentation som beskriver hur ett program kommunicerar med
huvudenheten. På LP306 finns det en ingång för en strömkabel, en utgång för sensorer, fyra utgångar för övriga I/O-enheter samt en ingång för en seriell-enhet. I Figur 14 i kapitel 5.2.3.3 kan delarna studeras monterade på ställningen.
Tabell 2 Matris över delar till Binar Pick-to-Light
Del Antal Funktion
LP306 1 Huvudenhet(Kopplas till PC genom USB)
LP350 18 Sensorer
LP125 1 Verktyghållare
M12 Connector 1 Kopplar LP306 till LP350
IDC Connector 6 Koppla ihop 2 rader med LP350
Terminator 1 Sitter i slutet av kopplingen efter LP350
IDC Kabel 6 Koppla M12 connector till LP350 samt mellan LP350 IDC Ändkabel 4 Kopplar ihop IDC connector med varandra
M12 Kabel 3 Koppla LP306 till M12 Connector eller enheter som använder M12
Binar Pick-To-Light
För att bestämma vilket språk som skulle användas användes först en PICK-chart (Figur 6) för att ge en översikt över olika val som fanns att tillgå. De förslagen som plockades var baserades på
informationen som fanns att tillgå från tidigare projekt, programmeringsspråk där mycket tillgång till hjälp finns samt baserat på tidigare erfarenhet av språken.
Figur 6 PICK-Chart över olika programmeringsspråkl
Det fanns tillgång till ett program som var skrivet i Pascal för att testa utgångarna på huvudenheten.
Programmet hade behövts skrivas om för att det skulle uppfylla funktionskraven. Eftersom ingen tidigare erfarenhet fanns i Pascal ledde detta inte till någon större fördel för att använda Pascal som programmeringsspråk.
Lite erfarenhet fanns i språket Python men det skulle innebära att ett helt nytt program skulle behöva skrivas för att kunna utföra uppgiften. Det lutade åt att programmeringen skulle ske i Python men för och nackdelar ställdes upp för att göra valet lite klarare (Figur 7 & Figur 8).
Figur 7 Pascal fördelar och nackdelar
Svår Kill Challange
C/C++
Javacript
Golang Java
TypeScript Pascal
Possible Implement
Python
Lätt
Låg Fördelar Hög
PICK-Chart val av programmeringsspråk implementering av Pick-To-Light
Svårighetsgrad
Figur 8 Python fördelar och nackdelar
Med Python och Pascal jämnförda beslutades det att programmeringen skulle ske i Python. Det finns stora tillgångar till hjälp då Python är ett mer använt språk och det är många av de som
programmerar kan språket. Det är ett väldigt populärt språk eftersom det är enkelt att lära sig då det använder sig av en enkel syntax och Python är ett språk som kan användas till mycket (Eastwood, 2020). Detta ansågs leda till en större chans att lyckas med projektet och var grunden för valet.
Ett flödesschema ställdes upp för att enkelt kunna följa vad programmet skall göra. Flödesschemat
tillsammans med en beskrivning av flödets gång kan studeras i Figur 9.
Figur 9 Flödesschema för programmets gång
I utbildningsmiljön finns det sju stationer som alla har olika delar att montera på trampbilarna.
Stationerna är placerade i formen av ett U och när en station är färdig med sitt moment av monteringen flyttas bilen fram till nästa station för nästa moment i monteringen.
Stationen som syns i Figur 10 är station fyra och den stationen valdes för implementationen baserat på att det är den station med flest detaljer att plocka och det är en station där alla delar används i monteringen. I stationen finns det sju olika detaljer som skall plockas. De fem översta små blå lådorna innehåller de små delarna som skall plockas, det är dessa delar som kommer ha mest användning av Pick-to-Light systemet eftersom de är små och svårare att urskilja från varandra jämfört med ratten (den lite större blå lådan) och rattstången (de genomskinliga lådorna på golvet till vänster). De andra stationerna har färre detaljer att plocka och vissa stationer har dynamiska
plockinstruktioner, vilket innebär att det inte alltid är samma delar som skall monteras. Stationen valdes också på grund av att den ligger i nära anslutning till efterkommande station och på så sätt kan systemet utökas till den stationen i framtiden. Station fyra är idag fri från tekniska hjälpmedel likaså är alla andra stationer. Nere till vänster i Figur 10 finns det två genomskinliga plastlådor som kommer ersättas av en plastlåda som kommer få plats i materialfasaden som implementeras. Den syns i Figur 14 i kapitel 5.2.3.3 och är den blå plastlådan nere till vänster.
Figur 10 Station 4 före implementering av Pick-to-Light
5.2.3.2 Programmering
Styrenheten och alla sensorer har egna MacIDn (enhetens unika nummer). På styrenheten fanns MacID skriven och för de enskilda sensorerna krävdes det att informationen hämtades från en REST API. För att hämta alla MacIDn användes programmet Postman. I Postman går det enkelt att skicka REST kommandon för att hämta ut data. MacIDn är skriva som hexadecimala tal och behövde konverteras till vanliga decimaltal för att kunna programmeras. Ett Exceldokument skapades för att enkelt kunna ställa upp alla MacIDn och dessa blev även märkta på sensorerna själva för att
underlätta inför senare programmering av systemet. I tabell 3 kan de uppställda macIDn studeras.
Tabell 3 MacIDn uppställda i en tabell
När alla macID var fastställda kunde test av funktioner börja, på alla sensorer finns det en lampa som lyser när sensorn är utlöst samt en lampa som kan lysa i olika färger beroende på vad den skall ha för funktion. Genom att skicka instruktioner till alla sensorer i Postman och starta lampan samt föra en hand över sensorn och läsa resultatet fastställdes det att sensorn kunde skicka och ta emot signaler.
När det var säkert att alla sensorer funkade som utlovat kunde arbetet gå vidare till nästa del i projektet.
Variabler skapades för att skicka en begäran till API. Variablerna kan ses i Figur 11 och dessa är inte kompletta utan de sätts ihop för att skapa en hel adress som automatiskt skickas till webbläsaren för att hämta JSON informationen. För att hämta information behövs först adressen som är ”main_api”
och sen behöver vi välja vart vi ska hämta informationen från och där finns två val, ”call_api” eller
Nummer Hex Dec Märkt Test
LP306 801B10 8395536 X
1 800257 8389207 X X
2 800435 8389685 X X
3 80040F 8389647 X X
4 8002AC 8389292 X X
5 8002B4 8389300 X X
6 8004FD 8389885 X X
7 80022E 8389166 X X
8 800280 8389248 X X
9 8002A9 8389289 X X
10 8002E1 8389345 X X
11 80030B 8389387 X X
12 800311 8389393 X X
13 800312 8389394 X X
14 80031F 8389407 X X
15 800350 8389456 X X
16 800366 8389478 X X
17 80037B 8389499 X X
18 8002B2 8389298 X X
MacAdress
”call_api_spec”. ”call_api” hämtar alla enheter som är kopplade till huvudenheten och
”call_api_spec” tillsammans med en macID hämtar specifik information från en av enheterna som är kopplad till huvudenheten.
Figur 11 Variabler för att skicka och ta emot JSON information
Underprogram skapades för att skicka och ta emot information till och från sensorerna samt tända och släcka lampor. Exempel på ett av dessa underprogram finns i kapitel 5.2.3.2 Figur 13.
Programmet följer flödesschemat som finns i Figur 9 i kapitel 5.2.3.1 och användargränssnittet kan
studeras i Figur 12. Sekvensen startas när operatören trycker på ”Run Program” i programmet. Först
läser programmet av en textfil för att veta vilka lampor som skall tändas i vilken ordning. Den första
gröna lampan kommer att tändas som i sin tur väntar på en signal från sensorn. När operatören
plockat detaljen och utlöst sensorn kommer den gröna lampan att släckas och nästa gröna lampa i
ordningen tänds. Programmet kan pausas för att fylla på detaljer genom att Trycka på ”Pause
Program” i programmet och startas igen genom att trycka på ”Resume Program”. Om operatören
skulle plocka fel detalj i ordningen och utlösa fel sensor kommer programmet att skicka en felkod
som gör att alla lampor blinkar rött tre gånger. Programmet återställer sig från felet automatiskt. Om
operatören behöver göra en ändring i plocksekvensen görs detta genom att stoppa programmet
genom att trycka på ”Stop Program” och ändra en textfil som programmet läser av för att veta vilka
lampor som skall tändas i vilken ordning. Om det skulle bli något fel och operatören behöver byta
lampa som lyser görs det genom ”Skip Sensor” knappen som hoppar fram en lampa i taget i
sekvensen.
Figur 12 Användargränssnitt för Pick-to-Light Programmet.
En väntetid på en sekund (sleep (1) i koden) lades till innan nästa sensor kan bli utlöst eftersom programmet avläser sensorerna för snabbt och de utlöser felkoden innan operatören har hunnit ta bort handen efter att ha plockat detaljen. Detta gör att operatören inte kan plocka detaljerna lika snabbt som tidigare men det var något som krävdes för att programmet skulle funka. Efter väntetiden lades till var det inga problem med att hinna plocka detaljerna utan att felkoden hann utlösas. Tiden på en sekund valdes inte på några speciella grunder. Det gjordes endast ett test för att säkerställa att operatör hinner föra in handen, plocka en detalj och sen ta ut handen igen utan att felkoden skall utlösas. Det funkade bra när systemet testades och det upplevdes inte att det skapade några onödiga väntetider. Försök gjordes att koppla bort den senast tända sensorn men det skapade problemet att ifall den senast använda sensorn blev utlöst funkade inte felkoden.
Varje gång något skall programmeras används en kort PDCA cykel. Där planering sker av önskad funktion. Utförande av programmeringen sker. Kontroll, fick vi önskad funktion eller behöver vi tänka om för att det vi önskar skall ske. I sista steget bestämmer vi om vi skall ha kvar det som det var om önskad funktion är uppnådd eller om det skall justeras för att fungera på ett bättre eller annorlunda sätt. Här nere kommer ett exempel på en PDCA cykel för programmeringen.
Plan: Programmet skall hämta data från sensor för att veta om det är utlösta.
Do: Programmera för att uppnå önskad funktion.
Check: Kom data in i programmet som tänkt?
Act: Skall sättet som data hämtas från sensor användas eller går det att göra det på ett bättre sätt eller kom data inte in i programmet och det behöver justeras för att data skall kunna avläsas?
Det här var ett simpelt exempel på en PDCA cykel som var ständigt återkommande under
programmeringen och ofta tog det flera försök för att lyckas hämta eller skicka bara en liten bit
information. Genom exemplet blev till slut koden som kan ses i Figur 13. Där ett underprogram har
skapats för att hämta information från sensorerna. Först skickas JSON koden för att hämta
informationen, informationen formateras sedan om för att bli läsbar sedan väljs den relevanta informationen ut och i detta fall lämnar programmet en etta eller nolla. På så sätt kan programmet avgöra om sensorn har blivit aktiv och kan avgöra om den skall släcka lampan och gå vidare till nästa instruktion eller om den skall hålla lampan tänd till operatören har plockat detaljen.
Figur 13 Kod för att hämta information från sensorer
5.2.3.3 Implementationen
När programmeringen var klar testas systemet utan att monteras för att säkerställa önskad funktion.
Detta gjordes genom att använda samma program som skapats men färre sensorer är kopplade till styrenheten. När en lampa tändes fördes handen över sensorn för att utlösa den. Testet
genomfördes med färre sensorer på grund av sättet som programmet är uppbyggt på. Det innebär
att det inte påverkas av hur många sensorer som är inkopplade. Om sensorn utlöstes och nästa
lampa i ordningen tändes fungerade programmet som önskat. Även felkoden som programmerades
testades genom att medvetet föra handen över fel sensor och kontrollera att alla lampor tändes
röda. Testprotokollet som skapades och följdes finns i tabell 4.
Tabell 4 Testprotokoll för Pick-to-Light Systemet
Testprotokoll Pick-to-Light System
Steg Test Avklarat
1 Starta program på datorn enligt manualen x
2 Säkerställ att små LED på sensorerna lyser
ett fast skenx
3 Starta programmet GoKart-PTL x
4 Säkerställ att macIDn är inskrivna i dokumentet Sensorer.txt x 5 Starta programmet genom att trycka på Run Program i GoKart-PTL x 6 För hand över sensor som lyser grönt, upprepa tills alla sensorer har testats. x 7 Tryck på knappen Pause Program i GoKart-PTL, för hand över sensor och händer inget
så är programmet pausat.
x
8 Tryck på Resume Program i GoKart-PTL, Säkerställ att programmet körs genom att föra hand över sensor som lyser. Hoppar den till nästa sensor i sekvensen körs programmet igen.
x
9 Tryck på knappen Skip Sensor i GoKart-PTL för att hoppa till nästa sensor i sekvensen. x 10 Tryck på Knappen Stop Program och lampa skall slocka. (Återställer programmet) x 11 Starta programmet igen genom att trycka på Run Program i GoKart-PTL x 12 När lampa är tänd för hand över sensor för att säkerställa felmeddelandets funktion.
Röda Lampor skall tändas och släckas.
x
När funktionen av systemet var säkerställt kunde montering på materialfasaden ske. Listerna
monterades alla sensorer kopplades ihop med huvudenheten. I Figur 14 kan det monterade systemet studeras när det står på plats med allt inkopplat. Huvudenheten finns i den ljusblå cirkeln i Figur 14.
Sensorerna är det som finns i de röda cirklarna i Figur 14. och i de gröna cirklarna finns de omkopplare som används.
På de två större lådorna som står längst ner på bilden krävs det att operatören för handen över
sensorerna för att utlösa dem eftersom sensorn pekar uppåt. På grund av det ändå hade krävts en
manuell utlösning av sensorerna. Detta eftersom räckvidden på sensorerna inte är mer än tio
centimeter och positionen på lådorna gör att det är mer än tio centimeter från där operatören
plockar detaljen till sensorn. Samt att ha sensorerna monterade på detta sätt möjliggör användning
av lådorna som kan stå i mitten på materialfasaden utan att behöva montera någon extra list till
sensorerna. Övriga sensorer sitter på ett sådant sätt att de kommer utlösas när operatören för in
handen i lådan.
När en låda är tom är tanken att den skall tas ut från materialfasaden och ställas längst upp för att visa att den är tom. För att sensorerna inte skall utlösas när en låda tas ut finns det en pausfunktion i programmet som skall användas vid byte av låda.
Figur 14 Station 4 efter Pick-to-Light systemet är implementerat
När alla komponenter satt där de skulle testades systemet en sista gång. Testet utförs på samma sätt som testet innan systemet monterats på plats och testprotokollet kan studeras i Tabell 4. Först bestämdes ordningen på vilka sensorer som skulle lysa genom att ändra textfilen med macIDn. I detta steg var det tacksamt att ha märkt upp alla sensorer med sin egen macID för att enkelt kunna se vilken sensor som skulle läggas in i textfilen samt vilken ordning de skulle ligga i. Nu ställdes programmet in för station fyra och det gjorde att alla lampor lyser i rätt ordning för stationen. Även felkoden testades när systemet var monterat för att säkerställa att inget blev fel när systemet installerades. Systemet passerade testet utan problem är redo att användas i undervisningen. Det enda problemet som dök upp är ifall operatören skulle föra sin hand för högt över sensorerna när detaljer plockas, det leder till att sensor inte utlöses. Detta sker eftersom sensorerna bara aktiveras på ett visst avstånd(cirka 10 centimeter) och om avståndet mellan operatörens hand och sensorn är större än det avståndet kommer inte sensorerna att utlösas. Det som kan göras för att åtgärda problemet är att montera sensorerna på ett annat sätt. Vilket skulle kunna vara ovanför lådorna och sensorerna pekar ner istället. Beslutet togs att låta sensorerna sitta kvar och tydliggöra i
instruktionerna till systemet vad som skall göras om en sensor inte utlöses eftersom ställningen är
byggd på ett sätt som skapar andra problem om sensorerna skulle peka neråt. Samma problem kan uppstå även om sensorerna pekar neråt, dessutom behövde höjden på rälsen som håller lådorna ändras och eftersom dessa står i en lutning och den översta lutar åt motsatt håll kan det bli trångt att få in fyllda lådor.
I programmet finns instruktioner för hur operatören skall göra för att köra systemet samt vad alla knappar gör. Dessa kan studeras i Figur 12 i kapitel 5.2.3.2
5.2.4 Avslutningsfasen
All information som tagits fram om systemet har överlämnats. Det innehåller instruktionerna som
tagits fram i projektet samt instruktionerna från Binar, tabellen med macIDn, programmet i sig, och
programmets källkod för att underlätta för framtida konfigurering av systemet. För att kunna köra
systemet kommer det behövas en dator som är kopplad till styrenheten med Binars drivrutin samt
programmet som skapats för att kunna hålla systemet igång under tiden det körs. Detta har
klargjorts i instruktioner vilka program som behöver köras och hur de skall köras. Instruktioner för
körning kan studeras i Figur 12 i kapitel 5.2.3.2 och instruktioner för installation kan studeras i bilaga
3.
6. Resultat
6.1 Implementation
Systemet implementerades på station fyra enligt överenskommelse med projektets handledare.
Programmet för systemet har skrivits i programmeringsspråket Python som är ett av de största programmeringsspråken vilket leder till att det finns stor chans att någon annan i framtiden skulle kunna göra om programmet ifall det skulle anses nödvändigt.
6.2 Programmet
Ett användargränssnitt skapades för att förenkla körning av systemet. Vilket också leder till att inga onödiga program behöver köras i bakgrunden. Tack vare detta kommer det inte krävas någon kraftfull dator för att köra systemet. Systemet kräver endast att datorn använder sig av Windows då Binars programvara för att köra systemet endast funkar på Windows. I användargränssnittet finns instruktioner skriva som kan studeras i Figur 12 i kapitel 5.2.3.2. För att underlätta konfigurering av systemet finns en textfil där operatören kan skriva in de macid som tillhör sensorerna i den
ordningen operatören önskar att de ska lysa. En enkel instruktion har även skrivits för att installera programmet. Det kan läsas i bilaga 3. All dokumentation leder till enklare körning tack vare att den beskriver hur användaren skall gå till väga för att starta systemet första gången samt hur användaren kör systemet samt vad alla knappar har för funktion.
6.3 Före Pick-to-Light
Stationen testades snabbt innan implementationen av Pick-to-Light varpå det tog ungefär 1 minut och 30 sekunder att göra hela processen. Det krävdes att hålla fokuset uppe för att komma ihåg vilken detalj som skulle plockas i vilken ordning och det gjorde att det tog längre tid. Ibland krävdes det en snabb titt på lappen med instruktioner för att komma ihåg vad som var nästa steg i processen.
Lappen sitter på väggen en liten bit bort och det går inte att hålla en lapp med instruktioner i handen eftersom båda händerna krävs vid montering av vissa delar. Det är något som blir bättre med övning men det tar en stund innan operatören har den självsäkerheten för att klara av att göra allt utan större tankeverksamhet.
6.4 Efter Pick-to-Light
Pick-to-Light systemet installerades på ställningen och funktionen testades enligt testprotokollet som kan läsas i 6.4.1.1 tabell 4. När funktionen var säkerställd gjordes några tester av tiden det tog att plocka med hjälp av Pick-to-Light systemet. Tiden var ungefär densamma (1 minut och 30 sekunder) som innan däremot finns det andra vinster med Pick-to-Light. Eftersom Pick-to-Light är ett Poka-Yoke system innebär detta att systemet kommer hjälpa till att minska förluster genom att fel eller misstag upptäcks innan de sker. Pick-to-Light kan också hjälpa nya operatörer komma in i produktionen på ett enklare sätt då dessa inte behöver läsa igenom instruktionerna på samma sätt som innan.
Eftersom operatören inte behöver komma ihåg vilken del som skall plockas när utan kan fokusera på själva monteringen av detaljen på trampbilen.
Vid en undervisning i utbildningsmiljön hade några studenter chansen att testa systemet när det
fanns tid kvar efter lektionen. Testet som gjordes var mest ett funktionstest för att se så att systemet
funkade som planerat och det var inget test som var planerat. Studenterna upplevde inga problem
med systemet. Den som utförde testet var handledaren för projektet och lite tankar från studenterna samlades efteråt. De upplevde att monteringen blev enklare att utföra då det inte krävdes lika mycket energi för att tänka på vilken detalj som skulle plockas. Konfigureringen av systemet funkade som det skulle och instruktionerna gick bra att följa.
Pick-to-Light är inte felfritt, det behövs fortfarande instruktioner för att operatören skall veta vart
detaljerna skall monteras, och instruktioner för hur detaljerna skall monteras. Det finns instruktioner
som kan följas som fungerar för det gamla sättet att plocka utan Pick-to-Light och dessa fungerar
även till Pick-to-Light systemet eftersom allt plockas i samma ordning bara att det finns en lampa
som visar operatören vilken detalj som skall plockas.
7. Diskussion
7.1 Problemlösningen
Problemet som skulle lösas var implementering av ett Pick-to-Light system från Binar. Det finns tillräckligt med material för två materialfasader. I projektets nuvarande skede har bara en
materialfasad implementerats. Detta är på grund av att det krävs mer avancerad programmering då det i teorin skulle behöva köras två program samtidigt. Ett användargränssnitt skapades för att operatör enkelt skall kunna starta och stoppa systemet. Programmet är även konfigurerbart till den nivån att det går att ändra plockordning innan systemet startas.
En väntetid på en sekund efter att en sensor har utlösts för att undvika felmeddelande är inte önskvärd. Genom att lägga till kod i programmet som gör att den senaste utlösta sensorn inte kan utlösas igen kan detta problem bli löst. Försök att programmera detta gjordes men försöken misslyckades. Problemen som uppstod när fördröjningen försökte ersättas var att felkoden inte funkade som planerat och i samtal med projektets handledare beslutades att felkoden var viktigare.
Ett problem som begränsar systemet är avsaknaden av en funktion gör att olika plockorder kan läsas in. Om en annan station skulle använda sig av systemet där en trampbil inte skall ha en viss del finns det inget snabbt sätt att göra en förändring i ordningen som detaljer plockas. Detta kan lösas med användning av en streckkodsläsare med förprogrammerade streckkoder, alternativt någon form av QR-kod som kan avläsas med en kamera.
När lådor skulle bytas uppstod problemet att felkoden utlöstes, detta löstes genom att lägga in en pausfunktion i programmet som gör att systemet hamnar i ett viloläge där det bara är att starta systemet igen.
Det gjordes ingen riktig studie för att jämföra tiden det tog att montera detaljer på trampbilen med eller utan Pick-to-Light systemet. Av de få testerna som gjordes tog det lika lång tid och det kan bero på att plockningen redan var optimerad för att ta så kort tid som möjligt. Eftersom testerna var så få testades inte alla möjligheter såsom eventuella felplock eller tapp av material men dessa skulle också påverka resultatet.
7.2 Teknologi, Samhälle och Miljö
Genom att implementera ett Pick-to-Light system kan ett företag bidra till en mindre mental påfrestning på operatören än det var tidigare eftersom operatören inte behöver lägga lika mycket fokus på plockandet utan kan fokusera mer på att montera och säkerställa kvalité vilket i sin tur också kan leda till minskad påverkan på miljön. Detta eftersom högre kvalité betyder färre produkter som måste kasseras.
Teknologin är konstant förändrande och det leder i sin tur till att komponenterna som används till
systemen kan bli föråldrade snabbt. Binar har dock varit bra genom att låta deras komponenter vara
bakåtkompatibla, det innebär att knappar och sensorer kan användas till nästa utgåva av systemet
om det skulle önskas.
7.3 Framtida Utveckling
Det finns en hållare för ett verktyg som skulle kunna användas på materialfasaden. Att implementera denna skulle kräva att programmet struktureras om eftersom det är en annan sorts kod som behöver skickas för att få lampan till verktygshållaren att lysa samt en annan sorts kod för att läsa av signalen från verktygshållaren.
Det finns tillräckligt med sensorer och kablar för att köra systemet på två stationer. Programmet kommer behöva ändras för att detta skall funka. Det kan bero på att programmet är skrivet i just Python och programmet behöver översättas till ett annat språk. Ingen närmare forskning har gjorts i varför programmet inte funkar på flera stationer mer än bara spekulationer samt slutsatsen att programmet endast kan köras på en station.
Det finns instruktioner för plockning och monteringen av detaljerna från station 4 men dessa kan skrivas om och göras enklare men det är inget som har diskuterats med handledare.
Det skulle kunna implementeras ett sätt att läsa in någon form av streckkod för att kunna använda
sig av olika plockorder. Detta skulle göra systemet mer användbart för andra stationer där förändring
i vilka detaljer som skall plockas sker. I nuvarande form fungerar endast systemet optimalt på en
station där plockordningen är statisk.
8. Slutsats
Ett Pick-to-Light system från Binar skulle konfigureras och implementeras.
Systemet är konfigurerbart.
Systemet kräver inga extra program annat än de som skapats för systemet.
En Instruktionsmanual har skrivits för att underlätta användningen av systemet.
Ett Pick-to-Light system har implementerats på station fyra i utbildningsmiljön på Högskolan i Skövde.
Systemet uppfyller kraven som specificerats. Det finns felmeddelande, det är konfigurerbart och det finns ett användargränssnitt för att underlätta körning. Genom att programmera knappar med olika funktioner går det till exempel att stoppa systemet för att byta lådor, stoppa och starta om systemet utan att stänga av programmet och ett sätt att hoppa till nästa sensor i ordningen ifall något fel skulle uppstå. Systemet är konfigurerbart genom en textfil som kan skrivas om för att justera
plockordningen utan kunskap av programmering.
Innan programmet körs finns det en textfil med instruktioner i hur operatören installerar och startar programmet. Efter programmet har startats finns det instruktioner i programmet som hjälper operatören att köra programmet samt beskriver hur ändringar i plockordningen görs.
När programmet körs finns det en väntetid på en sekund efter att en sensor har blivit utlöst som hade kunnat lösas på ett bättre sätt. Försöken att åtgärda detta misslyckades och väntetid fick vara kvar.
Det finns en del över som inte har använts och det är verktygshållaren, denna var ingen del som var överenskommen att den skulle vara med därför har den inte implementerats samt att programmet behöver ändras för att den skall funka. Det finns inte heller något sätt att läsa dynamiska
plockinstruktioner men detta var inte heller någon överenskommen funktionalitet.
Pick-to-Light systemet har implementerats på station fyra med de funktioner som var överenskomna
med projektets handledare. Programmet går att konfigurera utan att ha kunskap i programmering
genom en textfil. Det finns en verktygshållare som kan implementeras till systemet samt att det finns
en användning för dynamiska plockinstruktioner vilket inte heller har implementerats.
Referenser
Andersson Willaume t., Catic M., (2014) Projektmodell för ett konsultbolag. Chalmers Tekniska Högskola, Göteborg Sverige. https://odr.chalmers.se/bitstream/20.500.12380/202840/1/202840.pdf
Bicheno, J., Holweg, M., (2016) The Lean Toolbox. A Handbook for Lean Transformation. Buckingham: PICSIE Books
Binar Elektronik AB, (2014) Kvalitetssäkrande Poka Yoke-system [Användarmanual].
https://docplayer.se/20446063-Control-systems-lp204-anvandarmanual-installationsmanual.html (2020-04-20) Binar Elektronik AB, (2016) LP352 Pick-to-Light [Installationsmanual].
Dennis, P., (2015) LEAN Production simplified. Florida: CRC Press
Eastwood, B. (2020) THE 10 MOST POPULAR PROGRAMMING LANGUAGES TO LEARN IN 202011.
https://www.northeastern.edu/graduate/blog/most-popular-programming-languages/[2020-11-11]
Groover, M. (2016) Automation, Production Systems, and Computer-Integrated Manufacturing. Essex: Pearson Education Limited
Guo, A., Raghu, S. Xie, X., Ismail, S. Luo, X., Simoneau, J., Gilliland, S., Baumann, H., Southern, C., Starner, T., (2013) A Comparison of Order Picking Assisted by Head-Up-Display (HUD), Cart-Mounted-Display (CMD), Light, and Paper Pick List. Georgia Institute of Technology & Ubimax GmbH
https://dl.acm.org/doi/pdf/10.1145/2634317.2634321
IDG.se (u.å) Parsning https://it-ord.idg.se/ord/parsning/ [2020-11-09]
JSON (u.å) Introduktion till JSON. https://www.json.org/json-sv.html [2020-07-04]
Liker, J. (2004). The Toyota Way. 1:7. uppl., Stockholm: Liber.
Martin Murray (2018) Amazon Strategy for Pick to Light Systems in Warehouses
https://www.thebalancesmb.com/pick-to-light-warehouse-systems-2221456 [2020-04-13]
Nationalencyklopedin, (u.å.) Montering. http://www.ne.se/uppslagsverk/encyklopedi/enkel/montering-(2) [2020-04-20]
NewSeed (u.å.) REST API – vad betyder det? https://newseed.se/fakta/rest-api-vad-betyder-det/ [2020-07-04]
Peterson, P., Johansson, O., Broman, M., Blücher, D., Alsterman, H., (2009) Lean- Gör avvikelser till framgång.
Bromma: Part Media
Tutorialspoint (u.å.) Pascal Overview. https://www.tutorialspoint.com/pascal/pascal_overview.htm [2020-07- 04]
Wasilewski, M (2019) What Is Python? When and Why Should I Use It in My Project? A Guide for Entrepreneurs https://www.netguru.com/blog/what-is-python-when-why-guide [2020-07-04]
Zomer, M. (2018) [fotografi] https://www.pexels.com/sv-se/foto/forbindelse-kabel-kabel-laddare-laddare- 914915/ [2021-01-20]
Bilagor
Bilaga 1. Arbetsgång och tidsplan
Tidsplanen ställdes upp inför examensarbetet med tanken att det gamla systemet skulle användas. Det
var innan det nya systemet hade kommit till HIS. Det tog några veckor för det nya systemet att komma
till HIS vilket gjorde att hela projektet blev försenat. Detta ledde till att tidsplanen fick ändras drastiskt
och alla delar inte hanns med på samma noggranna nivå som hade hoppats. Dock uppfyllde projektet
målen som hade ställts upp och de målen som inte klarades var de jag hade ställt upp för mig själv. Det
största problemet att överkomma var att bestämma vilket av systemen som skulle användas. Efter
mycket velande bestämdes det att det nya systemet fick bära eller brista.
Tabell 5 GANTT schema före projektet
Aktivitet V.15 V.16 V.17 V.18 V.19 V.20 V.21 v.22 V.23
Läsa på om Pick-to-Light
Planera och Montera
Konfigurering/Programmering
Testkörning
Rapport Skrivning V.15 V.16 V.17 V.18 V.19 V.20 V.21 v.22 V.23
Specifikation
Midterm
Slutgiltig Rapport
Tabell 6 GANTT schema som tiden faktiskt användes
Aktivitet V.15 V.16 V.17 V.18 V.19 V.20 V.21 v.22 V.23
Initieringsfasen
Planeringsfasen
Genomförandefasen
Programmering
Implementering
Avslutningsfasen
Rapport Skrivning V.15 V.16 V.17 V.18 V.19 V.20 V.21 v.22 V.23
Specifikation
Midterm
Slutgiltig Rapport
Aktivitet V.40 V.41 V.42 V.43 V.44 V.45 V.46 v.47 V.48 Initieringsfasen
Planeringsfasen
Genomförandefasen
Programmering
Implementering
Avslutningsfasen
Rapport Skrivning V.40 V.41 V.42 V.43 V.44 V.45 V.46 v.47 V.48
Specifikation
Midterm
Slutgiltig Rapport
Rapport Skrivning V.49 V.50 V.51 V.52 V.53 V.1 V.2 v.3 V.4
Specifikation
Midterm
Slutgiltig Rapport
Bilaga 2. Kod för Pick-to-Light systemet
self.lamps = []
#Adresser dit datan skall skickas
self.main_api = "http://localhost:8080/rest/binar/"
self.call_api = "get/modules"
self.post_api = "io/put/"
self.call_api_spec = "get/module/"
self.header = {"Content-type" : "application/json"}
#Datan som skall skickas
self.payloadon = {'Idx' : 0, 'Data' : 1, 'Params':[{"Color": 2}]}
self.payloadoff = {'Idx' : 0, 'Data' : 0, 'Params':[{"Color": 0}]}
self.payloadfault = {'Idx' : 0, 'Data' : 1, 'Params':[{"Color": 1}]}
self.payloadspec = {'Type' : 'Input', 'Idx' : 0}
self.payloadspeco = { 'Type' : 'Output', 'Idx' : 0}
self.current_lamp = 0 self.last_lamp = 0
def runprg(self):
if self.runprogram == 0:
self.sensorfile = open("Sensorer.txt", "r") self.sensors = self.sensorfile.read()
self.lamps = self.sensors.split(",") self.sensorfile.close()
self.pausprog = 0 self.runprogram = 1
self.thread = threading.Thread(target=self.program) self.thread.start()
def pausprg(self):
if self.pausprog == 0:
self.pausprog = 1
def resumeprg(self):
if self.pausprog == 1:
self.pausprog = 0
def skipsnsr(self):
if self.runprogram == 1:
self.skip = 1 sleep (0.2) self.skip = 0
def stopprg(self):
if self.runprogram == 1:
self.runprogram = 0 self.current_lamp = 0
self.turn_off_lampS(self.lamps)
def close(self):
self.runprogram = 0
self.turn_off_lampS(self.lamps) self.master.quit()
def is_sensor_active(self,macid):#avläser vilken sensor som är aktiv spec_data = requests.post(self.main_api + self.call_api_spec + mac id, json=self.payloadspec, headers=self.header)
spec_datajson = spec_data.json()
data_read = spec_datajson['Input']['Data']
return data_read == 1
def turn_on_lamp(self, macid):#tänder lampa
requests.post(self.main_api + self.post_api + macid, json=self.payload on, headers=self.header)
def turn_off_lamp(self, macid):#släcker lampa
requests.post(self.main_api + self.post_api + macid, json=self.payload off, headers=self.header)
def turn_off_lampS(self, macids):#släcker lamporna for macid in macids:
requests.post(self.main_api + self.post_api + macid, json=self.pay loadoff, headers=self.header)
def turn_on_all_red(self, macids):#tänder alla röda lampor for macid in macids:
requests.post(self.main_api + self.post_api + macid, json=self.pay loadfault, headers=self.header)
def any_incorrect_sensor_active(self, lamps, current_lamp, last_lamp):#avl äser om inkorrekt sensor är aktiv
for i in range(len(self.lamps)):
if i != self.current_lamp and self.is_sensor_active(self.lamps[i]) :
return True return False
def program(self):
for lamp in self.lamps:
self.turn_off_lamp(lamp)
self.turn_on_lamp(self.lamps[self.current_lamp]) while self.runprogram == 1:
if self.is_sensor_active(self.lamps[self.current_lamp]) or self.sk ip == 1:
self.turn_off_lamp(self.lamps[self.current_lamp])
self.last_lamp = self.current_lamp #används inte vågar inte ta bort ifall programmet skulle krascha
self.current_lamp +=1
if self.current_lamp == len(self.lamps):
self.current_lamp = 0
self.turn_on_lamp(self.lamps[self.current_lamp]) sleep (1)
while self.any_incorrect_sensor_active(self.lamps, self.current_la mp, self.last_lamp):
self.turn_on_all_red(self.lamps) sleep (1)
self.turn_off_lampS(self.lamps)
self.turn_on_lamp(self.lamps[self.current_lamp]) while self.pausprog == 1:
pass else:
sleep (0.1)
root = Tk()
my_gui = MyFirstGUI(root)
root.protocol("WM_DELETE_WINDOW", my_gui.close) root.resizable(False, False)
root.mainloop()
