Utveckling av madrasstestare

Full text

(1)Institutionen för systemteknik Department of Electrical Engineering. !. Examensarbete. Utveckling av madrasstestare. Examensarbete utfört i Reglerteknik vid . Tekniska högskolan vid Linköpings universitet av . Haris Kaniza. !. LiTH-ISY-EX-ET--14/0422--SE . !. Linköping 2014. ! ! ! ! ! TEKNISKA HÖGSKOLAN LINKÖPINGS UNIVERSITET. ! ! Department of Electrical Engineering . Linköping University . S-581 83 Linköping, Sweden . Linköpings tekniska högskola. Institutionen för systemteknik. 581 83 Linköping.

(2) !. ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !.

(3) ! Utveckling av madrasstestare. Examensarbete utfört i Reglerteknik vid . Tekniska högskolan vid Linköpings universitet av . ! !. Haris Kaniza. LiTH-ISY-EX-ET--14/0422--SE. ! ! ! ! ! ! ! ! ! ! ! !. Handledare: Daniel Berggren. . Lenze AB i Linköping. Examinator: Torkel Glad . Linköping 20 Januari, 2014. ! !. Johan Dahlin. ISY, Linköpings universitet. ISY, Linköpings universitet.

(4) ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !.

(5) Institution och avdelning Institutionen för systemteknik. Presentationsdatum 2014-06-11 Publiceringsdatum (elektronisk version). Department of Electrical Engineering. 2014-06-18. Språk x Svenska Annat (ange nedan). Antal sidor 80. Typ av publikation Licentiatavhandling x Examensarbete C-uppsats D-uppsats Rapport Annat (ange nedan). ISBN (licentiatavhandling) ISRN LiTH-ISY-EX-ET--14/0422--SE Serietitel (licentiatavhandling) Serienummer/ISSN (licentiatavhandling) -. URL för elektronisk version http://www.ep.liu.se. Publikationens titel Utveckling av madrasstestare. Development of mattress tester. Författare Haris Kaniza Sammanfattning Detta examensarbete har utförts vid Lenze AB i Linköping åt kunden Texo Application AB för att utveckla en madrasstestare. Utvecklingen innefattade programmering av PLC med HMI och frekvensomvandlare för att driva systemet. Madrasstestarens är menad att testa madrasser/sängar för att säkerställa att de är godkända för försäljning genom att en press trycker med varierat tryck på madrassen. Slutprodukten blev en CSV-fil som listar moment från noll till 1000 Nm och position på pressen för varannat moment. This Bachelor thesis has been done for Lenze AB in Linköping for the customer Texo Application AB, the project was to develop a machine to test mattresses. The development affected PLC-programming with built HMI and inverters to control the system. The machine is designed to test mattresses before they are approved for sales by applying pressure with various force on the mattress. The end product will be a CSV-file witch lists a torque from zero to 1000 Nm and the position of the press for every other torque.. Nyckelord Frekvensomvandlare, PLC, CoDeSys, Moment, HMI, CAN.

(6) ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !.

(7) Sammanfattning. !. Detta examensarbete har utförts vid Lenze AB i Linköping åt kunden Texo Application AB för att utveckla en madrasstestare. Utvecklingen innefattade programmering av PLC med HMI och frekvensomvandlare för att driva systemet. Madrasstestarens är menad att testa madrasser/sängar för att säkerställa att de är godkända för försäljning genom att en press trycker med varierat tryck på madrassen. Slutprodukten blev en CSV-fil som listar moment från noll till 1000 Nm och position på pressen för varannat moment. . ! ! ! ! !. Abstract. !. This Bachelor thesis have been done for Lenze AB in Linköping to the customer Texo Application AB, the project was to develop a machine to test mattresses. The development affected PLCprogramming with built HMI and inverters to control the system. The machine is designed to test mattresses before they are approved for sales by applying pressure with various force on the mattress. The end product will be a CSV-file witch lists a torque from zero to 1000 Nm and the position of the press every other torque.. ! ! ! ! ! ! ! . xii.

(8) ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !. xiii.

(9) Förord. !. Jag vill tacka alla medarbetare på Lenze AB som har gett mig möjligheten till ett trevligt och lärorikt projekt och jag vill rikta ett speciellt tack till min handledare Daniel Berggren. Ett tack till min handledare och examinator på Linköpings universitet.. !. Sist men inte minst ett stort tack till alla mina nära och kära som har hjälpt, trott och stöttat mig genom mitt examensarbete.. !. Linköping 22 Maj 2014. !. Haris Kaniza. ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !. ! ix.

(10) ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !. !. x.

(11) Innehållsförteckning. Lista av figurer!. 12!. Förkortningar!. 14!. 1 Inledning!. 1!. 1.1 Syfte. 1. 1.2 Bakgrund till examensarbetet. 1. 1.3 Metod. 1. 1.4 Mål och frågeställningar. 2. 1.5 Avgränsningar. 2. 2 Teori!. 3!. 2.1 Vad är en frekvensomvandlare?. 3. 2.1.1 Öppen/sluten loop. 3. 2.1.2 Servo. 4. 2.1.3 PI-regulator. 6. 2.2 Hur fungerar en PLC med HMI?. 7. 2.2.1 Arkitektur. 7. 2.2.2 Programmering av PLC, CoDeSyS. 8. 2.2.3 Exempelkod. 10. 2.2.4 HMI. 12. 2.3 Utvecklingsmiljö. 12. 2.3.1 L-force Engineer HighLevel. 13. 2.3.2 L-force PLC Designer. 15. 2.3.3 VisiWinNET Smart. 16. 3 Implementation!. 20!. 3.1 Överblick på systemet. 20. 3.1.1 Överblick, Frekvensomvandlare. 22. 3.1.2 Överblick, PLC/HMI. 22. 3.1.3 Flödesschema. 22. 3.2 Frekvensomvandlare . 26. 3.3 PLC-Programmering. 27. 3.3.1 Funktioner. 27. 3.3.2 CSV. 34. 3.4 HMI Design. 36. 3.5 Diagnos. 37. 4 Resultat!. 38!. 5 Diskussion!. 43 xi.

(12) Lista av figurer. !. !. Figurnummer. Figurnamn. Sida. Figur 1. Ett system i en öppen loop. 19. Figur 2. Ett system i en sluten loop. 20. Figur 3. Blockdiagram över servo. 21. Figur 4. Arkitektur på en PLC. 24. Figur 5. En lista på POUs. 25. Figur 6. Skapa en ny POU. 25. Figur 7. Exempelkod, IF-sats, fönster, jämförelse. 26. Figur 8. Exempelkod, FOR-loop. 26. Figur 9. Exempelkod, Array. 26. Figur 10. Exempelkod, Case. 27. Figur 11. Mjukvara, EASY Navigator. 29. Figur 12. Mjukvara, L-force Engineer HighLevel. 30. Figur 13. Mjukvara, CanIn och CanOut. 30. Figur 14. Mjukvara, Parameter list på MotorInterface. 31. Figur 15. Mjukvara, L-force PLC Designer. 32. Figur 16. Mjukvara, VisiWinNET Smart. 33. Figur 17. Mjukvara, Kanaler. 33. Figur 18-20. Mjukvara, Form. 34. Figur 21. Mjukvara, Language switching. 35. Figur 22. Överblick på systemet. 36. Figur 23. Schema på konstruktionen. 37. Figur 24. Flödesschema. 39. Figur 25. Mått mellan maskin och madrass. 40. Figur 26. Bild över moment, heltal. 43. Figur 27. Bild över moment, flyttal. 44. Figur 28. Funktion, InsertToArray. 45. Figur 29. Funktion, GoToBed, Manuell. 46. Figur 30. Funktion, GoToBed, Auto. 46. ! xii.

(13) Figurnummer. Figurnamn. Sida. Figur 31. Cykler i NumberOfLaps. 47. Figur 32. Funktion, NumberOfLaps. 48. Figur 33. Funktion, Clear. 49. Figur 34. CSV-exempel. 51. Figur 35. HMIstruktur. 52. Figur 36. Diagnosmjukvara, max: 20. 53. Figur 37. Diagnosmjukvara, max: 10. 53. Figur 38. Diagnosmjukvara, max: 1. 53. Figur 39. Oscilloskop, Jog1/Jog2 = 300/30. 57. Figur 40. Oscilloskop, Jog1/Jog2 = 600/90. 57. ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !. xiii.

