Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Chips OTool on August 30, 2014, 02:05:34 PM
-
My last post got me no responses, but maybe I'll get lucky this time.
I am trying to adjust my mini-lathe steppers so the distances on the Mach3 screen have some relationship to reality. My z screw is 8 TPI, so 8 turns per inch. At 200 steps/turn, you would think I would be fine with 1600 steps/inch, but I am very close to correct with 6667 steps/inch. Obviously, something is messed up. I don't see any obvious relationship between 6667 and 1600. Maybe the correct figure is 6400, meaning I'm off by a factor of four for some reason, but I still have no idea what that reason is.
My x screw is 25 TPI, so presumably 5000 steps/inch. The figure I'm actually using is 75000!
Mach3 is set up for inches, but it says not to use this setting to change the way it reacts to G code. I can't find any other setting.
I am using a Kflop and Kstep. KMotion is set up in Step/Dir mode.
-
Are your drivers micro stepping types? If so what are they set to?
-
Thanks for replying. I will try to answer without saying anything stupid, but I can't promise anything.
The controller is a Kflop, which has a bunch of settings. The one I'm using says "Step Dir." There is also a microstepping setting, but the Step Dir thing was suggested to me.
I finally realized that Mach3 Turn does not have all the windows Mach3 Mill has. I went into the F6 window in Mach3 Mill, whatever it's called, and I made the mm/inch change. Then I went back to Mach3 Turn and tried the motors. The units are still way off.
-
I stuck a G20 in the code to see if that made any difference, but it didn't.
-
Well, with microstepping the driver modulates the current to the stepper so as to divide each step into "n". This means that the motor, from Mach's p.o.v., has 200n steps. If your z axis was set to 4 micro steps per step, that would account exactly for what you see assuming that the steps per inch should be 6400. Similarly, if n is set to 16 on the axis. Try putting the numbers 6400/inch and 80000/inch into Mach and see if that gives the right calibration. This assumes that the available numbers with the drive are 2, 4, 8, 16 etc which is normal.
Microstepping can give a small improvement in resolution at the expense of accuracy, but is mainly for smoother operation. Setting it to 16 is a bit high I would have thought, 4 or 8 on each axis is about right.
Hope this helps.
-
Thanks for the help. Do you have any idea where I would find "n" in the software? I don't see it in the KMotion config/flash screen.
-
Well, I DID find one thing. According to a Dynomotion support page, the Microstepping setting, which appears to be fixed, is 16x. I assume this is the figure you're talking about. Maybe Mach3 and KMotion are not on the same page about this, i.e. Mach3 expects a lower number?
In the configuration area, there is a setting for microstepper amplitude, which sounds like a voltage to me. When I select "Step Dir" mode, this setting greys out, suggesting it doesn't apply. Since I'm in Step Dir mode, I am wondering what the deal is.
I have had some confusion because Mach3 Turn didn't show me all the configuration stuff that was available in Mach3 Mill. I just located an axis calibration tool in Mach3 Mill, which may solve the problem, if I can get a good travel measurement.
-
Using the calibration utility and a dial indicator, I came up with 83333.33 steps/inch on x and 6475 on z. I got some figures that varied badly until I realized I wasn't taking the backlash out before each measurement. Tomorrow I'll see if this actually works.
-
KStep microstepping is fixed at 16, but Mach doesn't know the difference. All Mach is interested in is how many steps it takes to move a known distance.
The amplitude setting that gets grayed out is of no interest in the KMotion Config&Flash screen. In StepDir mode, all you are interested in is the output channel (should be 8-11 for a single KStep), and the output gain if you need to swap axis direction. Remember that any changes you do on the Config&Flash screen will get wiped out by the settings in yout init.c file whenever you hit reset in Mach.
Anyway, using your figures-
Z-axis = 8tpi x 200 x 16 = 25600 steps per inch
X-axis = 25tpi x 200 x 16 = 80000
You're 6475 is only about a quarter of what it should theoretically be. You've not changed the output gain from 1 to 4 on that channel by any chance?
You can use output gain in open loop to increase the number of pulses, however it has no benefit and usually makes things more confusing when you come to setting up the axis or want to change something later.
-
I have been fooling with this thing a lot today.
First, I tried to get the backlash out. Measuring by turning the steppers while using a dial indicator, I came up with the figures of ~0.0005 on the x axis, which makes me wonder if it needs to be loosened, and .007 on z. I programmed this stuff into the backlash area of Mach3 and enabled it, but I do not know whether the program is supposed to be started with the backlash taken up or left in for the PC to take out, so for all I know, I could be doubling my backlash error.
I switched to "Exact Stop" mode because I read that this was necessary to make backlash correction work.
I have two programs that do nothing but move an axis (x or z) back and forth by 0.5". I ran those and came to the conclusion that the best steps/unit for x as 81540. Over half an inch, this agrees with the indicator to within a thousandth. Z is now at 6580, after measuring. I can't explain it.
I can't tell if backlash correction is working on x, since the backlash is really too small to distinguish from my own error in reading the dial from two feet away.
I have not changed the output gain. It's still 1.
Kmotion has a backlash function, but to use it, I think I have to know the steps/unit figure, so I haven't tried to use it yet. Again, I don't know whether you take up the backlash before starting the program.
Update: I turned off the backlash correction in Mach3, and now I'm getting a consistent 0.499" when I ask for 0.500", in EITHER direction. None of this makes sense.
-
Ignore backlash until you get the units set correctly.
The Mach backlash setting will have no effect on an external motion controller anyway, as the backlash is handled internally by the controller.
Probably best if you have a read through this post I made last week over on the HSM forum - http://bbs.homeshopmachinist.net/threads/63822-Help-Choosing-Electronics-for-CNC-Lathe-Conversion?p=933822#post933822 as it covers the basic process of setting things up.
Something does seem a bit strange with your Z-axis steps. Any chance you could attach your kflop init file, or even just copy and paste your channel configuration settings from it?
-
That's my thread! I have been looking for help all over the place. Thanks for the info on the Mach3 backlash tool not applying to external controllers. That's a major help.
Here is the init.c file:
#include "KMotionDef.h"
// Defines axis 0, 1 as simple step dir outputs
// enables them
// sets them as an xz coordinate system for GCode
int main()
{
ch0->InputMode=NO_INPUT_MODE;
ch0->OutputMode=STEP_DIR_MODE;
ch0->Vel=100;
ch0->Accel=1000;
ch0->Jerk=10000;
ch0->P=1;
ch0->I=0;
ch0->D=0;
ch0->FFAccel=0;
ch0->FFVel=0;
ch0->MaxI=200;
ch0->MaxErr=200;
ch0->MaxOutput=200;
ch0->DeadBandGain=1;
ch0->DeadBandRange=0;
ch0->InputChan0=0;
ch0->InputChan1=1;
ch0->OutputChan0=8;
ch0->OutputChan1=1;
ch0->MasterAxis=-1;
ch0->LimitSwitchOptions=0x100;
ch0->LimitSwitchNegBit=0;
ch0->LimitSwitchPosBit=0;
ch0->SoftLimitPos=1e+009;
ch0->SoftLimitNeg=-1e+009;
ch0->InputGain0=1;
ch0->InputGain1=1;
ch0->InputOffset0=0;
ch0->InputOffset1=0;
ch0->OutputGain=-1;
ch0->OutputOffset=0;
ch0->SlaveGain=1;
ch0->BacklashMode=BACKLASH_OFF;
ch0->BacklashAmount=0;
ch0->BacklashRate=0;
ch0->invDistPerCycle=1;
ch0->Lead=0;
ch0->MaxFollowingError=1000000000;
ch0->StepperAmplitude=250;
ch0->iir[0].B0=1;
ch0->iir[0].B1=0;
ch0->iir[0].B2=0;
ch0->iir[0].A1=0;
ch0->iir[0].A2=0;
ch0->iir[1].B0=1;
ch0->iir[1].B1=0;
ch0->iir[1].B2=0;
ch0->iir[1].A1=0;
ch0->iir[1].A2=0;
ch0->iir[2].B0=1;
ch0->iir[2].B1=0;
ch0->iir[2].B2=0;
ch0->iir[2].A1=0;
ch0->iir[2].A2=0;
EnableAxisDest(0,0);
ch1->InputMode=NO_INPUT_MODE;
ch1->OutputMode=STEP_DIR_MODE;
ch1->Vel=100;
ch1->Accel=1000;
ch1->Jerk=10000;
ch1->P=1;
ch1->I=0;
ch1->D=0;
ch1->FFAccel=0;
ch1->FFVel=0;
ch1->MaxI=200;
ch1->MaxErr=200;
ch1->MaxOutput=200;
ch1->DeadBandGain=1;
ch1->DeadBandRange=0;
ch1->InputChan0=1;
ch1->InputChan1=2;
ch1->OutputChan0=9;
ch1->OutputChan1=3;
ch1->MasterAxis=-1;
ch1->LimitSwitchOptions=0x100;
ch1->LimitSwitchNegBit=0;
ch1->LimitSwitchPosBit=0;
ch1->SoftLimitPos=1e+009;
ch1->SoftLimitNeg=-1e+009;
ch1->InputGain0=1;
ch1->InputGain1=1;
ch1->InputOffset0=0;
ch1->InputOffset1=0;
ch1->OutputGain=-1;
ch1->OutputOffset=0;
ch1->SlaveGain=1;
ch1->BacklashMode=BACKLASH_OFF;
ch1->BacklashAmount=0;
ch1->BacklashRate=0;
ch1->invDistPerCycle=1;
ch1->Lead=0;
ch1->MaxFollowingError=1000000000;
ch1->StepperAmplitude=250;
ch1->iir[0].B0=1;
ch1->iir[0].B1=0;
ch1->iir[0].B2=0;
ch1->iir[0].A1=0;
ch1->iir[0].A2=0;
ch1->iir[1].B0=1;
ch1->iir[1].B1=0;
ch1->iir[1].B2=0;
ch1->iir[1].A1=0;
ch1->iir[1].A2=0;
ch1->iir[2].B0=1;
ch1->iir[2].B1=0;
ch1->iir[2].B2=0;
ch1->iir[2].A1=0;
ch1->iir[2].A2=0;
EnableAxisDest(1,0);
DefineCoordSystem(0,-1,1,-1);
//return 0;
}
-
Ha, I did wonder if there really had been a surge in lathe kflop mach users :)
A couple things that stand out are the missing code to tell the kflop a kstep is attached, and your velocity, acceleration and jerk are low.
Try using the basic kstep example file supplied with kmotion, and editting it to suit, as it contains settings that are pretty good to start with, and the required code to implement all the kstep features.
Should be a case of just editting the DefineCoordMotion statement so only 2 axis are activated.
-
Actually, that IS one of the files that came with KMotion, but I don't think it's Kstep-specific. I can root around and dig one out. I know it's in there.
I thought that when I wrote (0,-1,1,-1) I was calling 0 "x," deactivating y, and calling 1 "z". Wrong?
-
That's correct, however the example files are set up for 3 or 4 axis, so you'll need to change it.
-
I am looking at the "mot" files in Kmotion. It appears that they duplicate a lot of the stuff in the init.c file. Not sure why I need mot files AND an init.c file.
-
You don't need or use the mot files. They're solely motor config files, which are only any use via the config&flash screen.All you use for most things are c files, which are what configure the motors for normal use.
-
I got this to work in Mach3 and KmotionCNC, but the steps/inch setting seems to be wandering around now. I am working on that. The motors run much cooler now. I am researching jerk to find out the right setting. I have a physics degree, so I have some clue what acceleration per second is, but "jerk" is an engineering term, so I have never worked with it before. It sounds like a bad thing, but I assume it refers to softening the changes in motion, like reducing the pressure on a brake pedal?
Anyway, I will keep fooling with it. You have been a tremendous help. I had no idea the Kflop had to be told there was a Kstep, or that the mot files were not needed.
It's pretty cool, finally seeing something happen in KmotionCNC.
#include "KMotionDef.h"
// Defines axis 0, 1 as simple step dir TTL outputs for KSTEP
// enables them
// sets them as an xz coordinate system for GCode
int main()
{
double T0, LastX=0, LastZ=0, Tau;
KStepPresent=TRUE; // enable KSTEP input multiplexing
FPGA(KAN_TRIG_REG)=4; // Mux PWM0 to JP7 Pin5 IO 44 for KSTEP
FPGA(STEP_PULSE_LENGTH_ADD) = 63 + 0x80; // set polarity and pulse length to 4us
ch0->InputMode=NO_INPUT_MODE;
ch0->OutputMode=STEP_DIR_MODE;
ch0->Vel=40000;
ch0->Accel=200000;
ch0->Jerk=4e+006;
ch0->P=0;
ch0->I=0.01;
ch0->D=0;
ch0->FFAccel=0;
ch0->FFVel=0;
ch0->MaxI=200;
ch0->MaxErr=1e+006;
ch0->MaxOutput=200;
ch0->DeadBandGain=1;
ch0->DeadBandRange=0;
ch0->InputChan0=0;
ch0->InputChan1=0;
ch0->OutputChan0=8;
ch0->OutputChan1=0;
ch0->MasterAxis=-1;
ch0->LimitSwitchOptions=0x0;
ch0->SoftLimitPos=1e+030;
ch0->SoftLimitNeg=-1e+030;
ch0->InputGain0=1;
ch0->InputGain1=1;
ch0->InputOffset0=0;
ch0->InputOffset1=0;
ch0->OutputGain=1;
ch0->OutputOffset=0;
ch0->SlaveGain=1;
ch0->BacklashMode=BACKLASH_OFF;
ch0->BacklashAmount=0;
ch0->BacklashRate=0;
ch0->invDistPerCycle=1;
ch0->Lead=0;
ch0->MaxFollowingError=1000000000;
ch0->StepperAmplitude=20;
ch0->iir[0].B0=1;
ch0->iir[0].B1=0;
ch0->iir[0].B2=0;
ch0->iir[0].A1=0;
ch0->iir[0].A2=0;
ch0->iir[1].B0=1;
ch0->iir[1].B1=0;
ch0->iir[1].B2=0;
ch0->iir[1].A1=0;
ch0->iir[1].A2=0;
ch0->iir[2].B0=0.000769;
ch0->iir[2].B1=0.001538;
ch0->iir[2].B2=0.000769;
ch0->iir[2].A1=1.92076;
ch0->iir[2].A2=-0.923833;
EnableAxisDest(0,0);
ch1->InputMode=NO_INPUT_MODE;
ch1->OutputMode=STEP_DIR_MODE;
ch1->Vel=40000;
ch1->Accel=200000;
ch1->Jerk=4e+006;
ch1->P=0;
ch1->I=0.01;
ch1->D=0;
ch1->FFAccel=0;
ch1->FFVel=0;
ch1->MaxI=200;
ch1->MaxErr=1e+006;
ch1->MaxOutput=200;
ch1->DeadBandGain=1;
ch1->DeadBandRange=0;
ch1->InputChan0=0;
ch1->InputChan1=0;
ch1->OutputChan0=9;
ch1->OutputChan1=0;
ch1->MasterAxis=-1;
ch1->LimitSwitchOptions=0x0;
ch1->SoftLimitPos=1e+030;
ch1->SoftLimitNeg=-1e+030;
ch1->InputGain0=1;
ch1->InputGain1=1;
ch1->InputOffset0=0;
ch1->InputOffset1=0;
ch1->OutputGain=1;
ch1->OutputOffset=0;
ch1->SlaveGain=1;
ch1->BacklashMode=BACKLASH_OFF;
ch1->BacklashAmount=0;
ch1->BacklashRate=0;
ch1->invDistPerCycle=1;
ch1->Lead=0;
ch1->MaxFollowingError=1000000000;
ch1->StepperAmplitude=20;
ch1->iir[0].B0=1;
ch1->iir[0].B1=0;
ch1->iir[0].B2=0;
ch1->iir[0].A1=0;
ch1->iir[0].A2=0;
ch1->iir[1].B0=1;
ch1->iir[1].B1=0;
ch1->iir[1].B2=0;
ch1->iir[1].A1=0;
ch1->iir[1].A2=0;
ch1->iir[2].B0=0.000769;
ch1->iir[2].B1=0.001538;
ch1->iir[2].B2=0.000769;
ch1->iir[2].A1=1.92076;
ch1->iir[2].A2=-0.923833;
EnableAxisDest(1,0);
DefineCoordSystem(0,-1,1,-1);
SetBitDirection(45,1); // set Enable Signal as Output
SetBit(45); // Enable the amplifiers
// Add a small amount of Coordinated Motion Path smoothing if desired
// Tau = 0.001; // seconds for Low Pass Filter Time Constant
// KLP = exp(-TIMEBASE/Tau);
KLP=0; // force to 0 to disable
// printf("Tau=%f KLP=%f\n",Tau,KLP);
for (;;) // loop forever
{
WaitNextTimeSlice();
// Service Amplifier disable after no activity for a while
if (ch0->Dest != LastX || ch1->Dest != LastZ)
{
// we moved - enable KStep Amplifers
SetBit(45);
T0 = Time_sec(); // record the time and position of last motion
LastX=ch0->Dest;
LastZ=ch1->Dest;
}
else
{
if (Time_sec() > T0 + 10.0) ClearBit(45);
}
}
return 0;
}
-
Couple things if you're using that file as is.
Remove the bit that disables the amplifiers after being idle for a period, as it means position can be lost if the steppers happen to move when power is removed.
Also when running mach, I'd remove the SetBit(45) line, and instead set an enable in mach to Port 1 Pin 45, so the amps only get enabled when Mach does.
Jerk is a measurement of how quickly acceleration/deceleration is applied, and in KFlop is a measurement of counts/pulses per second per second per second (I bet you had to read that several times, as it took me a while to get my head around it!)
Without jerk, which is how Mach3 runs, on acceleration there is a sudden increase in the rate of pulses, which leads to a sudden change in force as something stationary suddenly has to accelerate. With jerk, the rate at which the acceleration is applied is controlled, so you get a smoother start to acceleration.
Think of it as when you press the accelerator in a car, if you suddenly stamp it to the floor, you start accelerating quickly and provided you've got enough horses under the bonnet, you get abrubtly forced back into the seat.
Now taking the same car, if you gradually press the accelerator to the floor, you ultimately get to the same acceleration rate, however you don't get as abrubtly forced back into the seat.
The trick is applying enough Jerk, so things accelerate smoothly and quick enough without causing jerky movement. It does essentially result in a very basic S-curve motion profile.
One thing to note, is while running KFlop with Mach, you have to ensure that the Mach settings aren't limited by the KFlop settings, as the KFlop max speed settings will over rule Mach settings. This can lead to a condition where actual movement is ever increasingly lagging behind Mach. I'm not sure what would happen if the lag becomes too big, but it's something to be aware of.
However none of that explains your step per unit issues.
I'd maybe try dropping the acceleration rate and speed rate down in Mach, incase you're loosing steps during the moves. Another way to check for this would be to set up a dial gauge against the carriage, zero the axis, then do a rapid away, then a slower feed return to the gauge. You're most likely to lose steps during the rapid, so doing a rapid in one direction followed by a slow return is more likely to show up lost steps.
Might also be worth checking that all your couplings are tight.
My next move after that would be visually check the motors are turning the correct number of turns for a requested move. i.e. mark the motor/coupling then command a move of 0.125" and check the motor does rotate one full turn. And if it does, check your screw is 8tpi.
-
I am getting back to this today. I got a call from Dolphin CAD/CAM about a discount, so I have been trying to get their demo to work with Alibre Design Personal, and it has sucked up a lot of time.
Regarding jerk, I have no idea what an acceptable figure is. I assume the notation used ("4e+006") means "4.00 x 10 to the sixth power," but I don't know what the units are or what levels make sense.
M x velocity is about 25"/min., and my z is about 138. The x acceleration is about 3.3"/second^2, and the z figure is about 32. Mach3 picked these figures. I don't know why it would ever need to move that fast on a mini-lathe in a garage. I can fool with it and see what happens.
-
Well, I guess the jerk units must be inches/sec.^3. I must have been asleep when I wrote that.
-
It's count/sec^3, where count is either encoder counts, or microsteps depending on what you're driving.
KFlop has no interest in whether you're working in inches or mm, it's only interested in raw numbers. It's upto Mach/KmotionCNC/whatever other interface you're using to create the raw numbers via a format that humans are more likely to comprehend.
-
Just realised the bit I mentioned about making sure Mach isn't slowed by the KFlop settings might be causing you issues.
Take your 75000 steps per inch figure as an example.
Ignoring acceleration for now, if you command a move of 60inch per minute, you need KFlop to generate 75000 steps per second.
Now if you have the axis/channel in KFlop set at a max speed of say 50'000, that means the KFlop/actual motion is going to trail Mach's planned trajectory by an ever increasing 25'000 steps per second, or 1/3" per second.
This also applies to acceleration, but you also have the added complication of jerk.
Using the same 75'000 figure, say you have your acceleration set at 1"/sec^2, this means after 1 second Mach expects motion to be at 1"/sec, and the KFlop should be outputting 75'000 steps per second to acheive this, which you would think is acheivable by setting an acceleration rate of 75'000 in your axis/channel.
However, that doesn't allow for Jerk. If you have Jerk set to 75'000, it's going to take 1 sec for the KFlop to reach max acceleration, by which point you're lagging behind the Mach trajectory.
I can't remember how KFlop handles the lag scenario, but I suspect it just continues to buffer motion.
And having just searched the yahoo list, the axis commanded position will keep increasing while the actual position lags, to the point where either the axis disables because of max following error limit being exceeded, or if trajectory stops allowing the axis to catch up, the axis will come to an abrupt uncontrolled stop.
So the moral of the story is, make sure you're conservative with your Mach settings.
-
I am still fooling with this. I'm trying to figure out as much as I can so I don't waste other people's time too much.
I learned more new stuff. It appears that I shouldn't even think about setting things in Mach3 until I've tried KMotion. And if I use KMotionCNC, I have to remember to go through that, too. I am trying to resist downloading mot files out of habit.
It turns out KMotionCNC has an area where you set the motor up. It's in Tool Setup/Trajectory Planner. I had to go in there and tell the software how many counts per inch I wanted. For unknown reasons, on x, I ended up with 81958 and change. The x axis appears to be accurate to within a thousandth over half an inch, which is not something I'm going to complain about on a Chinese mini-lathe.
Now I'm having fun with backlash correction. This is found in the init.c file, and to turn it on, I have to change "ch0->BacklashMode=BACKLASH_OFF;" to "ch0->BacklashMode=BACKLASH_LINEAR;." You would think the opposite of "off" would be "on," but no. It's "linear."
My problem now is figuring out when the backlash correction is added and how. The x backlash is less than a thousandth, which I don't understand, but anyway, it's so small, it's difficult to know whether correction works or not. I am trying to use z to figure it out.
The documentation says the correction works in the "positive" direction, but it doesn't say what that means. If I enter a number of steps (you can't enter thousandths) adding up to 10 thousandths, does that mean I put the lathe at zero with the backlash taken out and turn it on, and then it moves the dial ten thousandths the other way and THEN starts counting the z travel? Danged if I know.
To make things even worse, I bought Dolphin CAD/CAM, so if I ever get KMotionCNC figured out, I'll have to start over with Dolphin. But it looks like a great program.
I'm still blown away by the fact that KMotion reckons the steps/inch thing in inverse distance per cycle, where a cycle is four steps, but I'm sure there is some solid engineer reason for it.
-
The official quote from the manual-
Sets or gets the Backlash Compensation mode from either BACKLASH_OFF (0) to BACKLASH_LINEAR (1). When the backlash mode is set to Linear mode, whenever the commanded destination begins moving in the positive direction, a positive offset of the amount, BacklashAmount, will be applied. The offset will be ramped upward as a linear function of time at the rate specified as the BacklashRate. Whenever the commanded destination begins moving in the negative direction the offset will be removed by ramping downward toward zero at the same rate.
What it essentially means, is that when you move in the positive direction, the backlash amount gets added, at the rate specified by BacklashRate.
So to use some random figures, say you have backlash set at 1000, with a backlash rate of 1000.
Now you command a move of say 3000 steps at 1000 steps per second. As the axis moves at the set rate, it applies the backlash on top of the set motion rate*, so after 1 second, the axis has actually moved 2000 steps. After the backlash has been applied, the axis then continues to move at it's set motion rate of 1000 steps per second until it reaches 4000 steps, which if your backlash is set correctly should be the equivalent of moing 3000 steps.
If you then command another move in the same direction of say 1000, as backlash has already been applied, the axis simply moves 1000 steps, so the axis should of now physically of moved 4000 steps (or 5000 steps with backlash applied)
In reverse, the exact same thing happens, but things count down instead of up. So if you start at a physical 4000 steps (5000 with backlash applied), and command a move of 4000 to return to zero, as the axis starts to move, an additional 1000 steps will be added to the first second of motion to remove the backlash amount.
The idea is, that due to backlash applying no load to the drive system, it can be added quickly to motion moves, so that backlash is removed prior to the axis physically starting to move. The 1000 step example I used is very high setting for most systems, and in practical use a backlash setting that high will cause problems. Backlash is essentially a sticking plaster solution, and only really meant to handle very minimal backlash which can't be removed through other means.
Any large amounts of backlash where the tool can pull/push against the backlash, means that if you use a high backlash rate, you can miss steps due to a large amount of backlash being too quickly applied against axis load, however if you use too low a backlash rate, then the backlash won't be applied quickly enough during moves.
-
And the Backlash_Linear is because it leaves open the option to add other backlash modes at a later date.
Linear is the simplest method to handle backlash, but there are other more complex methods.