Determining Max Speed and Acceleration

jay_s_uk

@deckingman thanks for that response. I agree I should probably make the parameter description better.
I need to look and see what I can do to make the repeatability better. With klipper you can see the step position whereas we don't have that with marlin so what the script does is homes, moves back by 1mm and then records that position. It then does the test moves, goes back to that saved position and then measure how far it has to move until it triggers the endstops. I couldn't think of any other way of doing it with RRF unless you have any ideas?

I'll see what I can do to make the script more universal in terms of the origin (I hadn't thought about that). I can also put a check in to see whether the probe exists. The bed levelling is mostly there for vorons where the gantry drops.

@Falcounet was also going to look at adding some repeatability tests in for the endstops so I'll check in with him.

The criteria for whether a skip is detected is 1 full step so maybe this is a little tight (it calculates what a step equals and I think I have to go slightly higher due to decimal places).

But thanks for your feedback and I'll look at updating it

deckingman

@jay_s_uk No worries. Thinking about it some more, I reckon for a CoreXY, it would be better just to do rapid 45 degree moves. With anything else, we have two motors contributing to motion so all sorts of interactions going on. If we are just concerned about missed steps, then we should concentrate on doing each motor individually don't you think? So maybe two macros - the first one does Xmin Ymin to Xmax Ymax thus exercising just the Alpha motor, the second doing Xmax Ymin to Xmin Ymax - i.e the Beta motor. Single motor moves on a CoreXY would be the worse case so that's what the machine limits should be set to - even though other moves might use both motors.

EDIT. Xmin Ymin to Xmax Ymax is only 45 degrees if the axes lengths are the same for X and Y. So you'd need to see which axis has the shortest travel distance and apply this distance to both axes, i.e. from Xmin Ymin to Xmin+travelDistance Ymin+travelDistance.

dc42

@deckingman RRF automatically reduces the maximum speed for 45 degree moves (unlike Klipper). So it shouldn't matter whether you do X and Y moves or 45 degree moves. Preferably, do both.

This also means that on a CoreXY machine the maximum X and Y speeds should be set 1.4 times higher than for Klipper on the same machine.

deckingman

@dc42 I was just thinking that if the objective is to look for skipped steps caused by high speed and/ or high acceleration, then the worse case scenario would be if all the load was on one motor. Hence front left to rear right at 45 degrees to exercise only the Alpha motor, and front right to rear left at 45 degree to exercise only the Beta motor.

dc42

@deckingman said in Determining Max Speed and Acceleration:

I was just thinking that if the objective is to look for skipped steps caused by high speed and/ or high acceleration, then the worse case scenario would be if all the load was on one motor

If the macro works by setting the M203 X and Y values very high and then trying G1 commands at different speeds, then you are right. If instead it works by adjusting the M203 X and Y values at each step and then commanding G1 moves at or above those speeds, then RRF will automatically reduce the speed if it's a diagonal move, so the direction you choose shouldn't matter.

deckingman

@dc42 The macro that @jay_s_uk posted takes speed and acceleration inputs ,then performs a series of moves using those same values. The idea behind it is to run the macro multiple times, each time with higher speed and/or acceleration. As far as I can work out, it then returns the print head to its original start position (which was determined as being 1mm away from the end stops) then measures how far the print head has to move until the end stop triggers. The difference between the start and end positions being used as a measure of any skipped steps. So my point is that the pure X or pure Y moves would share the load between both motors and so those moves would be less likely to suffer skipped steps than single motor moves.

deckingman

@jay_s_uk Hi Jay. I hacked your macro around in order to test end-stop repeatability. It's specific to my machine (Y homes to max, origin is in the centre of the bed). It does essentially what your macro did but replaces the entire move section with a simple, slowish speed move. So it homes just X and Y (no point doing Z) at 60mm/minute, establishes the start position, moves 10mm away from both end stops at 1800 mm/minute (30mm/sec), then establishes the end positions and differences just like you were doing. Then it increases the homing speed by 60mm/sec and repeats the process.

Here is the code

var xPositionStart = 0
var yPositionStart = 0
var xPositionEnd = 0
var yPositionEnd = 0
var xPositionDifference = 0
var yPositionDifference = 0
var feedRate = 60
var feedRateStep = 60

