Preview only show first 10 pages with watermark. For full document please download

Manual 9780883

   EMBED

Share

Transcript

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 ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! 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 ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! 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 ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! 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 ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! xiii 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 ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! x 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 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 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 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 ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! xv 
 xvi 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 Figur 16: Mjukvara, VisiWinNET Smart Figur 17: Mjukvara, Kanaler 17 ! ! 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 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 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 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 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 ! ! ! ! ! ! ! ! ! Figur 24: Flödesschema 23 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 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 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 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 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 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 • 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 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 Figur 32: Funktion, NumberOfLaps ! ! 32 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 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 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 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 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 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 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 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 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 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 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 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 snabbare system. Detta märktes när CSV-filen sparades då tiden för den process sänktes från ca. 30 sekunder till ca 2 sekunder. ! Konstruktion Eftersom kunden köper in delar så måste systemet byggas upp från grunden, all logisk utrustning (Frekvensomvaldnare, PLC och HMI) byggs in i ett elskåp. Resterande delar byggs upp på stativet så som motor, sensorer, linjärenhet och press se ritning i Figur 23. Lenze AB har avvecklat sin verkstad sedan några år, vilket innebär att den avdelning och lokal som skötte konstruktion av elskåp ej finns längre. På grund av detta måste kunden bygga elskåpet själv även om han ville att konstruktionen skulle ingå i projektet. Konstruktionen av elskåp och stativ skulle vara passande för examensarbetet för det skulle ge en bättre förståelse för systemet. Det innebär även att två olika bilder om hur systemet ska vara uppbyggt kan inträffa som inte stämmer överens mellan utvecklare och kund. ! Kommunikationsproblem En viktig del i varje system är kommunikation mellan noder i form av en buss eller liknande. Det här är även en aspekt som har många felkällor. Först och främst måste man förstå den buss man väljer, veta dess fördelar och begränsningar. Man måste veta hur mycket data man kan skicka och hur frekvent, går det att skicka samtidigt som man läser? Även om den data man transporterar via bussen är digital sker oftast transporten av information analogt via kabel eller liknande. Det här öppnar upp ännu fler felkällor, kabeln som används måste vara bra isolerad med ett jordskal. Längden på kabeln påverkar också samt resistansen på sändare och mottagare så att spegling att inte sker i kabeln. De system som sänder/tar emot data måste också ha ett bra jordplan så störningar inte sker utifrån eller av varandra. Det här var något som visade sig vara ett problem under projektets gång. Frekvensomvandlaren och motorn var fastskruvade i ett plexiglas-ställ vilket ej var ett bra jordplan. CAN-kabeln mellan PLC och frekvensomvandlare var skadat i skärmen vilket blottade de ledningar där datat transporterades. Det här gav att man fick CAN-bus error med jämna mellanrum. Eftersom det ej fanns andra kablar tillgängliga löstes problemet tillfälligt med att ha en DiagnosAdapter kopplad mellan laptop och frekvensomvandlare. Laptop:ens inre resistans fungerade som ett jordplan. ! ! ! ! ! 45 CSV-modul Den kod som sköter lagringen av CSV-filer blev tillhandahållen i typ av en modul (flera POU som anropar varandra, samt ett POU med testdata). Totalt innehöll modulen över 1000 rader kod vilket tog tid att sätta sig in i. Dessutom var koden skriven för ett annat typ av system. Oftast när man blir tillhandahållen kod är det sällan koden är skräddarsydd för det system man utvecklar. Ett stort problem med modulen var att det ej fanns dynamiskt minne, med andra ord är programmeraren tvungen att allokera så mycket minne som krävs för varje rad. Problemet är att varje rad är olika lång beroende på det data vilket gör det svårt att veta hur mycket minne som ska allokeras. Det val som gjordes var att skriva ut data i intervall för att säkerställa sig att all data skrevs ut. Detta resulterade dock i att tiden att skriva ut all data ökade. Att kunden senare bytte hårdvara till en snabbare PLC resulterade i att tiden minskade. ! Återkoppling Något som visade sig vara en kritisk punkt var återkopplingen, se avsnitt 2.1.1 för mer information. Frekvensomvandlaren ska kunna styra olika typer av motorer och det är servot som förstärker styrsignalen till motorn. Dock måste frekvensomvandlaren känna till vilken typ av motor och vilken återkoppling som används. Återkopplingen är inte bara viktig för att veta positionen på motorn, reglering och felkontroll utan även för att skydda hårdvaran. Om frekvensomvandlaren ej känner till motordatan finns risken att styrsignalen förstärks till en spänning och en frekvens högre än den som är menad till motorn. Om återkoppling ej existerar kan frekvensomvandlaren inte få respons om de höga signalerna. Detta kan leda till överhettning och i värsta fall skada delar av motorn. När man jobbar med flera projekt på samma frekvensomvandlare är det viktigt att spara/läsa rätt parametervärden på frekvensomvandlaren. 8400 Topline som användes har en utsignal mellan 1.3 till 89A (0.37 till 45kW), vilket är ett brett arbetsområde. På grund av det breda arbetsområdet är det viktigt att ha rätt motorparameter. Skulle man ha en 1.3A motor kopplad till frekvensomvandlaren men ha motorparameter till 89A kan motorn skadas mycket snabbt. ! Teoretisk bakgrund Den här rapporten och examensarbetet är baserat på att utvecklaren och läsaren har en teoretisk grund att stå på. De teoriområdena som har berörts är reglerteknik, industriella styrsystem, digitalteknik, programmering och en liten del mekanik. Risken finns att förståelse bortfaller om läsarens teoretiska kunskap ej uppfyller de nivåer som rapporten är skriven inom. ! ! ! 46 Förbättringar Att vidareutveckla projektet skulle vara fullt möjligt med anseende på vissa aspekter. Visserligen uppnår det befintliga systemet de krav som ställs men det finns alltid utrymme för förbättring. En idé kan vara att skicka CSV-filen via nätverket till en mailadress eller server. Det finns så klart risker för säkerhetsbrist om systemet är kopplat mot Internet som måste ses över då. En annan utveckligen kan vara att ha transportband fram till pressen så användaren inte behöver förflytta madrassen manuellt och därmed kunna lägga på flera testobjekt. Mjukvaran som har utvecklas för att skapa en diagnos på CSV-filen kan också utvecklas vid behov. En visualisering är alltid lättare för användaren, speciellt om man ej är van vid terminaler. Att utveckla mjukvaran med språket C# skulle öppna upp möjligheten till en visualisering där användaren kan bläddra efter filer och ställa in filter för utdatan. Anledningen till att C# skulle vara bra för vidareutveckling är att språket tillhör samma familj som C++ och endast korrigeringar skulle krävas i den befintliga koden. ! Egen regulator Som nämnt i kapitel 2.1.3 krävs regulatorer för att utföra vissa arbeten på ett smidigt och stabilt sätt och under rubriken Resultat visas hur olika hastigheter på joggar kan minska arbetstiden på systemet. Att skapa en egen regulator i funktionen GoToBed som reglerar efter hur långt ifrån målet positionen är. Exempelvis att sänka hastigheten när positionen när 80% av sträckan är tillryggalagd. Detta skulle eliminera överslängen och därmed utesluta korrigering vilket skulle leda till förkortad arbetstid. ! ! ! ! ! ! ! ! ! ! ! ! ! ! 47 1 Texo Application hemsida - Kund. http://www.texoapplication.se/index.php [Hämtad: 2014-03-03] 2 Lenze AB educational Powerpoint (2010), Frekvensomvandlare 3 Baldor Motor and Drives, Servo control facts Sid. 9-10! http://www.baldor.com/pdf/manuals/1205-394.pdf [Hämtad: 2014-03-03] 4 Baldor Motor and Drives, Servo control facts Sid. 11-12! http://www.baldor.com/pdf/manuals/1205-394.pdf [Hämtad: 2014-03-03] 5 Lennartson, B. (2002) Reglerteknikens grunder ! fjärde upplagan, sid. 1-5 6 Lennartson, B. (2002) Reglerteknikens grunder ! fjärde upplagan, sid. 301-305 7 Erickson, L. (1996) Programmable logic controllers. IEEE Potentials 15(1): Sid. 14-17 8 Parr, E. A. (1995) Industial control handbook, andra upplagan, sid. 429-466 9  Mikkor, A. and Roosimölder L. (2004),. Programmable logic controllers in process automation. Proceedings of the 4th International DAAAM Conference Industrial Engineering. 55-57. Tallin, Estonia 10 Bolton, W. (2006) Programmable Logic Controllers ! fjärde upplagan, Sid. 16-20 11 User Manual for PLC Programming with CoDeSys 2.3 Sid. 1-8! http://www.parkermotion.com/manuals/Hauser/Compax3/CoDeSys_Manual_V2p3.pdf ! [Hämtad: 2014-03-06] 12 L-force Controls HMI EL 100 series Visualisation and control under Windwos CE, Sid 3-5! http://www.lenze.com/fileadmin/lenze/documents/en/flyer/ FLY__13384745__HMI_EL_100__en.pdf [Hämtad 2014-03-07] 13 INOSOFT - next generation hmi, ! http://www.inosoft.com [Hämtad 2014-03-10] 14 Inverter Drives 8400 TopLine ! http://www.lenze.com/en/products/inverters/inverters-control-cabinet/inverter-drives-8400-topline/! , Hämtad [2014-03-13] L-force catalogue - Inverters! http://www.lenze.com/fileadmin/lenze/documents/en/catalogue/ CAT_CAP0405_IN_84TL_en_GB.pdf, Hämtad [2014-03-13] 15 HMIs with Windows CE - EL 100 series Sid. 2-11 - 2-14! http://www.lenze.com/fileadmin/lenze/documents/en/catalogue/CAT__13377367__PCbased_Automation__en.pdf, Hämtad [2014-03-13] 16 What is a CSV File? ! http://www.softinterface.com/Convert-XLS/Features/CSV-File-Definition.htm [Hämtad 2014-03-24] 17 Motor testmiljö, Lenze AB! http://www.lenze.com/en/products/motors/servo-motors/mcs-synchronous-servo-motors/ ! Hämtad [2014-04-08] 18 Controller p300, Lenze AB! http://www.lenze.com/en/products/controls/controller-p300/ Hämtad [2014-04-08] 19 Controller p500, Lenze AB! http://www.lenze.com/en/products/controls/controller-p500/ Hämtad [2014-04-08] 48