Closing the (stepper) loop in LinuxCNC

[bbg]

Ik ben aan het orienteren voor een besturing voor mijn portaal frees (in aanbouw). Ik heb 4 stepper motors met incrementele (quadratuur) encoders achter op. Graag zou ik dat vanuit LinuxCNC aansturen en de loop sluiten in LinuxCNC (en niet op driver nivo). Uit de documentatie maak ik op dat het zou moeten lukken met een 6i25 in combinatie met een 7i76 en een 7i85S (op de tweede poort).

Ik wil graag bij jullie checken of ik niets stoms over het hoofd zie voordat ik de hardware ga bestellen.

[audiomanics]

gewaagd! je zal dan toch ook de driver op een of andere manier voor de gek moeten houden want die verwacht gewoon bepaalde pulsen en anders gaat hij in de fout... Of je moet een heel andere driver kunnen gebruiken (een niet-closed loop)
Misschien het closed-loop verhaal vergeten en een glasliniaal gebruiken?? (wat dan toch stiekem een closed loop is)

Kees

[bbg]

Ik gebruik een open loop driver (had ik er niet bij verteld). Anders wordt het inderdaad wel heel spannend

In het (mechanisch) ontwerp wordt rekening gehouden met het kunnen monteren van glaslinealen. Het is nu relatief eenvoudig om de extra montage vlakken en gaten mee te nemen. De terug koppeling zou dan inderdaad ook over glaslinealen kunnen. Maar ik weet niet of de performance verbetering de extra ellende van dynamica in de regellus waard is. Een leuk experimentje als de boel in elkaar zit!

[bbg]

Ik heb vandaag een 7i76E en 7i85S besteld bij eusurplus. Hopelijk zijn die binnen bij het einde van de week. Kunnen we dan wat ervaring in de praktijk op doen :-)

[DaBit]

Ik doe op mijn frees Z-as vrijwel hetzelfde, maar dan met een (Ditron) glaslineaal. Op de draaibank X-as ook, met een magnetisch meetlint.
Voor de kosten hoef je het niet te laten; glaslinealen zijn best betaalbaar.

Wat je er wel mee kunt: positiefouten detecteren en corrigeren.
Wat je er niet mee kunt: de motortjes even snel laten draaien als closed-loop steppers dat kunnen.

Mijn hardware is wel wat anders; op de frees interface ik de stappenmotor en lineaal van de Z direct met de 2e poort van de 6i25 zonder tussenkomst van een 7i85S of 7i76. Op de draaibank heb ik wel een 7i85S, maar die draait dan weer een aangepast FPGA-image zodat ik de spindel-servo kan sturen met dat kaartje.

[bbg]

Allemaal wat langzamer gegaan dan verwacht maar vandaag een stepper closed loop laten draaien op de tafel onder linuxCNC. Eigenlijk best wel eenvoudig.

Setup is een 7i76e met daaraan een 7i85s verbonden via de eerste expansie poort. Ik heb een bitfile van Mesa voor deze combi op de 7i76e geflashed. In de HAL heb ik de feedback van de stepgenerator naar de PID controller vervangen door de feedback van de encoder:

Code: Selecteer alles

unlinkp hm2_7i76e.0.stepgen.00.position-fb
net x-pos-fb hm2_7i76e.0.encoder.00.position

Wel direct wat "limit cycles" maar dat eenvoudig opgelost met een kleine " deadband" (ter grote van de halve encoder resolutie) in de PID. Uiteraard moet een en ander straks in de machine worden getuned. Het ging nu even alleen om het concept werkend te krijgen. Ik heb nu twee rotary encoders die achterop de steppers passen. Ik overweeg om lineare encoders voor de andere assen te gebruiken.

Ik heb ook nog een simple HAL component gemaakt met "halcompile". Ook weer best eenvoudig em biedt veel mogelijkheden.

Hoe meer ik van de details van LinuxCNC leer hoe enthousiaster ik word

[DaBit]

Code: Selecteer alles

unlinkp hm2_7i76e.0.stepgen.00.position-fb
net x-pos-fb hm2_7i76e.0.encoder.00.position