(14) Förkortningar. !. AC. Alternating Current. ASCII. American Standard Code for Information Interchange. BOOL. Boolean TRUE/FALSE. C. Programmeringsspråk. C++. Programmeringsspråk. C#. Programmeringsspråk, “C-sharp”. CAN. Controller Area Network. CoDeSys. Programmeringsspråk, Controlled Development System. CPU. Central Processing Unit. CSV. Comma Delimated File/Character Separated File. DC. Direct Current. EPROM. Erasable Programmable Read Only Memory. GND. Ground, (jord). HMI. Human Machine Interface. Hz. Hertz, frekvens. INT. Integer, heltal. IR. Infraröd/Infrared. Nm. Newtonmeter. OS. Operativsystem. PC. Personal Computer. PLC. Programmable Logic Controller. POU. Program Organization Unit. RAM. Random Access Memory. ROM. Read Only Memory. RPM. Rotates per minute. SYM. Symbolfil för PLC. UI. User Interface. USB. Universal Serial Bus. WLAN. Wireless Local Area Network. ! xiv.

(15) ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !. ! xv.

(16) . xvi.

(17) 1 Inledning. !. Detta kapitel avser att ge läsaren en förståelse varför och hur arbetet har gjorts. . 1.1 Syfte. Syftet med examensarbetet var dels att konstruera en madrasstestare till kunden Texo Application AB1 men även att få en god inblick om hur en frekvensomvandlare och PLC kan styra en maskin till att utföra ett arbete från start till slut. Eftersom det är en riktig kund och projekt så var det viktigt att inte enbart lösa problemet utan även att skapa ett användarvänligt UI och täcka alla felkällor där användaren kan göra fel.. !. 1.2 Bakgrund till examensarbetet. Innan en produkt kan säljas till allmänheten är det vanligt att den testas så att den uppfyller vissa krav och detta gäller även sängar/madrasser. För att utföra sådana tester krävs en maskin som antingen pressar ner eller rullar madrassen. Pressvarianten utför test för att säkerställa att fjädringen i madrassen är godkänd för olika typer av vikt. Rullvarianten utför test för rörande objekt på madrassen, så som rullande i sömn. Det här examensarbetet fokuserade på själva pressfunktionen. En madrasspress fungerar så att en lastcell kopplas till ett stativ med en linjärenhet. En lastcell är en typ av sensor som mäter krafter. En linjärenhet är ett typ av ställdon med en rörlig del som används för att förflytta och positionera föremål. Under lastcellen placeras en press som sakta körs ner mot en madrass. När pressen går emot madrassen ökar momentet i lastcellen, positionen på hur långt ner pressen har gått skickas genom återkoppling till PLC:n som lagras beroende på momentet. Ett test består av ett till fem cykler där varje cykel testar noll till 1000 Nm både på vägen ner och upp.. ! ! !. 1.3 Metod. Själva arbetet har delats upp i moduler. Varje modul har innehållit ett antal delmoment vilket har gjort arbetet strukturerat. Först har studier om teorin studerats för att få en grund att stå på. Därefter har översiktliga skissar skapats just för de krav som modulen har. Därefter har själva implementationen utförts beroende på hårdvaran. Slutligen har tester utförts i ett testlaboratorium för att felsöka och utesluta problem/fel.. ! ! !. 1.

(18) De fem största modulerna med examensarbetet var: . Programmering av huvudprogram i PLC . Inställning och reglering av frekvensomvandlaren . Design av HMI. Kommunikationsystem. Spara CSV-fil på USB. Utöver dessa moduler har mindre moduler skapats.. ! 1.4 Mål och frågeställningar. Konstruktion - Hur bygger man upp ett färdigt system med frekvensomvandlare, PLC och . HMI?. Kommunikation - Hur kommunicerar de olika komponenterna med varandra?. Programmering - Hur programmerar man PLC och frekvensomvandlare?. Resultat - Hur ska resultatet presenteras och vart/hur ska det sparas?. !. 1.5 Avgränsningar. Vissa avgränsningar har gjorts för att kunna få en realistisk lösning. Lastcellen som registrerar momentet har en viss precision vilket resulterar i att en begränsning har gjorts när en position ska lagras. Cykeltiden för hur ofta main-programmet ska köras var begränsat vilket resulterar i att uppdateringstiden för momentet begränsas. Eftersom Texo Application AB befinner sig i Älmhult nära Skånes gräns och det är där maskinen är placerad, gav detta svårigheter att testa och felsöka i den miljö som systemet är menat att arbeta i.. ! ! ! ! ! ! ! ! ! !. 2.

(19) 2 Teori. !. Det här kapitlet ska ge läsaren en bättre förståelse om de system och miljöer som använts under projektet. Vi inleder med att diskutera vad en frekvensomvandlare och PLC är och fortsätter sedan med en introduktion till de mjukvaror som användes. . !. 2.1 Vad är en frekvensomvandlare?. En frekvensomvandlare eller frekvensomriktare är en konstruktion som är kopplad direkt till AC/ DC motorer. Dess uppgift är att anpassa den spänning och frekvens som tillförts motorn beroende på den belastning som motorn utsätts för. Anledningen till detta är för att hålla optimal magnetisering på motorn även utanför den nominella arbetspunkten (där motorn är menad att arbeta). Det finns olika uppsättningar av frekvensomvandlare beroende på vilket arbete man vill utföra.2 Några exempel är att styra stora motorer för att öppna/stänga dammar, styra en produktionslinje eller styra en sågklinga för att kapa material på en viss längd.. !. 2.1.1 Öppen/sluten loop. En aspekt som särskiljer frekvensomvandlare är om det är öppen eller sluten loop i systemet, om det finns någon återkoppling (feedback) i systemet. Återkoppling är en signal som skickas tillbaka från motorn till frekvensomvandlaren.3 . ! !. I ett system med en öppen loop går styrsignalen från frekvensomvandlaren direkt till motorn. Med andra ord går information bara i en riktning. När signalen kommit fram till motorn utför motorn sitt arbete utan att frekvensomvandlaren har tillgång till den faktiska hastigheten. Detta innebär att frekvensomvandlaren inte kan kompensera för. Figur 1: Ett system i en öppen loop. tung last eller för att rotorn sitter fast. När man skickar ut en styrsignal till en motor som inte får rotera fritt alstras ett moment och den här “oändliga” lasten ger att motorns strömförbrukning ökar. Övervakas inte detta kan strömmen öka snabbt och motorn kan överhettas och gå sönder/ta eld.. !. 3.

(20) I ett system med en sluten lopp skickas en styrsignal till motorn precis som det öppna systemet. Den stora skillnaden är att motorn i det slutna systemet skickar tillbaka information genom feedbackmodulen till frekvensomvandlaren. Denna information anger exempelvis om arbetet är utfört eller inte. Även rotationshastighet och position skickas tillbaka. Återkopplingssignalen tas sedan upp av frekvensomvandlaren för att bearbeta den på olika sätt, exempelvis för Figur 2: Ett system i en sluten loop. servostyrning.. !. Det finns ett antal både för- och nackdelar med båda systemen. En öppen loop är relativt enkel att sätta upp och är billigare på grund av att man inte använder en feedback-modul. Dock är den inte så funktionellt eftersom det inte finns någon feedback. För enklare arbeten där lasten inte ändras kan en öppen loop vare en bra och billig lösning. En sluten loop är som sagt mer funktionell än en öppen loop vilket resulterar i att man kan konstruera ett mer komplext system. Störsignaler är också en faktor som avgör val av sluten eller öppen loop. En störsignal är en yttre faktor som påverkar systemet genom att störa styrsignalen. Ett exempel kan vara ett öppet fönster i ett rum där en termostat ska hålla konstant temperatur i. Det öppna systemet har svårt att kompensera för det här fenomenet eftersom det ej får någon återkoppling om vad som har hänt. Ett system kan vara mer eller mindre robust, vilket är hur lätt störsignaler påverkar.. !. 2.1.2 Servo. Servo är ett samlingsnamn för servostyrning, servokontroll, servoteknik, servomotor, servobroms m.m. Servo kan ses som ett system som ändras beroende på olika förhållanden. Användningsområdet för en servo är oftast för att förstärka signaler, med det menas att användaren skickar signaler med låg spänning som styrsignal från ett gränssnitt som sen förstärks av servokontrollen. Fördelen med det här systemet är för att kunna styra stora maskiner och konstruktioner med hjälp av en liten spak eller HMI. Servon använder sig utav slutna loopar som definierades i det tidigare stycket. Återkopplingen beror på vilken typ av kontrollprofil som används. De vanligaste profilerna är position (Table positioning) och hastighet (Speed control).4. ! !. 4.

