LabView-baserat produktionstest för borstlösa trefasiga likströmsmotorer LabView-based production test for brushless three phase direct current motors

LabView-baserat produktionstest

för borstlösa trefasiga

likströmsmotorer

LabView-based production test for

brushless three phase direct

current motors

MARLENE THULIN

KTH

LabView-baserat produktionstest för

borstlösa trefasiga likströmsmotorer

LabView-based production test for brushless three phase

direct current motors

Marlene Thulin

Examensarbete inom Datateknik/Elektroteknik, Grundnivå, 15 hp

Handledare på KTH: Torgny Forsberg Examinator: Elias Said

TRITA-CBH-GRU-2019:043 KTH

tidseffektivitet prioriteras för att minimera negativ inverkan på produktionstakten.

I detta projekt överfördes ett produktionstest för färdigmonterade borstlösa DC-motorer med driv-elektronik till en ny testutrustning hos företaget Allied Motion. Testet skulle moderniseras och införas i företagets mjukvaruplattform uppbyggd i programspråket LabView.

Testsekvensen kunde effektiviseras främst genom att kombinera dess delmoment och låta körningar av motorn användas för att testa flera egenskaper istället för att upprepas. Resultatet blev ett test som täckte in samma mätningar som i det äldre systemet med undantag för enstaka moment, samt mätte hastighet och momentkarakteristik med högre precision. Det omarbetade testet bestod av fyra deltes-ter jämfört med tidigare tolv steg, och implemendeltes-terades i fyra LabView-baserade testfall som kunde användas för att skapa en komplett testsekvens i plattformen.

Uppgiften visade sig dock kräva mer tid och arbete än vad som uppskattats inledningsvis, och därför återstod flera av de arbetsuppgifter som planerats inom projektet att slutföra innan det nya testet skulle kunna tas i bruk i produktionen.

Nyckelord

fore time efficiency must be prioritized in the design of such tests in order to minimize the negative effect imposed on production rate.

In this project an existing production test for fully assembled brushless DC motors was re-mented for a new test equipment at Allied Motion. The purpose was to modernize the test and imple-ment it in the company’s own LabView-based software platform.

The test sequence was streamlined by combining and thereby reducing the number of steps, using the same motor runs to test multiple functions rather than repeating run sessions to collect data for sim-ilar test steps. The project resulted in a new test that, with a minor exception, covered the same meas-urements as in the old system and measured speed and torque performance with higher precision. The new test consisted of four partial tests instead of the earlier version’s twelve test steps, which were implemented in LabView-code as four separate test cases that could be used in creating complete test sequences in the software platform.

The project task though turned out to require more time and effort than was initially estimated, and several parts that had been planned to be completed within the project time still remained before the test could be taken into use in the production line.

Keywords

1.2 Målsättning ... 2

1.3 Avgränsningar ... 2

1.4 Författarens bidrag till examensarbetet ... 3

2 Teori och bakgrund ...5

2.1 Borstlösa DC-motorer (BLDC)...5 2.1.1 Uppbyggnad ...5 2.1.2 Styrning ...5 2.1.3 Karakteristik ... 7 2.2 Produktbeskrivning ... 9 2.3 Testning ... 10 2.4 Befintligt testsystem ... 11 2.4.1 Testrigg ... 11 2.4.2 Testsekvens ... 12

2.5 Utrustning för nytt testsystem ... 13

2.5.1 Testrigg ... 13

2.5.2 MintDriveII _{... 14}

2.5.3 LabView... 15

2.5.4 Allied Motions LabView-plattform ... 16

3 Metod ... 19

4 Genomförande ... 19

4.1 Litteraturstudier ... 19

4.2 Arbetsprocess ... 20

4.3 Analys och omarbetning av teststeg ... 21

4.4 Koppling av hårdvaruutrustning ... 22 4.5 Implementation i mjukvara ... 26 5 Resultat ...27 5.1 Nya testfall ...27 5.2 Mjukvara ... 29 5.2.1 Uppbyggnad ... 29 5.2.2 LabView-resurser ... 30 5.2.3 LabView-testfall ... 31

6 Analys och diskussion ...37

1 Inledning

Allied Motion, som examensarbetet utfördes i samarbete med, tillverkar och säljer elektriska motorer av olika storlekar och modeller för användning i bland annat styr-system för elfordon. Moderna elmotorer förses ofta med elektronik för kontroll och feldetektion. Den borstlösa likströmsmotorn, ofta förkortad ”BLDC”, drivs genom att bestämda sekvenser av strömpulser matas till kopparlindningarna och behöver en krets som sköter denna matning. Beroende på produktens användningsområde kan elektroniken utgöras av allt ifrån enklare styrkretsar till avancerade inbyggda system som stödjer flera kommunikationsprotokoll.

Vid tillverkning av komplexa produkter som elektronik är arbetet med testning en viktig del för att säkerställa kvalitet, och görs ofta i flera olika steg i produktionsked-jan. En kostnadseffektiv teststrategi handlar om en avvägning mellan noggrannhet och effektivitet. Fel bör hittas så tidigt som möjligt då kostnaderna ökar ju senare i processen de åtgärdas, samtidigt sänks produktiviteten ju mer tidskrävande test- och felsökningsrutiner som tillämpas.

Ett antal olika tester som skiljer sig i syfte och omfattning används vanligen i indu-strin. Kretskort kan exempelvis testas separat och grundligt ned på komponentnivå, och senare i tillverkningen ingå i nya test som görs på hela den produkt kortet mon-terats i.

I detta projekt implementeras produktionstest för BLDC-motorer. Detta avser ett rutinmässigt test som utförs på samtliga enheter, i detta fall sent i tillverkningsked-jan då motorerna är färdigmonterade med inbyggd styrelektronik. Produkten testas som helhet för att validera dess funktion under normala arbetsförhållanden.

1.1 Problemformulering

På företaget användes en äldre testutrustning baserad på PLC (Programmable Logic Controller) för produktionstest av borstlösa trefasiga likströmsmotorer. Denna hade begränsad precision i hastighetsmätningen, var svår att underhålla och att automa-tiskt lagra testresultaten från i databaser. Företaget önskade modernisera testningen genom att flytta den till en nyare LabView-baserad miljö och en modernare testrigg baserad på systemet Baldor MintDrive.

1.2 Målsättning

Det övergripande målet var att utveckla fungerade LabView-baserade testfall för två modeller av borstlösa DC-motorer.Testfallen skulle kunna användas i företagets be-fintliga LabView-plattform av operatör på produktionsavdelningen.

Dokumentation över testproceduren skulle tas fram som ger operatören tillräckliga instruktioner för att genomföra testerna på egen hand.

Testerna som utvecklades skulle täcka in minst de teststeg som genomförs i den äldre utrustningen, i den utsträckning dessa bedömdes fortsatt relevanta. Ett mål var att effektivisera genomförandet av befintliga mätningar genom att optimera och kom-binera teststegen där så var möjligt.

De teststeg som utformades skulle använda vetenskapligt grundade och vedertagna metoder för test och mätning.

Projektet innebar att utveckla och förändra ett Människa-Tekniksystem, där olika operatörer skall arbeta med resultatet utan att vara insatta i kodens och utrustning-ens inre funktionssätt. Ett lyckat projektresultat skulle innebära en övergång till ett annat system för de som arbetar med befintlig utrustning.

Hänsyn skulle därför även tas till ergonomiska aspekter inom människa-maskinin-teraktion för att minimera fel som uppkommer på grund av mänskliga missförstånd eller svårighet att tolka maskingränssnittet. Vid utformning av fysisk testutrustning beaktas ergonomiska aspekter för att minimera säkerhetsrisker och arbetsmiljöpro-blem. I detta projekt som handlade om mjukvaruutveckling för en befintlig utrust-ning hade dock frågorna relevans vid utformutrust-ning av testprocedurer och användar-gränssnitt.

1.3 Avgränsningar

De motormodeller som hanteras i projektet är Allied Motions BLDC3 med 5-polig kontakt samt en med 10-polig kontakt. Motorn finns i tre varianter med något skilda storlekar och specifikationer.

1.4 Författarens bidrag till examensarbetet

