Utformning och installation av internetuppkopplad datalogger för kontinuerlig sintringsugn : Utveckling och implementation av Raspberry Pi baserad internetupkopplad datalogger, samt framtagning av lösningsförslag för viktmätning

(1)

Utformning och installation av internetuppkopplad

datalogger för kontinuerlig sintringsugn

Utveckling och implementation av Raspberry Pi baserad internetupkopplad datalogger, samt framtagning av lösningsförslag för viktmätning

Design and installation of internet-connected datalogger for continous

sintering furnace

Development and implementation of Raspberry Pi based internet-connected datalogger, and generation of solutions for weight measuring

Nygårds, E., Oliw, M.

Linköpings universitet ; Institutionen för ekonomisk och industriell utveckling

Kandidatuppsats, 16 hp ; Maskinteknik

Vårterminen 2021 ; LIU-IEI-TEK-G–21/01994—SE

Examinator: Fredric Malm Handledare: Peter Hallberg

Linköpings universitet SE-581 83 Linköping, Sverige 013-28 10 00, www.liu.se

(2)

Förord

Stort tack till Ola Litström och Jonas Bergendal för möjligheten att få utföra detta exjobb, Mikael Svensson och Magelie Darnis och Andreas Olofsson för deras stora hjälp vid vägledning, runtvisning, diskussioner samt inköp. Tack även till alla andra arbetande vid Höganäs PoP-center för feedback och tips. Stort tack till examinator Fredric Malm och handledare Peter Hallberg för ett väldigt välstrukturerat upplägg av exjobbet. Seminarietillfällena var till väldigt stor nytta, tack också till vår opponentgrupp Sebastian Salmson och Armin Ranjdideh. Sist men inte minst tack till Stack Overflow för att du existerar.

Lycka till med läsningen! Linköping, 14 juni 2021

Erik Nygårds Martin Oliw

(3)

Sammanfattning

Höganäs AB har ett kundcenter där deras metallpulver används för att replikera kunders processer, därmed fås kunskap om hur deras pulver uppför sig och hur det kan förbättras. Pulvret pressas vanligt-vis, och sintras sedan i sintringsugnar där temperatur och atmosfärskomposition ger en detalj önskade egenskaper. Höganäs AB sparade ej värden från dessa processer på ett lättillgängligt sätt, vissa värden sparades inte ner alls. För att öka förståelse av dessa parametrars påverkan på producerade detaljer ville de därför att dessa värden skulle samlas och sparas på molnet. De ville även få lösningsförslag och koncept för implementering av viktmätning på in- och utmatningssidan av ugnen.

I projektet användes Ulrich & Eppingers produktutveklingsmetod, modifierad genom att utföra kontinuerliga tester parallellt med designen. Projektet delades även in i tre delar som gjordes samtidigt. Datorarkitektur, fysisk inkapsling och viktmätningskoncept.

För att sammanställa och ladda upp på molnet valdes att använda en Raspberry Pi 3 B+, en mikropro-cessor. Den kopplades upp på WiFi för att sedan kunna ladda upp filer på OneDrive. Mätvärdena från ugnen togs från ugnens PLC via OPCUA och gasmätningsenheten via seriell kommunikation.

På grund av metallpulvret fanns det ledande damm i luften vilket kunde leda till krypströmmar eller kortslutningar om det skulle samlas på processorenheten. Därav krävdes att dammet hölls bort från den. Höljet designades därför för att vara någorlunda tätt. Höljet producerades med 3D-printing i PETG. Tätningen utnyttjade PETG:s elasticitet för att elastiskt deformera en upphöjd tätning, och därmed täta, utan att behöva göra flera komponenter än lock och botten. För kabelgenomföringen utnyttjades kablarnas elastiska deformation för att täta. För att starta och stoppa loggar implementerades en skärm, även den tätades med en överlappande del längs skärmens kanter.

Själva loggningen av ugnsparametrarna delades upp i två loggar, en dagslogg och en jobblogg. Dagsloggen tog mätpunkter med långa intervall, 30 minuter, och kördes kontinuerligt. Varje dag laddade den upp en loggfil för just den dagen, därav namnet. Jobbloggen startades manuellt via skärmen och användes för att ta mätvärden med snabbare frekvens då en produktionsserie kördes. Loggfilerna laddades sedan upp i en Onedrive mapp.

Produkten testades med några sluttester, både för den fysiska konstruktionen samt för mjukvaran. För den fysiska konstruktionen testades främst de numeriska kraven i kravspecifikationen. Medan mjukvaran testades över längre tid för att verifiera funktionaliteten.

Den slutgiltiga produkten var en tätad, hållfast, lättdemonterad och kabelavlastande 3D-printad låda med en 3,5 tums touchscreen och anslutet tangentbord. Den samlade den önskade datan och kompilerade den i loggfiler som program som t.ex. Microsoft Excel kan läsa av.

Viktmätningskonceptet som togs fram som lösningsförslag var en egengjord lösning med lastcel-ler under påmatningsrampen. Vikten mäts då automatiskt i farten och inga avbrott behövs göras. Även två reservlösningar togs fram.

(4)

Abstract

Höganäs AB has a customer center where they perform their cutomers production processes using their own metal powder, thereby gaining knowledge of how the powder behaves and how it can be improved. The powder is usually pressed, and then sintered in a sintering furnace where temperature and atmosphere composition gives the component its desired characteristics. Höganäs AB didn’t save the parameters from these process’s in a easily accessible way, some values were not saved at all. To increase understanding of these parameters impact on the produced detail they wanted these parameters collected and stored in the cloud. They also wanted solution ideas and concepts for implementation of weight measuring on both the in- and output side of the furnace.

This project used Ulrich & Eppinger’s product development method, modified by performing continous testing parallell to the design process. The project was also separated into three parts worked on simultaneously. Computer architecture, physical casing and weight measuring.

To compile and upload to the cloud a Raspberry Pi 3 B+, a micro processor, was used. It con-nected via WiFi to upload files to OneDrive. The measured values from the furnace were gathered from the furnace’s PLC via OPCUA and a gas measuring unit via serial communication.

Because of the use of metal powder there was conductive dust in the air which could lead to lea-kage currents and short circuiting if it were to gather on the processor unit. Hence the dust had to be kept away. The casing was therefore designed to be relatively airtight. The casing was made with 3D-printed PETG. The seal utilized PETG’s elasticity to elastically deform an elevated seal, and thereby sealing the casing, without having to produce more components than a bottom and a lid. The cable feedthrough used the cables elastic deformation to seal. A screen was implemented to start and stop logging processes, which was also sealed using an overlapping lip around it’s rim.

The logging of the furnace parameters was split in two logs, a log and a job-log. The day-log took measurements continously over a day in long intervals, 30 minutes. At the end of the day a day-log was uploaded for that day, hence the name. The job-log had to be started manually via the screen and was used to take measurements with higher frequency during a production series. Log files of both types were uploaded to a OneDrive folder.

The product was tested with a number of final tests, both for the casing and the software. The casing was tested primarily for the numerical requirements set in the requirements specification. While the software was tested over a longer period of time to ensure functionality.

The final product was a sealed, robust, easily disassembled and cable strain relieved 3D-printed box with a 3.5 inch touchscreen and a connected keyboard. It collected the desired data and compiled it to log files readable by programs such as Microsoft Excel.

The weight measuring concept produced was a self-made solution with load cells under the loa-ding ramp. The weight is then measured automatically during the regular loaloa-ding process without disrupting it. Two backup solutions were also put forward.

(5)

Innehåll

1 Inledning 1 1.1 Bakgrund . . . 1 1.2 Problembeskrivning . . . 3 1.3 Syfte . . . 3 1.4 Mål . . . 3 1.5 Avgränsningar . . . 3 1.6 Frågeställningar . . . 4 2 Teori 5 2.1 Sintring . . . 5 2.2 Sintringsatmosfärer . . . 5

2.3 Processorer och kontrollenheter . . . 6

2.3.1 Raspberry pi . . . 6

2.3.2 Industrialiserad Raspberry pi . . . 6

2.3.3 PLC, HMI och Övervakningsdator . . . 7

2.4 Mjukvara . . . 7

2.4.1 OPCUA . . . 8

2.5 Mätrullar och mätplattor . . . 8

3 Metod 9 3.1 Planering . . . 9 3.2 Konceptutveckling . . . 10 3.2.1 Kundbehov . . . 10 3.2.2 Kravspecifikation . . . 10 3.2.3 Konceptgenerering . . . 10 3.2.4 Konceptevaluering . . . 10 3.3 Systemdesign . . . 10 3.4 Detaljdesign . . . 11

3.5 Testning och förfining . . . 11

4 Genomförande 12 4.1 Planering . . . 12 4.2 Kundbehov . . . 12 4.3 Kravspecifikation . . . 13 4.4 Konceptgenerering . . . 16 4.4.1 Koncept - Datalogger . . . 16 4.4.2 Koncept - Viktmätning . . . 17 4.5 Konceptevaluering . . . 18 4.5.1 Datorarkitektur - Konceptevaluering . . . 18

4.5.2 Fysisk konstruktion - Konceptevaluering . . . 20

4.5.3 Viktmätning - konceptevaluering . . . 23 4.6 Systemdesign . . . 24 4.7 Detaljdesign . . . 28 4.7.1 Fysisk detaljdesign . . . 28 4.7.2 Mjukvaruutveckling . . . 33 4.8 Slutgiltiga tester . . . 34 4.8.1 Programtester . . . 34

(6)

4.8.2 Fysiska tester . . . 34

5 Resultat 36 5.1 Program . . . 39

5.1.1 Dagslogg - Slutgiltigt program . . . 39