(21) . Figur 3: Blockdiagram över servo Positionskontroll (Table positioning). För att detta ska fungera krävs en återkoppling mellan motor och kontrollenheten (t.ex. tachometer, resolver eller encoder). Kortfattat är det ett mekaniskt system som använder bland annat optik på 360 grader och en räknare för att hålla koll på hur långt/antal varv motorn har roterat. Räknaren ökar om motorn roterar åt ett håll och minskar i den andra riktningen. Positionskontroll används ofta tack vare sin hemsökning (Homing). Homing är ungefär vad det låter som, användaren säger åt servot att just den här positionen är “Home”, vilket blir position noll för att ha en referens att utgå ifrån. Detta är en fördel för vissa maskiner där man har fysiska delar som ska förflytta sig såsom robotarmar eller pressar. En Homing kan sättas manuellt eller genom att låta motorn gå en riktning tills dess att den aktiverar en givare (mekanisk eller IR), då den vänder tills den går av givaren eller träffar en ny, mellan dessa två lägen blir positionen “Home”.. Förflyttning av positioner sker oftast genom två olika sätt, absolut och relativ. Absolut innebär att användaren anger destination i position och maskinen förflyttar sig dit medan relativ så förflyttar sig maskinen så många enheter som användaren matar in från sitt hemläge.. !. Varvtalsstyrning (Speed control). Servot i frekvensomvandlaren reglerar på ett börvärde (styrsignal) som är den hastighet (varvtal [rpm]) användaren önskar. Ett scenario kan vara om användaren har angett 1500 rpm som hastighet till börvärdet. Av någon anledning (exempelvis motorn har för hög last) roterar bara motorn med 1200 rpm, då kommer en signal skickas från feedbackmodulen (riktig hastighet) till kontrollenheten 5.

(22) med information om att hastigheten är 1200 rpm. Kontrollenheten jämför då börvärdet med återkopplingen och ökar spänningen till servokontrollen, vilket resulterar i högre hastighet på motorn. På så sätt håller motorn en konstant hastighet oberoende på förhållanden som påverkar motorn såsom last. I praktiken används oftast varvtalsstyrning för att reglera vissa variabler. Exemplevis att styra pumpar för att få önskat flöde genom att reglera varvtalet.. !. 2.1.3 PI-regulator. En regulator5 är ett system som använder sig utav information för att beräkna och ställa ut en styrsignal. Regulatorer kan finnas överallt i vår omgivning, några exempel kan vara; farthållaren i bilar som ska hålla konstant hastighet oberoende på upp-/nedförsbackar, underlag och förarens styrning med ratt. En termostat som ska hålla en konstant temperatur i ett rum oavsett hur många människor det finns i rummet eller om fönstret är öppet. Till och med vår kropp har flera regulatorer; pupillernas vidgas eller sammandrar beroende på ljuset i omgivningen, svettning för att reglera kroppens temperatur och balanssinnet som låter oss stå kvar på marken vid knuffar och stötar. Den mest kända klassen av regulatorer är den så kallade PID-regulatorn. En PID-regulator består av tre element: en proportionerlig del (P-del), en integrerande del (I-del) samt en deriverande del (D-del). P-delen är proportionell mot reglerfelet med en förstärkningskonstant Kp. En hög Kp konstant leder till ett snabbt system med lägre stigtid men kan leda till överslängar. I-delen är en integral på summan av processtörningar, den används främst för att höja förstärkningen vid lägre frekvenser och eliminera kvarstående stegstörningsfel. D-delen gör beräkning på processtörningar över tid för att förstärka stabiliseringen, dock används denna del inte så stor utsträckning på grund av sin känslighet för mätstörningar6. (e(t) är felet).. !. I detta examensarbete användes en PI-regulator för att sköta motorns reglering i frekvensomvandlaren. Frekvensomvandlaren tar emot återkopplingen med hjälp av en resolver i form av hastighet och position i blocket Parameter list, MotorInterface som visualiseras i Figur 14. Signalen jämförs då med börvärdet och regleras i PID-blocket där D-delen är noll. D-delen valdes till noll för att ge bättre resultat vid varvtalsstyrning då mätbrus kan ge sämre resultat med D-del.. Formel 1: P-del. ! !. Formel 2: I-del. ! 6. Formel 3: D-del.

(23) 2.2 Hur fungerar en PLC med HMI?. Vid år 1960 började började utvecklingen av PLC:n (Programmable Logic Controller) för att byta ut hårdkopplade reläpaneler. Anledningen till att en efterfrågan efter PLC:n började ta form var på grund av den tidskrävande omkoppling och felsökning som reläer krävde. År 1968 gav General Motors Corporation (GM) ut en lista med kriterier och krav på den första PLC:n de planerade att använda för produktionslinjen. Ett fåtal företag tog på sig uppgiften och vid år 1970 var den första PLC:n skapad7. Den största fördelen med PLC:n är att det är ett flexibelt system där förändringar och korrigeringar kan ske via program istället för att koppla om kretsar. Detta leder till att PLC är ideellt för robotapplikationer där ändringar sker ständigt8. Med modern kommunikation behöver inte dessa ändringar ske lokalt. Nackdelar med PLC:n är att de inte är utrustade med tillräckligt mycket minne för att lagra stora mängder information. Även det att varje PLC måste programmeras för att kunna utföra ett jobb, det kräver mer från användaren jämfört med reläer9.. En PLC kan ses som hjärnan i systemet. Det är en fysisk del uppbyggd av flera komponenter så som CPU, ROM/EPROM, RAM, bussar och in-/ut-gångar10. PLC:n är oftast kopplad till en frekvensomvandlare. Det finns olika kommunikationsprotokoll så som CAN, EtherCat, med mera. Nu för tiden är vissa frekvensomvandlare mer användarvänliga och låter användaren styra vad som ska hända när vissa krav är uppfyllda, mer om det här tas upp under rubriken 2.3 Utvecklingsmiljö. Dock kan inte frekvensomvandlaren hantera all logik och därför krävs en PLC för detta. Vissa PLC:n har inbyggda HMI-paneler eller ingång att koppla in en extern panel. . !. 2.2.1 Arkitektur. Liksom många system följer PLC:n en viss arkitektur som visas i Figur 4. CPU eller processorn är den enhet som exekverar och kontrollerar alla operationer i PLC:n. Den har en klockfrekvens som oftast ligger mellan 1 och 8 MHz5 och detta avgör hur ofta en cykel sker i systemet. All data som ska skickas mellan olika block i PLC:n flödar igenom bussar. Det är i princip anslutningar mellan de olika blocken, där blocken antingen skickar eller lyssnar efter data. Det finns även minnesblock som hanterar det minne som finns lagrat i PLC:n. ROM/EPROM är den typ av minne som innehåller data som ej försvinner när spänningen går låg (permanent lagring). RAM är tillfälligt minne där användarens data lagras och intern data såsom räknare och timers. PLC:n har oftast ett litet batteri till RAM-minnet som håller kvar informationen i minnet under period efter att spänningen slås av. För att på ett enkelt sätt förklara hur data går igenom minnen kan man säga följande; när en användare har programmerat en kod i en utvecklingsmiljö och kompilerar koden (build) lagras datan i RAM i utvecklingsmiljön. Går man online, det vill säga skickar över informationen till. 7.

(24) PLC:n lagras det i “Data RAM”, och slutligen om man skapar ett boot project så lagras informationen i PLC:ns ROM5.. Figur 4: Arkitektur på en PLC 2.2.2 Programmering av PLC, CoDeSyS. PLC:n har i uppgift att styra frekvensomvandlaren och för detta så krävs ett program som ska kunna exekveras. Det programmeringsspråk som har använts är CoDeSys (Controlled Development System) som har en IEC-61131-3 standard, det innebär att CoDeSys är uppbyggt av fem olika “språk”6 som ses i Tabell 1.. Språk. Förklaring. Sequential Function Charts (SFC). Flöden. Ladder Diagram (LD). Virtuellt, relä och spolar. Instruction List (IL). Kan liknas med assembler. Function Block Diagram (FBD). Hantera BOOL och analoga signaler. Structured Text (ST). Kan liknas med C/PASCAL Tabell 1: IEC-61131-3 standard. I många fall används mer än ett av de fem språken i ett projekt för att få en bättre hantering och överblick av projektet. Tack vare POU:s blir utvecklingsmiljön enklare att hantera för användaren. Ett POU som ett delprogram i projektet som utför ett arbete. Varje POU kan skapas från de fem språken ifrån standraden, men även välja om POU:t ska vara ett program, funktionsblock eller funktion. Ett projekt behöver dock ha ett POU vid namn PLC_PRG som skapas vid projektets start, detta liknar main-funktionen i C/C++11.. 8.

