• No results found

5.2 Mjukvara

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”.

Då vissa hårdvarunära funktioner dessutom ansågs motiverade att skötas av en ap-plikation i MintDriveII åtgick tid till att utforma en lämplig modell för mjukvaran, distribuera ansvarsområden mellan mjukvarudelarna och utforma eller modifiera gränssnitten mellan dem.

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.

Standarderna beskriver metoder för direkt mätning av vridmoment genom monte-ring av dynamometer eller momentgivare på motoraxeln. Under testkörningen an-vändes dock lastmotorn direkt sammankopplad med testobjektet. En momentgivare

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.

Vid omarbetning av testet och i implementation i kod har ambitionen varit att för-enkla för operatören i möjligaste mån och ge tydlig lättolkad information. Exempel-vis har de mätningar som fortfarande utförs manuellt placerats tätt tillsammans och i början av testet för att frigöra operatörens tid och uppmärksamhet under resten av testkörningen. I testfallen har också ett statusfält placerats dit löpande information om vad som händer skrivs ut under körningen. Dock återstår att göra en mer genom-gående analys av hur de grafiska användargränssnitten kan utformas på bästa sätt.

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.

Önskvärt vore att även kunna automatisera de delar av testet som görs manuellt, i synnerhet ljudmätningen där operatörens uppskattning blir subjektiv och kan skilja sig mellan individer. Ljudmätning har dock visat sig svårt att automatisera och krä-ver mer arbete än vad som hade varit möjligt inom detta projekt.

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:

http://www.abbmotion.com/products/servodrives/mintdrive.asp. [Använd 15 04 2019]. [12] ”ABB Completes Acquisition of Baldor Electric Company,” 27 1 2011. [Online]. Available: https://www.baldor.com/our-profile/news/company-news/detail?id={B57DFCA8-5C50-43BC-9015-D594A0286310}. [Använd 15 04 2019].

[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.

[26] IEEE Power and Energy Society, ”IEEE Std 112™-2017. IEEE Standard Test Procedure for Polyphase Induction Motors and Generators,” The Institute of Electrical and Electronics Engineers, New York, 2018.

Related documents