5.1.2 Jobblogg - Slutgiltigt program . . . 42

5.2 Fysisk konstruktion . . . 47 5.3 Testresultat . . . 47 5.4 Viktmätning . . . 49 6 Diskussion 50 6.1 Metod . . . 50 6.2 Genomförande . . . 50 6.3 Resultat . . . 51 6.3.1 Fysisk konstruktion . . . 51

6.3.2 Mätvärden och mjukvara . . . 51

6.3.3 Slutgiltiga tester . . . 52 6.4 Viktmätning . . . 53 6.5 Framtida utveckling . . . 54 6.6 Samhällelig diskussion . . . 54 7 Slutsatser 56 Bilagor 59

(7)

Figurer

1 Exempel på komponenter tillverkade med hjälp av sintring av metallpulver [6] . . . 1

2 Bild av den bandugn som projektet behandlar, vänster figur visar inmatningssidan och höger utmatningssidan. De gröna bältena är respektive in och utmatningsbälten . . . 2

3 Schematisk bild av ugnen samt vart enheterna mäter och var de är. De röda linjerna symboliserar mätdataflöden, de går från ugnen till antingen PLC:n eller gasmätningen . . 3

4 Diagram av sintringsprocessen, först komprimeras det lösa pulvret i den önskade formen, sedan sintras det så att partiklarna växer ihop och porerna krymper [7, s.34] . . . 5

5 En Raspberry pi 3 b+ . . . 6

6 En Raspberry pi kopplad till en Unipi 1.1 expansionskort. Tack till Unipi technology för tillstånd [9] . . . 7

7 En PLC processor, CPU 416-3 från Siemens Simatic s7-400 serien [12] . . . 7

8 Enkel skiss på en mätrulle-enhet med en rulle. De kan ha flera mätrullar för att mäta i flera punkter eller för att stabilisera detaljer ovanpå dem . . . 8

9 Visualiering av Ulrich & Eppingers produktutvecklingsmetod . . . 9

10 Visualiering av den modifierade verisionen av Ulrich & Eppingers produktutvecklings-metod. De två nivåerna från steg 1 till 4 representerar indelningen i fysisk konstruktion och mjukvaruutveckling . . . 9

11 Koncept 1-4 för viktmätningen, koncepten kan använda antingen färdiga produkter eller egnakonstrueras. Koncept 3 kan inte använda färdiga produkter . . . 17

12 Koncept 8, en egen lösning. Lastceller fastmonterade i pårampen och ugnen eller påmat-arbandets sida . . . 18

13 Koncept 9-10, båda koncepten är egengjorda lösningar som utgår från lastceller. . . 23

14 Koncept 11, drivna rullar med lastceller. Bandet är avkortat för att göra plats åt rullarna . 24 15 Schematisk bild av den fysiska konstruktionen . . . 25

16 Den initiella CAD modellen som gjordes under systemdesignen . . . 25

17 Schematisk bild av kodlogiken i dagsloggen. Datasamlingsloopen skriver data till samma fil över ett dygn. Först när det blir en ny dag skickar den upp filen på Onedrive och skapar en ny fil . . . 26

18 Schematisk bild av kodlogiken för jobbloggen. När ugnen är tom på skepp startar en timer, när timern gått ut utan något nytt skepp avslutas loggningen och filen laddas upp på Onedrive . . . 27

19 Genomskärning av en prototypmodell av produktens fysiska inkaspling . . . 28

20 Demonstration av hur en modell förlorar upplösning när den förbereds för att printas, modellen i fråga är en sektion i genomskärning av förseglingen . . . 29

21 Deformationsanalys av tvärsnittet på förseglingen, delfig a visar odeformerat tillstånd och delfig b deformerat tillstånd . . . 29

22 En testprototyp som användes för att testa tätningen, kabelgenomföring och dess tätning samt skruvförband . . . 30

23 Kabelgenomföringen för den tjockare ethernet kabeln. . . 30

24 Aluminiumoxidpulver-badet med prototyplådan i under test . . . 31

25 Det tjockare triangulära mönstret på insidan av lådans väggar . . . 31

26 Lockets insida. Det tjockare mönstret stärker upp locket för att göra både tätningen bättre samt ge en bättre känsla vid användandet av skärmen . . . 32

27 Skärmen monterad i lådans lock. För att täta kring skärmen förlängdes lockets kanter ut över skärmens kant. Då skärmen hade en dödzon längs med kanten där inga tryckningar registreras begränsade inte detta skärmens funktionalitet . . . 32

(8)

FIGURER

28 Tätningspluggarna i CAD-modellen. Alla är lika stora förutom pluggen för ethernet

ka-belgenomföringen . . . 33

29 Schematisk bild av ugn, mätenheter och logger. De röda sträcken visar vart mätdata tas

och vad som tar vilka värden. De gröna sträcken visar varifrån logger läser datan. De blå

”WiFi” symbolerna symboliserar kommunikationen mellan loggern och molnet . . . 36

30 Den slutgiltiga produkten. Notera att den i denna bild inte är monterad på väggen . . . . 37

31 Programmatiskt flödeschema av dagsloggen. Gult innebär loopar och struktur, orange

betyder villkor, blått och grönt differentierar olika loopar . . . 41

32 De två dialogrutorna i det grafiska användarinterfacet, delfig a är den första dialogrutan

och b den andra. Observera att dess storlek är anpassade efter storleken på produktens

skärm, 3,5 tum . . . 43

33 Programmatiskt flödeschema av jobbloggern. Gult innebär loopar och struktur, orange

betyder villkor, rosa betyder att programutförandet står still tills någon input sker, blått och grönt differentierar olika loopar. Streckade linjer betyder att argument skickas medan

heldragna linjer är programmets flöde . . . 44

34 Den spruckna lådan efter fallet på 3 meter. På bilden kan plattan som ersatte skärmen synas 47

35 Kabeltestet med 35 N i last. Kabeln gled inte märkbart under testets gång . . . 48

36 Botten av lådan precis efter pulvertestet. Se kapitel 6.3 för vidare diskussion om testet . . 48

37 Graf över CPU temperaturen under ett dygn . . . 49

(9)

Tabeller

1 Tabulerade kundbehov för huvudprodukten, bestämda utifrån projektägarens önskemål . 12

2 Tabulerade kundbehov för viktmätningen, framtagna efter projektägarens önskemål . . . 13

3 Den framtagna kravspecifikationen för huvudprodukten. Prioriteringsgraderna betyder

att krav med värdet 1 är absoluta måsten och har högst prioritering. Prioritering 2 är mycket bra att ha medans 3 betyder att det kan vara bra att ha. Med procenthalten för generaliseringen menas hur generaliserad produkten är. Där 0% betyder att produkten helt måste göras om för att användas vid en ny maskin. Medan 100% betyder att den kan

kopplas in i vilken maskin som helst på Höganäs utan modifiering . . . 14

4 Kravspecifikationen för viktmätningen, prioriteringsgraderna är lika som för

huvudpro-duktens kravspecifikation . . . 15

5 Resulterande kombinationsmatris av koncepten för arkitektur och styrenhetsalternativ.

Med slavsystem menas ett system med mindre kraftfulla enheter på varje maskin som

kommunicerar med en större enhet som sammanställer datan . . . 16

6 Kombinationsmatris för de fysiska konsutrktionskoncepten på systemnivå . . . 16

7 Kombinationsmatris för viktmätningskoncepten, d.v.s. en cell i kolumn ett kan

kombi-neras med någon cell i kolumn två. Se fig 2 för positionsförklaring. Med´´USB våg´´

menas en vanlig våg, till exempel köksvåg, med en seriell port. Se kapitel 2.5 för

förkla-ring av mätrullar och mätplattor. . . 17

8 Datakonceptevaluering 1, med slavsystem med PLC som centralenhet som

referenskom-bination, detta då den typen av system är det som typiskt används inom industri . . . 19

9 Datakonceptevaluering 2, med förra beslutmatrisens vinnare som referens . . . 19

10 Första beslutsmatris för den allmänna konstruktionsmetoden, se tab 6 för namnförklaring 20

11 Andra belutsmatrisen för evaluering av allmän kostruktionsmetoden . . . 20

12 Första beslutsmatris för evalueringen av tätning och kylningskombinationer för

3D-printning. Här är A5 referens . . . 22

13 Andra beslutsmatrisen för evalueringen av tätning och kylningskombinationer för

3D-printning. Här är kombinationen F3 + K4, väl förseglad utan kylning referens . . . 22

14 Första utvärderingen av viktmätningskoncepten, se bilaga B.3 t.o.m. B.10 för bilder på

alla koncept i denna tabell. Från denna evaluering beslutades att fortsätta utveckla

kon-cept 4 och 8 . . . 23

15 Slutgiltiga evalueringen av viktmätningskoncepten. Koncept 8 användes som referens då

den hade högst poäng i föregående utvärdering, se tab 14. Resultatet av utvärderingen var att koncept 8 ansågs det bästa med koncept 4 och 9 som reserv ifall koncept 8 ej kan

mäta vikt i farten . . . 24

16 Produktens faktiska egenskaper jämfört kravspecifikationen, se tab 3. Resultaten

presen-teras i detalj i detta kapitel och diskupresen-teras vidare i kapitel 6 och 6.3 . . . 38

17 Exempel på hur en sektion av en jobblogg kan se ut, notera skeppräkningen . . . 45

(10)

Ordlista

Alfanumerisk - Samlingsnamn av bokstäverna A-Z och siffrorna 0-9. Exempelvis A5 och R7.

Asynkront - (Inom kommunikation) Innebär att två saker kommunicerar, men kommunikationen är inte tidsberoende. Det vill säga ett meddelande behöver inte anlända samtidigt som mottagaren söker efter meddelanden.