Dat stuurt alleen maar de encoderpositie terug naar motion. Of heb je ook een PID tussen motion en de stepgen hangen?

Hier een stukje van mijn config, voor de stepper-Z-as met glaslineaal als terugkoppeling:

Code: Selecteer alles

# ################
# Z Axis
# ################

setp   hm2_5i25.0.stepgen.00.dirsetup        [JOINT_2]DIRSETUP
setp   hm2_5i25.0.stepgen.00.dirhold         [JOINT_2]DIRHOLD
setp   hm2_5i25.0.stepgen.00.steplen         [JOINT_2]STEPLEN
setp   hm2_5i25.0.stepgen.00.stepspace       [JOINT_2]STEPSPACE
setp   hm2_5i25.0.stepgen.00.position-scale  [JOINT_2]STEP_SCALE
setp   hm2_5i25.0.stepgen.00.step_type        0
setp   hm2_5i25.0.stepgen.00.control-type     1
setp   hm2_5i25.0.stepgen.00.maxaccel         [JOINT_2]STEPGEN_MAXACCEL
setp   hm2_5i25.0.stepgen.00.maxvel           [JOINT_2]STEPGEN_MAX_VELOCITY

# encoder feedback, linear
setp hm2_[HOSTMOT2](BOARD).0.encoder.04.counter-mode 0
setp hm2_[HOSTMOT2](BOARD).0.encoder.04.filter 1
setp hm2_[HOSTMOT2](BOARD).0.encoder.04.index-invert 0
setp hm2_[HOSTMOT2](BOARD).0.encoder.04.index-mask 0
setp hm2_[HOSTMOT2](BOARD).0.encoder.04.index-mask-invert 0
setp hm2_[HOSTMOT2](BOARD).0.encoder.04.scale  [JOINT_2]INPUT_SCALE_LINEAR

# set PID loop gains from inifile
setp zservo_pid.Pgain [JOINT_2]P
setp zservo_pid.Igain [JOINT_2]I
setp zservo_pid.Dgain [JOINT_2]D
setp zservo_pid.bias [JOINT_2]BIAS
setp zservo_pid.FF0 [JOINT_2]FF0
setp zservo_pid.FF1 [JOINT_2]FF1
setp zservo_pid.FF2 [JOINT_2]FF2
setp zservo_pid.maxoutput [JOINT_2]STEPGEN_MAX_VELOCITY
setp zservo_pid.error-previous-target 1

setp zscale_pid.Pgain [JOINT_2]SCALE_P
setp zscale_pid.Igain [JOINT_2]SCALE_I
setp zscale_pid.deadband [JOINT_2]SCALE_DEADBAND
setp zscale_pid.FF0 0.0
setp zscale_pid.maxerrorI [JOINT_2]SCALE_MAXCORR
setp zscale_pid.maxoutput [JOINT_2]SCALE_MAXCORR
setp zscale_pid.error-previous-target 1

net z-pos-cmd 	joint.2.motor-pos-cmd => SnSMill-correction.z-motorposcmd-in
net z-joint-cmd joint.2.pos-cmd => SnSMill-correction.z-jointposcmd-in
net zpos-cmd-corrected SnSMill-correction.z-motorposcmd-out => zscale_pid.command => zscale_sum2.in0
net z-pos-fb     SnSMill-correction.z-motorfb-in  <=  hm2_[HOSTMOT2](BOARD).0.encoder.04.position => zscale_pid.feedback
#net z-motor-fb SnSMill-correction.z-motorfb-out => joint.2.motor-pos-fb
# Dirty hack to make the laser_enable component work on micrometer scale coordinates
net z-pos-cmd  joint.2.motor-pos-fb
net z-pos-pidout zscale_pid.output  => zscale_sum2.in1
net z-pos-summed zscale_sum2.out => zservo_pid.command
net z-servo-pos-fb 	hm2_5i25.0.stepgen.00.position-fb => zservo_pid.feedback
net z-vel	zservo_pid.output => hm2_5i25.0.stepgen.00.velocity-cmd
net z-enable     joint.2.amp-enable-out =>  hm2_5i25.0.stepgen.00.enable => zscale_pid.enable => zservo_pid.enable