(25) . Figur 5: En lista på POU:s. !. ! !. Figur 6: Skapa en ny POU. Den POU-uppsättning som har använts under det här projektet var av typen Program och språket ST. Program är en typ av POU som ej kräver in-/ut-gångar för att exekvera. Anledningen för det är att ST ger programmeraren fria händer att hantera, tilldela och jämföra variabler. Figur 5 visar en lista på POU:s och Figur 6 visar fönstret där ett nytt POU skapas. Som de i flesta programmeringsspråk finns det logiska operander och olika typer av variabler.. !. Det finns flera datatyper/operander men följande var de som användes mest under projektet och övriga anses icke relevanta för rapporten.. Datatyper. • BOOL: 1 bit som sätts TRUE/FALSE.. • INT: Finns som SINT(1 byte), INT(2 byte), DINT(4 byte), LINT(8 byte) som lagrar heltal.. • REAL: Finns som REAL(4 byte) och LREAL(8 byte) som lagrar flyttal.. • ARRAY: En icke-dynamisk container som kan lagra datatyper.. • STRING: En samling av tecken.. Operander, jämförelse, aritmetik, loopar och tilldelning. • IF: Används i vanliga IF-satser där man kontrollerar uttryck.. • AND,OR,NOT: Grindar som styr OCH-, ELLER- och INTE uttryck.. • <, >, <> , >= , <=: Jämförelser mellan datatyper.. • := : Tilldelning. • FOR: En loop med gränser, går från start till slut med ett visst steg.. • WHILE: En loop som loopar tills ett uttryck uppfylls.. • CASE: Switch-case, använder INT för att säga vilken del av koden som ska exekveras.. 9.

(26) Alla datatyper och funktionsblock (variabel) måste definieras innan de kan användas. Detta görs på två olika sätt, antingen lokalt eller globalt. Definieras variabeln lokalt hanteras den i POU:n och skapar inte konflikter med andra variabler med samma namn i andra POUn. Globala variabler definieras i sitt eget fönster, alla POU kan skriva/läsa dessa variabler.. !. 2.2.3 Exempelkod. Figur 7: Exempelkod, IF-sats, fönster, jämförelse I Figur 7 ser vi ett POU av typen Program - ST, de lokala variablerna ligger mellan VAR och END_VAR. Koden beskriver en enkel IF-sats som kollar om variabeln A är större än B. Om A är större blir Bigger sann, annars falsk. I följande figurer kommer endast koden att visas.. ! !. ! !. Figur 9: Exempelkod, Array. Figur 8: Exempelkod, FOR-loop 10.

(27) Figur 8 visar en kod för en FOR-loop, cnt är en INT som används som en räknare. Loop:en kommer börja på ett och för varje varv upp till 100 kommer variabeln A att adderas på med ett.. Figur 9 visar en kod för en Array av typen INT. Som tidigare nämnt måste man allokera minnet själv som programmerare, det vill säga att det ej finns något dynamiskt minne. Det kan ses på [1..10] i figuren, där defineras en array med tio platser. I koden sätts värdet ett på plats ett, värdet fem på plats två, värdet 20 på plats 3 och värdet 100 på plats tio.. ! ! ! ! ! ! ! ! ! ! !. Figur 10: Exempelkod, Case. ! ! ! ! Figur 10 visar en kod på en Case-sats. Stegningen av casen sker med hjälp utav en INT (Stepper). När koden börjar sätts Stepper till 10 och hoppar in i första delen utav koden. Om Bool1 skulle vara sann går koden vidare annars stannar den där och väntar på Bool1. I Case 20 ser man ett exempel på en kommentar som skrivs: (*kommentar*). På slutet går Stepper tillbaka till 0. Anledningen till att man använder den här typen av struktur är för att låta koden gå en cykel, och för att säkerställa att delar av koden exekverar i rätt ordning.. ! ! ! ! !. 11.

(28) 2.2.4 HMI. HMI (Human Machine Interface) är en visuell kontrollpanel för användaren som underlättar styrningen av en maskin. Ett system kan bli mycket komplext med många variabler att övervaka och justera. Därför är det viktigt att ge en bra överblick samt möjligheten att enkelt ändra på vissa variabler. Ett HMI är vanligtvis en touchpanel som användaren lätt kan manövrera med sina fingrar. I många fall (även i det här projektet) sitter HMI-panelen ihop med PLC:n, men i vissa fall kan panelen vara separat kopplat till PLC:n. HMI:t hanterar variabler ifrån PLC:n men det finns även möjlighet att läsa/skriva till variabler i frekvensomvandlaren. Eftersom HMI-panelen oftast sitter ihop med PLC:n så behöver man bara läsa in den SYM-fil som skapas när man bygger projektet. För att få kontakt mellan HMI och frekvensomvandlare måste man ha någon typ av kommunikationssystem, t.ex. CANbus. . Programmeraren måste designa/programmera själva designen i en utvecklingsmiljö som påminner mycket om C# som kommer tas upp under rubriken Utvecklingsmiljö12. . !. 2.3 Utvecklingsmiljö. För att projektet ska kunna vara möjligt att utföra behövs ett par utvecklingsmiljöer eller mjukvaror. Som tidigare nämnt har Lenze sina egna mjukvaror för programmering/inställningar av frekvensomvandlare, PLC och HMI.. !. Lenze AB använder en programvara vid namn EAZY Navigator som är en samling av genvägar för alla mjukvaror som används på företaget. De mjukvaror som användes för projektet var:. • L-force Engineer HighLevel 2.19. • L-force PLC Designer v. 2.6. • VisiWinNET Smart. • Drive Solution Designer. !. Vi diskuterar dessa kort nedan.. 12.

(29) . Figur 11: Mjukvara, EASY Navigator. ! 2.3.1 L-force Engineer HighLevel. Denna mjukvara sköter styrning och övervakning av frekvensomvandlaren. Vid start av nytt projekt får användaren välja vilken hårdvara som projektet ska implementeras på, såsom frekvensomvandlare, motor, och växlar. Beroende på vilken hårdvara som valdes byggs ett kopplingsschema upp i mjukvaran. Där kan användaren koppla eller byta upp ledningar mellan in/ utgångar. Det finns även funktionsblock som användaren kan lägga ut i kopplingsschemat för att göra vissa beräkningar eller modifieringar såsom AND, OR, NOT, bitar, räknare, ord, heltal, delayer m.m. Det finns även en panel som visar valda variabler så som spänning, position, ström o.s.v. som oftast används för felsökning eller övervaka systemet under körning. Det finns olika kommunikationssystem som används men det vanligaste är CAN OnBoard som kommunicerar med andra delar i systemet så som PLC. Det finns inställningar i mjukvaran för Canbus. För att skapa själva kommunikationen måste man lägga ut så kallade CANblock ut på kopplingsschemat, det finns två typer; CanIn och CanOut. Som man kan förstå på namnen är CanIn det block som läser in variabler till mjukvaran och CanOut är det blocket som skickar ut variabler, se Figur 13. Mjukvaran har även parametrar för alla variabler vilket gör det lättare för användaren att söka och hitta det hen letar efter. Varje parameter har en adress som bland annat kan användas till att skriva till och läsa från parametern i HMI:t. Varje block i kopplingsschemat har en funktion så kallad Parameter list. Den öppnar upp en typ av inställningar som är kopplat till varje blocktyp. Till exempel, öppnas 13.

(30) Parameter list på blocket MotorInterface visas en mängd inställningar och visualiseringar som berör motorns reglering, återkoppling o.s.v. se Figur 14.. Figur 12: Mjukvara, L-Force Engineer HighLevel. ! ! ! ! ! ! ! ! ! ! ! !. Figur 13: Mjukvara, CanIn och CanOut 14.

(31) Figur 14: Mjukvara, Parameter list på MotorInterface. ! 2.3.2 L-force PLC Designer. Denna mjukvara tar hand om styrning och programmering av PLC:n. Som tidigare nämnt är en PLC en typ av logisk kontroller. För att kunna hantera PLC:n behöver man en mjukvara där själva programmeringen utförs (CoDeSys). Precis som Engineer-mjukvaran har användren möjlighet att mata in vilken typ av PLC hen arbetar med för att begränsa och sålla bort onödiga inställningar som den valda PLC:n kanske inte har. PLC Designer är mer än bara en texteditor för rå kod utan det finns en mängd val och funktioner som ger användaren bättre kontroll och struktur över projektet. Som tidigare nämnt finns det en mängd kommunikationssystem mellan de olika systemen. När programmeraren har byggt sin kod kan hen gå online vilket bränner över den exekverbara koden till PLC:n. Detta sker oftast genom Ethernet/WLAN. Det är också viktigt att det finns en kommunikation mellan frekvensomvandlare och PLC, som tidigare nämnt användes CAN-bus i detta projekt. Liksom som i Engineer, måste man hantera vilka variabler som ska läsas in och vilka som ska skickas ut på bussen, detta kan göras på flera olika. I det här projektet gjordes det genom att skapa ett POU av typen Program - Funktionsblock. Anledningen till upplägget var att det är lättare att se bussen som visuella block. Utöver kommunikation finns det flera användbara funktioner som har använts flitigt under projektet. En utav dessa var Task configuration, som används till att inkludera POUn till projektet. Det innebär att för att ett POU ska kunna köras i klockcykeln måste det läggas till som task där man även kan ställa in prioritet, tid för cyckel, watchdog m.m. En annan funktion som har varit användbar är Library Manager, som används till att läsa in bibliotek. Det innebär att programmeraren kan underlätta arbetet för sig själv genom att läsa in befintliga bibliotek, som kan innehålla färdiga funktionsblock. Ett exempel kan vara 15.