Bandugn - Kontinuerlig ugn för sintring med olika zoner av värme. Skepp färdas genom ugnen på ett mesh-band av rostfritt stål.

Börvärde - Börvärde är en reglerteknisk term, ett börvärde är det värde som en maskin försöker nå. Maskinen ”tänker” att en parameters värde ”bör” vara börvärdet.

CAD - Computer Aided Design, program för 3D-modellering

csv - csv(Comma Separated Values) är en typ av avgränsad textfil som används för att skapa ma-triser. Varje kommatecken ses som gränsen mellan kolumner i en denna typ av fil.

Daggpunkt - Daggpunkten är temperaturen då den relativa luftfuktigheten av en gas når 100% under förutsättningen att innehållet ånga är densamma.

Diffusion - Molekylers förmåga att migrera från ett område med hög koncentration till ett med lägre koncentration.

Endogas - Endotermisk gas, används i ugnar under sintringsprocessen. Gasblandningen består av

H2, H2O, CO, CO2, N2och CH4. Gasen är giftig och bildar explosiva ämnen med luft. [1]

GUI - GUI står för Graphical User Interface och beskriver den delen av program som är använ-darinriktade, alltså det grafiska interfacet.

Headless - Dator utan möjlighet till direkt input, den har ingen skärm, mus, tangentbord osv.

HMI - HMI, Human Machine Interface är en del av industriella styrsystem som visar data från de faktiska styrsystemet och möjliggjör input från operatör. Numera ofta i form av en touchskärm. Kapillärverkan - Även kapillärkraft, ett flytande ämne får en kraft att föras längs ett smalt ut-rymme. Kraften uppstår på grund av molekylär vidhäftning när två ämnen hamnar nära varandra. [2] [3] Karburisering - Processen att härda en stålyta med kol. Kolhalten i stålet ökar.

Lastcell - Lastceller är en typ av sensor som kan detektera en kraft genom att mäta förändringen av resistansen i en speciellt utformad krets när den deformeras. De är den vanligaste sensorn som används för att väga saker. [4]

Lott / Lotter - En produktionsserie, till exempel 100 kugghjul är en lott.

(11)

bör-Datalogger för sintringsugn Nygårds, E., Oliw, M.

jar smal och växer större när partiklarna blir tätare.

Mikrokontroller - En enkel liten dator som sitter på ett enda chip. Typexempel är arduino, som använder Atmega mikrokontroller. De har vanligtvis endast plats för ett litet program som körs om och om igen.

Open source - Mjuk- eller hårdvara som tillåts användas, studeras, delas och modifieras av andra parter. Exempel på licens som ger open source är GNU.

PLC - Programmable Logic Controller, industriell mikrokontroller som använder ladderprogram-merade program gjorda för industriell processkontroll.

Porositet - Andelen luft/tomrum i materialet. Ett material med många hålrum är poröst, har hög porositet.

Python - Python är ett kodspråk byggt för att vara simpelt att använda. En stor fördel är den uppsjö av bibliotek som finns tillgängliga.

Raspberry Pi - Mikrodator med processor och minne. Kan köra flera program samtidigt.

RS232 - RS232 (Recommended Standard 232) är en standard för seriell kommunikation mellan datorer och annan utrustning, det reglerar signalers spänning, utseende och frekvens. Det definierar även utseende och design på de fysiska kontakter som bör användas med standarden. Vanliga kontakter för rs232 är DB9 och db-25m.

Seriell kommunikation - Seriell kommunikation är en metod för datorer att kommunicera med varandra där meddelanden skickas som en serie bitar över en kanal. Jämförs med parallell kommunika-tion där flera bitar överförs samtidigt över flera olika kanaler.

Sinterstål - Material innehållande huvudsakligen järn tillverkat genom sintringprocess.

Sintring - Sintring är en tillverkningsprocess där fina ihoppressade partiklar utsätts för hög tem-peratur under materialets smältpunkt, växer ihop och skapar en solid.

Skepp - Brickor/tråg på vilka pressade pulverkomponenter färdas genom en bandugn, vanligtvis ryms många komponenter på ett skepp. Skeppen är utöver komponenterna fyllda med aluminumoxid-pulver.

SSH - SSH står för Secure Shell Protocol och är ett kryptografiskt protokoll för kommunkation över osäkrade nätverk. Det används typiskt för att ge tillgång till kommandolinje på unix system över nätverk. Ärvärde - Ärvärde är en reglerteknisk term, det är värdet som en parameter någon maskin försö-ker styra faktiskt är.

(12)

Datalogger för sintringsugn Nygårds, E., Oliw, M.

1 Inledning

I det här avsnittet presenteras företaget kortfattat samt en bakgrund till projektarbetet. Även syfte och mål med projektet redovisas samt avgränsningar och frågeställningar.

Processkontroll blir allt viktigare inom industri. Tillverkningsprocesser effektiviseras alltmer ge-nom precis kontroll av de styrande faktorerna. Till exempel ger precisare temperaturkontroll i stålugnar mindre felmarginaler i den färdiga produkten. Med långsiktig insamling av parametrarna kan de användas för att vidare studera deras inverkan på processens produkt och bilda underlag för förbättring av processen. Denna studie omfattar design och implementering av ett datasamlande system anpassat för industriellt bruk på mindre skala.

1.1 Bakgrund

Höganäs är ett världsledande företag inom tillverkningen av järn och metallpulver för användning i en uppsjö av ändamål. Några exempel på dessa är MIM (Metal Injection Molding), Additiv tillverkning, HIP (Hot Isostatic Pressing) och traditionell pressning och sintring. Tillverkning med pulver är en produktionsmetod som ger många designmöjligheter. Det går att tillverka komplexa detaljer med god precision snabbt och med modifierbar densitet och porositet, några exempel på pulvermetallskompo-nenter kan ses i fig 1. Höganäs har ett kundcenter, CDC (Customer Development Center), där tester och utvärderingar av egna produkter i kundernas tillverkningsprocesser utförs.

En nyckelprocess för tillverkning av pulvermetallkomponenter är sintringen, en process där fina ihoppressade partiklar utsätts för hög temperatur under materialets smältpunkt. De växer då ihop och skapar en solid, för vidare information se kapitlet: 2 Teori. [5] Sintringsprocessen är mycket viktig för de mekaniska egenskaperna av de färdiga komponenterna och därför är processkontroll väsentlig för att önskade egenskaper ska uppnås. Denna kontroll sker med hjälp av industriella kontrollenheter och ett antal processparametrar som inhämtas genom sensorer i sintringsugnen. I nuläget sparas inte dessa värden efter att processen genomförts. För att fördjupa förståelsen av hur de olika parametrarna påverkar den slutgiltiga produkten efterfrågas därför en lösning för att spara och visualisera processparametrar på ett enkelt och smidigt sätt. Dessutom finns det intresse att implementera viktmätning både före och efter sintringen. Detta ses dock som ett mindre prioriterat delprojekt som ej nödvändigtvis behöver utmynna i färdig implementerad produkt.

Figur 1 : Exempel på komponenter tillverkade med hjälp av sintring av metallpulver [6]

Miljön denna produkt kommer användas i är en industrimiljö. Dock pågår ingen massproduktion i loka-len, vilket leder till en renare miljö med mindre vibrationer än andra industrimiljöer, se fig 2. På grund av användningen av metallpulver finns det dock risk för elektriskt ledande dammpartiklar i luften. Det-ta utgör en fara för elektriska komponenter då dammet kan leda till krypströmmar och kortslutningar.

(13)

Eftersom lokalen är ett ugnsrum är temperaturen ofta över normal rumstemperatur, upp till 50◦C.

Kom-ponenter som befinner sig nära ugnen utsätts för ännu högre temperaturer.

(a) Ugn in, på inmatningsbältet syns ett antal skepp på väg in i ugnen. Påmatarplattan är stålplattan med små väggar som går mellan påmatarbandet och hu-vudbandet

(b) Ugn ut, på utmatningsbandet står två tomma skepp. Avmatarplattan är lik påmatarplattan, dock mycket kortare

Figur 2 : Bild av den bandugn som projektet behandlar, vänster figur visar inmatningssidan och höger utmatningssidan. De gröna bältena är respektive in och utmatningsbälten

Ugnen i fråga, se fig 2, heter BU-92 och är en kontinuerlig bandugn. Det betyder att ett band går genom hela ugnen, där sintringsprocessen utförs från start till slut utan avbrott. Komponenter som ska sintras läggs upp på påmatarbandet i så kallade skepp, små metallbrickor fyllda med aluminiumoxid, för att sedan åka framåt tills de stannar vid påmataren. Påmataren är en platta som med hjälp av en elektrome-kanisk cylinder skjuter komponenterna över påmatarplattan till bandet på ugnen. Komponenten sintras genom att långsamt färdas genom de olika zonerna i ugnen. Zonerna har olika temperaturer och atmo-sfärer, se 2.2. De inledande zonerna har hög temperatur för att utföra själva sintringen, slutstegen är nedkylande för att snabbkyla och få ner temperaturen närmare rumstemperatur. Sedan puttas skeppet av bandet med en avmatare, likt påmataren, över den kortare avmatarplattan till utmatningsbandet där det väntar på upphämtning av personal. Data från ugnen mäts av ugnens styrenhet, en Siemens PLC, och en Zirox gasmätningsenhet. Se fig 3 för en förklarande bild av ugnen och mätningar.

(14)

Figur 3 : Schematisk bild av ugnen samt vart enheterna mäter och var de är. De röda linjerna symboliserar mätdataflöden, de går från ugnen till antingen PLC:n eller gasmätningen

