For a while now there has been a problem with the way the movement speeds of the carriage have been calculated. Speeds are integers in [0, 255].
When a speed is sent to the PICs it is treated as a pre-load for an interrupt timer. Thus if you send 255 you get one tick between a stepper motor step and the next. 254 gives two ticks (i.e. half the speed), 253 gives 3 (i.e. 1/3 the speed) and so on. This is clearly non-linear.
If you had a speed of 200 and you wanted three-quarters of that, it used to send 150, which clearly does not give the actual speed in good honest mm/s that you intended, if the 200 gave you the right number of mm/s for that.
Now I've added a function:
public static int LinePrinter.speedFix(int oldSpeed, double factor);
Where factor is a fraction in [0, 1], and I have checked the new code into the repository.
This does the right thing, so if you say
int newSpeed = LinePrinter.speedFix(200, 0.75);
you get back the PIC interrupt pre-load that gives you the nearest speed to 3/4 the speed you got for a pre-load of 200.
I hope that this makes lots of things simpler and more accurate (like the changes in interrupt times that the software sends to get the same speed in mm/s for lines at different angles).
Don't chain calls to this function - there's a rounding that happens each time it is called and errors will accumulate. It is much better to keep speed factors in doubles, multiplying them, then just call speedFix() once at the end of the chain.
best wishes
Adrian
[
reprap.org]
[
reprapltd.com]
