MachineKit Closed loop on X and Y

[Edgardo Gho]

Hello,

I have setup a Raspberry PI running machine kit to drive a mill (X,Y,Z axis).

Each axis has a stepper motor coupled to a really bad screw.

On X and Y there is a linear scale (5 microns pulses) which I read using a modified Encoder Hal component.

I setup up the HAL with one encoder for X, one for Y. The encoder position (in machine units) is feed into Motion (Axis.0 and Axis.1) though one of the feedbacks, and its also feed into a PID (one per axis).

The PID inputs are in position units but the output is on velocity which goes into Stepgen configured as velocity to drive the steppers (the stepper have a driver which receives pulse+direction).

All of this setup works great IF I move axis independently.. meaning.. if I move X +5mm several times, the PID makes sure it reaches the point.

The Screws have a lot of backlash, so if I would move X back -5mm on open loop it does not move back 5mm (because of the backlash) but using the PID and the encoder it compensates perfectly and it reaches the point with no issues.

Same with Y axis.

The problem I have is when both Axis have to move at the same time, and one of the axis encourters backlash. Imagine doing half a circle.. one of the axis will move at constant speed but the other will reach a 0 speed point and reverse rotation at half of the moment.

WHile the second axis reverses, there is backlash, but the other axis continue going forward so circle gets distorted.

I tried reducing increasing the resolution of the arc (doing lots of small arc movements) and adjusting errors.. but what I need is for one axis to stop while the other compensates for backslash.

I tried adding G61 for exact stop but this had no effect on the backlash.

Any clues on how can I force the Trajectory planner to compensate for backlash using the encoders?

Best Regards,

Edgardo

[justin White]

Are you using backlash compensation? I’ve used it for a couple thou backlash but decided it wasn’t needed. In your case maybe it’s a good idea to try it. You have to set acceleration pretty high to overcome the issue your having so that it can wind out the backlash quickly while the other axis is in motion. High acceleration should help using backlash correction or not.

[Bas de Bruijn]

I think you should Google a bit on backlash and Machinekit / Linuxcnc

http://www.machinekit.io/docs/config/ini_config/#axis_-num-section-a-id-sub-axis-section-a

Please see the Backlash section.

I’ve also seen some topics on the linuxcnc forums.

Personally I’d fix the backlash :) 5 mm seems excessive to me and it seems you are trying to solve a problem at the wrong spot.

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/1db75010-6f2b-4f6f-90c0-4183d2e0b52e%40googlegroups.com.

[Edgardo Gho]

Thanks for the feedback.

I have not used backlash compensation. The reason  is that I thought that using a closed loop would take care of the need to estimate a backlash value (since the linear scale gives the actual position).

I'll try increasing the acceleration to allow the PID to compensate the backlash faster.. and will read about backlash compensation on the axis section.

The idea of my project is to add linear scales to the worse possible X and Y mill and get good results out of it. I could have use better components (like antibacklash circular balls screws) but I'm trying to figure out if by attaching a couple of simple linear scales to the mill I can reduce most of the mechanical issues with a closed loop.

I'm thinking about writting a HAL component that will detect a backlash condition (sign change on the PID output) and stop all the axis movement until I can compensate the backlash on the axis with problems.. and then continue the movement.

I've tried doing something similar measuing the error on the PID and if this error was greater than a setpoint value stop the other axis until they both catch up.. but this did not work great. IT ends up moving one axis and then the other most of the time.

[justin White]

Running a closed loop can’t compensate for backlash by itself because just a PID loop does not consider which direction the last move was made in. That’s what backlash comp does, accounts for the change in direction at the specified amount of backlash and uses the max acceleration available to try to take the backlash up seamlessly.

[Edgardo Gho]

Cool,

Would the backlash compensation stop the other axis until the backlash catches up?

Or does it just accelerates as much as it can to try to compensate it quicker and have less effect?

I ask this because I won't have the machine around for a couple of days so I'm planning ahead... I will definetively try the backlash compensation.

If the other axis is not stopped until the backlash is compensated, and being that these are Stepper motors (so they could be stopped while waiting for compensation).. is there a HAL component available to syncronize axis-pairs?

Thanks

[justin White]

I can’t say for certain but I don’t believe that the backlash comp on one axis effects the other it shouldn’t really have to. Is there really that much backlash that you think it should allow the other axis to slow down or stop? I read your first post not to mean that you had 5mm backlash, I just assumed that was the arbitrary number you were moving the axis. If it really has that much I think you should do something about the hardware. .030” would be extreme backlash imo, if we’re talking about close to .200” I wouldn’t bother trying to compensate for that. Running a mill with that much backlash is going to be a horrible experience with chatter and accuracy.