Författaren har själv utfört litteratursökningar och studier av teori. Analys och om-arbetning av befintligt test utfördes av författaren i samråd med projektets handle-dare, där förslagen till ändringar diskuterades innan beslut togs om upplägg för det nya testet.

I projektet implementerades det omarbetade testet i programkod för en existerande mjukvaruplattform. Författaren stod själv för designval av hur mjukvaran skulle struktureras inom ramen för plattformens designregler, och utformning av gräns-snitt mellan de olika mjukvarudelar som utvecklades.

Programkod för testfallen i LabView togs fram genom omarbetning av och tillägg till ett enkelt exempelprojekt. Detta rekommenderades då nya testfall skulle tas fram, för att utgå från en fungerande uppsättning av de metoder som krävdes för systemets hantering av testfallet. Författaren skapade själv koden för de arbetsuppgifter som respektive testfall utförde och den lagring av data som behövdes, samt utformade användargränssnitt för inställningsfönster och det panelfönster som visades under själva testet.

LabView-kod för kommunikation med motordrivenheten MintDriveII _{togs fram}

ge-nom att modifiera koden i ett liknande LabView-projekt som tagits fram av andra utvecklare på företaget. Koden var inte direkt applicerbar i det egna projektet men dess hantering av ActiveX-objekt studerades och anpassades till en användbar form. Även för en funktion som lät användaren öppna och spara filer med testinställningar togs inspiration från kod som fanns sedan tidigare på företaget, dock kunde inte hel-ler denna användas direkt utan modifierades till att bland annat hantera en annan filtyp.

Den Mint Basic-kod som utarbetades var även den en utbyggnad av en tidigare ap-plikation, som handledaren själv programmerat en längre tid tillbaka för test av en enklare motormodell. Dess befintliga struktur för kommandohantering behölls, men författaren ändrade i befintliga kommandofunktioner och lade till egna komman-don.

2 Teori och bakgrund

2.1 Borstlösa DC-motorer (BLDC)

2.1.1 Uppbyggnad

Elektriska motorer finns i en mängd utföranden och brukar grovt uppdelas i AC- och DC-motorer (växelström respektive likström). Den borstlösa DC-motorn kan sägas falla mellan kategorierna, med uppbyggnad som en permanentmagnetiserad syn-kron AC-motor men karakteristik liknande DC-motorns [1, pp. 1, 391]. I Figur 2.1 jäm-förs uppbyggnaden hos DC och BLDC-motorn.

I borstlösa DC-motorer samt permanentmagnetiserade AC-motorer består rotorn av magneter medan lindningar av koppartråd endast finns i statorn, d.v.s. motorns icke-rörliga del. Vridmomentet som ger rotationsrörelse uppstår då ström flyter ge-nom statorlindningarna och ger upphov till magnetfält som samverkar med rotor-magneternas fält. För att åstadkomma en konstant rotation måste statorfältet konti-nuerligt förflyttas runt rotorn, vilket innebär att lindningarna måste magnetiseras i en bestämd sekvens. AC-motorns faslindningar matas med sinusformad ström som ger denna sekvens, medan lindningarna i BLDC-motorn istället utsätts för omväx-lande positiva och negativa DC-pulser.

För denna förflyttning av magnetiseringsström mellan faser, så kallad kommutering, används kontakter i form av ”borstar” i traditionella DC-motorer som släpar mot ro-terande anslutningar till rotorns lindningar. Då ingen ström går genom den rörliga delen av BLDC:n behövs inga borstkontakter, vilket ger motortypen fördelar i form av mindre förlusteffekter, värmeutveckling och förslitning som annars orsakas av friktionen mellan borstar och rotor.

2.1.2 Styrning

Kommuteringen i den bortslösa DC-motorn sköts av en styrkrets som ger matning av strömpulser i rätt ordning till statorlindningarna. ”Six step” är en vanlig kommu-teringsprincip för trefasiga BLDC-motorer, där lindningarna polariseras i en sekvens av sex olika kombinationer för att ge roterande rörelse. Två faser magnetiseras i varje läge med motsatta polariteter medan den tredje lämnas inaktiv. Styrningen reali-seras vanligen med en effektbrygga uppbyggd av MOSFET-transistorer, där brygg-kopplingarna för de tre faserna delar matningsspänning och jordpunkt, se Figur 2.2

nedan. Med Y-kopplade lindningar i motorn som delar en gemensam neutralpunkt

kan motsatt polarisering åstadkommas genom att öppna den övre respektive undre transistorn i två olika faser. Den övre transistorn leder ström från matningen genom den ena fasen till neutralnoden, strömmen leds sedan via den andra fasen genom undre transistorn till jord.

För att kunna aktivera faserna i rätt ordning behöver styrkretsen återkoppling om

rotorns aktuella position för att avgöra utsignalerna för nästa läge. Den vanligaste formen av återkoppling görs med hallgivare som sitter placerade kring rotorn, och vars mönster av pulssignaler kan avläsas för att bestämma position och hastighet. Hallgivare ger en digital utsignal som beror av magnetfält som känns av nära sensorn [1, pp. 395-396].

En annan teknik för återkoppling är encoder, som består av en skiva försedd med positionsinformation i form av linjer eller spalter som kan läsas av en ljus- eller av-ståndssensor. Encoderskivan är kopplad till axeln och roterar i samma hastighet, och kan ge information med hög precision beroende på antalet linjer [1, pp. 375-381]. Teknisk utveckling inom borstlösa DC-motorer har även lett till konceptet ”sensor-less” där inga sensorer placeras vid rotoraxeln. Position och hastighet kan istället bestämmas genom att känna av spänningen i statorlindningarna, eftersom en emk-spänning induceras ”tillbaka” i lindningen när en permanentmagnet passerar [1, pp. 412-415] [2].

Styrkretsen använder oftast PI- eller PID-reglering [1, pp. 406-408] för att styra mo-torn efter antingen önskad hastighet, position eller ström, som representerar vrid-moment. En varierbar insignal representerar börvärde och reglering enligt sluten-loop-principen [3] görs med återkoppling av aktuellt varvtal, position eller ström. Moderna styrkretsar innehåller ofta mer funktionalitet än denna reglering och kan utgöras av komplexa inbyggda system med exempelvis programmerbart minne, övervakning av parametrar för feldetektion och stöd för olika kommunikations-gränssnitt [4, pp. 309-311].

2.1.3 Karakteristik

Emk-spänning

Statorlindningarna fungerar som spolar enligt induktionsprincipen. Förändring av magnetflödet inuti en spole inducerar en s.k. ”emk”-spänning över den, vilket sker inuti motorn när rotorns permanentmagneter passerar lindningarna. Hos en borst-lös DC-motor har de emk-spänningar som uppkommer en trapetsform, se Figur 2.3

nedan.

En Emk-konstant, Ke, definieras vanligen för BLDC-motorn som relationen mellan

total emk e och hastighet ω med enheten rad/s enligt följande: [5, p. 984] [4, p. 292]

𝑒 = 𝐾_𝑒𝜔 (1)

Alternativt uttrycks hastigheten som n med enheten varv per minut:

𝑒 = 𝐾_𝑒𝑛 (2)

Vridmoment

Det utvecklade elektromagnetiska vridmomentet Te i BLDC-motorn beror av

emk-spänningarna exsamt strömmarna genom faslindningarna ix och kan uttryckas

𝑇_𝑒 = 𝑃𝑒 𝜔 =

𝑒𝑎𝑖𝑎+𝑒𝑏𝑖𝑏+𝑒𝑐𝑖𝑐

𝜔 (3)

Effekten Pe är enligt omskrivning av (3) produkten av moment och vinkelhastighet:

𝑃𝑒= 𝑇𝑒𝜔 (4)

I varje läge vid ”six step”-kommutering utvecklas effekt i de två aktiva faserna, me-dan den fas som inte leder ström inte heller bidrar till effekten. De aktiva faserna har mot varandra motsatt strömpolaritet, men då emk-spänning och ström har samma

polaritet respektive varje fas ges samma bidrag till effekt och därav vridmoment [1, p. 401]: 𝑇𝑒 = 𝑒𝑎𝑖𝑎+𝑒𝑏𝑖𝑏+𝑒𝑐𝑖𝑐 𝜔 = 𝐸𝐼+(−𝐸)(−𝐼) 𝜔 = 2 𝐸𝐼 𝜔 (5)