(32) WORDS_TO_BITS och BITS_TO_WORD som används till Can-bussen. De två funktionsblocken användes för att omvandla ett 16bitars ord till individuella bitar och tvärtom.. Figur 15: Mjukvara, L-force PLC Designer. ! 2.3.3 VisiWinNET Smart. Mjukvaran berör HMI-designen för PLC:n. Mjukvaran påminner mycket om C# där det både finns visuella element att lägga till och redigera, men även möjligheten att programmera. Precis som Engineer och PLC Designer får användaren möjligheten att skräddarsy projektet beroende vilken hårdvara som används. En funktion som är viktig inte bara för det här projektet men generellt till HMI-design är att programmeraren har möjlighet att infoga befintliga variabler från Engineer och PLC Designer. Det görs lätt genom att skapa en så kallad “kanal” i mjukvaran, där kan användaren välja vilken typ av kanal som ska skapas. En kanal är ett kommunikationssystem som kan ses som “vägar” mellan till exempelvis Engineer och PLC Designer. Figur 17 visar hur det ser ut när man skapar en ny kanal. För att skapa en kanal mellan PLC Designer och VisiWinNET skapar man en kanal av typen “CoDeSys” och mellan Engineer och VisiWinNET skapar man en kanal av typen “LenzeCAN”. När man har valt vilken kanal man vill använda har man möjligheten att välja vilka variabler man vill läsa/skriva i kanalen13. . !. 16.

(33) Figur 16: Mjukvara, VisiWinNET Smart. Figur 17: Mjukvara, Kanaler. 17.

(34) ! ! Själva designen består av “fönster” vid namn Forms, varje Form är en sida/fönster som visas i HMI-panelen på PLC:n. Programmeraren designar själv varje Form beroende på vad som behövs i HMI:t, det finns en verktygspanel i mjukvaran som innehåller olika objekt som används för design. I verktygspanelen finner man in/ut-variabler, texter, mätare, knappar m.m. De objekt som kan påverkas av variabler är det möjligt att binda variabler till, så som knappar, mätare och in/utvariabler. . !. !. Figur 19: Mjukvara, Form. Figur 18: Mjukvara, Form. ! !. Figur 20: Mjukvara, Form. 18.

(35) Oftast är HMIn designade att kunna användas i mer än bara ett land och då är det viktigt att alla användare förstår gränssnittet (UI). Det skulle vara klumpigt att skapa dubletter av alla Forms med olika språk och ännu värre om det är mer än två språk som ska implementeras. Detta kan lösas lätt med hjälpa av Language switching, som fungerar så att man skapar en “ordlista” för varje text i olika språk. Därefter är det lätt att bara skapa en knapp som växlar mellan de olika språken och byter ut texten i varje variabel i Formen.. Figur 21: Mjukvara, Language switching. ! ! ! ! !. 19.

(36) 3 Implementation. !. Det här kapitlet ska ge läsaren en bättre förståelse om hur problem löstes och hur lösningen implementerades.. !. 3.1 Överblick på systemet. Figur 22 visar en överblick på system med aspekt på hårdvara och kommunikation. Följande rubriker kommer ta upp mer detaljerad information om de större objekten i figuren.. Figur 22: Överblick på systemet. ! En fysisk DiagnosAdapter kopplades mellan frekvensomvandlaren och datorn som användes för att bygga och diagnosera frekvensomvandlaren med hjälp av L-force Engineer Highlevel. Kommunikationen mellan utvecklingsmiljö och PLC/HMI skedde igenom ett LAN med hjälp av en router. Anledningen till routern var på grund av brist på Ethernet uttag i datorn.. ! ! ! ! ! !. 20.

(37) Figur 23: Schema på konstruktionen. Figur 23 visar en översikt av konstruktionen på maskinen. I elskåpet(10) sitter frekvensomvandlaren, PLC och HMI. På toppen av linjärenheten sitter motorn(12) som styr enheten, på botten sitter själva pressen(9). Mellan pressen och linjärenheten sitter lastcellen(7). Under pressen är där madrassen kommer placeras för testning. Vid testning kommer linjärenheten att röra sig vertikalt med hjälp av motorn. Lastcellen kommer vara direkt kopplad till frekvensomvandlaren för registrering av moment.. ! ! ! ! ! ! ! ! !. 21.

(38) 3.1.1 Överblick, Frekvensomvandlare. Frekvensomvandlaren som valdes till projektet var 8400 TopLine C, Lenze14. Anledningen till detta val var baserat på kundens beskrivning av konstruktionen och de funktioner som skulle utföras. Det var relativt enkla funktioner som krävdes såsom positionering, servostyrning, PID-reglering m.m. Kommunikationen mellan frekvensomvandlaren och PLC/HMI skedde med hjälp av en CAN-kabel.. !. 3.1.2 Överblick, PLC/HMI. I Figur 22 presenterar PLC/HMI som två enheter men egentligen är det endast en enhet av typen EL 108 N PLC, Lenze15. Anledningen till den uppdelade visualiseringen är för att ge läsaren en bättre förståelse till att det är två olika system som behandlas på olika sätt. . !. 3.1.3 Flödesschema. Flödesschemat i Figur 24 representerar de funktioner och processer som används och anropas från HMI:t. Flödesschemat är en förenklad bild för att ge läsaren en överblick av systemet. De funktioner som är väsentliga för projektet tas upp mer under avsnitt 3.3. Observera att flödesschemat är på svenska men att användaren kan välja språk mellan svenska och engelska i HMI:t.. !. Schemat börjar vid Start och det är vid den här positionen som användaren börjar då systemet startar, här ska användaren mata in fyra variabler:. • Momentgräns: [REAL (flyttal)] den gräns om hur högt moment får bli tills pressen vänder för mätning uppåt under varje cykel.. • Maxmoment: [REAL] är den gräns på momentet där pressen stängs av, behövs för att pressen inte ska trycka igenom madrassen till golvet.. • Antal cykler: [INT] avgör hur många cykler maskinen ska köra (en cykel är att maskinen pressar ned till momentgräns och sen pressar upp tills dess att momentet blir 0). Variabeln ska vara mellan 1 och 5 efter kundens krav.. • Hastighet: [REAL] bestämmer pressens hastighet.. Dessa variabler måste vara skilda från 0, samt så måste Antal cykler vara mellan 1 och 5 för att användaren ska kunna fortsätta.. ! ! ! ! !. 22.

(39) ! ! ! ! ! ! ! ! !. Figur 24: Flödesschema. 23.

(40) . Sedan får användaren möjligheten till att välja vilket läge hen vill utföra testet på; Automatiskt eller Manuellt. Läge innebär hur maskinen ska lokalisera madrassen efter att Homing har utförts.. !. • Automatisk: Pressen kommer börja gå ned i en högre hastighet än den som används vid testning för att minimera tiden för en cykel. När lastcellen registrerar ett moment högre än fem Nm stannar pressen. Ett problem som uppstår är att pressen har en relativ hög hastighet och hinner inte stanna vid madrasskanten utan trycker ned något. Vid det här läget kommer riktningen ändras och hastigheten sänkas vilket resulterar i att pressen åker upp och momentet sänks. När momentet är noll igen stannar pressen och en BOOL att madrassen är hittat blir sann.. • Manuell: Vid val av manuellt läge får användaren mata in två variabler (Mått A och Mått B) av typen INT, se Figur 24. Med hjälp av dessa mått räknar programmet ut Mått C, det blir måttet mellan hempositionen och där madrassen börjar. Madrassen lokaliseras då pressens position är större eller lika med Mått C. Liksom i Automatläget hinner inte pressen stanna direkt vid kontakt med madrassen. Detta problem hanteras på samma sätt som förut. . Figur 25: Mått mellan maskin och madrass. ! ! ! ! ! 24.