Otherwise if your acceleration is setup properly it can easily wring out the backlash before your other axis moves enough to cause arcs to be misshaped. Depending on how bad it is you could see a minor step in the work but at that point i think you should tighten up the machine.

[Edgardo Gho]

I think my first post was misunderstood or poorly stated by me. Sorry about that.

What I meant is that if I move lets say the X axis forward  3 times at 5mm intervals (it moves from 0.000 to 15.000)... if I then move back again 3 times at 5mm intervals I don't get back to 0 due to backlash.

I'll post my backlash numbers once I have access to the machine again in a couple of days, but its not 5mm backlash.

I'm not working on a commercial project or intend to use this mill for anything other than this research. I'm doing a university project where the goal is to automate a manual mill (with really bad screws) using linear scales and steppers. My goal is to come up with a setup/config or something useful (hal module) that would kept 2 axis syncronized to compensate for terrible backlash.

I'm trying to use as much of what linuxcnc/machinekit has built it to address this problem, and if that is not enough try to modify it (machinekit) to get better results.

I'll publish my numbers in a couple of days (backlash and result after the acceleration).

I record the encoder values into a sepparate file and I generate a BMP with all the encoder pairs to keep a consistent test environment for changes.

[Edgardo Gho]

I tried setting up backlash compensation (setting the backlash = xxxxx on the axis) and increasing accelerations but that did not help much.

I spent more time trying to figure out how motion works, and noticed that motion keeps moving independently from what the PID is doing. Basically motion is reading the encoder position for an axis, generates a "next position" at a certain feed rate and outputs the error from the current position vs desired position.. and if this error is higher than a preset value it reports joint x error.

So if the preset error is too low, it fails pretty quickly.

What I ended up doing is putting a comp module with the f-error output vs a preset value (0.1mm) .. so if the error is greater than that, it would set the feed-hold input for motion. This way motion will stop until the error goes back to less than 0.1mm. I combined X and Y using an or2 and the backlash gets compensated by the PID.

Basically I'm stopping the motion module so it won't keep trying to change the position until the PID reaches (or is close to reach) the desired position.

I upload a picture generated by recording the encoder output for X and Y. Each pixels is 0.01mm. You can see artifacts when the spiral changes direction on one of the 2 axis but this is greatly reduced compared to running it without stopping motion.

I still have to adjust error values and tune the PID.

The speed that I get is obviously not great considering most of the time motion is stopped waiting for the PIDs to reach the desired position.

[justin White]

I missed the part where you said you are using linear encoders, that's a bit different. Backlash comp is probably not a great idea in that case as I'm pretty sure it's just a dumb "whip the lash out" on direction change kind of thing. Your backlash is already accounted for by the fact that your measuring the table directly and not the motor prior to the point the backlash exists or not measuring it at all.

The fact that the axis has to stop and reverse a noticeable amount implies that it is overshooting too far and just requires better PID tuning, the error should be decreasing over time as the PID "learns" the correction values. I'm not a PID tuning wizard, I generally have to read up on it every time I do it since I don't do it often. I  run the Brushless DC spindle motor on my mill with a torque mode drive (Mesa 8i20) which is generally not the thing to do since spindle control is inherently a velocity mode deal with the drive handling half the loop. The moment a free spinning cutter enters a workpiece there is a drastic change in the torque required to maintain that spindle speed, then it levels off mid cut. It's difficult to tune a PID for velocity control over a torque mode drive but it works very well now, and as you can imagine it has to be very fast. I do rigid tapping as well with this setup. Your use case is typical, the only thing you should really need is what you originally had with a position input and velocity output PID it just needs proper tuning.

As a side note I just stumbled across the AT_PID component. Didn't even know it existed but an auto tuning PID would be pretty neat if it actually works well. I may try it on my spindle

[dave engvall]

Hi all,

Years ago I tried the at_pid and it didn't work very well if at all. Like I said it has been years. Tuning torque mode is difficult at best but at least on a spindle  one doesn't have to worry about it crashing something. I have thought about the idea of manual tuning to get close and then implementing a monte-carlo to finish the process. My experience with linear scales and velocity mode has not been good. Just not enough counts. Having said that the dual encoder approach the guys used on Stu's big machine should work very well. Since you already have the linear encoder the expense to add a rotary encoder is minimal. There are people in both mk and linuxcnc plenty bright enough to write an auto-tune but since this is a volunteer group some has to want to do it. Most of us get by with manual tuning and get very good following errors but it is tedious.

Hang in there.

Dave

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/d04c7a95-7a31-4ff2-af87-f0dcfca237ab%40googlegroups.com.