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.

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

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]

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

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.

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

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

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

Figur 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

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

4.7 Detaljdesign

Detaljdesignen utfördes med hjälp av Fusion 360[22] för CAD modellerna och med Python för programmeringen. Nedan redogörs för den fysiska detaljdesignen samt för utvecklingen av mjukvaran.

4.7.1 Fysisk detaljdesign

Materialet för lådan var PETG (polyethylen terapthalat glykol), det valdes över PLA (Polylaktid) på grund av dess värmetålighet. PETG tål högre temperaturer vilket var till fördel då enheten kunde bli varm under lång tid. [24]

För att försegla enheten valdes att utveckla en försegling inbyggd i skalet där botten och toppen möts, se fig 19. När toppen sedan skruvades fast orsakades en elastisk deformation som förseglade lådan, se fig 21. Denna lösning förlitade sig på de elastiska egenskaperna av den polymer som produkten gjordes av, PETG, och tillverkningsmetodens förmåga att lätt producera komplexa former. Lokal plastisk deformation inträffade då kontaktytan mellan den hemisfäriska undre delen av förseglingen och den övre skåran var mycket liten. Den plastiska deformationen i sin tur gav en tillräckligt stor yta för att vidare deformation förblev elastisk vilket gav en tät försegling av lådan.

Figur 19 : Genomskärning av en prototypmodell av produktens fysiska inkaspling

Då tillverkningen skedde med 3D printad plast skilde sig de tillverkade detaljerna mycket från modellen, specifikt blev små detaljer dåligt representerade, se fig 20. Därför producerades successivt tester av de delar av modellen som hade klena dimensioner för att verifiera funktionen.

För att få en initiell teoretisk verifiering av tätningen gjordes en kontaktbaserad FEM-simulering i Fusion 360. Lastfallet var 11 N tryckkraft på den övre delen av förseglingen med den lägre fixerad i alla leder. Detta för att simulera beteendet av förseglingen så långt från två skruvhål som möjligt. Modellen var ett tvärsnitt av förseglingsgeometrin med ett djup på en mm, se fig 21.

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

Figur 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

(a) (b)

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

För att fysiskt testa tätningen skrevs en del av modellen ut. Detta för att spara tid vid produktionen, men även för att lätt kunna testa de mest kritiska delarna av modellen, se fig 22.

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

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

Utöver att testa tätningen testar modellen ovan i fig 22 kabelgenomföringen samt skruvförbanden. Kabelgenomföringen tätades med en ”klämring”, se fig 23, som utnyttjar kabelns mjukare hölje för att elastiskt deformera den. Då agerar kabeln som en o-ring vilket leder till en tätad genomförning.

Figur 23 : Kabelgenomföringen för den tjockare ethernet kabeln.

Kabeltätningen testades först genom att undersöka om det gick att se hålrum runtom kabeln. När inget hålrum var synligt gjordes dragtester för att se hur hårt kabeln måste dras för att tappa fäste och glida. När den behövda kraften ansågs tillräckligt hög bedömdes modellen färdig för komplett utskrift. För att möjliggjöra test av tätningen behövdes de oanvända hålen täppas till. Då gjordes små pluggar för varje hål. Pluggarna gick att sätta i och ur med öglor för snöre eller tråd. Tråden kunde sedan fästas i andra änden på en större ögla på lådan när de inte var inpluggade. Den kompletta utskriften användes för att testa hela modellens täthet genom att försänkas i ett bad aluminiumoxidpulver, se fig 24. Även ett falltest utfördes för denna modell. Lådan fylldes med järnskrot tills den vägde ungefär lika mycket som om Raspberryn var i den. Sedan släpptes den från ungefär 1, 2 och 3 meters höjd. Den släpptes en gång från varje höjd förutom 3 meter där den släpptes två gånger med olika sidor nedåt. Dock hade denna modell ett litet fel från modelleringen, då en sträcka av lockets tätningsskåra var igentäppt. Detta gjorde att båda testernas resultat inte var helt representativa.

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