while iterations <10
	G28 XY ; home just X and Y
	G91; relative
	G0 X{move.axes[0].min + 1} F1800
	M400
	G0 Y{move.axes[1].max - 1} F1800
	M400
	set var.xPositionStart = move.axes[0].machinePosition; set X start position	
	set var.yPositionStart = move.axes[1].machinePosition ; set Y start position
	
	G1 X10 Y-10 F1800; move away 10mm @ 30mm/sec
	M400; wait for move to finish
	
	; Go back to 1mm from endstops and measure distance to endstop for Comparison
	G90; absolute
	G0 X{move.axes[0].min + 1} F1800
	M400
	G91 ; relative
	G1 H4 X{-move.axes[0].max} F{var.feedRate} 
	M400
	G4 S1
	set var.xPositionEnd = move.axes[0].machinePosition + 1

	G90;absolute
	G0 Y{move.axes[1].max - 1} F1800
	M400
	G4 S1
	G91; relative
	G1 H4 Y{move.axes[1].max} F{var.feedRate}
	M400
	G4 S1
	set var.yPositionEnd = move.axes[1].machinePosition - 1

	set var.xPositionDifference = abs(var.xPositionStart - var.xPositionEnd)
	set var.yPositionDifference = abs(var.yPositionStart - var.yPositionEnd)
	echo "X difference is " ^ var.xPositionDifference, " at homing feedrate of " ^ var.feedRate, " mm/minute"
	echo "Y difference is " ^ var.yPositionDifference, " at homing feedrate of " ^ var.feedRate, " mm/minute"
	set var.feedRate = var.feedRate + var.feedRateStep

......and here is the console readout from running it............

23/07/2023, 12:22:47 X difference is 0.250 at homing feedrate of 600 mm/minute
Y difference is 0.100 at homing feedrate of 600 mm/minute
23/07/2023, 12:22:15 X difference is 0.050 at homing feedrate of 540 mm/minute
Y difference is 0.088 at homing feedrate of 540 mm/minute
23/07/2023, 12:21:42 X difference is 0.188 at homing feedrate of 480 mm/minute
Y difference is 0.100 at homing feedrate of 480 mm/minute
23/07/2023, 12:21:10 X difference is 0.050 at homing feedrate of 420 mm/minute
Y difference is 0.100 at homing feedrate of 420 mm/minute
23/07/2023, 12:20:38 X difference is 0.050 at homing feedrate of 360 mm/minute
Y difference is 0.113 at homing feedrate of 360 mm/minute
23/07/2023, 12:20:05 X difference is 0.038 at homing feedrate of 300 mm/minute
Y difference is 0.100 at homing feedrate of 300 mm/minute
23/07/2023, 12:19:33 X difference is 0.038 at homing feedrate of 240 mm/minute
Y difference is 0.137 at homing feedrate of 240 mm/minute
23/07/2023, 12:19:00 X difference is 0.025 at homing feedrate of 180 mm/minute
Y difference is 0.125 at homing feedrate of 180 mm/minute
23/07/2023, 12:18:27 X difference is 0.212 at homing feedrate of 120 mm/minute
Y difference is 0.062 at homing feedrate of 120 mm/minute
23/07/2023, 12:17:54 M98 P"0:/macros/endStopRepeatability.g"
X difference is 0.062 at homing feedrate of 60 mm/minute
Y difference is 0.038 at homing feedrate of 60 mm/minute

So it looks like my homing micro-switches have a repeatability of up to 0.25mm (worse case). That's fine for homing purposes but not good for determining precise positioning errors. No doubt, slotted opto switches would be more repeatable but I doubt too many people would want to change their otherwise perfectly acceptable micro-switches just for the purpose of establishing their machines' maximum capabilities.

So I guess a valid approach might be to only flag the possibility of missed steps if the positional difference is greater than the repeatability error for the switch. In my case, I could only say that there is a high likelihood of skipped steps if the difference between start and end is greater than 0.25 mm. The trouble is, at 80 steps per mm for my X and Y axes, 0.25mm equates to 20 full steps. But then I guess if you push the envelope and get into genuine skipped step territory, you are likely to see more than 20 missed steps so maybe it's still a valid approach? Dunno......

EDIT. The error at 120mm/minute (2mm/sec) homing speed is much the same as the error at 600mm/minute (10mm/sec) so slow homing speed doesn't help repeatability (although it could be even worse at higher homing speeds).

gloomyandy

@deckingman Interesting, a few questions so I can get my head around what is going on...

You mention "it homes just X and Y (no point doing Z) at 60mm/minute". It looks like you are using G28 to set the initial position, is the feedrate in your homex.g/homey.g for the final homing move 60mm/min?

It looks like the final H4 move is only 1mm is that correct? What acceleration is being used for that move? Does it allow the target speed to be reached over a 1mm move?

