Closed loop stepper dmv glaslineaal?

[Leeuwinga]

Kreeg net een piublicatie van Texas instruments
wellicht heb je er iets aan voor je ontwikkeling?
zie: http://www.ti.com/tool/drv8301-ls31-kit ... ldocuments

[Baksteen]

Neem een simpele temperatuurregeling bijvoorbeeld. Een regelaar die een 1kW verwarming aanstuurt om temperatuur te regelen kan op een gegeven moment wel 10kW willen om een fout weg te werken, maar die 10kW is er gewoon niet, dus weg lineariteit. Moet je zelfs bij een simpele PI(D)-controller al met windup-compensatie aan de gang.

Het (ongeregelde) systeem is dan nog steeds lineair. Bij een aangedreven glaslineaal is dat niet zo: als je 2x zo veel stappen maakt beweeg je niet 2x zo ver. Het probleem zit hem in omkeren, daar ga je een hystereselus in. Een simpele PID regelaar laat dan de spindelsnelheid oplopen omdat er niets gebeurt tot je aan de overkant van de hystereselus bent, dan draait de spindel te snel en heb je overshoot.

Je hoeft in dit geval eigenlijk ook geen generieke controller voor 'onbekende lineaire systemen' zoals klassiek PID te gebruiken, maar je kunt een model inbrengen.

Dat is inderdaad precies wat je hier moet doen, in nulde orde is dat een rechthoekige (inelastische) hystereselus.

Ga ik over op een compleet motormodel voor de stroomsturing ipv een simpele PID, dan heb ik geheid meer rekenwerk nodig per stap, gaat de bandbreedte van de regeling alsnog omlaag omdat ik minder vaak 'bij kan sturen', en schiet ik er per saldo niks mee op.

Ik denk dat PID goed werkt omdat de stappenmotor nooit sneller kan stappen dan je de stroom in de spoel kan aanpassen. De LR tijdconstante van de winding is dus typisch klein tov de tegen-EMF variatie. De tegen EMF veroorzaakt dus een trage verstoring in een snel teruggekoppeld LR systeem met vaste tijdconstante, daarom is de regeling goed om een werkpunt te lineariseren en werkt PID. Kun je de stroomregeling ook analoog doen?

Ik begin nu te zien welke kant je op wilt, voor de stroomsturing kun je de positie feedback mooi gebruiken. Als je met een realistische systeemfunctie werkt kun je waarschijnlijk ook machinefouten reduceren. Hoe ver je daarmee kunt gaan hangt wel af van de data kwaliteit die weer afhangt van de stijfheid van de machine ivm resonanties. Zoals gezegd, ik ben heel benieuwd hoe dat in de praktijk uitpakt. Als je er meer dan een factor 2 uit weet te halen denk ik dat je veel geinteresseerden hebt!

[DaBit]

Het (ongeregelde) systeem is dan nog steeds lineair.

Mjah, goed, in dit simpele geval misschien wel. In de praktijk heb je altijd wel ergens een dode tijd, stictie, frictie, noem maar op.

Kun je de stroomregeling ook analoog doen?

Had ik kunnen doen, maar waarom zou ik? Meer elektronica nodig, weinig toegevoegde waarde, en dan moet je weerstandjes en condensatortjes veranderen als je van motor wisselt in plaats van een getalletje in de code wijzigen (of de processor zelf het getalletje laten uitzoeken).

Ik heb er hooguit spijt van dat ik de windingstroom niet direct meet in de leiding naar de motor, maar indirect (voor de elektronici: tussen onderste poot van de H-brug en de systeemmassa).

Inmiddel bestaat het stroomcontrole-algorithme deels uit een open-loop welke dmv een versimpeld motormodel een waarde voor de sturing over tijd voorspelt, en een PI-regelaar die de (onvermijdelijke) fout wegregelt tegen de tijd dat de open loop vind dat-ie er zou moeten wezen.