Figur 24 : Aluminiumoxidpulver-badet med prototyplådan i under test

Från pulvertestet konstaterades att skruvkraften från hörnen inte var tillräcklig för att täta lådan i mitten av långsidorna. Därav gjordes två nya skruvhål där. För att även minska den behövda skruvkraften för att täta lådan höjdes förseglingen upp något, se fig 25.

Muttrarna skruvarna fästes i sattes på undersidan av botten för att minska antalet varv för att skruva i eller ut skruvarna. Därmed minskades tiden att öppna och stänga lådan, för t.ex. service eller felsökning. Den nya positionen förenklade även montage av själva muttrarna.

I falltestet klarade lådan av alla höjder förutom det sista släppet på tre meter. Då släpptes lådan med ena långsidan, sidan med modellfelet, nedåt. Lådans vägg brast och stora sprickor samt några hål bildades. Därav konstaterades att ytterligare styrka i väggarna var nödvändigt. För att stärka upp väggarna gjordes ett tjockare triangulärt mönster längs med väggarna, se fig 25. Dessutom hjälpte det att täta lådan då tätningen blev styvare.

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

För att underlätta interaktionen med loggningsprogrammet valdes att använda en skärm. Efter samtal med projektägare samt övriga arbetande i kundcentrat valdes att köpa en 3,5 tums touchscreen från ELFA [25]. Skärmen var ämnad att visa ett grafiskt användargränssnitt där användaren kan starta och stoppa en jobblogg. Skärmstorleken var begränsad av strömtillförseln då större skärmar krävde en egen strömkälla, medan mindre skärmar kunde använda Raspberryns ström. Skärmen monterades i lådans lock med skruvförband, se fig 27. För att ge en bättre känsla vid användandet av skärmen stärktes locket

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

upp med ett triangulärt mönster och stag likt de längs lådans innersidorna. Skärmens position fixerades, utöver skruvarna, med en upphöjd kant som skapade en försänkning där skärmen placerades, se fig 26. Skärmen monterades direkt på Raspberryn.

Figur 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

Figur 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

För att täta lådan då inte alla kabelgenomföringar användes gjordes tätningspluggar, se fig 28. Pluggarna gjordes som separata detaljer med öggla för att dra snöre genom och fästa i en större öggla på lådans botten.

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

Figur 28 : Tätningspluggarna i CAD-modellen. Alla är lika stora förutom pluggen för ethernet kabelge- nomföringen

4.7.2 Mjukvaruutveckling

”Hardware eventually fails, software eventually works” - Michael Hartung

Samtidigt som designprocessen av den fysiska inkapslingen pågick utvecklades ett program för att hämta de sökta parametrarna från PLC:n och gasmätningsenheten, se fig 3. För att kommunicera med de två styrenheterna behövdes olika strategier tillämpas.

Gasmätningsenheten var ämnad för loggning till en dator med hjälp av ett program från tillverka- ren och var utrustad för seriell kommunikation med standarden RS-232. Tillverkarens program prövades men ansågs olämpligt då det inte gick att integrera med resten av programmstrukturen och enbart var kompatibelt med Windows system. Istället studerades vad tillverkarens program gjorde, vilket var att seriellt skicka alfanumeriska koder till mätenheten som i sin tur skickade tillbaks det mätvärde som motsvarade den koden. Ett enkelt program skrevs sedan i Python som hade samma funktion för att testa denna överföring och mottagning. En begränsning med denna metod var att endast de tre mätvärdena som visades på skärmen av gasmätningsenheten gick att hämta. Tillverkaren av gasmätningsenheten be- kräftade att endast tre av de fyra värdena enheten kunde visa gick att hämta ut vid en och samma tidpunkt. För att kommunicera med PLC:n krävdes en annan strategi. Då det var en nyare PLC av typen s7-1500[14] var den från fabrik utrustad med en OPCUA server, se kapitel 2.4.1, som endast behövdes konfigureras och aktiveras för att kunna användas. På S7-1500 läser den integrerade servern av PLC:ns addressutrymme och gör det tillgängligt för klienter. Där visas alla variabler som PLC:n har i minnet och alla in och ut signaler. För att undersöka addressutrymmet och hitta variabler som motsvarade de sökta parametrarna och deras nod ID användes en grafisk klient [26]. När parametrarnas nod ID var kända programmerades en enkel klient med hjälp av en Pythonbaserad implementation av OPCUA för att verifiera funktionen.

