Closing the loop with linear encoders

I would guess that you were tripping FERROR when coming to a halt rather than MAX_FERROR at max velocity.

pid.z.maxerror mainly caps the max PID P-term output. In your case the PID can not put out more than 0.0127 * PGain. Which sounds like it might be a little low.

Yes, the 0.127 mm is a setting for a stepgen loop
and likely too small for real physical feedback

Also I would not expect the I terms to do
much of anything if less than 1000 or so

An I value of 1 means a .01mm error results in a correction velocity
of only 0.01 mm/sec^2)

That is, an error of 0.01mm that persisted for 1 second
would only result in a a correction velocity of 0.01mm/s at the
end of that second

I've significantly improved the transient response of the axes now, having increased the maxerror to 5.0

However:

andypugh wrote: I would guess that you were tripping FERROR when coming to a halt rather than MAX_FERROR at max velocity.

Yes, I get persistent "Joint 1 following error" when coming to a halt. Must admit I'm confused about the multiple velocity and accel parameters. There's one of each in the Joint, Axis and Stepgen sections. If I have the axis slower than the joint or vice versa, would this cause a problem?

Is there a hierarchy of speeds and accels? Should the stepgen values be 25% bigger - or at least 25% bigger?

[AXIS_Z]
# Min was -100; Max 10. Change to -100, 100
MIN_LIMIT = -100.0
MAX_LIMIT = 20
MAX_VELOCITY = 50
MAX_ACCELERATION = 100

[JOINT_1]
TYPE = LINEAR
HOME = 0.0
FERROR = 50
MIN_FERROR = 10.0
MAX_VELOCITY = 50
MAX_ACCELERATION = 100
# What are these scale things?
BACKLASH = 0.000
INPUT_SCALE = 200
# INPUT_SCALE is encoder counts per machine unit (5um scale)
OUTPUT_SCALE = 1.000
MIN_LIMIT = -100
MAX_LIMIT = 20
HOME_OFFSET = 1.0
HOME_SEARCH_VEL = 5.0
HOME_LATCH_VEL = 1.0
HOME_USE_INDEX = NO
HOME_IGNORE_LIMITS = YES
HOME_SEQUENCE =
# HOME_IS_SHARED = 1
# The values below should be 25% larger than MAX_VELOCITY and MAX_ACCELERATION
# If using BACKLASH compensation STEPGEN_MAXACCEL should be 100% larger.
STEPGEN_MAXVEL = 125
STEPGEN_MAXACCEL = 750
P = 50
I = 0
D = 0
FF0 = 0
FF1 = 0.6
FF2 = 0.017
BIAS = 0
DEADBAND = 0.0045
MAX_OUTPUT = 0
# these are in nanoseconds
DIRSETUP = 10000
DIRHOLD = 10000
# These were 5000ns. The Lichuan drive supports 600k in diff mode
STEPLEN = 2500
STEPSPACE = 2500
STEP_SCALE = 846.15
# number of pulses per machine unit
HOME_OFFSET = 0.0

Yes, I think I've learnt that getting those velocity and accel settings in the right region up front is key to this. If you get them wrong, they will limit the response. And if you change them, the PID settings will need to be refettled. Finally I have them fairly well set up and the PID settings seem to be a lot closer to what the system should be capable of. It may not be 100% optimal but it feels fairly close now.



I ended up using both D and FF1 although they should have a fairly similar effect. Also the FF2 seems to be worth playing with - sounds as if this can compensate for the inertia to some degree. Together, I have significantly improved the behaviour. I'm getting a pretty snappy response with negligible overshoot, quick settling time and minimal positional error, notwithstanding the 5um resolution of the scales.

The Z axis following error has also been fixed - this seems to have been caused by setting the max velocity too low, which prevented the motor responding fast enough to satisfy the control loop.

Thanks for the help getting here.

I am prepared to state that your X is fast enough.

I am surprised by your lack of love for the I term. That's my favourite.

I was looking and Bantams and Chipmasters when I decided to CNC a proper lathe. Then I found a Holbrook Minor. I reckon that the Bantam will serve you well, and I have a feeling that a converted manual lathe leaves you more freedom to do "wierd stuff" than a purpose-built CNC.

Threading will be a revelation.

Have you seen: forum.linuxcnc.org/41-guis/26550-lathe-macros?start=150#82743
I do 90+% of my lathe stuff that way, rather than use CAM.

Yes, I saw that when you posted it - looks pretty tasty and I'd want to be able to make use of it myself. Rightly or wrongly I fancied the look of the Probe Basic interface despite having no experience of lathe CNC yet. Would it be reasonably possible to integrate these macros with the PB GUI?

The Bantam's leadscrews were becoming rather old and worn and difficult to do anything accurate with, so this should improve the precision by an order of magnitude. There are better machines available but the Domestic Manager would need me to part (fully?) exchange some of my vitals for any of them. Machine space is also getting tight, which you might argue is a a sign of success.