1.2 Problembeskrivning

Höganäs AB vill att ugnsparametrarna som redan mäts men ej sparas ska sparas ner för att öka spårbarhet och förståelse. Dessa värden ska sparas ner i någon form tillgänglig via internet, för att sedan kunna visualiseras på ett smidigt sätt. De vill att datasamlingsenheten ska generaliseras så långt som möjligt för att möjliggöra framtida expansion till flera ugnar och andra typer av maskiner, exempelvis pressar. För potentiell vidareutveckling och anslutning till olika maskiner ska eventuellt hölje vara tillräckligt flexibelt för att inte behöva omdesignas.

De söker även förslag på hur mätning av vikten på ut- och ingående skepp kan utföras, vilket ej mäts i nuläget. För viktmätningen söks lösningsförslag och idéer, färdig produkt är inte nödvändigt.

1.3 Syfte

Syftet med projektet är att öka förståelse och spårbarhet av olika parametrar, som t.ex. ugnsatmosfär och in-/utmatningsvikt, i Höganäs AB:s sintringsugn.

1.4 Mål

Målet med projektet är att på 10 veckor designa, producera, testa och implementera en lösning för att mäta och spara de olika parametrarna av intresse i sintringsugnen. Samt att ta fram lösningsförslag för mätning av vikt på in- och utgående skepp.

1.5 Avgränsningar

I syfte att begränsa projektet i tid samt komplexitet har avgränsningar behövt göras. Nedan följer dessa avgränsningar.

• Ett serverdatabassystem behöver ej sättas upp. • Produkten ska inte massproduceras.

• Endast en produkt till en ugn behöver tillverkas i detta projekt. • Koden behöver endast vara funktionell.

(15)

• Lösningsförslag för viktmätning tas endast till konceptstadiet.

1.6 Frågeställningar

Nedan följer de frågeställningar som ställs.

• Hur kan produkten göras lämpad för den industriella miljön?

• Hur kan datan lagras för att vara lättillgänglig samt lätt att visualisera? • Kan produkten generaliseras för användning på olika maskiner? • Hur kan viktmätning av pulverprodukter implementeras?

• Hur kan produkten säkerställa exakta och konsistenta mätvärden över längre tid?

(16)

2 Teori

I detta kapitel redogörs teori relaterat till projektet.

2.1 Sintring

Sintring är ett viktigt steg i tillverkningsprocessen för pulvermetalldetaljer där de får sin slutgiltiga storlek och styrka. Sintring är en materialteknisk process där kompakterad massa av små partiklar av ett eller flera ämnen hettas upp till en temperatur under det huvudsakliga ämnets smältpunkt. Vid denna temperatur kan diffusion mellan partiklarna ske vilket leder till midjebildning. Midjorna växer med tiden och till slut växer alla partiklar ihop och porositeten går mot noll, se fig 4. Denna sammanväxt leder till att detaljen krymper, hur mycket den krymper beror huvudsakligen på hur långt förloppet gått och initiell porositet efter kompaktering. Diffusionsförloppet bestäms av materialets temperatur, kontaktyta mellan partiklarna och tid spenderad i den höga temperaturen. Genom att variera sintringstemperatur, tid och pulvrets sammansättning kan alltså den slutgiltiga produktens porositet och styrka kontrolleras.

Figur 4 : Diagram av sintringsprocessen, först komprimeras det lösa pulvret i den önskade formen, sedan sintras det så att partiklarna växer ihop och porerna krymper [7, s.34]

Legering kan ske genom sintring, då blandas partiklar av legeringselement såsom grafit eller mangan in i pulverblandningen innan sintring. I ugnen diffunderar dessa legeringsämnen ut i huvudämnet, denna process sker långsammare än sammanfogningen av huvudämnet. Ofta används även material med sig-nifikant lägre smältpunkt än det huvudsakliga ämnet i pulverblandningen, i järnbaserade blandningar är det främst koppar som används. Vid sintringen smälter dessa material och flödar genom kapillärverkan in i porerna mellan huvudpartiklarna, det ger ökad styrka och lägre porositet. [5]

2.2 Sintringsatmosfärer

Under sintringsprocessen i en sintringsugn förs detaljen genom ett antal olika temperaturzoner. Dessa temperaturzoner har utöver olika temperaturer olika atmosfärer. Atmosfärens kemiska komposition är av stor vikt för detaljens slutgiltiga kvalitet. Medans temperaturerna orsakar själva sintringsprocessen är den kontrollerade atmosfären ansvarig för att pulvret behåller, eller uppnår, den önskade kemiska kompositionen.

De vanligaste ugnsatmosfärstyperna är ”avkolningsminskande”, ”karburiseringsminskande” och ”neutral” [1].

En avkolningsminskande atmosfär syftar till att minska eller eliminera stålets avkolning. Det gör att kolet stannar kvar i stålet och detaljen bibehåller sin tänkta kemiska komposition. Atmosfären

(17)

kan vanligtvis bestå av väte eller separerad ammoniak, vilket är ammoniak som brutits isär till dess beståndsdelar; väte och kväve.

Den karbsuriseringsminskande atmosfären minskar eller tar bort stålets förmåga att ta upp mer kol från atmosfären. För att göra detta kan endogas, endotermisk gas, användas. Se ordlistan för mer information om endogas. Gasen förhindrar att detaljens yta oxideras, vilket gör att den inte reagerar med kol i luften. Endogas innehåller bland annat kvävgas, kolmonoxid och vattenånga. Ånghalten i gasen är vanligtvis ungefär 4% vilket gör gasen extremt avkolnande. För att anpassa gasen till sintringsprocessen reduceras ånghalten till högst 0.2%. Detta görs genom nedkylning och torkmedel. När ånghalten når

0.2% har gasen en daggpunkt på -10◦C [1]. Detta gör daggpunkten till en viktig parameter att styra då

den har stor påverkan på stålets kvalitet.

En neutral atmosfär innehåller kväve som tillsammans med ämnen i detaljen skapar reducerande och karburiserande förhållanden. Både den reducerande och karburiserande effekten kan kontrolleras genom att släppa in små mängder av olika gaser.

2.3 Processorer och kontrollenheter

Här presenteras processorer, mikroprocessorer och kontrollenheter som är relevanta för projektet.

2.3.1 Raspberry pi

En Raspberry pi är en enkortsdator med mycket kompakt fysiskt format, se fig 5. Medans den fysiska datorn inte är open-source är all mjukvara det, vilket förenklar användning och modifiering av existeran-de kod. Den är billig jämfört med industriella lösningar och har ett stort bibliotek av färdiga moduler. Det finns även många olika tilläggskort för att utöka enkortsdatorns hårdvara och en aktiv användar-grupp som utvecklar open-source mjukvara för användning på datorn. Dock har en Raspberry pi mindre processorkraft än en större dator och är mindre fysiskt och elektroniskt tålig.[8]

Figur 5 : En Raspberry pi 3 b+

2.3.2 Industrialiserad Raspberry pi

Byggd på samma arkitektur som en ordinarie Raspberry pi men med ytterligare portar av typer som är vanliga inom industrin. De är även anpassade för att passa in i PLC, HMI och övervakningsdator

(18)

strukturen som ofta används inom industri. Exempel på industrialiserade Raspberry expansionskort är Unipi 1.1, se fig 6 [9], och Monarco hat [10]. De är billigare än standard industriella PLC system, men signifikant dyrare än en enkel Raspberry pi. De är ofta byggda så att elektroniken tål mer än en standard Raspberry pi.

Figur 6 : En Raspberry pi kopplad till en Unipi 1.1 expansionskort. Tack till Unipi technology för tillstånd [9]

2.3.3 PLC, HMI och Övervakningsdator

PLC är industriella mikrokontroller, se fig 7, som programmeras med så kallad ladderprogrammering, de är mycket pålitliga och tåliga men har mindre processorkraft och funktioner än en enkortsdator. En PLC har heller inget sätt att kommunicera information till en användare eller långsiktigt spara data utan måste kombineras med HMI(Human Machine Interface) enheter och övervakningsdatorer för att kunna utföra dessa funktioner. Den mjukvara som körs på dessa enheter är även closed source, och kostar ofta en avsevärd mängd. Enheterna kostar även mer än motsvarande open source lösningar. [11]

Figur 7 : En PLC processor, CPU 416-3 från Siemens Simatic s7-400 serien [12]

2.4 Mjukvara

Mjukvara eller programvara är datorprogram eller operativsystem som kan köras på datorer eller andra processorenheter. Nedan presenteras mjukvara relevant för projektet.

(19)

2.4.1 OPCUA

OPCUA (Open Platform Communications Unified Architecture) är ett standardiserat protokoll för kommunikation mellan maskiner i industriell miljö. Det används i stor utsträckning för att imple-mentera övervakning och dataloggning av industriell styrenheter. Protokollet är plattforms- och tillverkaroberoende, det vill säga att det är kompatibelt med och kan köras på Linux, Windows, PLCer och mycket annat. Det finns många implementationer av OPCUA i olika programspråk, men alla har samma typer av funktioner och kan kommunicera med varandra tack vare den delade standarden.[13] OPCUA indelas generellt i en eller flera klienter och en eller flera servrar. Klienterna kommuni-cerar med servern, där servern skickar information till klienterna. Servern är den mer hårdvarunära delen i systemet som tillhandahåller data från något styrsystem, denna data kan sedan avläsas av klienter. Datan på en server är organiserad i ett system av så kallade noder, där alla noder har ett unikt id. Avläsningen av noder kan ske antingen genom ett abonnemang där servern skickar uppdateringar till klienten som abonnerar när någonting händer, vanligtvis när det abonnerade värdet ändras. Eller genom att klienten efterfrågar värdet av en nod, som sedan skickas av servern vid första möjliga tillfälle. En del nyare industriella styrsystem inkluderar en OPCUA server på enheterna för att underlätta implementation av loggning och kontroll. För detta projekt är det främst är det PLCer av märke Siemens som berörs och då specifikt S7-1500.[14]