De parametrar som söktes från PLC:n var temperatur av de olika zonerna, bör och ärvärden, bandhastighet, bör och ärvärde, och skepp i ugnen. Bandhastigheten stod i klarspråk i PLC:ns minne med en decimals noggrannhet, de kunde hämtas av klienten utan att konverteras. Zonernas tempera- turvärden härstammade från analoga mätvärden från temperatursensorerna med en styrka på 4-20 mA. Dessa analoga signaler konverterades av PLC:n till ett digitalt värde inom området 0-27684. Dessa värden hämtades av programmet för att sedan konverteras vidare till grader Celsius i området 0-1400. Utifrån dessa två punkter, 0 till 0 och 27684 till 1400, kunde en konverteringsfaktor kalkyleras. Även totala mängden skepp i ugnen fanns i minnet, men det önskades även att kunna se vilka skepp i en lott som var i ugnen när. Därför utfördes räkning av skepp genom att abonnera på den variabel som signalerar

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

att matningscylinder in- och ut-aktiverades. Ett abonnemang skickar värdet på en variabel till klienten när det ändras istället för att värdet skickas när klienten efterfrågar det. Således skickades ett värde ”Inmat=TRUE” när inmatningscylindern tryckte på ett skepp på huvudbandet och ett ”Utmat=TRUE” när ett matas av. Utifrån detta sparades vilka skepp i serien som för tillfället var i ugnen och hur många skepp som totalt var i ugnen. Även totala mängden skepp i en serie sparades utifrån dessa två variabler. När kommunikationen hade verifierats med båda styrenheterna implementerades de i de slutgilti- ga programmen, se kapitel 4.6 för vidare information om programstruktur. Eftersom räkning av skepp endast var relevant för jobbloggen inkluderades mätningen av de parametrarna inte i dagsloggen. Vid vidare tester av programmen noterades att de ibland kraschade om båda kördes samtidigt. Orsaken till detta problem visade sig vara att både dagsloggern och jobbloggern utnyttjade samma seriella port för att hämta värden från gasmätningsenheten. Om de försökte använda den exakt samtidigt kraschade endera av de två programmen. Det var inte möjligt att använda separata seriella portar då endast en port fanns på gasmätningsenheten. Därför implementerades ett system där programmen kom- municerar att de utför en mätning sinsemellan. När ett program inledde en seriell mätning kontrollerade det först att porten inte var upptagen genom att se om det fanns en fil som sa att porten var upptagen eller ej. Fanns ingen sådan fil skapade programmet en och påbörjade mätningen, när mätningen var färdig tog den bort filen igen.

4.8 Slutgiltiga tester

I detta kapitel presenteras de slutgiltiga testerna som gjordes för både programmet och den fysisk kon- struktionen, resultaten av dessa presenteras i 5.3 Testresultat.

4.8.1 Programtester

För att testa programmets funktion i sin helhet gjordes drifttester över flera dagar. Drifttestet innefattade passiv loggning av ugnsparametrarna under hela dygn med dagsloggern, se kapitel 4.6, samt loggning av hela lotter med jobbloggern, se kapitel 4.6. Testets utfall visade då om programmet fungerade i längden eller om det uppstod fel med tiden.