(41) Efter det att madrassen är lokaliserad står programmet i .Main och är redo att utföra själva testet. För att utföra ett test ska användaren aktivera Starta sampling. Denna funktion aktiverar en övervakning av lastcellen och sparar värden i arrayerna. Användaren ska även aktivera Starta körning vilket gör att pressen börjar gå ner och sen upp när momentet specificerat av att Momentgräns har uppnåtts. Mer information om finns i avstnitt 3.3.1. När testet är klart får användaren välja om hen vill spara värdena till en CSV-fil på ett USB-minne i PLC:n, då skrivs först Filnamnet in, sedan Skapa fil och slutligen Skicka data. Det finns även funktioner i .Main som kan anropas när som:. !. • Kalibrera: Programmet använder sig utav två olika positioner, en för att hålla koll på den totala utsträckningen på linjärenheten och en för att övervaka den sträcka som madrassen trycks ner. Den sist nämnda positionen är den information som lagras och sätts när sängen lokaliserades. Om av någon anledning denna positionen ej skulle vara noll vid madrassens topp kan användaren trycka på kalibrera för att nollställa den. . • Jog up/ner: De här funktionerna låter användaren jogga maskinen upp/ner. Jogga innebär att man. ! ! ! ! !. låter maskinen gå en viss riktning och hastighet utan hinder.. 25.

(42) 3.2 Frekvensomvandlare . Den profil som valdes för projektet var Positionskontroll (Table positioning). Anledningen till valet är för att systemet måste känna till aktuell position och kunna utföra en Homing. Under projektets gång har logik och uträkningar används så lite som möjligt i frekvensomvandlaren. Anledningen till det valet baserades mest på det faktum att det är en begränsad arbetsmiljö men även för att skilja på funktioner i PLC:n och de block som styr motorn. Som tidigare nämnt används CANbuskommunikation mellan frekvensomvandlare och PLC. I Engineer visualiseras det med två block, en för IN och en för UT (se Figur 13). De variabler som skickas via bussen är:. !. IN (Till frekvensomvandlaren):. • Homing Start/Stop - [BOOL] Aktiverar och avaktiverar Homing.. • PosExecute - [BOOL] Skickar en positiv trig till att starta exempelvis Homing.. • Val av Profil - [INT] Växlar emellan Homing och Joggning.. • ManJogPos/Neg - [BOOL] Riktning på Jog.. • ManJogSpeed2 - [INT] Hastighet för den jog som används för själva körningen.. • ManJogExecute2ndVel - [BOOL] Aktiverar den jog som används för själva körningen.. !. UT (Från frekvensomvandlaren):. • HomingDone - [BOOL] Indikerar att Homing är klar. • JogSpeed - [INT] Den hastighet på jog som används.. • TorqueSetValue - [REAL] Momentet från lastcellen.. • MotorPosAct - [INT] Position.. !. Utöver de variabler som skickas in/ut från frekvensomvandlaren finns även funktionsblock/grindar som inverterar och konverterar variabler.. ! ! ! ! ! ! !. 26.

(43) 3.3 PLC-Programmering. I detta avsnitt kommer koden som skrivits i PLC:n att listas och förklaras i pseudoformat eller kodformat. . !. 3.3.1 Funktioner. !. Funktion: InsertToArray. Som tidigare nämnt kommer maskinen att använda ett moment från lastcellen för att avgöra hur mycket pressen trycker ned på madrassen. Eftersom det finns en återkoppling i systemet kan vi mäta positionen, det vill säga hur långt ner/upp pressen har gått. Som kan användas för att skapa en Insertfunktion. Insertfunktionen visas Figur 28. Kravet från kunden var att lagra den sträcka som pressen har tryckt ner på madrassen för varannat moment från 0 Nm till 1000 Nm, det vill säga alla jämna heltal. Eftersom det ej finns något dynamiskt minne i CoDeSys så skapades två arrayer av typen INT för att lagra positionen, en för vägen ner och en för vägen upp. Ett val gjordes att använda flyttal på momentet för att få en bättre precision vid lagring av position. . Figur 26: Bild över moment, heltal Figur 26 visar en bild över vart insättningen i arrayen skulle ske om momentet skulle vara av typen INT istället för REAL (heltal istället för flyttal). De röda ytorna visar vart insättningen kan ske för varje jämnt moment beroende på när klockcyklen infaller till koden för insättning. Även om man väljer att läsa in momentet som ett heltal betyder det inte att lastcellen bara kan registrera heltal. Det man kan se i figuren är att intervallet sträcker sig nästan över ett helt moment, det leder till dålig precision på grund av trunkering. Anledningen till den dåliga precisionen är den att för exempelvis moment 2 Nm skulle programmet lagra positionen mellan 2,00… Nm till 2,99… Nm. Även med en avrundning blir det dålig precision eftersom de röda ytorna bara skulle förflyttas bakåt 0,5 Nm. Figur 27 visar hur det här problemet löstes.. ! !. 27.

(44) Figur 27: Bild över moment, flyttal Att låta momentet lagras som typen REAL istället för INT öppnar upp en bra lösning för hur man kan få en bättre precision för lagring av position. Genom att skapa två stycken variabler LimitMin och LimitMax av typen REAL kan intervallen som visas i Figur 26 minskas. Genom att hårdkoda dessa variabler för första momentet och sedan addera på båda variabler med 2 efter varje insättning “flyttas” gränserna till nästa hela moment efter varje insättning. En stor fördel med den här lösningen är att programmeraren har möjlighet att “krympa” intervallet för att få en bättre precision. . Några exempel på gränser och intervall:. !. !. LimitMin LimitMax. Intervall (enheter). 1.5 . 2.5. 1. 1.6 . 2.4. 0.8. 1.7 . 2.3. 0.6. 1.8 . 2.2. 0.4. 1.9 . 2.1. 0.2. Som man ser i tabellen ovan har programmerarn möjlighet att sänka intervallet genom att höja LimitMin<2 och samtidigt sänka LimitMax>2. Om man jämför med fallet då momentet är av typen INT och då LimitMin är 1,9 och LimitMax är 2,1 sänks intervallet där insättningen sker med 80%. Den flaskhals som kan uppstå är att cykeltiden är för låg och att momentet hinner gå igenom intervallet innan koden hinner exekvera. . ! ! !. 28.

(45) . Figur 28: Funktion, InsertToArray I Figur 28 kan man se strukturen över hur insättningen sker och det som beskrevs tidigare. Funktionen använder sig utav två olika räknare, en för att hålla kolla på positionen i arrayen där värdet ska sättas in och en för att förhindra att värden som redan är insatta skrivs över.. ! ! ! ! !. 29.

(46) • GoingUp - [BOOL] Kollar om insättningen sker för upp/ner-vägen. . • g_xSample - [BOOL] Aktiverar start av sampling.. • g_xDirection - [BOOL] Riktning för motorn.. • g_rTorque - [REAL] Momentet.. • PositionArray - [ARRAY[INT]] Arrayen för nervägen.. • PositionArrayUP - [ARRAY[INT]] Arrayen för uppvägen.. • BedPosition - [INT] Positionen från toppen av madrassen neråt.. • LimitMin - [REAL] Undre gränsen för intervallet.. • LimitMax - [REAL] Övre gränsen för intervallet.. • i,j,m,n - [INT] Räknare.. !. Funktion: GoToBed. Som beskrivet i avsnitt 3.1.3 måste maskinen hitta madrassen innan användaren kan påbörja testning, det görs av funktionen GoToBed. Hur funktionen fungerar står beskrivet i avsnitt 3.1.3 och kommer ej upprepas här istället presenterar vi hur koden är strukturerad. . ! ! ! ! ! ! !. Figur 29: Funktion, GoToBed, Manuell. !. Figur 30: Funktion, GoToBed, Auto 30.

(47) Funktion: NumberOfLaps. Användaren har möjlighet att mata in antal cykler som tidigare är nämnt och förklarat i avsnittet 3.1.3. Användaren har möjlighet att välja mellan ett och fem cykler för varje körning. InsertToArray är som sagt den funktion som lagrar positionen i två arrayer, en för vägen ned och en för vägen upp. Det hade inte varit lika optimalt att låta den funktionen lagra 10 arrayer, istället lagras de två arrayerna i InsertToArray och sedan skicka över de till temporära arrayer. Därefter rensas arrayerna i InsertToArray, detta sker så många gånger som användaren angett cykler.. Figur 31: Cykler i NumberOfLaps Figur 31 illustrerar hur insättningen sker i de temporära Arrayerna för varje cykel. Alla platser i de temporära är nollsatta som inledningsvis, det är en fördel som kommer förklaras i avsnitt 3.3.2.. ! ! ! ! ! ! !. 31.

(48) Figur 32: Funktion, NumberOfLaps. ! ! 32.