2.5 Mätrullar och mätplattor

Mätrullar är cylindrar som kan mäta vikt genom vertikal belastning samtidigt som de tillåter detaljer att rulla vidare ovanpå dem, se fig 8. Dessa används ofta i industrier med höga enhetsflöden. Exempel på dessa är ”BMGZ021 – Robust measuring roller for flat conveyor belts” från FMS [15] och ”Roller conveyor YRO” från KERN [16].

Figur 8 : Enkel skiss på en mätrulle-enhet med en rulle. De kan ha flera mätrullar för att mäta i flera punkter eller för att stabilisera detaljer ovanpå dem

Mätplattor är ungefär som vanliga vågar, skillnaden är att det inte finns en display eller att den är separat från själva mätenheten. De är specialiserade för industriellt bruk och har då seriell anslutning, som till exempel USB eller RS-232. Exempel på mätplattor är ”iWeigh 8” x 8” Weigh Module” från Loadstar Sensors [17], ”EC-NSW” från WIPOTEC OCS [18] och ”Portable Industrial Scale PCE-PB 60N” från PCE Instruments [19].

(20)

3 Metod

Metoden som används under projektets gång är baserad på Ulrich & Eppingers produktutvecklingsmetod [20], men skiljer sig något, se fig 9. En av skillnaderna är att en uppdelning av konceptgenerering och evaluering kommer utföras. De delas in i tre huvudområden, datorarkitektur, fysisk konstruktion och viktmätning. Detta för att underlätta arbetet. Dessutom kommer speciellt fokus läggas på att utföra kontinuerliga tester under system- och detaljdesignsfaserna, se fig 10. Det kommer även inte göras någon massproduction. Viktmätningen har en separat utvecklingsprocess som påbörjas senare i projektet än utvecklingen av huvudprodukten. Denna utvecklingsprocess förs enbart till konceptevalueringssteget.

Figur 9 : Visualiering av Ulrich & Eppingers produktutvecklingsmetod

Figur 10 : Visualiering av den modifierade verisionen av Ulrich & Eppingers produktutvecklingsmetod. De två nivåerna från steg 1 till 4 representerar indelningen i fysisk konstruktion och mjukvaruutveckling

3.1 Planering

Projektet inleds med planeringen där tidsplaner och planeringsrapport görs. Tidsplanen görs för att få en uppfattning av prioriteringen av ingående delar. Med en tillräckligt bra tidsplan kan arbetet helt följa tidsplanen och projektet kan utföras på ett optimalt sätt. Delmål ställs upp i tidsplanen för att tvinga arbetet att nå en viss punkt vid ett visst tillfälle. Detta säkerställer att projektet når dit det är tänkt och då kan avslutas som planerat.

(21)

3.2 Konceptutveckling

Konceptutvecklingen behandlar framtagning av behov, krav, koncept samt evaluering av dessa koncept.

3.2.1 Kundbehov

Första steget i konceptutvecklingen är framtagning av kundbehov. Detta kan ske på olika sätt beroende på projektets upplägg. Det kan ske med hjälp av t.ex. enkäter, marknadsundersökningar eller intervjuer. Kundbehov kan dessutom tas fram från projektbeskrivningar där projektägarna specificerar vad de vill att produkten ska klara av samt andra avgränsningar. Dessa kompileras i en kundbehovslista som används för framtagning av en kravspecifikation.

Kundbehoven delas in i två delar, huvudprodukt och viktmätning, då behoven för dessa är olika.

3.2.2 Kravspecifikation

Kravspecifikationen baseras på kundbehoven, men även fysiska begränsningar eller mål för produkten. För att underlätta fortsatt arbete sätts numeriska krav i så stor utsträckning som möjligt. Detta görs för att underlätta konceptevalueringen och eventuella tester av den färdiga produkten.

I kravspecifikationen konverteras kundbehoven till produktkrav som beskriver vad produkten be-höver göra eller hur den beter sig i olika situationer. Målet med kravspecifikationen är att minska eller eliminera subjektiva behov för att möjliggöra en objektiv design och evaluering.

Likt kundbehoven görs två kravspecifikationer.

3.2.3 Konceptgenerering

Konceptgenereringens mål är att framställa så många idéer och designer som möjligt. Det finns en uppsjö olika metoder för själva konceptgenereringen där metoder passar olika bra beroende på projekt, personer samt tidsbegränsningar. Koncepten ska kunna tillgodose kundbehoven samt uppnå ändamålet för produkten. De behöver dock inte vara inom ramen för rimlighet, orimliga koncept kan föra tankegångar till nya koncept som kanske är rimliga. Antalet koncept som tas fram är enligt Ulrich & Eppinger vanligtvis cirka 10 till 20 stycken. Detta kan dock variera beroende på projektets utseende. Fler koncept är dock att föredra då antalet outforskade idéer minskar.

Som tidigare nämnt under rubrik 3 Metod delas detta steg upp i tre delar, datorarkitektur, fysisk konstruktion samt viktmätning.

3.2.4 Konceptevaluering

Konceptevalueringen fungerar som ett avslutande steg för konceptutvecklingen. Koncepten som togs fram i konceptgenereringen jämförs och evalueras för att få fram den bästa lösningen och bästa produkten. Koncepten kan evalueras på många olika sätt men de baseras alltid på kravspecifikationen, där koncepten jämförs efter hur väl de uppfyller kraven. Kraven viktas även för att få fram det koncept som uppfyller de viktigaste kraven på bästa sätt.

Som tidigare nämnt under rubrik 3 Metod delas detta steg upp i tre delar, datorarkitektur, fysisk konstruktion samt viktmätning.

3.3 Systemdesign

I systemdesignsfasen definieras produktens arkitektur samt en nedbrytning av produkten i delsystem. En preliminär design av de viktigaste komponenterna görs och även en preliminär assembly i ett CAD (Computer Aided Design)-program. Detta för att få en uppfattning av produktens generella form, storlek

(22)

och utseende. I denna fas kan större problem upptäckas och åtgärdas.

Systemdesignen är det som konceptgenereringen och evalueringen kommer att beröra. Detta på grund av att detaljdesignen innefattar för många designval för att det ska vara lönsamt.

3.4 Detaljdesign

I detaljdesignen utformas alla ingående komponenter i alla system. Detta inkluderar fastställning av geometri, material, toleranser samt standardkomponenter. Detaljdesignen utgår från och påverkas av systemdesignens utformning.

Som nämnt i 3.3 utförs detaljdesignen utan dokumenterad konceptgenerering och evaluering. De-signval diskuteras och testas för att snabbare uppnå en väl fungerande design. Detta på grund av den mängd val som måste göras på den förutbestämda tiden.

3.5 Testning och förfining

Under testning och förfiningen produceras en eller flera prototyper som används för att testa produktens funktioner. Beroende på resultaten från de utförda testerna förfinas produkten. Förfiningen kan ske på olika sätt, t.ex. kan en ny konceptgenerering utföras centrerad kring de problem som uppstod. När produkten klarar alla tester på en tillfredsställande nivå kan en slutprodukt produceras.

I detta projekt kommer testningen att ske parallellt med tidigare steg då det bedöms nödvändigt för att uppnå en slutgiltig produkt. Tester utförs på prototyper och specifika delar av produkten. På grund av detta ses detta steg istället som steget för sluttester. Dessa sluttester verifierar produktens funktioner i sin helhet.

Detta steg följs vanligtvis av massproduktion, se fig 9, eftersom detta inte kommer göras i detta projekt ignoreras det steget.

(23)

4 Genomförande

I detta kapitel beskrivs genomförandet av projektet.

4.1 Planering

Planeringen av projektet startade med möten med projektägarna vid Höganäs, där beskrevs projektet samt hur tidsplaner kan tänkas se ut med start och slutdatum. Därefter skrevs en projektbeskrivning följt av möte med projektägare, handledare samt examinator där projektets mål fastställdes. En preliminär tidsplan gjordes innan besök på Höganäs anläggning hade schemalagts. Detta gjordes för att möjliggöra en tidigare start på det initiala arbetet. Efter ytterligare möte med projektägarna fastställdes ett slutgil-tigt schema med besökstider i Höganäs. Sedan lades ett slutgilslutgil-tigt GANTT-schema upp. Stora delar av projektet förlades på plats i Höganäs kundcentra för att förenkla arbetet med projektets praktiska delar.

4.2 Kundbehov

Kundbehov togs fram främst genom möten med projektägarna samt genom projektbeskrivningen. Behov togs även fram genom analys av själva ugnen och styrenheter. Dessa kundbehov kompilerades i en lista som sedan användes som grund för kravspecifikationen, se tab 1. För mätningen av in- och ut-vikter behövdes andra kundbehov tas fram.

Tabell 1: Tabulerade kundbehov för huvudprodukten, bestämda utifrån projektägarens önskemål

Behov # Behov

1 Produkten stör inte regelbundet bruk av ugn

2 Produkten måste tåla den industriella miljön

3 Produkten behöver kunna automatiskt logga all data

4 Data måste sparas på ett lättillgängligt sätt

5 Sparad data måste gå att visualiseras

6 Produkten får inte avsevärt modifiera ugn/annan utrustning

7 Produkten måste vara lättanvänd

8 Produkten kan servas om något går fel