Vid belastning av motorn utvecklas ett vridmoment som uppväger det pålagda be-lastningsmomentet TL på motoraxeln samt förluster i form av friktions- och

tröghets-moment [5]:

𝑇𝑒 = 𝑇𝐿+ 𝐵𝜔 + 𝐽 𝑑𝜔

𝑑𝑡 (6)

Momentkonstanten Kt definieras som relationen mellan ström och totalt utvecklat

vridmoment:

𝑇_𝑒 = 𝐾_𝑡𝑖 (7)

I verkliga motorer kan variationer i fasströmmar samt i inducerad emk förekomma och orsaka momentvariationer [1, pp. 402-404] [6].

Varvtal

BLDC-motorns varvtal är proportionellt mot matningsspänningen [1, p. 406]. Då samma spänning används för matning till lindningarna genom de tre inverterarkret-sarna kan varvtalet regleras genom att variera den gemensamma matningsspän-ningen. Vanligen sker dock varvtalsregleringen av motorn genom att styrkretsen va-rierar de signaler som öppnar och stänger MOSFET-transistorerna i så kallad puls-breddsmodulering (PWM) medan matningsspänningen är konstant [1, pp. 409-411].

Varvtal-momentrelation

Utvecklat moment är omvänt proportionellt mot varvtalet. Motorn har därför högst hastighet i obelastat tillstånd och utvecklar maximalt moment vid full belastning, det vill säga då lastmomentet helt bromsar in axelns rörelse. Karakteristiken visas i Figur 2.4 nedan. Kurvans lutning är relaterad till lindningsresistansen Ra, emk- och

mo-mentkonstanterna Ke och Kt och är idealt konstant och oberoende av

matningsspän-ningen V.

2.2 Produktbeskrivning

De två motormodeller som behandlades i projektet är uppbyggda på samma sätt men den ena modellen har ett enklare gränssnitt till den inbyggda styrelektroniken med en 5-polig kontakt, medan den andra, standardmodellen, har en 10-polig kontakt och finns i tre storlekar. I Figur 2.5 visas den 10-poliga BLDC3-motorn.

Tabell 2.1: Kontaktgränssnitt för och Tabell 2.2 nedan beskriver kontaktgränssnitten till

respektive modell. Motordriften regleras baserat på hastighetsbörvärde, och motorn med det enklare gränssnittet kan endast köras i medsols riktning.

Tabell 2.1: Kontaktgränssnitt för 5-polig modell

1 24 V DC VCC

2 Speed Analog insignal för hastighetsbörvärde

3 Brake Digital insignal för bromsning

4 Hall A Digital utsignal från Hallgivare A

5 0 V GND

Tabell 2.2: Kontaktgränssnitt för 10-polig modell

1 24 V DC VCC

2 0 V GND

3 0 V Referensjord för signaler

4 Speed Analog insignal för hastighetsbörvärde

5 5,7 V ref Matning till potentiometer för analog signal

6 Dynamic brake Digital insignal för bromsning

7 CW/CCW Digital insignal för riktningsval

8 Enable Digital insignal för aktivering av kontrollfunktioner

9 Hall A Digital utsignal från Hallgivare A

10 Hall B Digital utsignal från Hallgivare B

Motorerna styrs med ”six step”-kommutering och har tre hallgivare som används för återkoppling och reglering. Rotorn är uppbyggd av neodymmagneter och har fyra magnetsiska poler.

En LED-lampa som kontrolleras av motorns styrelektronik indikerar funktion eller hårdvarufel med grönt respektive rött ljus. Figur 2.6 från databladet visar översiktligt

styrkretsens uppbyggnad.

Den inbyggda elektroniken har funktioner för att bland annat känna av övertempe-ratur och att begränsa strömmen. Moment-varvtalskarakteristiken för de tre olika motorstorlekarna framgår i Figur 2.7, och skiljer sig från den ideala graf som visas i

figur Figur 2.4 på grund av att styrelektroniken begränsar motorns effekt.

2.3 Testning

Testning är ett brett begrepp som omfattar arbete för att verifiera en framtagen pro-dukts funktion och uppfyllelse av ställda krav. Vilken teststrategi ett företag använ-der syftar på hur man med helhetssyn på produktlivscykeln prioriterar upptäckt och hantering av kvalitetsbrister, olika slags testmetoder används för att implementera strategin. [7, pp. 4-7], [8, p. 27]

Vid tillverkning av elektronik utförs testning med fördel på flera nivåer både i pro-duktutvecklingen och i den löpande produktionen istället för att utgöra en avgränsad fas. Det är motiverat att tillämpa testning tidigt i en process då kostnaden för att

Figur 2.6: Förenklat schema över BLDC3. Källa: [25]

rätta till ett fel i en produkt ökar ju senare det upptäcks. För komplexa system beräk-nas kostnaderna öka exponentiellt [9], ett vanligt antagande för elektronikprodukter är att ett fel är 10 gånger dyrare att åtgärda jämfört med om det upptäckts i föregå-ende steg [7, pp. 53-54] [10, p. 3].

Prioriteringar vid utformning och implementering av tester skiljer sig åt mellan olika faser i tillverkningskedjan. Testning under design och konstruktion, exempelvis ”typtester”, bör vara utförliga för att utesluta fel, verifiera egenskaper och eventuellt kravuppfyllnad enligt standarder. När produkten sedan masstillverkas utförs

pro-duktionstester på samtliga enheter i produktionslinjen, och då prioriteras istället

kostnadseffektivitet vilket innebär att test av varje enskild produkt bör ske på kortast möjliga tid utan att brista i kvalitet [10, pp. 6-7].

Några vanliga metoder att testa elektronik är:

ICT – In-Circuit test. Detlaljerat test av kretsen på komponentnivå genom att

kretskortet spänns fast i testutrustning med ”nåldyna” som ger kontakt mot test-punkter i kretsen.

Funktionstest. Kretsen eller den kompletta produkten testas via sitt normala

gränssnitt under de arbetsförhållanden produkten är designad för, för att verifiera normal funktion.

Belastningstest. Kretsen eller hela produkten utsätts för ”extrema” förhållanden,

eventuellt under lång tid, för att testa tålighet och robusthet. (Källor: [7, pp. 59-96] [8, pp. 27-29])

2.4 Befintligt testsystem

2.4.1 Testrigg

Det testsystem för BLDC3-motorer som var i bruk då projektet startade bestod av en testutrustning baserad på PLC och en fixtur där en motor av samma BLDC3-modell som de testade enheterna användes som lastmotor.

För hastighetsmätning användes hallgivarsignaler från den testade enheten och/el-ler lastmotorn. Förutom PLC-utrustningen fanns en specialbyggd analog kontroll-box för styrning av BLDC3-motorerna vid provkörning och manuell testning. Utrust-ningarna visas i Figur 2.8 nedan:

2.4.2 Testsekvens

Den testsekvens som kördes i PLC-utrustningen fanns beskriven i en användarma-nual och bestod av tolv steg. Steg 9–12 kördes i tre omgångar vardera med matnings-spänningar på 20, 30 respektive 24 Volt till testobjektet. Nedan beskrivs de deltester som ingick, med de engelska namn som används i manualen:

1. Inspection – motorn körs 2–3 s med 1 V referensspänning och matnings-spänningen mäts. Operatören skall kontrollera att motorn sitter ordentligt monterad och att körningen sker utan problem.

2. LED indicator – operatören kontrollerar LED-lampan på den testade en-heten som indikerar fel, denna skall lysa grön.

3. Run motor – motorn körs medsols och motsols och riktningsändringen skall detekteras från lastmototorns Hallgivarpulser.

4. Noise level – operatören anger om ljudnivån från motorn är acceptabel. 5. Current, stalled motor – motorn hålls i stillastående läge av lastmotorn

och strömmen mäts. Momentet genomförs manuellt om lastmotorn saknar broms, operatören skall då låsa fast motoraxeln mekaniskt inför mätningen. 6. Current, low speed – strömnivån vid ”låg eller ingen hastighet” mäts.