Lijkt uitstekend te werken; met 128 microsteps loopt de motor ook bij slechts 1 omw/min heel mooi soepel rond en komt er vrijwel geen geluid uit. De andere kant op gaat ook prima; 1000rpm was in ieder geval geen probleem en ik kon de as met het handje niet tegenhouden. De limieten heb ik nog niet opgezocht, en echte prestatiemetingen ook nog niet gedaan. Eerst de software maar eens 'klaar', maar die is een aardig eind nu.

Dynamisch microsteps interpoleren werkt ook uitstekend. In principe zijn aangeboden stap-pulsen nu halfsteps (maar da's ook maar een getalletje), dus 400 stappen per omwenteling (met de 2mm pitch trapeziumschroef op de BF20 is dat dus 0,005mm/stap). Intern word dit linear ge-interpoleerd om zo vloeiend mogelijk van positie N naar positie N+1 te gaan (en de voorspelling wanneer N+2 gaat komen word ook gedaan, uitgaande van lineaire acceleratie en deceleratie).

Het ene uiterste zijn lage toerentallen; dan word er geinterpoleerd naar 128 microsteps. Voor positionele nauwkeurigheid heb je geen 128 usteps nodig, maar de motorloop is beduidend soepeler dan met 'maar' 32 microsteps.

Het andere uiterste zijn hele hoge toerentallen; uiteindelijk draait de boel dan in 2-windingen-onder-stroom fullstep mode om toch zoveel mogelijk koppel over te houden. Massatraagheid zorgt dan wel voor een soepele motorloop.

Spul heeft helaas nog 1 ienemienerig 'klein' issue-tje: zo eens in het uur zegt de boel 'boem' en ontsnapt de heilige rook. Detail toch? . Voor die tijd is er ook niks raars te meten, dus da's lastig foutzoeken. Hoge motorspanning (45V), lage motorspanning (15V), hoge winding-piekstroom (4.2A), lage winding-piekstroom(1A), maakt allemaal niks uit.

Ik heb een idee waar ik het zoeken moet, maar ik moet eerst wachten op de postbode met wat vers spul. Je zou haast zeggen dat 't op ontwikkeling lijkt...

Als je met een realistische systeemfunctie werkt kun je waarschijnlijk ook machinefouten reduceren. Hoe ver je daarmee kunt gaan hangt wel af van de data kwaliteit die weer afhangt van de stijfheid van de machine ivm resonanties.

Inderdaad...

Zoals gezegd, ik ben heel benieuwd hoe dat in de praktijk uitpakt. Als je er meer dan een factor 2 uit weet te halen denk ik dat je veel geinteresseerden hebt!

Misschien doe ik het ook nog wel :D
Ik ben zelf ook wel nieuwsgierig namelijk. Maar eerst maar eens het spul gewoon 'conventioneel' aan de gang krijgen.

[DaBit]

Inmiddel bestaat het stroomcontrole-algorithme deels uit een open-loop welke dmv een versimpeld motormodel een waarde voor de sturing over tijd voorspelt, en een PI-regelaar die de (onvermijdelijke) fout wegregelt tegen de tijd dat de open loop vind dat-ie er zou moeten wezen.

En inmiddels is dat 'motor-model' alweer uit de code gewipt....

Stiekem kostte het evalueren ervan toch nog relatief veel rekenwerk. En dus relatief veel CPU-tijd, die niet aan iets anders besteed kan worden zoals de maximale microstep-frequentie opvoeren.

En toen won de praktische kant het van de theoretische kant: enkel een PI-controller kost veel minder rekenwerk. Daardoor kan de microstep-frequentie omhoog; sturing met 128usteps word volgehouden tot circa 100rpm (Op dat toerental kan de windingstroom het setpoint zowiezo al niet meer volgen bij realistische motorspanningen). Waardoor het windingstroom-setpoint van de PI-controller kleinere stappen maakt. Waardoor de PI-controller wat agressiever kan omdat de overshoot van een agressieve controller eigenlijk geen issue meer is (30% overshoot op een hele kleine stap is in absolute zin nog steeds bijna niks).

En waardoor het geheel uiteindelijk toch (nog) een tikje beter presteert kwa mooi rondlopen.

Zo zie je maar weer, de theoretisch mooiste oplossing hoeft in de praktijk helemaal niet de beste te wezen.

Al met al zit er weer eens veel meer tijd in die stepperdrivers dan van tevoren gepland, maar het is wel mooi spul geworden. Misschien ga ik ze ooit nog wel als bouwpakket leveren; duur aan onderdelen zijn ze niet.

Spul heeft helaas nog 1 ienemienerig 'klein' issue-tje: zo eens in het uur zegt de boel 'boem' en ontsnapt de heilige rook.
..
Ik heb een idee waar ik het zoeken moet, maar ik moet eerst wachten op de postbode met wat vers spul. Je zou haast zeggen dat 't op ontwikkeling lijkt...

Vers spul was binnen, en ik heb maar direct het hele pakket van maatregelen doorgevoerd, bestaande uit een kwak clampdiodes, transientsuppressors en . Niet erg wetenschappelijk, maar een MOSFET+driver paartje kost elke keer weer 2 euro tezamen, en na die een stuk of 5 geofferd te hebben word het vervelend. Voor de print ook; vooral de kleinere SMD-padjes worden er ook niet beter van als je ze tig keer verhit.

Voorzichtige voorlopige conclusie: het lijkt effect te hebben, want het is tot nu toe niet weer kapot gegaan...
Doet het dat wel dan moet ik toch echt ergens een snelle oscilloscoop vandaan toveren.

Edit: 2 plaatjes.

Stepperdriver in lekker-binnenzitten-testopstelling:


Staprespons van de stroom door de winding, 0Amp -> 2Amp -> 1Amp.
Kan nog een tikkie beter, maar niet veel.



De 'rimpeltjes' onderaan zijn het gevolg van een minimale pulsbreedte van de chopper. Dat trek ik nog wel strak. Staat nu allemaal op 'zeker goed'.

Foto is genomen toen het motortje met 32000 steps/sec (150rpm) rond aan het draaien was. Soepel en geluidloos.

Wederom geen stukken, dus ik vind het even 'goed genoeg'. Tijd om stappenmotoren op de frees de bouwen.

[DaBit]

't werkt ook prima. :)
Testopstelling:







Motoren krijgen 54 Volt, kan even niet hoger met 2 accu's en een 0-30V voedingkje.

Stuurcomputer is een oude AMD 1200+ met 256MB RAM (uit 2001...), en die doet het kwa realtime-performance niet heel slecht, maar ook niet super. Ik had eerst m'n oude Pentium-M laptopje welke het een stuk beter deed, maar die crashte na een halfuurtje en toen was zelfs de powerknop een graad of 50 . Na afkoelen deed-ie het nog steeds niet . Die RTAI-kernel doet rare dingen met de hardware. Nouja, ik had op zolder nog iets staan waarvan de witte kast inmiddels knalgeel is dus :)

Ik denk dat die AMD heel rap vervangen gaat worden door een Atom D525 in een stofdichte kast. Kan ik 2x zo rap mee steppen en dat blijft het in een dichte kast ook doen.

Die 26,4mm/sec is dus momenteel de limiet van de stuurcomputer. Doe ik minder stapjes per omwenteling, dan haal ik zo'n 30mm/sec als ik flink aan de kruistafel ga trekken om een freesbewerking na te doen. Zonder extra belasting was 40mm/sec geen probleem. Oftewel: met fatsoenlijke motorvoeding haal ik een 30-35mm/sec onder belasting (en doet die stappenmotor dus 1000rpm terwijl-ie nog koppel levert ook nog ). Ik ben tevree; 30-35mm/sec met een DaBit die aan de tafel hangt is iets waar ik royaal het spindelvermogen en stijfheid niet voor heb.

Acceleratie van 200mm/sec^2 is zo'n beetje de limiet van het freesmachien lijkt het. De kruistafel laat merken dat-ie veel meer niet echt leuk vind als-ie van richting moet wisselen. Zit toch altijd wel iets speling in trapeziumschroeven, en bij meer zegt het 'klak'. Ik hou niet van 'klak'. Ik heb getest tot 300mm/sec^2 (en 30mm/s als topsnelheid), en dat was voor de motor geen probleem. Spul kwam elke keer weer netjes exact op '0' terug. Uiteraard moet ik dezelfde test nog eens doen met 15 kilo aan materiaal op die kruistafel, maar ik verwacht niet onder die 200mm/sec^2 te duiken. En da's van stilstand tot volle snelheid in nog geen 2mm afstand.

Mwoah, ik geloof niet dat ik wat te klagen heb... :D

[Arie Kabaalstra]

Ik heb de ballen verstand van Electronica.. maar begrijp ik het goed dat je in wezen een driver hebt gebouwd die de positie bewaakt met glaslinealen?..

[DaBit]

Nee, nog niet. Dit zijn nog gewoon normale stepperdrivers. Ik ben meer van de evolutie van van de revolutie, dus laat het spul eerst maar eens 'conventioneel' goed werken.

Maar het voordeel hiervan is dat van deze drivers zowel de software als de hardware uit eigen pen komt, en dus te modificeren is naar eigen inzicht. Ik heb nog 'ruimte' om een glaslineaal aan te sluiten op de driver, en ik heb uiteraard ook toegang tot de software in de driver om het spul closed-loop te maken.

Vanavond trouwens de Y-as stappenmotor gemonteerd. Voor het bewerken van de askoppelaar en afstandsbusje meteen gebruik gemaakt van die gecomputeriseerde X-as, en dat wint het heel dik van aan wieltjes draaien. Zelfs al zou je geen programma kunnen draaien, dan nog is zeggen 'beweeg eens precies 30mm voor me' heerlijk.



Beetje simpel opgezet door wat de decoupeerzagen in een stukje 3mm staalplaat, maar goed is goed en recht is recht. Moeten zowiezo toch nog kunststof kapjes overheen om spanen en snijolie uit de buurt te houden.

[Swake]

Knap werk die driver! T'is nog wat vroeg om ze te bestellen zeker ?

[DaBit]

Tenzij je er heel erg om verlegen zit: ja. Ik zou ze bij voorkeur eerst zelf grondig testen.
(jammer dat 't kerst is; stepperdriverprintje nummer 2 is alweer gereanimeerd. Ik had 'm als onderdelen-donor gebruikt toen de heilige witte rook nog regelmatig ontsnapte) en ik sta te popelen om die machine met 2 gestuurde assen bezig te zien. Enkel een kwestie van de stappenmotoren netjes bekabelen, eigenlijk).