9 Produkten är inte alltför dyr

10 Produkten kan skillja på olika processerier

11 Produkten får gärna vara generaliserad, dvs den kan användas till andra maskiner

12 Produkten får gärna kunna logga data från flera maskiner samtidigt

13 Data omvandlas automatiskt till relevanta enheter vid behov

14 Produkten kan kopplas bort från ugnen

15 Produkten innehåller inga farliga ämnen

16 Stöttålighet, exempelvis att man tappar den eller stöter in i den

17 Kablar borde tåla att bli ryckta i utan att kopplas ut

18 Produkten lägger upp data på molnet

19 Produkten får inte vara för stor

Kundbehoven för viktmätningen togs fram på liknande sätt som de för huvudprodukten. Dessa sattes in i en tabell, se tab 2.

(24)

Tabell 2: Tabulerade kundbehov för viktmätningen, framtagna efter projektägarens önskemål

Behov # Behov

1 Produkten mäter vikt på individuella skepp

2 Produkten är inte alltför dyr

3 Produkten kommunicerar med dataspararen

4 Produkten är lätt att implementera

5 Viktmätningen har en rimlig precision

6 Produkten ökar inte produktionstiden

7 Produkten tar inte upp mycket plats

8 Viktmätningen sker automatiskt

9 Produkten är dimensionerad för antalet skepp/min

10 Produkten behöver minimal service

11 Produkkten klarar av vikten från ett fullastat skepp

4.3 Kravspecifikation

Kravspecifikationen baserades på kundbehoven och gavs numeriska värden för att möjliggöra kvantifie-ring av parametrar. Värdena togs fram från projektägarnas önskemål samt genom logisk rimlighet. De delades in i två kategorier, marginella samt optimala värden, där de marginella värdena är en lägsta nivå som ska uppnås. De optimala värdena kunde ses som mål att sikta för som är väldigt bra om de uppnås. Dessa krav skrevs upp i en tabell, se tab 3.

De givna parametrarna som skulle mätas var följande. • Ugninställda parametrar

– Temperaturinställningar zon för zon (bör- och ärvärden) – Bandhastighet (bör- och ärvärden)

• Ugnsatmosfär – Daggpunkt – Syrepartialtryck – CO-halt – H2-halt • In-/utmatning från ugn – Skeppräkning

Med ”Temperaturinställningar zon för zon (bör- och ärvärden)” menas både den inställda eftersökta temperaturen, börvärdet. Samt den faktiska temperaturen, ärvärdet, vid varje zon i ugnen. Denna konti-nuerliga bandugn har flera zoner med olika temperaturer som uppfyller olika funktioner.

(25)

Datalogger för sintringsugn Nygårds, E., Oli w , M.

Tabell 3: Den framtagna kravspecifikationen för huvudprodukten. Prioriteringsgraderna betyder att krav med värdet 1 är absoluta måsten och har högst prioritering. Prioritering 2 är mycket bra att ha medans 3 betyder att det kan vara bra att ha. Med procenthalten för generaliseringen menas hur generaliserad produkten är. Där 0% betyder att produkten helt måste göras om för att användas vid en ny maskin. Medan 100% betyder att den kan kopplas in i vilken maskin som helst på Höganäs utan modifiering

Behovs # Kravspec # Kravspec Kriterie Marginellt värde Optimalt värde Prioritering 1 1 Produkten stör inte ordinarie

funktion av tillkopplad maskin Binärt TRUE 1

2 2 Dammintrång är begränsat Procenthalt som kommer in

(%) 5 ca 0 2

2 3 Processorenheten överhettar ej *C 70 60 2

2 4 Temperaturintervall produkten

klarar *C 10-50 0-65 2

3 5 Produkten lagrar data automatiskt Binärt TRUE 1

4 6 Sparad data är lättilgänglig Binärt TRUE 1

5 7 Sparad data kan visualiseras Binärt TRUE 1

6 8 Produkten modifierar inte ugnen

vid montage Binärt TRUE 1

7 9 Produkten har ett lämpligt

HMI(Human Machine Interface) Binärt TRUE 1

8 10 Hårdvara lättåtkommen

(Tid att öppna) Tid (min) 10 3 3

9 11 Kostnad att tillverka Kr (kr) 4000 1500 2

10 12 Produkten skiljer på datan från

olika lotter Binärt TRUE 1

11 13 Produkten är generaliserad Procent (%) 0 85 3

12 14 Produkten lagrar data från flera

maskiner samtidigt Antal maskiner inkopplade 1 9 2

13 15 Data presenteras i korrekta enheter Binärt TRUE 1

14 16 Produkten är borttagbar Binärt TRUE 1

15 17 Produkten följer RoHS-direktivet [21] Binärt TRUE 1

16 18 Produkten tål ett fall från x meters

höjd på flat yta Meter fallhöjd(m) 1 3 3

17 19 Newton dragkraft på kabel

utan urkoppling Newton dragkraft (N) 10 30 3

18 20 Produkten lägger upp data

på molnet Binärt TRUE 1

19 21 Storlek i x, y, z Meter 0,4 x 0,4 x 0,2 0,2 x 0,1 x 0,08 2

(26)

För viktmätningen gjordes en separat kravspecifikation, se tab 4, baserad på dess separata kundbehov, se tab 2.

Tabell 4: Kravspecifikationen för viktmätningen, prioriteringsgraderna är lika som för huvudproduktens kravspecifikation

Behovs # Kravspec # Kravspec Kriterie Marginellt värde Optimalt värde Prioritering

1 1 Produkten mäter vikt på

individuella skepp Binärt TRUE 1

2 2 Kostnad Kr 2000 1000 2

3 3 Produkten kommunicerar

med dataspararen Binärt TRUE 1

4 4 Produkten modifierar inte

ugnen avsevärt Binärt FALSE TRUE 2

4 5 Produkten kräver inte

mjukvaruförändringar (ugn) Binärt FALSE TRUE 2

5 6 Viktmätningsprecision Felmarginal (g) +-35 +-25 2

6 7 Avbrott i produktion för att mäta vikt Produktionsavbrott (s) 2 0 3

7 8 Storlek utanför ugnen Meter 0,3 x 0,3 x 0,8 0,2 x 0,2 x 0,1 2

8 9 Viktmätningen kräver inte

mänskligt utförande Binärt FALSE TRUE 2

9 10 Enheter per minut produkten klarar

att väga utan förlorad precision Enheter/minut >0,25 0,25 2

10 11 Produkten behöver inte

regelbunden service Binärt FALSE TRUE 2

11 12 Vikt produkten klarar Kg 2,5 3 2

(27)

4.4 Konceptgenerering

Konceptgenereringen syftade till att ta fram övergripande koncept för produktens arkitektur, samt ko-cenpt för viktmätningen. Där togs koncept fram för generell produktionsmetod, försegling och kylning, men även för den övergripande arkitekturen för datasamling samt processoralternativ. Detaljdesignen stod för designen av själva komponenterna, till exempel designen på datasamlarens inkapsling och kabelgenomföring.

Genereringen av koncept för huvudprodukten inleddes med att två tankekartor (mindmaps) gjor-des, en för den fysiska konstruktionen (se bilaga B.1), och en för dator och elektronik (se bilaga B.2). För att få inspiration samt för allmän information undersöktes redan existerande lösningar, produkter samt processoralternativ. Därefter diskuterades idéer och lösningsförslag, dessa fördes sedan in i respektive tankekarta. Dessa tankekartor användes som baser i konceptgenereringen. De användes även som inspiration och hjälp till detaljdesignen.

4.4.1 Koncept - Datalogger

Genereringen av koncept delades in i två områden, likt de två tankekartorna, i fysisk konstruktion samt dator och elektronik, se tab 5 och 6. Detta gjordes då det bedömdes att de inte hade stor påverkan på varandra och att det därav blev lättare att utföra hela konceptsgenereringen.

Koncepten för datorarkitekturen togs fram från dess tankekarta, se bilaga B.2. Dessa ställdes upp i en kombinationsmatris där ett koncept i en kolumn kan kombineras med ett annat i den andra kolumnen, se tab 5.

Tabell 5: Resulterande kombinationsmatris av koncepten för arkitektur och styrenhetsalternativ. Med slavsystem menas ett system med mindre kraftfulla enheter på varje maskin som kommunicerar med en större enhet som sammanställer datan

Arkitektur Styrenhetsalternativ

DA1. Slavsystem P1. Raspberry pi

DA2. En enhet per ugn P2. Industrialiserad Rapsberry pi

DA3. En enhet för alla P3. PLC(Programmable Logic Controller), HMI, övervakningsdator

P4. Mikrokontroller, arduino P5. PC (Personal Computer)

De fysiska koncepten togs från tillhörande tankekarta och fördes in i en kombinationsmatris, se tab 6. Varje enskild cell i en kolumn kan kombineras med en annan cell i båda de andra två kolumnerna, förutom ”A5. Inget skal”, för att bilda en kombination som sedan kan utvärderas.

Tabell 6: Kombinationsmatris för de fysiska konsutrktionskoncepten på systemnivå

Allmän konstruktionsmetod Försegling Kylning

A1. 3D-print F1. Chassifläkt, ofiltrerad K1. Konvektion

A2. Ihopfästa plattor F2. Chassifläkt, filtrerad K2. Påtvingad konvektion

A3. Installationslåda F3. Väl förseglad K3. Kylvattenledning

A4. Fabriksskal F4. Halvöppen K4. Ingen kylning

A5. Inget skal

(28)

4.4.2 Koncept - Viktmätning