Looking at the initial output:

23/07/2023, 12:17:54 M98 P"0:/macros/endStopRepeatability.g"
X difference is 0.062 at homing feedrate of 60 mm/minute
Y difference is 0.038 at homing feedrate of 60 mm/minute

It seems like at that speed the repeatability might be better? I wonder if you ran multiple iterations at that single speed you would still see the odd spike in the error? I wonder if having this speed match the speed used in the homing files has any impact on things?

deckingman

@gloomyandy TBH, I just hacked Jay's original macro without looking too deeply at what's going on. But I'll do my best to answer your questions.

The second pass of my home X and home Y use a feed rate of 360 (so 6mm/sec).
My default accelerations for x and Y are set to 1000 mm/sec^2 and neither this macro nor my homing files change that so I guess that's what's being used. My maths is a bit rusty these days but I reckon accel of 1000 mm/sec^2 should lead to a maximum speed of 31.6 mm/sec over a distance of 1mm.
I guess what might be a pertinent test would be to run multiple iterations at a fixed speed of 360 which is the same as the second pass of the initial homing moves. So final home both axes at 360, move away, then move back to end stops all at the same speed, and repeat.

That'll be easy enough to do - I'll get on with it shortly when I've finished what I'm doing with the machine.

gloomyandy

@deckingman I make it 44.72mm/s (cheating by using this: http://instantphysics.com/motion/equations-of-motion/). But either way that should not be an issue!

Yes I agree that a test using the same speed for the homing moves and the position detection would be interesting!

I'd try it myself but the only (working) printers I have use sensorless homing which is a bit of a non starter for this sort of thing.

deckingman

@gloomyandy too late - I've already done it at 360mm/min(6mm/sec).

I did two runs. The first was 10 iterations, the second was 20.

For some reason, I can't download the console output so I've copied and pasted it into notepad.

console1.txt

One could play some statistical tricks and pick a sequence of 4 or 5 out of the data set and discard the other 15 or 16 readings as outliers, but even that sort of outrageous manipulation will still show a repeatability error of around 0.03 which is around 3 full steps.

I'm not at all surprised to find that a cheap mechanical micro-switch is only accurate to around 0.2mm. That's more than good enough for basic homing.

Maybe Jay's original macro is fundamentally OK but one would need to allow for these switch repeatability errors. So one could only say with confidence that missed steps were detected if the difference in position was greater than (say) 0.2mm.

Having said all that, I've just noticed that all the differences are positive. A quick gander at Jay's file (which I largely copied) shows that we are using the abs function.

I'll take that abs function out and run one more test so that we can see if the differences are all positive, all negative, or a mixture of both.

deckingman

Well I suppose one could say that X is always negative and Y is always positive and that if one thought about it hard enough and for long enough, there might be a reason for that. But it doesn't get away from the fact that 1 micro-step is 0.0125mm and a cheap mechanical micro-switch ain't gonna be accurate enough.

23/07/2023, 17:55:43 X difference is -0.038 at homing feedrate of 360 mm/minute
Y difference is 0.050 at homing feedrate of 360 mm/minute
23/07/2023, 17:55:06 X difference is -0.025 at homing feedrate of 360 mm/minute
Y difference is 0.075 at homing feedrate of 360 mm/minute
23/07/2023, 17:54:29 X difference is -0.038 at homing feedrate of 360 mm/minute
Y difference is 0.075 at homing feedrate of 360 mm/minute
23/07/2023, 17:53:52 X difference is -0.013 at homing feedrate of 360 mm/minute
Y difference is 0.088 at homing feedrate of 360 mm/minute
23/07/2023, 17:53:15 X difference is -0.038 at homing feedrate of 360 mm/minute
Y difference is 0.062 at homing feedrate of 360 mm/minute
23/07/2023, 17:52:01 X difference is -0.025 at homing feedrate of 360 mm/minute
Y difference is 0.087 at homing feedrate of 360 mm/minute
23/07/2023, 17:51:24 X difference is -0.212 at homing feedrate of 360 mm/minute
Y difference is 0.087 at homing feedrate of 360 mm/minute
23/07/2023, 17:50:47 X difference is -0.212 at homing feedrate of 360 mm/minute
Y difference is 0.113 at homing feedrate of 360 mm/minute
23/07/2023, 17:50:10 M98 P"0:/macros/endStopRepeatability.g"
X difference is -0.087 at homing feedrate of 360 mm/minute
Y difference is 0.150 at homing feedrate of 360 mm/minute