Dokumentationen beskriver inte detta steg i närmare detalj.

7. Run continuously – motorn körs och belastas via lastmotorn och ström-men mäts. Belastningen sker dels via bromsning av lastmotorn, dels genom att dess faser kortsluts.

8. CW/CCW detection – motorn körs, riktningssignalen ändras och riktning-sändringen skall detekteras från lastmotorn hallgivarpulser

9. Speed symmetry – hastigheten mäts då motorn körs vid ett antal olika vär-den på referensspänningen. Skillnavär-den mellan resultaten i de två körriktning-arna beräknas.

10. Speed linearity – hastigheten mäts då motorn körs vid fyra olika värden på referensspänningen. Linjäriteten i hastighetskurvan beräknas och hastig-heten vid maximalt börvärde kontrolleras.

11. 5,7 V reference – utsignalen från motorn för matning till potentiometer mäts

12. Dynamic brake – tiden mäts då motorn saktar in från konstant hastighet till stillastående utan respektive med bromssignal. Kvoten mellan tiderna skall ligga inom tillåtna gränsvärden.

2.5 Utrustning för nytt testsystem

2.5.1 Testrigg

Den nya testriggen var uppbyggd på en bänk med ett utrustningsskåp undertill, och dess huvuddelar utgjordes av en stationär PC-dator, motordrivenheten Baldor Mint-DriveII_{, en elmotor från Baldor med encoder samt en fixturanordning. Riggen hade}

tidigare använts för att testa andra modeller av små elmotorer. I fixturen kunde två motorer monteras vända mot varandra för sammankoppling av motoraxlarna vid test, se Figur 2.9 nedan. Figur 2.10 visar riggens uppbyggnad.

Genom att byta fixturdelen för testobjektet kunde olika motormodeller monteras fast, och även ett fäste för BLDC3 hade tillverkats tidigare. MintDriveII _{var monterad}

i skåpet tillsammans med ett variabelt spänningsaggregat, ett datainsamlingskort (Eng. ”Data Acquisition Card”, DAQ) och kringelektronik. I skåpets vägg fanns två kontakter monterande som på insidan var kopplade till olika portar hos MintDriveII

samt till spänningsaggregatet. Kontakternas syfte var att enkelt kunna koppla in den motor som skulle testas, och för detta användes specialbyggt kablage som passade det aktuella testobjektets gränssnitt.

lastmotor kontakter PC MintDriveII DAQ testobjekt spänningsaggregat

Figur 2.9: Fixtur för testobjekt (t.v.) och lastmotor (t.h.)

Figur 2.10: Förenklad skiss över nya testriggen Figur 2.9: Fixtur för testobjekt (t.v.) och lastmotor (t.h.)

2.5.2 MintDriveII

MintDriveII _{(se Figur 2.11) är en drivenhet för rörelsestyrning s.k. ”Intelligent Motion}

Control”. Drivenheten är en styr- och programmerbar hårdvara som kan användas för kontroll av elektriska motorsystem i exempelvis industritillämpningar [11]. Pro-dukten tillverkas av företaget Baldor som ägs av ABB sedan 2011 [12].

Förutom gränssnitt för servostyrning av en motor är drivenheten försedd med både digitala och analoga in- och utgångar som kan användas för mätningar och kontroll av ytterligare utsignaler.

MintDriveII _{kan kommunicera med en dator via det seriella gränssnittet RS232. Via}

funktionsbiblioteket ”Mint Motion Control” (MML) som stöds av drivenheten kan hårdvaran styras från värddatorn genom anrop till MML-funktioner över den seri-ella anslutningen. Komponenter i Mint-systemet visas i Figur 2.12 nedan.

Kontroll av MintDriveII-hårdvaran kan ske på flera sätt, däribland [13]: • Anrop via serieterminal i värddator till MML-funktionerna

• Körning av ett applikationsprogram i datorn som använder funktioner i sär-skilda Mint ActiveX-kontroller

• Kompilering och nedladdning till MintDriveII _{av ett program skrivet i språket}

Mint Basic, som körs i en virtuell maskin (”MVM”) på enheten

”Mint WorkBench” är en integrerad utvecklingsmiljö för programmering och kom-pilering av Mint Basic-applikationer, som även låter användaren styra och interagera med drivenheten via inbyggda programfunktioner och terminalfönster [14].

En mängd inställningar kan göras i drivenheten via kommandon eller programkod. Styrningen av motorn kan exempelvis göras baserat på önskad hastighet, position eller ström beroende på hur inställningen CONTROLMODE sätts.

Ett särskilt minnesutrymme kallat COMMS finns avsatt för delning av data mellan drivenhetens egen mjukvara och en extern applikation. COMMS är en matris (Eng. ”Array”) av 255 minneselement där de 99 första är fritt tillgängliga för användning i applikationer, medan de resterande är reserverade för systemparametrar [15].

2.5.3 LabView

LabView är en utvecklingsmiljö från National Instruments med grafiskt gränssnitt för programmering, där exekveringen baseras på dataflöden. LabView-applikationer byggs upp av ”Virtual Instruments”, förkortat VI, som är avgränsade programmodu-ler bestående av ett blockschema som innehålprogrammodu-ler modulens programkod, ett grafiskt gränssnitt samt eventuellt in- och utgående terminaler för data. I koden kan andra VI-moduler inkluderas och syns då som enkla block vars inre uppbyggnad är dold, men där flöden för indata och resultat kan kopplas till blockens terminaler.

En mängd färdiga funktionsblock finns tillgängliga i LabView-miljön och kan inklu-deras i schemat. Däribland finns logiska och numeriska operationer, funktioner för hantering av datasamlingar och kommunikation med externa program och resurser, exempelvis ActiveX-kontroller. I det grafiska gränssnittet placeras ”kontroller” som knappar och textfält varifrån data kan läsas i programkoden, och ”indikatorer” som lampor och grafer dit data kan skrivas ut [16]. I Figur 2.13 visas uppbyggnaden hos en

enkel VI som används i Allied Motions testplattform, vilken beskrivs i följande av-snitt.

Tilläggsverktyget G# från AddQ Consulting möjliggör objektorienterad LabView-kodning med klasser som kan innehålla privata och publika metoder och ärva från andra klasser [17].

2.5.4 Allied Motions LabView-plattform

När projektet genomfördes hade företaget tagit en skräddarsydd helt LabView-base-rad mjukvaruplattform i bruk och påbörjat implementering av nya och befintliga motortester för denna. Tester som körs i plattformen bygger förenklat på ”aktivite-ter” och ”resurser”.

En aktivitet, som ofta utgör ett avgränsat teststeg, utför en uppgift och anger som utdata om resultatet var lyckat eller misslyckat. En resurs erbjuder ett gränssnitt mot en specifik hårdvara, exempelvis en digital multimeter, och kan användas av aktivi-teter för att interagera med testriggens utrustning.

Testplattformen har en objektorienterad struktur där både aktiviteter och resurser implementeras som klasser med privata och publika metoder samt datamedlemmar. Teststeg och hårdvarugränssnitt som ska användas i plattformen måste programm-eras som aktiviteter respektive resurser och vara strukturerade enligt bestämda mönster. En viss uppsättning grundläggande metoder i form av virtuella instrument måste finnas med som anropas när aktiviteten eller resursen körs i plattformen. Information som behöver återanvändas i olika metoder sparas i en datastruktur för temporära attribut samt fildata som sparas i en konfigurationsfil mellan program-körningar.

Vid uppstart anropas metoder där bland annat klassens data laddas från fil. Ett in-ställningsfönster öppnas sedan där användaren kan ändra parametrar innan själva arbetet utförs i metoden ”RunTest” för aktiviteter respektive ”iTestPanel” för resur-ser. I dessa metoders användargränssnitt placerar programmeraren kontroller och/eller fält för återkoppling. RunTest-metoden i en aktivitet skall utföra aktivite-ten och utvärdera om resultatet är godkänt eller ej, medan iTestPanel hos en resurs ger användaren möjlighet att interagera med den hårdvara resursen är utvecklad för. Vid stängning körs en metod som åter sparar datan till fil.

Ett enkelt exempel på en aktivitet fanns som programmerare uppmanades utgå från vid utveckling av egna testfall. Användargränssnittet visas i Figur 2.14 nedan och