Koncepten för viktmätningen togs fram genom en undersökning av redan existerande lösningar. De fär-diglösningar som hittades användes antingen direkt som ett lösningskoncept eller som inspiration för vad som kan göras för att lösa viktmätningen. Först sammanställdes de olika koncepttyperna i en kombina-tionsmatris, se tab 7. På grund av utrymmesbrist vid implementation var positionen av enheten av stor vikt, därav togs även den med i matrisen.

Tabell 7: Kombinationsmatris för viktmätningskoncepten, d.v.s. en cell i kolumn ett kan kombineras med

någon cell i kolumn två. Se fig 2 för positionsförklaring. Med ´´USB våg´´ menas en vanlig våg, till

exempel köksvåg, med en seriell port. Se kapitel 2.5 för förklaring av mätrullar och mätplattor.

Viktenhet Position

Mätrulle Innan påmatningsband

Mätplatta Under påmatningsband

USB våg Påmatarplatta

Egen lösning Huvudbandet

Koncepten i kombinationsmatrisen användes sedan som grund för en konceptgenerering där skisser gjordes. Dessa skisser visar hur lösningarna kan se ut, antingen med en köpt färdig produkt eller med en egen skapad lösning, se fig 11 och 12.

(a) Koncept 1, en platt våg under pårampen där skeppen passerar över och mäts i farten

(b) Koncept 2, mätrulle monterad under påmatar-bandet precis där skeppen stannar innan påmatning

(c) Koncept 3, en fjäder med avståndssenssor mon-terade på påmatararmen. Fjädern komprimeras och avståndssensorn mäter distansen, vid konstant has-tighet kan då vikten bestämmas om friktionskon-stanten är känd

(d) Koncept 4, en separat våg på ett bord bredvid påmatarbandet. Skeppet vägs först för att sedan för-flyttas upp på påmatarbandet

Figur 11 : Koncept 1-4 för viktmätningen, koncepten kan använda antingen färdiga produkter eller eg-nakonstrueras. Koncept 3 kan inte använda färdiga produkter

(29)

Figur 12 : Koncept 8, en egen lösning. Lastceller fastmonterade i pårampen och ugnen eller påmatarban-dets sida

Fler koncept än de som visas ovan gjordes i detta steg, dessa återfinns under bilagor, se bilaga B.3 till och med bilaga B.10. På grund av likheten mellan på och av sidorna av ugnen gjordes inte separata koncept för dem. Istället återanvändes koncepten för påmatningen till avmatningen. Skillnaden mellan dem var att avrampen var betydligt kortare än pårampen, se fig 2. Detta gjorde att vissa koncept kunde få svårt att fungera väl på grund av utrymmesbristen där, till exempel Koncept 1, se fig 11.

4.5 Konceptevaluering

Konceptevalueringen skedde i tre olika moment. Först utvärderades systemkoncepten, de koncept rörande dator arkitekturen. Följt av koncepten för den fysiska konstruktionen och till sist viktmätningen. För system- och konstruktionskoncepten eliminerades orimliga koncept först, följt av två beslutsmatriser där koncepten betygsattes beroende på hur bra de uppfyllde vissa viktade krav. I beslutsmatriserna användes först ett utvalt koncept som referens, varefter vinnaren av den första matrisen användes som referens i den andra.

För viktmätningen gjordes först en inledande beslutsmatris där de bästa koncepten användes som grund för vidare utforskning av lösningsrymden. Dessa nya koncept utvärderades sedan i en beslutsma-tris för att komma fram till det teoretiskt bästa konceptet.

4.5.1 Datorarkitektur - Konceptevaluering

Evalueringen av datorarkitekturen påbörjades genom en så kallad koncept screening [20] där de minst lämpade alternativen avlägsnas.

Från kombinationsmatrisen för dator arkitektur, se tab 5, elimineras PC och arduino mikrokontroller. PC på grund av dess överdrivna storlek, se krav 21 i tab 3. Arduino eller liknande mikrokontroller saknar förmåga att kommunicera med molnet och är därmed inte lämpligt för bruk som central kontrollenhet för produkten, se krav 20 i tab 3.

Koncepten utvärderades sedan i en beslutsmatris med kriterium baserade på kravspecifikationen. Först med PLC baserat system som referens då det är industristandardsystem för att utföra datalagrande uppgifter, se tab 8. Sedan gjordes en andra utvärdering men med vinnaren av den första evalueringen som referens, se tab 9. En poängskala från -2 till 2 användes för att rangordna koncepten beroende på hur bra de uppfyllde kraven jämfört referensen.

(30)

Tabell 8: Datakonceptevaluering 1, med slavsystem med PLC som centralenhet som referenskombination, detta då den typen av system är det som typiskt används inom industri

Krav# Kriterie Vikt DA1 + P1

Slav. Rpi DA1 + P2 Slav. IRpi DA1 + P3 Slav. PLC. DA2 + P1 1 per ugn. Rpi

DA2 + P2 1 per ugn. IRpi

DA3 + P2 1 för alla. IRpi 21 Kompakthet 2 1 0 0 1 0 2 11 Pris 5 2 1 0 1 0 2 - Utvecklingsvänlighet 4 1 1 0 2 2 1 2, 4 Miljötålighet 1 -2 -1 0 -2 -1 -1 - Driftsäkerhet 3 -2 -2 0 -1 -1 -1 - Supporttillgänglighet 3 2 2 0 2 2 2

14 Max antal maskiner 4 2 2 0 0 0 -2

Summa: 4 3 0 3 2 3

Viktad summa: 22 16 0 16 10 12

Tabell 9: Datakonceptevaluering 2, med förra beslutmatrisens vinnare som referens

Krav# Kriterie Vikt DA1 + P1

Slav. Rpi DA1 + P2 Slav. IRpi DA1 + P3 Slav. PLC. DA2 + P1 1 per ugn. Rpi

DA2 + P2 1 per ugn. IRpi

DA3 + P2 1 för alla. IRpi 21 Kompakthet 2 0 -1 -2 0 -2 1 11 Pris 5 0 -1 -2 -1 -1 0 - Utvecklingsvänlighet 4 0 0 -2 2 2 0 2, 4 Miljötålighet 1 0 1 2 0 1 1 - Driftsäkerhet 3 0 0 2 1 1 1 - Supporttillgänglighet 3 0 0 -2 0 0 0

14 Max antal maskiner 4 0 0 -1 -1 -1 -2

Summa: 0 -1 -5 1 0 1

Viktad summa: 0 -6 -24 2 -1 -2

(31)

Efter andra omgången av evalueringen var slavsystem med Raspberry pi som central kontrollenhet och system med en Raspberry pi som kontroll och datasmalingsenhet per ugn de mest attraktiva koncepten för fortsatt utveckling. Systemet med en Raspberry pi per loggad maskin valdes för vidareutveckling då den ansågs enklare att utveckla och var billigare för mindre system då inga extra mikrokontrollers behövde inköpas. Kostnaden skulle dock vara lägre om ett större system önskades, då det skulle vara billigare att utöka nätverket med mikrokontroller än med Raspberry pi.

4.5.2 Fysisk konstruktion - Konceptevaluering

Evaluering av produktens fysiska konstruktionen delades in i två delar. Först bestämdes den allmänna konstruktionsmetoden för konstruktion av höljen, fästen och liknande, se tab 10. Dessa koncept evalu-erades för sig då de ansågs mestadels oberoende av de andra koncepten och därav separerbara. Då det fanns fler koncept för den fysiska konstruktionen än för dator arkitekturen valdes en ny rankingskala om -3 till 3. Detta för att lättare se skillnader mellan koncepten.

Tabell 10: Första beslutsmatris för den allmänna konstruktionsmetoden, se tab 6 för namnförklaring

Krav# Kriterie Vikt A1.

3D-print A2. Plattor A3. Installationslåda A4. Fabriksskal A5. Inget 2 Begränsat dammintrång 5 3 1 3 0 0 - Designfrihet 4 3 2 1 0 0 10 Lättåtkommen 2 -2 -2 -2 -3 0 11 Kostnad 3 -1 -2 -3 -3 0 18 Falltålighet 1 1 2 3 2 0 19 Kabelavlastning 3 3 2 2 1 0 - Produktionstid 2 -3 -2 -1 0 0 Summa: 4 1 3 -3 0 Viktad summa: 24 7 13 -10 0

Enligt tab 10 var 3D-printing den bästa produktionsmetoden givet de rådande förutsättningarna. På grund av detta användes det som referens i den kommande utvärderingen.

Tabell 11: Andra belutsmatrisen för evaluering av allmän kostruktionsmetoden

Krav# Kriterie Vikt A1.

3D-print A2. Plattor A3. Installationslåda A4. Fabriksskal A5. Inget 2 Begränsat dammintrång 5 0 -2 -1 -3 -3 - Designfrihet 4 0 -1 -2 -3 -3 10 Lättåtkommen 2 0 0 0 -1 3 11 Kostnad 3 0 -1 -2 -3 3 18 Falltålighet 1 0 2 3 2 -3 19 Kabelavlastning 3 0 -1 -1 -2 -3 - Produktionstid 2 0 1 2 3 3 Summa: 0 -2 -1 -7 -3 Viktad summa: 0 -16 -15 -36 -18

Enligt tab 11 förblev 3d printing det bästa alternativet. Därför gick konceptevalueringen vidare med detta som underlag. För att reducera antalet kombinationer samt för att eliminera orealistiska kombinationer

(32)