net homesw-z <= hm2_[HOSTMOT2](BOARD).0.7i77.0.0.input-14-not => joint.2.home-sw-in

[bbg]

Dat stuurt alleen maar de encoderpositie terug naar motion. Of heb je ook een PID tussen motion en de stepgen hangen?

Er zit inderdaad nog een PID tussen motion en de stepgen. De encoder positie gaat zowel naar motion als naar de PID. Als ik de voeding van de stepper uit zet krijg ik ook keurig een joint follow error. Dat zou niet gebeuren in open loop.

Ik genereer een hal file met pnconfig. In die file wordt het signaal x-pos-fb gecreerd waarin de positie van de stepgen naar motion en naar de PID gaat. In de custom hal unlink ik dan de positie van stepgen en vervang hem door de encoder positie.

Beetje omslachtig zo maar ik ben nog bezig om de boel op te zetten. Ik maak dan liever zo weinig mogelijk veranderingen in de hal file die pnconfig genereert.

[DaBit]

Oja, dat is tegenwoordig zo ja. Is dat die PID met P 100.0 en FF 1.0? Die ga je dan tezijnertijd nog wel willen tunen. Bekijk ook halscope eens en leer ermee omgaan; die ga je nog hard nodig hebben.

[bbg]

Oja, dat is tegenwoordig zo ja. Is dat die PID met P 100.0 en FF 1.0? Die ga je dan tezijnertijd nog wel willen tunen. Bekijk ook halscope eens en leer ermee omgaan; die ga je nog hard nodig hebben.

Een P van 1000.0 (staat standaard zo ingesteld):

Code: Selecteer alles

P = 1000.0
I = 0.0
D = 0.0
FF0 = 0.0
FF1 = 1.0
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.005
MAX_OUTPUT = 0.0

Ik heb wel een deadband nodig ivm limit cycles door de (verschillende) resoluties van de stepper en de encoder.

Tunen ga ik doen als ze in de machine gebouwd zijn. Met de encoders achter op de motoren verwacht ik dat de dominante dynamica toch de stepper rotor is (bij benadering tweede orde systeem: simpele massa) en de meeste fasedraaiing van de controller komt. En dan zal tunen niet zo lastig zijn. Maar bij terugkoppeling over een lineaal (zoals jij doet) zal het gedrag eerder 4de order zijn (massa veer massa) en zal tunen een stuk lastiger zijn.

Ik heb de halmeters wel al gebruikt. Ik heb halscope even opgestart en moet we daar nog in verdiepen. Ziet er op het eerste gezicht uit als mijn fysieke scoop.

Van de week eerst nog even bezig met de mechanica.

[DaBit]

Dat was mijn grootste probleem: de vertraging van de Leadshine AM882 stepperdrive. Mijn X en Y zijn servogestuurd door middel van vrij bejaarde analoge servo's (Omton/Yaskawa Sigma 1) waarvan de drive in torque-mode ingesteld staat en LinuxCNC de velocity/position lussen doet. De Z-as is een stepper; meer servo's had ik niet en die Z-as hoeft niet bloedsnel.
De servo's reageren vrijwel direct met amper vertraging op een commando. De Leadshine was een ander verhaal; die heeft wat milliseconden tussen commando en actuele positie zitten. Al met al was het nog een best gefoezel om die 3 assen synchroon te laten lopen.

Maar je kunt met een encoder wel leuke dingen doen. Een stappenmotor is een torsieveer; bij het houdkoppel zit je er een stap naast. Als je gaat accelereren (wat koppel vraagt; niet zelden is de inertie van de rotor en kogelomloop verantwoordelijk voor het leeuwendeel van het benodigde koppel) is een beetje feedforward op je acceleratie (FF2) dus best nuttig om dat te compenseren, bijvoorbeeld.
Met halscope (inderdaad vrijwel gelijk aan een fysieke scoop) kun je mooi commanded vs actual position plotten, en langzaam wat FF2 toevoeren.

Mijn linealen zijn verder vrij simpel kwa implementatie; de positieafwijking verloopt relatief langzaam en de bandbreedte van het mechanische systeem is laag, dus dat is voornamelijk de I die het werk doet, met een clamp op die I zodat de maximale correctie 0,07mm is.