in-nehåller en textsträng och en timer vars värden kan väljas i inställningsfönstret. De metoder som krävdes i plattformen fanns implementerade och projektet kunde mo-difieras främst genom att ändra i RunTest-metoden och lägga till attribut och fildata som behövde lagras.

Ett test består i plattformen av en sekvens av aktiviteter som exekveras i följd. För att bygga ett fullständigt test skapas ett ”testrecept” dit aktiviteter plockas in och ordnas, och parametrar väljs i respektive aktivitets inställningsfönster. En aktivitet kan återanvändas flera gånger i samma testrecept med olika parametrar. Ett enkelt exempel visas i Figur 2.15 , där aktiviteten från exempelprojektet lagts in i en

testse-kvens.

3 Metod

Följande metoder användes för att lösa uppgiften:

• Litteraturstudier och studier av dokumentation, kopplingsscheman och da-tablad

• Kartläggning av standarder för testmetoder • Intervjuer med personal på företaget

• Mätningar med oscilloskop samt digital multimeter

• Beräkningar för dimensionering av spänningsdelare, transistorkopplingar och filter

• Utformning av en modell för mjukvaran som passade testplattformens struk-tur och designregler, och som implementerades i LabView- och Mint Basic-kod

4 Genomförande

4.1 Litteraturstudier

För att fördjupa kunskaperna om borstlösa DC-motorer samt om testutveckling gjor-des en litteraturstudie inledningsvis i projektet.

Studier av dokumentation till den befintliga testutrustningen och intervjuer med personal på företaget, främst den processingenjör som ansvarade för testutrust-ningar och även handledde projektet, gjordes för att få kunskap om syftet med de tester som utfördes och om företagets teststrategi och -metoder. Tillgänglig doku-mentation bestod av kopplingsscheman och instruktioner avsedda att användas av operatör, där beskrivningen av teststegen var kortfattad och med få tekniska detaljer (se avsnitt 2.4.2).

Inför utformning av nya testfall gjordes en kartläggning av standarder för testmeto-der inriktade på elektriska motorer och i synnerhet borstlösa DC-motorer.

4.2 Arbetsprocess

I syfte att strukturera arbetsprocessen söktes en modell för testframtagning under projektets inledande litteraturstudie. Ingenjören Stephen F. Scheiber beskriver i boken ”Building a successful Board test strategy” [7] den ”idealiserade” processen för utveckling av testprogram framtagen av företaget Racal-Dana, se Figur 4.1 nedan.

Denna modell användes som ledning vid framtagning av tidplan för arbetet. Valide-ring av testprogrammets funktionsduglighet görs genom att testet provkörs och re-sultaten jämförs mot alternativa metoder som manuell testning eller en äldre befint-lig testprocedur [7, pp. 230-235].

Det finns många olika alternativa modeller för planering av projektarbeten. Ett känt mer traditionellt koncept är ”Vattenfallsmodellen” där projektet uppdelas i större tydligt avgränsade faser som genomförs i tur och ordning. Modernare så kallade ”Agila” metoder, varav ”Scrum” är en av de mer kända modellerna, bygger istället på mer inkrementell utveckling, och korta intervall där fokus ligger på att prioritera krav och leverera fungerande delresultat [21, pp. 473-477] [22, pp. 7-40].

4.3 Analys och omarbetning av teststeg

Den befintliga testsekvensen som beskrivs i avsnitt 2.4.2 analyserades och möjlig-heter att effektivisera körningen av testet identifierades i samråd med handledaren för projektet. Följande slutsatser drogs:

• Inspektionen i steg 1 kunde bortses från i nya implementationen då manuell inspektion anses vara en del av processen och inte av testutrustningen

• Kontroll av LED-indikator i steg 2 och motorljud i steg 4 skulle även i det nya testet baseras på återkoppling från operatören. De delar av testet som invol-verar operatören borde utföras så nära varandra som möjligt så att de auto-matiserade momenten sedan kan köras utan avbrott.

• Syftet med strömmätning i steg 6 vid ”låg eller ingen” hastighet var otydligt, momentet skulle bortses från tills vidare

• Körning och belastning av motorn i steg 7 (”Run continuously”) skulle ersät-tas med ett utförligare test av hastighet vid flera olika belastningsnivåer och uppritande av en moment-hastighetskurva

• Strömmätning vid låst motoraxel (”Stalled torque”) i steg 5 skulle kunna om-fattas av samma test som ersatte steg 7, då låst axel motsvarar ett moment-hastighetsläge på kurvan.

• Steg 9 och 10 som mätte hastighetskarakteristikens linjäritet respektive sym-metri baserades båda på mätningar av hastighet som funktion av börvärde och skulle kunna kombineras i samma testfall. En enskild serie mätningar kunde då användas för att testa båda egenskaperna.

• Referensspänningen på 5,7 V hos den 10-poliga motorn mättes först i steg 11 i det befintliga testet. Denna konstanta utsignal är viktig för motorns funktion och enkel att mäta och borde därför testas i början av den nya sekvensen för att utesluta större fel så tidigt som möjligt

• Syftet med mätning av inbromsningstiden i steg 12 var att kontrollera att bromsfunktionen fungerar. Att mäta just tid var inte ändamålet utan en me-tod för att jämföra förloppen vid avstängning och bromsning.

• Även utsignalerna från hallgivarna skulle testas, inledningsvis bestämdes att grundläggande funktion skulle verifieras genom att mäta pulssignalerna vid ett enskilt hastighetsläge. Senare diskuterades frågan vidare och det ansågs relevant att testa att pulssignaler kan detekteras vid alla hastigheter

4.4 Koppling av hårdvaruutrustning

Den befintliga Baldor-motorn i testriggen utnyttjades som lastmotor genom att mo-toraxlarna kopplades samman vid test, se Figur 4.2: Huvudkomponenter i hårdvaruupp-sättning nedan. Belastningen av BLDC3-motorn kunde då varieras genom att variera

börvärdet för vridmoment i MintDrive och axelns hastighet kunde utläsas baserat på återkoppling från lastmotorn.

Befintliga kopplingar mellan skåpets kontakter och den inbyggda testutrustningen undersöktes. En av kontakterna var kopplad till lämpliga portar hos MintDrive och det variabla spänningsaggregatet sedan tidigare testuppsättning och borde även kunna användas till BLDC3-motorerna. En kabel hade byggts långt innan projektet för att kunna koppla in BLDC3-motorn med 10-polig kontakt, undersökning visade dock att fel kontaktdon använts samt att kabeln hade en inre kortslutning.

Delar till nytt kablage beställdes därför, och då leveransen dröjde byggdes ett tillfäl-ligt kontaktgränssnitt på ett prototypkort för att kunna testköra motorer under mjukvaruutvecklingen. Kablar kopplades temporärt in direkt på MintDrive-enhet-ens portar, och samma skyddsresistanser som enligt kopplingsschemat fanns mellan portarna och skåpets kontakt monterades på prototypkortet.

MintDriveII PC Variabelt Spännings-aggregat Testobjekt Lastmotor Matning Återkoppling Styrsignal Ut sp än n in g R S 23 2 S ign al er Kabel för testobjekt kontakt NI PCI-6221 DAQ strömtång

Digital ingång 24 V

Hallgivarsignal 12 V

Hallgivarutgångarna kopplades först till digitala ingångar hos MintDriveII_{, vilket}

krävde signalförstärkning för att Hallgivarsignalernas 12 V-nivå skulle kunna detek-teras på ingångarna. Enligt databladet definierades 24 V ±20% som ”hög” digital sig-nal hos MintDrive. Inverterande kopplingar med MOSFET-transistorer monterades därför på prototypkortet, se Figur 4.3 nedan.

Senare flyttades kopplingen för läsning av Hallgivarna till digitala ingångar med räk-narfunktion hos datainsamlingskortet NI PCI-6221.

Transistorkopplingarna byttes ut mot spänningsdelare för att sänka den höga spän-ningsnivån från 12 V från Hallgivarutgångarna till maximalt 5 V på datainsamlings-kortets ingångar. Ingångarna var försedda med interna 20 kΩ ”pull-down”-mot-stånd, därför valdes yttre 33 kΩ-motstånd som gav spänningsnivån:

12 ∗ 20 𝑘

20 𝑘+33 𝑘 ≈ 4,53 𝑉 (8)

Dock upptäcktes att betydande störningar på signalen plockades upp via kabeln och försvårade korrekt pulsdetektion, se Figur 4.4 nedan. Vid körning av en

flankräknar-funktion i National Instruments DAQ-mjukvara detekterades ständigt falska pulser då motorn stod still.

Figur 4.4: Oscilloskopbild av Hallgivarsignal med störningar

Kablaget byttes ut mot en skärmad kabeltyp och ett lågpassfilter skapades genom att räkna ut lämplig kapacitans som kopplades in vid befintliga spänningsdelare enligt

Figur 4.5 nedan.

Enligt BLDC3-motorns datablad är maximalt varvtal knappt 4000 varv per minut och Hallgivarna ger två pulser per varv. Maximal grundfrekvens på pulssignalerna bör därför vara

4000

60 ∗ 2 ≈ 133 𝐻𝑧 (9)

En fyrkantspuls består av oändligt antal udda multiplar – ”övertoner” - av grundfre-kvensen, och ju fler övertoner som behålls efter lågpassfiltrering desto tydligare puls-form bibehålls [23, pp. 63-81]. Filtrets brytfrekvens måste därför sättas så att ett an-tal övertoner inkluderas.

Sambandet mellan kapacitans och brytfrekvens härleddes enligt följande:

(𝑅𝑖𝑛|| 𝑋𝐶) = 𝑅𝑖𝑛∗( 1 𝑗𝜔𝐶) 𝑅𝑖𝑛+( 1 𝑗𝜔𝐶) = 𝑅𝑖𝑛 1+𝑗𝜔𝑅𝑖𝑛𝐶 (10) 𝑈𝑢𝑡 𝑈𝑖𝑛 = (𝑅𝑖𝑛|| 𝑋𝐶) 𝑅+ (𝑅𝑖𝑛|| 𝑋𝐶)= ( 𝑅𝑖𝑛 1+𝑗𝜔𝑅𝑖𝑛𝐶) 𝑅+( 𝑅𝑖𝑛 1+𝑗𝜔𝑅𝑖𝑛𝐶) = 𝑅𝑖𝑛 𝑅+𝑅𝑖𝑛+𝑗𝜔𝑅𝑅𝑖𝑛𝐶 (11)

Ekvation (11) omskriven på Bodes normalform [24, pp. 101-108] ger: 𝑅_𝑖𝑛 𝑅+𝑅_𝑖𝑛

∗

Vid brytfrekvensen för filtret gäller: | 1 1+𝑗𝜔(𝑅𝑅𝑖𝑛 𝑅+𝑅𝑖𝑛)𝐶 | = 1 √2 ⇒ 𝜔 ( 𝑅𝑅𝑖𝑛 𝑅+𝑅𝑖𝑛) 𝐶 = 1 (13) 𝑓 = 1 2𝜋(𝑅𝑅𝑖𝑛 𝑅+𝑅𝑖𝑛)𝐶 (14)

Givet befintliga resistanser för spänningsdelning erhölls sambandet:

𝑓 =

2𝜋(20𝑘∗33𝑘 20𝑘+33𝑘)𝐶

=

𝐶 (15)

En kapacitans på 10 nF skulle enligt sambandet ge brytfrekvensen 1278 Hz vilket skulle omfatta högsta grundfrekvensen samt 3:e, 5:e, 7:e och 9:e övertonen. Då vär-det inte fanns att tillgå seriekopplades istället två kondensatorer på 22 nF för att ge kapacitanser på 11 nF och teoretiska brytfrekvensen 1162 Hz, vilket var under men nära 9:e övertonen.

4.5 Implementation i mjukvara

De nya teststegen implementerades i programkod för dels testplattformen i LabView och dels för MintDrive i språket Mint Basic.

Gränssnittet för att kommunicera med MintDrive-hårdvaran implementerades som ”resurs” för att följa testplattformens designregler. En ”Baldor-resurs” hade utveck-lats på företaget tidigare, men visade sig inte användbar då den var utformad för en mycket specifik applikation och använde en ActiveX-kontroll med begränsat funkt-ionsutbud. Baldor-resursen arbetades därför om till en version med mer generellt gränssnitt, där funktioner för att skriva och läsa önskad ingång, utgång eller COMMS-element lades till. Den nya resursen använde en ActiveX-kontroll av typen ”MintControls” som erbjöd en mängd funktioner varav många motsvarade funkt-ionsanrop till Mint Motion Library.

En extra resurs skapades också som en digital version av den fysiska kontrollbox som användes för manuell testning. Denna resurs använde i sin tur den nya Baldor-re-sursens funktioner.

Varje nytt teststeg implementerades sedan som en separat ”aktivitet” i LabView. Plattformens exempelprojekt användes som utgångspunkt och modifierades till öns-kat beteende.

För programmering av MintDriveII _{användes ett Mint Basic-program som utvecklats}

för test av en annan motormodell och var uppbyggt som en tillståndsmaskin som läste in och hanterade kommandon. Programstrukturen behölls men kommando-uppsättningen modifierades och de funktioner som anropades ändrades för att passa testfallen för BLDC3-motorer.

Ett alternativt sätt att strukturera mjukvaran hade varit att bygga vidare på de Mint Basic-applikationer som utvecklats för tidigare motortest, där MintDriveII_-enheten

5 Resultat

5.1 Nya testfall

De tolv steg som utgjorde testsekvensen i det äldre systemet arbetades om till fyra steg som beskrivs nedan.

Initial Motor Run Test

Tabell 5.1: Testfall 1 " Initial Motor Run Test"

Syfte Kontrollera att kommuteringen fungerar samt avverka steg som kräver återkoppling från operatör

Ersätter tidigare steg 2, 3, 4, 11

Egenskaper som testas 10-polig 5-polig Villkor

Referensspänning 5,7 V stämmer • Spänning inom gränsvärden Motor kan köras medsols • • Axelrörelse i medsols riktning

detekteras

Motor kan köras motsols • Axelrörelse i motsols riktning detekteras

Ljudnivå acceptabel • • Positiv återkoppling från opera-tör

LED-indikator fungerar och inga hårdvarufel indikeras

• • Positiv återkoppling från oper-atör

Speed vs. Torque Test

Tabell 5.2: Testfallet "Speed Vs Torque Test"

Syfte Testa motorns hastighets-momentkarakteristik samt ström vid belastning

Ersätter tidigare steg 5,7

Egenskaper som testas 10-polig 5-polig Villkor

Hastighet vid belastning stämmer med produktspecifikation

• • Axelhastighet inom gränsvärden

Ström vid belastning stämmer med produktspecifikation

Speed Linearity and Symmetry Test

Tabell 5.3: Testfallet "Speed Linearity and Symmetry Test"

Syfte Testa motorns hastighetskarakteristik samt utsignaler från hallgivare

Ersätter tidigare steg 3, 8, 9, 10

Egenskaper som testas 10-polig

5-polig Villkor

Medsols hastighet varierar linjärt med börvärdet

• • Axelhastighet inom gränsvärden

Motsols hastighet varierar linjärt med börvärdet

• Axelhastighet inom gränsvärden

Hastighetskarakteristiken är lika i medsols och motsols körriktning

• Skillnad mellan hastighetskur-vorna inom gränsvärden Pulsfrekvens från hallgivare A

va-rierar linjärt med börvärdet

• • Pulsfrekvensen stämmer med axelhastigheten

Pulsfrekvens från hallgivare B va-rierar linjärt med börvärdet

• Pulsfrekvensen stämmer med axelhastigheten

Brake test

Tabell 5.4: Testfallet "Brake Test"

Syfte Kontrollera att motorns bromsfunktion fungerar Ersätter tidigare steg 12

Egenskaper som testas 10-polig

5-polig Villkor

Bromsfunktion vid körning medsols

• • Kvot mellan bromssträcka med respektive utan broms under gränsvärde

Bromsfunktion vid körning motsols

5.2 Mjukvara

5.2.1 Uppbyggnad