gjordes en koncept screening, likt den för dator arkitekturen. Exempel på kombinationer som togs bort är ”F3. Väl förseglad” med ”K2. Påtvingad konvektion” då en fläkt inte kan fungera som den ska om den är tätt förseglad, se tab 6. Även de båda chassifläktsalternativen tillsammans med ”K4. Ingen kylning” togs bort då chassifläktarna naturligt ger kylning. När screeningen var klar utvärderades resterande kon-cept baserat på att de produceras med 3D-printing. I första jämförelsen användes ”A5. Inget skal” som referens, se tab 12. I den andra evalueringen användes vinnaren av den första som referens, se tab 13.

(33)

Tabell 12: Första beslutsmatris för evalueringen av tätning och kylningskombinationer för 3D-printning. Här är A5 referens

Krav# Kriterie Vikt

F1 + K2 Ofiltrerad Chassifläkt F2 + K2 Filtrerad Chassifläkt F3 + K1 Väl förseglad, Konvektion F3 + K3 Väl förseglad, Kylvattenled. F3 + K4 Väl förseglad, Ingen kylning F4 + K1 Halvöppen, Konvektion F4 + K2 Halvöppen, Påtvingad konvektion F4 + K3 Halvöppen, Kylvattenled. A5 Inget 2 Begränsat dammintrång 5 1 2 3 3 3 0 0 0 0 3 Kylning 1 2 0 -1 1 -3 0 2 3 0 10 Lättåtkommen 2 -2 -2 -3 -3 -3 -1 -1 -1 0 11 Kostnad 3 -2 -3 -2 -2 -2 -1 -2 -1 0 13 Generaliserbarhet 3 -1 -1 0 -3 0 0 0 -3 0 18 Falltålighet 1 2 2 3 3 3 1 1 1 0 19 Kabelavlastning 3 3 3 3 3 3 3 3 3 0 21 Storlek 1 -2 -2 -1 -1 -1 -1 -1 -1 0 - Produktionstid 2 -2 -2 -2 -2 -2 -1 -2 -2 0 - Komplexitet 3 -2 -3 -2 -2 -1 0 -1 -1 0 Summa: -3 -6 -2 -3 -3 0 -1 -2 0 Viktad summa: -7 -10 3 -4 4 2 -4 -9 0

Tabell 13: Andra beslutsmatrisen för evalueringen av tätning och kylningskombinationer för 3D-printning. Här är kombinationen F3 + K4, väl förseglad utan kylning referens

Krav# Kriterie Vikt

F1 + K2 Ofiltrerad Chassifläkt F2 + K2 Filtrerad Chassifläkt F3 + K1 Väl förseglad, Konvektion F3 + K3 Väl förseglad, Kylvattenled. F3 + K4 Väl förseglad, Ingen kylning F4 + K1 Halvöppen, Konvektion F4 + K2 Halvöppen, Påtvingad konvektion F4 + K3 Halvöppen, Kylvattenled. 2 Begränsat dammintrång 5 -2 -1 0 0 0 -3 -2 -3 3 Kylning 2 2 1 1 2 0 1 2 3 10 Lättåtkommen 2 1 1 0 0 0 2 2 2 11 Kostnad 3 -2 -3 -1 -1 0 -1 -2 -1 13 Generaliserbarhet 3 -1 -1 0 -3 0 0 0 -3 18 Falltålighet 1 -1 -1 0 0 0 -2 -2 -2 19 Kabelavlastning 3 0 0 0 0 0 0 0 0 21 Storlek 1 -1 -1 0 0 0 0 0 0 - Produktionstid 2 0 0 0 0 0 1 0 0 - Komplexitet 3 -2 -3 -1 -1 0 2 0 1 Summa: -6 -8 -1 -3 0 0 -2 -3 Viktad summa: -21 -24 -4 -11 0 -6 -10 -16 22

(34)

4.5.3 Viktmätning - konceptevaluering

Konceptevalueringen för viktmätningen inleddes med en beslutsmatris där koncepten i kapitel 4.4.2 jämfördes för att ta reda på de teoretiskt bästa koncepten. Denna beslutsmatris innehöll två egengjorda lösningar med resten färdiga produkter. Detta gjorde att beslutsmatrisen gav en bra insikt i vilka typer av lösningar som var passande.

Beslutsmatrisen använde, likt tidigare evalueringar, viktade krav från kravspecifikationen för vikt-mätning. Jämförelseskalan var från -3 till 3 där högre poäng var bättre, referenskonceptets poäng sattes till 0 på alla kriterier, se tab 14.

Tabell 14: Första utvärderingen av viktmätningskoncepten, se bilaga B.3 t.o.m. B.10 för bilder på alla koncept i denna tabell. Från denna evaluering beslutades att fortsätta utveckla koncept 4 och 8

Krav# Kriterie Vikt Koncept 1 2 3 4 5 6 7 8

2 Kostnad 4 0 -1 2 1 0 -1 -2 3

4 Produkten modifierar

inte ugnen avsevärt 2 0 0 1 3 0 0 -3 0

6 Viktmätningsprecision 2 0 -1 -3 2 -2 -1 0 1

7 Avbrott i produktion

för att mäta vikt 1 0 0 0 -1 0 0 0 0

8 Enhetens storlek 2 0 -1 1 3 -1 0 1 3

9 Viktmätningen kräver inte

mänskligt utförande 4 0 0 0 -3 0 0 0 0

10 Enheter per minut produkten klarar

att väga utan förlorad precision 3 0 0 0 -1 0 0 0 0

11 Produkten behöver inte

regelbunden service 4 0 -1 -3 3 -2 -1 -2 1

12 Vikt produkten klarar 5 0 0 -1 0 0 0 1 0

- Simplicitet 2 0 -1 -2 3 -1 -1 -3 2

Summa: 0 -5 -5 10 -6 -4 -8 10

Viktad summa: 0 -14 -15 22 -16 -12 -21 28

Då en egengjord lösning fick högst poäng valdes att vidareutveckla egengjorda lösningar. Detta gjordes som en ny konceptgenerering, men med fokus på egengjorda lösningar. Genereringen ledde till följande koncept, se fig 13 och 14.

(a) Koncept 9, lastceller monterade under bandet precis där skeppen väntar för att bli påmatade

(b) Koncept 10, lastceller monterade på påmataren

Figur 13 : Koncept 9-10, båda koncepten är egengjorda lösningar som utgår från lastceller.

(35)

Figur 14 : Koncept 11, drivna rullar med lastceller. Bandet är avkortat för att göra plats åt rullarna

Dessa koncept användes sedan tillsammans med koncept 4 och 8 i en beslutsmatris för att få fram det teoretiskt bästa konceptet, se tab 15.

Tabell 15: Slutgiltiga evalueringen av viktmätningskoncepten. Koncept 8 användes som referens då den hade högst poäng i föregående utvärdering, se tab 14. Resultatet av utvärderingen var att koncept 8 ansågs det bästa med koncept 4 och 9 som reserv ifall koncept 8 ej kan mäta vikt i farten

Krav# Kriterie Vikt Koncept 4 8 9 10 11

2 Kostnad 4 -1 0 0 0 -2

4 Produkten modifierar inte ugnen avsevärt 2 -1 0 0 0 -3

6 Viktmätningsprecision 2 1 0 -1 -3 3

7 Avbrott i produktion för att mäta vikt 1 -1 0 0 0 0

8 Enhetens storlek 2 0 0 0 -1 -2

9 Viktmätningen kräver inte mänskligt utförande 4 -3 0 0 0 0

10 Enheter per minut produkten klarar

att väga utan förlorad precision 3 -1 0 0 0 0

11 Produkten behöver inte regelbunden service 4 3 0 -1 0 -3

12 Vikt produkten klarar 5 0 0 0 0 3

- Simplicitet 2 3 0 0 -1 -3

Summa: 0 0 -2 -5 -7

Viktad summa: -2 0 -6 -10 -15

Då koncept 8, se fig 12, fortfarande fick högst poäng ansågs det vara det teoretiskt bästa konceptet, med koncept 4 och 9 som reservkoncept ifall koncept 8 inte kan mäta vikt medans skeppet förflyttar sig över plattan.

4.6 Systemdesign

Systemdesign av produktens fysiska design inleddes med en allmän schematisk bild av den fysiska designen, se fig 15. Sedan sammanställdes en initiell CAD modell med de olika fysiska delarna av inkapslingen, se fig 16. För CAD modelleringen användes programmet Fusion 360.[22]

(36)

Figur 15 : Schematisk bild av den fysiska konstruktionen

Figur 16 : Den initiella CAD modellen som gjordes under systemdesignen

För att hämta och spara data från de två styrenheterna behövdes ett program skapas. Det beslutades att skriva det i python då en av gruppmedlemmarna hade tidigare erfarenhet av kodspråket och för dess enkla syntax jämfört med exempelvis C eller Assembly.

Då kontinuerlig loggning av data över hela dagar önskades, utöver loggning av produktionsserier, delades programmet upp i två. Ett program för loggning under aktivt bruk av ugnen med hög data-punktsfrekvens och räkning av skepp och ugnsparametrar, hädanefter kallad jobbloggern. Samt ett med låg datapunktsfrekvens som enbart loggade ugnsparametrarna, hädanefter kallad dagsloggern. Dagsloggern, se fig 17, kördes kontinuerligt utan avbrott medans jobbloggern, se fig 18, endast kördes när den manuellt startades.

För att spara data på en tillgänglig plats beslutades att skriva loggfiler på format .csv (comma se-parated values) som sedan laddades upp till en folder på Onedrive[23]. Dagsloggern laddade upp en fil om dagen och jobbloggern när den detekterade att inga skepp fanns i ugnen en viss tid eller den manuellt avslutades.

(37)

Figur 17 : Schematisk bild av kodlogiken i dagsloggen. Datasamlingsloopen skriver data till samma fil över ett dygn. Först när det blir en ny dag skickar den upp filen på Onedrive och skapar en ny fil