I have to implement limit switches for the Z axis next. As I need to accommodate a range of different chucks and a moving tailstock, some sort of cunning concept is required, that I haven't seen in any of the online machine manuals. I will repurpose the carriage stop at the headstock end, while at the tailstock end I need to detect either the tailstock itself or a default stop of some kind. I also have to machine up a rear cover for the cross slide ballscrew, a solid toolpost and a replacement for the cross slide handwheel shaft.

I'm not sure I fully trust these Lichuan servos. It may be that there's actually some I in their controller that you can't access through the "software". I do have some I term - here are the current (final-ish?) values for the X axis. I found FF1 to be better than D for some reason. Both FF1 and FF2 are very sensitive but these values are at their sweet spots. Bear in mind this is a position loop using step/dir:

STEPGEN_MAXVEL = 125
STEPGEN_MAXACCEL = 750
P = 60
I = 40
D = 1
FF0 = 0
FF1 = 0.4
FF2 = 0.01
BIAS = 0
DEADBAND = 0.0045

Muzzer wrote: I fancied the look of the Probe Basic interface despite having no experience of lathe CNC yet. Would it be reasonably possible to integrate these macros with the PB GUI?

It should be. It's a GladeVCP screen, so should be embeddable in any of the GUIs. But note that the touchscreen version depends on a physical "go" button l(linked to gladevcp.cycle-start) which will need to be arranged somehow.

I have to implement limit switches for the Z axis next. As I need to accommodate a range of different chucks and a moving tailstock

I configured mine to home towards the tailstock having decided that there is no practical way to protect against chuck impingment using the soft limits. My sensors are proxes looking at holes drilled in the sides of the ways filled with delrin plugs.
The idea of a movable limit switch target that can be set up as a precautionary measure is a good one, though. And something that I might look in to. Ditto tailstock protection. I can fairly easily add some more proxes to the saddle as the saddle has a 7i73 lurking in the apron.
Because homing is awkward I actually set my lathe up with absolute encoders so I don't need to.

I'll have a go at embedding this when I get to that stage. I'll read up on GladeVCP in the meantime.

What proximity sensors have you been using? I bought a bucket load of Omron clones that looked like this:
TL-Q5MC1TL-Q5MC1 They worked fine but may not be the most accurate sensors and have a fairly large active area. As you say, there's nothing stopping me using several sensors and switches at the tailstock end.

No eBay APP ID and/or Cert ID defined in Kunena configurationI am a cheapskate and tend to use this sort of thing:


Note that these have the thread all the way to the end, which means that they will work when buried in metal. The ones with visible plastic at the end will not (they detect the metal that they are buried in)

PNP for Mesa cards, NPN for parallel port cards, in general.

I manage to machine my own version of the lathe pawn yesterday. One thing I noticed is that the Z axis motion was not very smooth - it seemed to be executing a series of steps rather than a continuous motion. With my calibrated eyeball and finger, I'd guess these are of the order of a few degrees of rotation of the 5mm ballscrew ie perhaps 100um or so steps. I have 846 steps per mm going to the servo if I understand correctly, so the resolution of the steps surely isn't the cause.

Could there be a mismatch between my PID tuning and the step gen perhaps - or a smoothing function / filter that I should be setting up? The behaviour seems to result in features on the machined part, not surprisingly. Can anyone see what's happening here?



Here's the relevant section in the INI file:

[AXIS_Z]
MIN_LIMIT = -410
MAX_LIMIT = 2.0
MAX_VELOCITY = 100
MAX_ACCELERATION = 600

[JOINT_1]
TYPE = LINEAR
HOME = 0.0
FERROR = 50
MIN_FERROR = 10.0
MAX_VELOCITY = 100
MAX_ACCELERATION = 600
# What are these scale things?
BACKLASH = 0.000
INPUT_SCALE = 200
# INPUT_SCALE is encoder counts per machine unit (5um scale)
OUTPUT_SCALE = 1.000
MIN_LIMIT = -410
MAX_LIMIT = 2.0
HOME_OFFSET = 5.0
HOME_SEARCH_VEL = 5.0
HOME_LATCH_VEL = 1.0
HOME_USE_INDEX = NO
HOME_IGNORE_LIMITS = YES
HOME_SEQUENCE =
# HOME_IS_SHARED = 1
# The values below should be 25% larger than MAX_VELOCITY and MAX_ACCELERATION
# If using BACKLASH compensation STEPGEN_MAXACCEL should be 100% larger.
STEPGEN_MAXVEL = 125
STEPGEN_MAXACCEL = 750
P = 50
I = 10
D = 3
FF0 = 0
FF1 = 0.85
FF2 = 0.005
BIAS = 0
DEADBAND = 0.0045
MAX_OUTPUT = 0
# these are in nanoseconds
DIRSETUP = 10000
DIRHOLD = 10000
# These were 5000ns. The Lichuan drive supports 600k in diff mode
STEPLEN = 2500
STEPSPACE = 2500
STEP_SCALE = 846.15
# number of pulses per machine unit
HOME_OFFSET = 0.0