Den slutliga mjukvaran bestod av en LabView-implementerad ”aktivitet” för varje testfall, två ”resurser” för kommunikation med MintDriveII _{samt en Mint Basic-applikation. Figur 5.1}

nedan visar det slutliga mjukvarusystemets lagerbaserade uppbyggnad.

MintDriveII Mint Motion Library COMMS Mint Basic-Applikation Testfall BLDC3-resurs Baldor-resurs DAQmx-funktioner DAQ NI PCI-6221 Användargränssnitt, Testparametrar, Gränsvärden, Styrning Styrfunktioner, Portkonfiguration Kommunikationsgräns-snitt till hårdvara

Hårdvaru-nära funktioner

5.2.2 LabView-resurser

Den understa ”Baldor-resursen” skötte kommunikationen med MintDriveII_-enheten

och erbjöd generella funktioner för läsning och skrivning av digitala och analoga por-tar och COMMS-element till resursen på nivån över. För att sköta kommunikationen lagrades en referens till ett ActiveX-objekt bland klassens attribut som anropades i de olika funktionerna.

Den mellanliggande ”BLDC3-resursen” erbjöd ett enkelt gränssnitt av styrfunktioner som användes i testfallen för att kontrollera signalerna till testobjektet. Vissa av funktionerna använde anrop till applikationen i MintDriveII _{genom att skriva}

kom-mandon till COMMS-minnet, exempelvis för att sätta värdet på matningsspänningen och lastmomentet. Exempel på användning av funktionerna visas i Figur 5.2.

Resursen kunde användas direkt för manuell styrning av motorn på samma sätt som den fysiska kontrollboxen, och dess användargränssnitt var utformat för att likna boxens kontrollpanel, vilket visas i Figur 5.3 nedan. De portar som motorn var kopp-lad till kunde väljas i resursens inställningsfönster och sparades i konfigurationsfilen mellan programkörningar.

Figur 5.3: Kontrollboxens panel (t.v.) och dess motsvarighet i LabView-resurs (t.h.)

5.2.3 LabView-testfall

I testfallen på den översta nivån i lagerstrukturen som visas i Figur 5.1 lagrades och hanterades parametrar för testkörning och gränsvärden för godkända resultat. Pa-rametrar som motormodell, matningsspänning, hastighetsbörvärde och körtid kunde ställas in i respektive testfalls inställningsfönster. I de två testfall där mät-ningar skulle göras vid flera olika värden på hastighetsbörväde respektive lastmo-ment kunde uppsättningar av testpunkter med tillhörande gränsvärden laddas från fil. I Figur 5.4 visas hur de färdiga testfallen används för att skapa testrecept i platt-formen, och Figur 5.5 visar exempel på en moment-varvtalskurva från körning av test-fallet ”Speed Vs Torque Test”.

Samma programkod utgjorde testfall för både den 10-poliga och den 5-poliga mo-dellen. Värdet på parametern för motormodell användes för att välja bort de moment som inte var relevanta för den senare och dölja motsvarande delar av användar-gränssnittet. Nedan följer flödesscheman i Figur 5.6 t.o.m. Figur 5.9 som beskriver im-plementationen av respektive testfall.

Initial Motor Run Test Mät referensspänning Kör medsols Kör motsols 5-polig? Mät axelhastighet Mät axelhastighet 5-polig? Start Fråga operatör om ljudnivå och LED

Stoppa motor Utvärdera test Slut j j n n

Speed Vs Torque Test

Kör motor vid märklast

Byt riktning Mät axelhastighet, ström

5-polig el. båda riktn testade?

Start

Stoppa motor

Utvärdera test, rita graf

Slut

Belasta med moment för låst rotor

Mät ström

Belasta med moment för nästa testpunkt Fler test-punkter? Mät axelhastighet, ström j j n n

Speed Linearity And Symmetry Test

Sätt börvärde till noll

Byt riktning Start

Stoppa motor

Utvärdera test, rita graf

Slut Sätt börvärde för nästa testpunkt Fler test-punkter? Mät axelhastighet, Hallgivarfrekvens j j n n 5-polig el. båda

riktn testade?

Brake Test Kör motor på inställd hastighet Byt riktning Stäng av motor Start Stoppa motor Utvärdera test Slut

Mät antal varv till stillastå-ende axel j n Kör motor på inställd hastighet Aktivera broms

Mät antal varv till stillastå-ende axel

5-polig el. båda riktn testade?

6 Analys och diskussion

Projektets målsättningar var att analysera och om möjligt effektivisera det befintliga testet och att skapa en fungerande implementation i LabView-plattformen.

Resultatet blev ett test uppdelat i fyra deltester jämfört med tidigare tolv. Funge-rande LabView-implementationer skapades för respektive deltest, som kunde sättas samman till en körbar testsekvens. Dock tog implementationen i mjukvara längre tid än planerat och därför återstod en del arbete vid slutet av den avsatta projekttiden innan testet skulle kunna tas i bruk i produktionen.

Målen hade även föresatt att vetenskapligt grundade och vedertagna metoder skulle användas för implementation av testerna, dock visade det sig svårare än väntat att hitta och tillämpa lämpliga sådana.

Hänsyn skulle enligt målen tas till ergonomiska aspekter kring operatörens interakt-ion med systemet. Detta gjordes till viss del men att göra en utförlig analys och an-passning av systemet kvarstod efter projekttiden.

Även dokumentation i form av instruktioner för operatörer återstod att skapa, vilket hade varit planerat inom projektet men inte hunnits inom utsatt tid.

Det nya testet innehöll färre moment främst eftersom teststegen kombinerades på ett sätt som gjorde att antalet körningar av motorn kunde minskas. Samma körning användes där det var möjligt för att testa flera egenskaper istället för att upprepas. Inledande inspektion, som skulle utföras men inte inom det automatiserade testet, och strömmätning vid ”låg eller ingen hastighet” hade också bortsetts från enligt överenskommelse. Därutöver täckte det omarbetade testet in de mätningar som gjordes i den äldre utrustningen. Hastighet som funktion av börvärde samt hastighet som funktion av lastmoment testades vid fler punkter och med högre precision än tidigare, men utöver det lades inga nya egenskaper att testa till i omfattningen. Fungerande implementationer av de nya testfallen skapades som planerat. För att åstadkomma lätthanterlig kommunikation mellan testfall och hårdvara, och samti-digt hålla en god mjukvarustruktur i enlighet med testplattformens designregler, åt-gick dock en del tid till att arbeta fram ”resurser”.

Att två olika resurser utformades i en lagerbaserad lösning var för att framöver und-vika situationen som uppstått i projektet, där en befintlig resurs visat sig allt för spe-cialiserad för en viss applikation för att direkt kunna användas i andra tillämpningar. I mjukvaran lades såväl testparametrar som programkontroll och utvärdering av re-sultat i LabView-delen av systemet, istället för att bygga ut Mint Basic-applikationen med funktioner för kompletta teststeg och låta drivenheten utföra huvuddelen av ar-betet. LabView-miljöns modulbaserade uppbyggnad och stora utbud av funktioner för datahantering gjorde att den delen ansågs lämpligare att lägga merparten av lo-giken i, för att underlätta framtida underhåll och utbyggnad av systemet.

Inför utvecklingsarbetet söktes standarder för testmetoder i syfte att använda dessa som ledning vid implementation av testfallen. Det visade sig dock svårt att hitta re-levanta dokument om testmetoder för just BLDC-motorer som dessutom var till-gängliga utan höga kostnader. Förutom de standarder som studerades finns exem-pelvis IEC 60034-20-1:2002 och den mycket omfattande NEMA MG1, vilka dock inte var tillgängliga till överkomlig kostnad.

