print head dynamics - how does it work?

mikeabuilder

Is there a wiki page that describes is some detail what goes into computing the dynamics of print head movement? I'm trying to build up my understanding, based on something I saw yesterday.

In testing my new CoreXY printer, I was using a macro I wrote to do repetitive straight line moves in specified directions. This is notfor printing, but to help me examine/debug the machine and set good values for max speed, accel, etc.

One thing I could observe while the macro is running is the max speed achieved is for various length lines. I can see the "requested speed" and the actual max speed on the web interface. So I set my requested speed to 200mm/sec and could see that on lines shorter than 100mm, I never accelerated to max speed. I did get there on a 200mm line. But only when the line was in the X direction. In the Y direction, I only achieved 141mm/sec for the same length line. I think the reason is that X direction moves accelerate a lot less mass (only the print head) than Y direction moves (which also move the "bridge" and Y rail sliders").

I assume that the max motor current is the limiting factor, but I also thought that if the motor doesn't have the torque to complete a move, then that move is "lost" and the motor has missed a step.

I always thought that the fw uses the line length and "steps per mm" to calculate the number of steps along the line, then calculates a time when each step should occur, based on not violating the max speed, acceleration and instantaneous speed change settings. Then it issues motor steps at the correct times to get to the end of the line.

But if this is so, how am I not losing steps?

This is not a crisis question, my printer seems to be working fine. I'm just trying to satisfy my curiosity.

bot

@mikeabuilder the situation you describe, with the requested and actual speed, is based purely on the acceleration, jerk, and speed values used by the firmware. The torque, motor current, or lost steps do not play a factor in that.

If you are not achieving the requested speed, it's because one or more axis is being limited by firmware settings. If you'd like an exact reason, post your config.g and a few sample lines of g-code which exhibit what you describe.

mikeabuilder

I want to be cautious about turning this into a problem statement and consuming a bunch of valuable time, but...

Here's the relevant section of my config.g.

; Motors
M569 P0.0 S0                                 ; physical drive 0.0 (Left-rear motor) goes backwards
M569 P0.1 S0                                 ; physical drive 0.1 (Right-rear motor) goes backwards
M569 P0.2 S1                                 ; physical drive 0.2 (Z motor) goes forwards
M569 P0.3 S1                                 ; physical drive 0.3 (Extruder) goes forwards
M584 X0.0 Y0.1 Z0.2 E0.3                     ; set drive mapping
M350 X16 Y16 Z16 E16 I1                      ; configure microstepping with interpolation
M92 X160.00 Y160.00 Z3200.00 E400            ; set steps per mm (really microsteps per mm)
M566 X900.00 Y900.00 Z60.00 E120.00          ; set maximum instantaneous speed changes (mm/min)
M203 X12000.00 Y12000.00 Z3000.00 E1200.00      ; set maximum speeds (mm/min)
M201 X500.00 Y500.00 Z20.00 E250.00          ; set accelerations (mm/s^2)
M906 X2200 Y2200 Z800 E800 I30               ; set motor currents (mA) and motor idle factor in per cent

And my gcode is in a macro. I've only pasted in the parts where I set the endpoints and call the move.

; Gather current position (endpoint 0)
var X_0 = move.axes[0].machinePosition
var Y_0 = move.axes[1].machinePosition

;Calculate other endpoint (endpoint 1)
var X_1 = {var.X_0 + var.len * cos(pi * var.angle / 180)}
var Y_1 = {var.Y_0 + var.len * sin(pi *  var.angle / 180)}




;Loop while drawing the line

while iterations < {var.loops}
  G0 X{var.X_1} Y{var.Y_1} F{var.speed}
  G0 X{var.X_0} Y{var.Y_0} F{var.speed}

I also made a little simulation in Excel, based on the assumption that the only things influencing the timing of "next steps" is the velocity limited by one of three constants: max velocity, max acceleration, and max instantaneous velocity change. I also assumed the timing calc for each is based on a single previous velocity.

You can see that in the simulation, the max velocity is reached within less than 1mm of the start of the movement, not what I observed. And note that I reduced the max instantaneous velocity from the 900mm/min in the config.g to 5mm/min because I wasted to see it have some effect in the sim. Without that change, the acceleration reaches it max value in the first motor step.

I guess the root of my original post is that I'm wondering if my simulation method accurately represents what the duet fw does.

bot

@mikeabuilder Interesting. There seems to be no reason that the moves would be very limited. Your understanding of the trapezoid seems correct.

Are you able to confirm that the printhead is indeed going too slow at times, or is the displayed value on DWC the only indication of a problem?

mikeabuilder

@bot - There is not really a problem I'm trying to solve, I'm just trying to get a better understanding of the physics because I think I'll do a better job of selecting configuration parameters.

dc42

@mikeabuilder by default RRF only uses instantaneous velocity change between pairs of moves that have both XY movement and extrusion.

mikeabuilder

@dc 42 - Thanks. I was going to write a long query here asking for more details. Then I thought I'd first try fighting the windmill (reading the source code). And along the way I found a file called "Movement in RepRapFirmware" in the documentation folder of the source code and it described it all very well in a way I can undersatand, so I can proceed with my excel simulation with some confidence that I'm running close to the actual code (I won't be trying to simulate PA, Input Shaping, or anything other than a single straight line in a Cartesian system).

So, another case of RTFM saving valuable time.