(49) Funktionen NumberOfLaps fungerar som följer: först måste sample och jog på motorn vara igång, sängen måste vara hittad samt en lokal räknare måste vara mindre eller lika med användarens cykel. När dessa villkor är uppfyllda väntar funktionen på att momentet ska bli lika med eller högre än Momentgräns. Då byter motorn riktning och körs tills dess att momentet blir mindre eller lika med 1 Nm och ökar den lokala räknaren med ett. Lokalt har inte mycket hänt hittills men i funktionen InsertToArray har båda arrayerna fyllts med värden från 0 Nm till Momentgräns. Nu sker själva insättningen till de temporära arrayerna, första varvet är CycleCnt = 1 och arrayerna från InsertToArray kopieras till temp11 och temp12. TempXY är de temporära arrayerna där X står för vilken cykel och Y är 1 för vägen ner och 2 för vägen upp. När arrayerna är kopierade rensas arrayerna i InsertToArray och nästa cykel påbörjas. Jog sätts till falsk efter varje cykel för att ge användaren möjlighet att inleda varje cykel när hen vill.. !. Funktion: Clear. Programmet använder sig utav två olika Clear-funktioner, deras funktion är att återställa platserna i arrayerna till deras ursprungliga noll-värde. Den ena funktionen rensar de arrayer som används i funktionen InsertToArray och den andra funktionen rensar de temporära arrayerna i funktionen NumberOfLaps. Anledningen till att det ej är en funktion som rensar alla arrayer är den att då skulle de temporära arrayerna rensas för varje cykel och resultera i att den sista cyklen lagras på cykel ett. Funktionerna är relativt lika, en FOR-loop stegar igenom varje array från position 0 till 500 och sätter värdet i varje position till 0. Skillnaden mellan de två Clear-funktionerna är att den som rensar i InsertToArray även sätter LimitMin och LimitMax till deras defaultvärde och nollställer de interna räknarna. . ! ! ! ! ! ! ! ! !. ! ! !. Figur 33: Funktion, Clear 33.

(50) 3.3.2 CSV. En CSV-fil (Character Separated File) är en typ av fil som kan liknas till en textfil, skillnaden är den att ett den använder sig utav ett ASCII-tecken för att skapa en separator. Separatorn i sin tur fungerar som en “vägg” som isolerar textsträngar. En textsträng mellan två separatorer hanteras som et enskilt objekt16. Fördelen med att använda en CSV-fil istället för en vanlig textfil är att texten blir formaterad efter separatorn och filen kan lätt läsas in i exempelvis Microsoft Excel för att enkelt göra beräkningar. . !. Ett funktionsblock skapades i programmet som tog in data i form av arrayer, filnamn och bitar för att skapa ny fil och skicka data till filen. Funktionsblocket har även utsignaler av typen BOOL som kollar om filen gick att skapa och om datat skrevs till filen. Innan arrayerna skickades till funktionsblocket konverterades de temporära arrayerna från typen Array[INT] till Array[STRING]. Eftersom det dynamiskt minne ej fanns tillgängligt var det nödvändigt för programmet att veta längden av varje sträng som skulle skrivas till filen. Ett problem uppstod eftersom alla rader inte var lika långa beroende på heltal, tiotal, hundratal eller negativa tal. Varje rad var i snitt 25-35 tecken och det skrivs ut 500 rader vilket resulterar i ungefär 15000 tecken för hela dokumentet. Varje sträng som skulle skrivas ut kunde ej vara längre än 256 tecken. . Problemet löstes när informationen delades upp och samtidigt sätta en tom sträng som var längre än den längsta raden. Informationen delades upp i omgånger på två rader i taget, fördelen var att ingen information missades eller skrevs över av annan rad. Nackdelen med en sådan uppdelning var att tiden att skriva all information till filen ökade drastiskt på grund av att programmet måste skicka en flagga tillbaka 250 gånger att informationen har skrivits. Det inledande värdet är noll på alla platser i de temporära Arrayerna vilket är viktigt för utskriften. Anledningen är att de moment som högre än Momentgräns och cykler högre än Antal cykler aldrig bearbetas och visas som 0 i CSV-filen. Det är därför viktigt att Clear-funktionerna fungerar bra för nästa körning.. ! ! ! ! ! ! ! !. 34.

(51) . Figur 34: CSV-exempel. Figur 34 visar en bild på en CSV-fil som skapats av programmet med hjälp av en testkörning. Som vi ser överst i filen skrivs Filnamn, Momentgräns, Hastighet, Antal cykler och datum ut. Därefter skrivs en rubrikrad ut för kraft och serier där en cykel har en serie ner och en upp. Slutligen skrivs datan ut med två rader i taget. Som vi ser i exemplet slutar informationen efter 26 Nm vilket var den Momentgräns användaren angivit och serier efter Serie2.2 är all data 0 eftersom användaren angivit Antal cykler till 2.. ! ! ! ! !. 35.

(52) 3.4 HMI Design. I detta avsnitt kommer en visualisering visas av HMI:t i form av ett schema som visar strukturen över From:erna. Ingen större förklaring kommer att finnas då en mer detaljerad finns under avsnitt 3.1.3. . ! ! !. Figur 35: HMIstruktur. 36.

(53) 3.5 Diagnos. När CSV-filen är skapad är det tänkt att kunden ska analysera resultatet för att dra slutsatser om testobjektet är godkänt för försäljning. CSV-filen är tänkt att öppnas och analyseras i Microsoft Excel eller liknande mjukvara för analys. En utökning av examensarbetet gjordes genom att skapa en mjukvara som utför en diagnos utav CSV-filen automatiskt. Mjukvaran är skriven i språket C++. Mjukvaran ber användaren mata in namnet på filen som ska diagnoseras samt en gräns på maximala skillnaden mellan två moment. Därefter stegar koden igenom filen och jämför nuvarande moment med föregående för varje cykel både upp och ned. När jämförelsen är klar skrivs alla resultat större eller lika med gränsen ut på en ny fil som även låter användaren veta vid vilket moment, vilken cykel och riktning det inträffade. . Figur 36: Diagnosmjukvara, max: 20. Figur 38: Diagnosmjukvara, max: 1. Figur 37: Diagnosmjukvara, max: 10. 37.

(54) 4 Resultat. !. Det här kapitlet är menat att redovisa resultatet på examensarbetet. Resultatet är baserat på hur den verkliga maskinen utförde sitt jobb jämfört med kraven. Alla krav som ställdes uppfylldes, vi ska nu istället diskutera hur variation av information och inställningar påverkar resultat och testning.. !. Maskinen använder sig utav två hastigheter för att utföra sin uppgift. Jog1 är den hastighet som används när sängen ska lokaliseras, den används endast på vägen ner tills dess att testobjektet har lokaliserats. Jog2 är den hastighet som används vid körning av testning och till den korrigering som krävs vid lokalisering av testobjekt i funktionen GoToBed. . En analys har utförts för att försöka lokalisera ideella värden för de båda hastigheterna. Med ideellt värde menas ett värde som minimerar den tid att lokalisera testobjektet men samtidigt minimera överslängning och felmarginal. Överslängning är det fenomen när ett objekt har för hög hastighet och inte hinner reglera sig till börvärdet och där med svänger över börvärdet innan det byter riktning för att återgå mot börvärdet. Felmarginal i den här benämningen menas med hur mycket resultatet urskiljer sig med börvärdet.. !. Analys på Jog1. Diagram 1 visar medelvärdet på tre olika tester för att hitta testobjektet (manuellt). De tre testerna var identiska i 29/30 av fallen vilket kan ses som ett stabilt system med lite variation. De inställningar som användes var: Mått C = 30 units och Jog2 = 30 units/s. Anledningen till att Jog2 hålls konstant och låg är för att minimera felkällor för testet. I diagrammet utläses att överslängningen ökar vid högre hastigheter. Med ökad överslängning innebär att funktionen GoToBed tar längre tid att utföra på grund av att Jog2 måste korrigera överslängen. Även felmarginalet ökar vid högre hastighet. Detta beror på att motorn inte hinner stanna då objektet lokaliseras. Det viktigaste för bra resultat är att felmarginalet är minimalt för att inte riskera dålig precision för testning. Hastigheten 600 units/s visade sig vara en bra hastighet med noll felmarginal och ca. 56% överslängning. . ! ! ! ! ! !. 38.