Vid studier av de standarder från IEEE och NEMA som hittades visade sig få metoder vara direkt och i helhet tillämpliga för denna typ av produktionstest av färdigbyggda motorer. Många av de rekommenderade metoderna involverade mätningar på och variation av parametrar direkt på motorfaserna, exempelvis sammankoppling av fa-ser eller bestämning av temperatur bafa-serat på uppmätta förändringar av lindnings-resistans. Vid det stadie i produktionen då testet gjordes var produkterna monterade så att styrelektronikens skyddskåpa inneslöt kablaget till motorfaserna. För mätning av momentkarakteristik fanns metoder beskrivna, för övriga delar av testet hittades inga standardmetoder. Det som befanns tillämpligt var endast proceduren för hur belastning applicerades vid test. Befintig funktion i Mint Basic-koden var utformad så att belastningen omedelbart nollställdes efter att medelhastighet och ström mätts upp vid en testpunkt. Koden ändrades så att belastningen kunde ändras succesivt för att spara tid och då standardmetoderna beskriver stegvis ändring av belastning, en-ligt exempelvis IEEE 113 5.7 bör belastningstest starta vid en hög belastning som successivt minskas.

Enligt momentekvationen (6) uppväger motorns elektromagnetiskt utvecklade mo-ment lastmomo-mentet samt tröghets- och friktionsförluster. Konstanterna för tröghet och friktion beräknades dock inte, vilket berodde på syftet med testet. I produktions-test ansågs det mer relevant att direkt mäta hastighet som funktion av pålagt last-moment än att beräkna vridlast-momentet kompenserat för förluster som utvecklades inuti motorn. Effekten är produkten av moment och hastighet enligt ekvation (4) och den nyttiga uteffekten av intresse för kunden är den del som relaterar till lastmo-mentet. Beräkningar av förlusteffekter och verkningsgrad bör vara mer relevant vid design och dimensionering och i typ- och valideringstester.

kopplad mellan motoraxlarna skulle monteras endast vid kalibrering för att ställa in korrekt omvandling av argument i Newtonmeter till rätt momentbörvärde hos Mint-Drive. En ständig användning av momentgivare ansågs i diskussion med handleda-ren överflödigt då linjäriteten i lastmotorns momentkaraktäristik var god och arbets-momentet för operatören annars skulle försvåras då testobjekt byttes i fixturen. Den modell för arbetsprocess som användes ansågs lämplig då den var inriktad på just testutveckling och betonar inledande kravspecifikation och dokumentation samt validering av testet efter utvecklingsarbetet. I projektet drog dock programutveckl-ingsfasen ut på tiden vilket gjorde att den validering och fokus på medveten design av användargränssnitt som planerats inte hanns med inom utsatt tid. Uppgiften upp-levdes inledningsvis enklare och mindre arbetskrävande än vad som senare visade sig. Att projektet utfördes av en enskild examensarbetare istället för två samarbe-tande studenter har säkerligen också inverkat på resultatet.

Vattenfallsmodellen hade använts i ett tidigare gruppbaserat projekt inom utbild-ningen och erfarenheten var att den lämpade sig mindre väl för utveckling av hård- och/eller mjukvara, då bristande hänsyn tas till att problem kan uppstå och beslut behöva omprövas under arbetets gång. Agila metoder som Scrum är dock ofta av-sedda för grupparbete där ett ”team” har tydligt uppdelade roller och gemensamma rutiner, vilket inte kan appliceras direkt på ensamarbete. En möjlig väg hade varit att ta inspiration från agila metoder och tillämpa de mest relevanta delarna i en egen modell. Fokus på att påbörja den praktiska utvecklingen så tidigt som möjligt och att arbeta inkrementellt med utvecklingen hade möjligen resulterat i att ett bättre resul-tat åstadkommits inom den planerade projekttiden.

7 Slutsatser

Det finns standardiserade testmetoder för elektriska motorer men dessa är mindre tillämpliga för snabba produktionstest av kompletta produkter. Utformning av såd-ana tester har inget givet svar utan är alltid en avvägning mellan omfattning, nog-grannhet, tids- och kostnadseffektivitet och där företaget självt måste besluta om vad som ska prioriteras.

Det befintliga testet kunde effektiviseras genom att antalet moment minskades, vil-ket bör gynna produktionsflödet genom mindre tidsåtgång för varje testkörning. Vid arbete med mjukvaruutveckling riskerar den tid och arbetsmängd som verkligen kommer att krävs att underskattas, då nya problem och frågeställningar ofta upp-kommer under processen, inte minst då man som utvecklare ska sätta sig in i regler och förutsättningar hos ett befintligt system och med begränsad erfarenhet av pro-gramspråken. Det är därför viktigt med god planering och att avsätta tid för oförut-sedda problem. Trots att detta togs hänsyn till i tidsplaneringen av projektet visade sig uppgiften dock kräva mer arbete än vad som hanns med inom utsatt tid.

Vidare arbete

Innan de nya testerna kan tas i produktion återstår att kalibrera instrumenten och validera testerna mer utförligt. Programkoden skall också testas igenom med avse-ende på robusthet och tillförlitlighet och förses med ytterligare felhantering, för att undvika att programmet fastnar under pågående test i ett läge där motorn är hårt belastad och blir överhettad.

Källförteckning

[1] S.-H. Kim, Electric Motor Control, Dep. of Electrical & Electronics Engineering, Kangwon National University, 2017.

[2] J. C. Gamazo-Real, E. Vázquez-Sánchez och J. Gómez-Gil, ”Position and Speed Control of Brushless DC Motors Using Sensorless Techniques and Application Trends,” Sensors, nr 10, pp. 6901-6947, 2010.

[3] V. Vandoren, ”Control Engineering,” 28 08 2014. [Online]. Available: https://www.controleng.com/articles/open-vs-closed-loop-control/.

[4] W. Drury, ”Motors, motor control and drives,” i Newnes Electrical Power Engineer's Handbook, Newnes, 2005, pp. 279-312.

[5] T.-Y. Ho, F.-T. Liu, G.-W. Ho och Y.-R. Lin, ”The implementation of a measurement system for brushless DC motor parameters,” International Journal of Green Energy, pp. 983-995, 2017.

[6] L. Sun, H. Gao, Q. Song och J. Nei, ”Measurement of Torque Ripple in PM Brushless Motors,” 2002.

[7] S. F. Scheiber, Building a Successful Board-Test Strategy, 2nd edition, Elsevier Inc., 2001. [8] Smartare Elektroniksystem, Smartare Elektronikhandboken, 2017.

[9] B. Haskins, J. Stecklein, B. Dick, G. Moroney, R. Lovell och J. Dabney, ”Error Cost Escalation Through the Project Life Cycle,” i INCOSE 2004 - 14th Annual International Symposium Proceedings, 2014.

[10] I. A. Grout, Integrated Circuit Test Engineering, Springer, 2006. [11] ABB, ”MintDrive-II,” [Online]. Available:

[13] ABB, Reference manual Mint Basic Programming, MN1955WEN, 2012. [14] ABB, ”MINT WorkBench,” 2013. [Online]. Available:

http://www.abbmotion.com/products/mint/workbench.asp. [Använd 13 04 2019]. [15] Baldor, ”AN00129-002 - Host Comms Protocol 2,” 2004.

[16] National Instruments, ”LabVIEW Environment Basics,” [Online]. Available:

http://www.ni.com/getting-started/labview-basics/environment. [Använd 13 05 2019]. [17] National Instruments, ”G# Framework - AddQ Consulting,” [Online]. Available:

http://sine.ni.com/nips/cds/view/p/lang/sv/nid/209103. [Använd 15 05 2019].

[18] IEEE, ”IEEE Std 113-1985. IEEE Guide: Test Procedures for Direct-Current Machines,” The Institute of Electrical and Electronics Engineers, 1985.

[19] IEEE Energy and Power Society , ”IEEE Std 115-2009. IEEE Guide for Test Procedures for Synchronous Machines,” The Institute of Electrical and Electronics Engineers, 2010. [20] NEMA, ”ICS 16-2001 Motion/Position Control Motors, Controls, and Feedback devices,”

National Electrical Manufacturers Association, 2001.

[21] R. Sherman, Business Intelligence Guidebook, Morgan Kaufmann, 2015.

[22] T. Gustavsson, Agil projektledning, tredje upplagan, Stockholm: Sanoma Utbildning, 2016. [23] B. A. Forouzan, Global Edition: Data Communications and Networking 5E, New York:

McGraw-Hill Education, 2013.

[24] B. Molin, Analog Elektronik, 2:a uppl, Studentlitteratur, 2009.

[25] Östergrens Elmotor, Brushless DC motors with integrated BLDC-3 Series, 2006.