Verder staan een hoop zaken nu hard in de code als constante, zoals de inductie en weerstand van de motor, wat een binnenkomende step-puls geacht word om te doen (volle stap? Halve stap? 1/64 microstap?), de gewenste motorstroom, etc. Voor mij persoonlijk geen probleem (code hercompileren en programmeren duurt toch zeker wel 20 seconden), maar 't is niet zoals de boze buitenwereld dat verwacht. Dat soort elementaire zaken moeten minimaal automatisch opgemeten (waar mogelijk) of ingesteld kunnen worden.

[roger de poger]

Ik heb RESPECT voor je project DaBit!
Echt vreselijk stoer om een driver vanuit nul op te bouwen EN er begrijpelijk verslag van te doen.
Je krijgt zelfs Arie stil

[Leeuwinga]

Ook vindt het een prestatie en een uitdaging om zelf een driver te maken.
Maar ik vraag mij wel af wat deze meer biedt tov. van huidige drivers in de markt.
De prijzen vooral door de chinezen zijn zo laag, dat je er zelf vaak de onderdelen
nog niet eens voor kunt kopen.
Zelf gebruik ik Gecko drives (G203V) maar ja, wie appelen vaart eet.......
Ik blijf dit item met heel veel intresse volgen, succes.
Cees

[joopbos]

Maar ik vraag mij wel af wat deze meer biedt tov. van huidige drivers in de markt

Het plezier van zelf iets maken!!

Joop

[Leeuwinga]

dat is een goed punt!

[hugo stoutjesdijk]

En er HEEEL veel van leert. En leren is leuk, ook al dachten we vroeger misschien anders.