(55) Slutposition. 100,00. Översläng. 95,00 90,00. 90. 92. 85,00 80,00. 78 79. 75,00. Position units. 70,00 65,00. 65. 60,00. 67. 60. 55,00. 54 54. 50,00. 47. 45,00. 30,00. 39 39. 44. 40,00 35,00. 47. 31 37 30 31 35 31. 33. 43. 36. 35 31 30. 41 41. 31. 33. 25,00 20,00. 100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500. Joghastighet units/s. !. Diagram 1: Analys på Jog1. ! ! Analys på Jog2. Diagram 2 visar slutposition på funktionen GoToBed (manuellt) med varierad hastighet. De värden som användes var: Mått C = 30 och Jog1 = 600 units/s. Det visade sig att värden på Jog2 inte kunde överstiga 110 units/s utan att ge ett felmarginal större än noll. Anledningen till felmarginalen i de högre hastigheterna är att motorn inte hinner stanna på korrigeringen. Jog2 är som tidigare nämnt en hastighet som används i själva testningen och bör ej överstiga en hastighet som resulterar i att precisionen försämras.. ! ! ! ! !. 39.

(56) Position. 40. 35. Position units. 30. 30. 30. 30. 30. 30. 27. 27 26 25. 25. 25. 24. 24 21 20. 20. 290. 310. 20. 15 30. 50. 70. 90. 110. 130. 150. 170. 190. 210. 230. 250. 270. Joghastighet units/s. ! ! !. Diagram 2: Analys på Jog2. Figur 39 och figur 40 visar skillnaden på två olika uppsättningar av hastigheter för att visa hur den totala tiden varierar för funktionen GoToBed (manuellt). Varje ruta på x-axeln representerar 4.09s och varje ruta på y-axeln representerar 200 rpm. . Figur 39 illustrerar uppsättning ett; Jog1 = 300 units/s och Jog2 = 90 units/s. . Figur 40 illustrerar uppsättning två; Jog1 = 600 units/s och Jog2 = 90 units/s.. Den totala tiden för uppsättning ett är 19,15 sekunder medan i uppsättning två är tiden 13,9 sekunder. Vi ser att genom att endast ändra joghastigheter kan utförandet av GoToBed sänkas med 5,25 sekunder. . ! ! ! ! !. 40.

(57) Figur 39: Oscilloskop, Jog1/Jog2 = 300/30. Figur 40: Oscilloskop, Jog1/Jog2 = 600/90 Diagram 3 visar oss hur lång tid det tar att lagra CSV-filen beroende på hur lång cykeltid MainTask har. Under examensarbetets gång användes en PLC (EL 108) med en CPU med lägre klockfrekvens än den som slutligen valdes att användas (p500). Detta resulterade i att cykeltiden på MainTask kunde sänkas från 50 ms till 1 ms. Som vi ser i diagrammet sänktes samtidigt tiden för att lagra CSV-filen från 89,2 till 4,2 sekunder.. ! ! ! ! ! ! ! !. 41.

(58) 90. 89,2. 75. 71,4. Tid för utföring [s]. 60. 52,9 45. 36,1 30. 18,3. 15. 0. 4,2. 5,7. 6,9. 1. 2. 3. 8,7 4. 10,4 5. 10. 20. 30. 40. Cykeltid för MainTask [ms]. Diagram 3: MainTask´s påverkan på CSV-lagring. ! Den 22 Maj 2014 avklarades examensarbetet då koden implementerades i den nya maskinen i Älmhult. Vissa ändringar gjordes på grund av otydlig beskrivning från kunden men kunde lösas på plats. En funktion att kunna läsa CSV-filer ska implementeras i framtiden men anses vara utanför examensarbetet. Den otydliga beskrivningen visade att det var kraft och ej moment som skulle lagras, lyckligtvis var ytterst små ändringar i frekvensomvandlaren som krävdes för att rätta till misstaget. . ! ! !. ! ! ! 42. 50.

(59) 5 Diskussion. !. Det här kapitlet är menat att ge läsaren en förståelse om vad skulle kunna förbättras för framtida utveckling, samt förklara vilka svårigheter och problem som uppstått under arbetet. Kapitlet är utformat med stycken som förklarar hur projektet utformades eller ändrats/avvikit baserat på olika variabler.. !. Testmiljö. Som tidigare nämnt är produkten skapad till en kund i Skåne, detta skapade problemet att testning på den verkliga arbetsmiljön inte kunde utföras inom dess att produkten vad i slutstadiet. En tillfällig lösning skapades på arbetsplatsen i Linköping med en testmiljö bestående av en frekvensomvandlare av typen 8400 Topline C, en PLC med inbyggt HMI av typen EL 108 N och en 0.25kW synkron servomotor17. Det gav en bra grund till det riktiga systemet, dock fanns det ingen möjlighet att ha en press mot ett objekt för att testa insättning i arrayerna. Det löstes med att ha en analog ratt som skalades om för att simulera ett moment från 0 till 1000 Nm. Den lösningen skapade ytterligare ett problem, precisionen på den analoga ratten blev sämre med högre skalning vilket resulterar i att varje moment har ett mindre fönster på ratten. Som tidigare nämnt i avsnitt 3.3.1 måste positionen lagras för varje jämnt moment för att lagra nästa position. Detta försvårade testen ännu mer på grund av den dåliga precisionen.. !. Kravspecifikation . Ett möte med kunden utfördes i Skåne innan projektet påbörjades för att samla information om vilka krav som ställdes på utvecklingen. Det visade sig vara en mindre introduktion om hur den gamla befintliga madrasstestaren fungerade och fria händer gavs att utveckla ett nytt system med nya lösningar. Bland annat gjordes valet att lagra CSV-filen på USB-minne direkt i PLC:n istället för att skicka filen till en PC via nätverket. Anledningen till att byta till USB-lagring var för att göra systemet självständigt samt spara resurser. Ingen extern dator ska behövas för att utföra tester. Fördelarna med denna lösning var dels billigare system men även att ha CSV-filerna lokalt och portabla, vilket skulle vara svårt med en PC som ej är uppkopplad på Internet. Nackdelarna är att det är svårt att få en överblick på filsystemet i USB-minnet genom HMI:t, samt att mjukvaror som används för att bearbeta CSV-filerna är för krävande för Windows CE.. ! ! !. 43.

(60) Upplärning. Något som tog upp mycket tid under projektets gång var förståelse om mjukvara och hårdvara. Även om det fanns bra kännedom om programmering och teori bakom reglering och styrsystem blev det svårt att påbörja utvecklingen direkt. Anledningen till det var att mjukvarorna och hårdvarorna var utvecklade av Lenze AB för att vara specificerade för deras produkter. En upplärningsperiod krävdes för att sätta sig in i de mjukvaror och system som krävdes för att utföra projektet. Det fanns även många bibliotek som var utvecklade av Lenze AB som innehöll färdiga funktionsblock som användes för att utföra konverteringar, skicka data via bussar m.m. . !. Beställning. Eftersom fria händer gavs för att utveckla madrasstestaren var det svårt att uppskatta den tid som skulle krävas för att färdigställa systemet. Kunden skulle meddelas när systemet var halvvägs avklarat så en beställning på hårdvaran kunde ske. Den tid som var planerad var ca. fem veckor men det visade sig ta betydligt mindre tid. Problemet som uppstod var att projektet blev klart innan kunden meddelades vilket resulterade i att projektet lades på is under leveranstiden som visade sig vara strax över sex veckor. Under denna tid utfördes mindre projekt på sidan av för att samla in mer kunskap om de system som används, det resulterade i förbättring av madrasstestaren. I framtida projekt eller återskapande av det här projektet skulle beställning ske baserat på leveranstiden för att utesluta väntetid som kan läggas på testning istället. . !. Förändring av hårdvara. Efter att leverantören hade skickat hårdvaran till kunden meddelade denne att han har beställt annan hårdvara än förväntat. Frekvensomvandlaren var fortfarande samma men PLC och HMI var av nyare och snabbare typ. Den nya PLC:n var av typen p30018 och är en helt ny produkt vilket innebär att inga färdiga templates fanns till förfogande för att skapa ett nytt projekt, istället användes dess uppgraderade version p50019 för att skapa en grund. Detta gjorde att den kod som var skriven i PLCDesigner v.2 fick skrivas om till PLCDesigner v.3.6. Inga större förändringar gjordes i koden, men det krävdes tid att sätta sig in i och förstå den nya mjukvaran. Ett nytt HMI var också nödvändigt att skapas för PLC:n. Den föregående PLC:n (EL 108) hade en CPU (XScale PXA 270) där frekvensen låg på 312 MHz medan den nya PLC:n (p300) har en CPU (ARM Cortex A8) på 800 MHz. Den PLC som användes för utveckling (p500) har en CPU (Intel® AtomTM) på 1.6GHz. Eftersom CPU:n har en högre frekvens kan fler operationer utföras på samma tid vilket resulterar i ett snabbare system. Innan beslutet om att ändra hårvaran togs var cykeltiden på koden 50ms, men tack vare att CPU:n uppgraderas kunde den tiden sänkas till 1ms vilket resulterade i ett 50 gånger 44.

No results found