Best posts made by gloomyandy

Hi in another thread (https://forum.duet3d.com/topic/25931/input-shaping-testing-and-thoughts) I reported my progress with using input shaping to deal with some of the ringing on my printer. As a result of these tests I decided to take a closer look at how klipper and RRF collect resonance data to be used as the basis for analysis of ringing and to help a user configure input shaping. Hopefully this will provide some useful input to @DC42 and @mfs12 in the production of the RRF input shaper plugin.

So both systems basically run some sort of movement to excite resonances in the printer and use an accelerometer to collect the data, In particular:

• RRF performs a simple linear move at the maximum current movement speed and when that move stops it then collects typically 1000 samples (taking less than a second) which is about 46kBytes of data.
• klipper runs what they call a resonance test that basically moves the print head from side to side a short distance ramping up the speed (and acceleration) of these movements to scan through a set of frequencies (the default range is 5 to 133Hz). This generates about 130 seconds worth of data, which is typically 170,000 samples, 3.6MBytes of data.

To allow comparison of the two I created a script that generates a klipper style set of movements to allow me to record a set of sample use RRF.

I collected two sets of data on my CoreXY printer. The first graph shows the RRF FFT results:

The second is the klipper style data:

As can be seen the give very different results!

I also modified the sample files to allow them to be processed by the klipper calibrate_shaper.py script. For the RRF style data it gave:

The klipper style data gives:

With such different outcomes it is hard to really decide which is correct. I've not tested the recommendation based on the klipper style data (RRF does not currently support the ei shaper). However based on my previous tests (and on measuring the ringing on the prints), the main visible problem is the hump that can be seen around 40Hz on the klipper style data. Some further thoughts and comments....

• Looking at the raw samples the current RRF data set only has a very small number of actual "real" values, in the file shown here only the first 100 points are above the noise floor. I'm not sure if this is really enough data to allow for an accurate analysis of what is happening over the given frequency range.
• The current input shaper plugin performs the test using the maximum movement speed, in my case this was 200mm/s. I'm not sure that this is a good idea. On my machine this introduces a considerable amount of energy into the frame of the printer such that it rocks. I'm pretty sure that this is responsible for the very low frequency peaks shown in the output. Reducing the maximum speed gives a different output (with not such a large low frequency peak), but has even fewer samples above the noise.
• To check that the "klipper" data was working correctly I monitored the test using a "spectrum analyser" app on my phone and it did indeed show a rising frequency from around 5Hz to 133Hz. So I think it is working correctly.
• To allow me to collect the larger volume of data needed for the klipper runs I had to modify RRF (in this case the STM32 port) to allow more than 64K of samples and also to fix an overflow problem in the data rate calculation when there are a large number of samples being saved.

I will continue to investigate this a little further, but I thought this data might be of interest and I'd welcome any thoughts or feedback.

A quick update. In a previous post I mentioned

There is something a little odd going off with the generated gcode, it does not run for as long as I would expect (approx 130 seconds). I'm not totally sure why, it could be because at the higher frequencies the movement is very small. It may be that jerk has some impact. I'm not sure if this problem is due to my script or the original klipper code.

Jerk does indeed have some impact but that was not the major problem. After running various additional tests and trying to figure out what was going on I reached out to @dc42 and he spotted that the moves being used by this test are not printing moves (as they do not include any extrusion), but I was setting the acceleration for a printing move using M204 P<aaaa>. I have now corrected this by specifying both P and T (just in case!), in the M204 commands. With this change the gcode file now runs for the correct period. Many thanks for your help David!

This has made a small change to the collected data as shown below:

and the data as processed by klipper:

The updated script (which also includes some other small corrections) is:

var title = "Klipper style vibration test V0.3"
var axis="Y"
var datarate=1320
var stime = state.upTime
var min_freq = 5.0
var max_freq = 10000/75
var accel_per_hz = 75
var hz_per_sec = 1
var freq = var.min_freq
var max_accel = var.max_freq * var.accel_per_hz
var X = 150.0
var Y = 150.0
var sign = 1.0
var t_seg = 0
var accel = 0
var max_v = 0
var L = 0
var nX = 0
var old_freq = 0
var filename = "/gcodes/vtest_" ^ var.axis ^ ".gcode"
echo "max_accel " ^ var.max_accel ^ " min freq " ^ var.min_freq ^ " max freq " ^ var.max_freq
echo > var.filename " "
echo >>var.filename "M201 X" ^ var.max_accel ^ " Y" ^ var.max_accel
echo >>var.filename "M205 X0 Y0"
echo >>var.filename "G91"
echo >>var.filename "M400"
echo >>var.filename "G4 S1"
echo >>var.filename "M956 P0 A0 S" ^ (var.max_freq - var.min_freq) * var.datarate * var.hz_per_sec 

echo "Testing " ^ floor(var.freq)
echo >> var.filename "echo " ^ var.freq
while var.freq < var.max_freq + 0.000001
	set var.t_seg = 0.25 / var.freq
	set var.accel = var.accel_per_hz * var.freq
	set var.max_v = var.accel * var.t_seg
	echo >>var.filename "M204 P" ^ var.accel ^ " T" ^ var.accel
	set var.L = 0.5 * var.accel * (var.t_seg*var.t_seg)
	set var.nX = (var.sign * var.L)
	echo >>var.filename "G1 " ^ var.axis ^ var.nX ^ " F" ^ var.max_v*60
	echo >>var.filename "G1 " ^ var.axis ^ -var.nX
	set var.sign = -var.sign
	set var.old_freq = var.freq
	set var.freq = var.freq + (2. * var.t_seg * var.hz_per_sec)
	if floor(var.freq) > floor(var.old_freq)
		;echo >> var.filename "echo " ^ floor(var.freq)
		echo "Testing " ^ floor(var.freq)
echo >>var.filename "G90"	
echo "total time " ^ state.upTime - var.stime

From the M671 documentation....

The X and Y coordinates in M671 are measured from the origin X0,Y0 set by M208. Measure to the pivot
point of the bed where it connects to the Z axis. This is often each leadscrew, but may also be offset from
the leadscrew if the bed rests on a carriage extending out from the leadscrew.

@mfs12 Here is the script. It is pretty much a simple translation of the klipper code. A few notes:

• I originally hoped to just have it drive the printer, but the script was too slow (at least in SBC mode), so instead it generates a gcode file that you then need to print.
• I modified it to use relative coordinates so that you can just position the print head before you run the script.
• There is something a little odd going off with the generated gcode, it does not run for as long as I would expect (approx 130 seconds). I'm not totally sure why, it could be because at the higher frequencies the movement is very small. It may be that jerk has some impact. I'm not sure if this problem is due to my script or the original klipper code.
• If you want to use it to collect acceleration data you will need a modified version of RRF that allows more than 64K samples to be collected and that fixes the overflow bug in the data rate calculation.
• Use it with care, and be ready to hit emergency stop!

var title = "Klipper style vibration test V0.2"
var axis="X"
var datarate=1320
var stime = state.upTime
var min_freq = 5.0
var max_freq = 10000/75
var accel_per_hz = 75
var hz_per_sec = 1
var freq = var.min_freq
var max_accel = var.max_freq * var.accel_per_hz
var X = 150.0
var Y = 150.0
var sign = 1.0
var t_seg = 0
var accel = 0
var max_v = 0
var L = 0
var nX = 0
var old_freq = 0
echo "max_accel " ^ var.max_accel ^ " min freq " ^ var.min_freq ^ " max freq " ^ var.max_freq
echo > "/gcodes/vtest.gcode" " "
;echo >>"/gcodes/vtest.gcode" "G1 X" ^ var.X ^ " Y" ^ var.Y
echo >>"/gcodes/vtest.gcode" "M201 X" ^ var.max_accel ^ " Y" ^ var.max_accel
echo >>"/gcodes/vtest.gcode" "G91"
echo >>"/gcodes/vtest.gcode" "M400"
echo >>"/gcodes/vtest.gcode" "G4 S1"
echo >>"/gcodes/vtest.gcode" "M956 P0 A0 S" ^ (var.max_freq - var.min_freq) * var.datarate * var.hz_per_sec 

;G1 X{var.X} Y{var.Y}
echo "Testing " ^ var.freq
while var.freq < var.max_freq + 0.000001
	set var.t_seg = 0.25 / var.freq
	set var.accel = var.accel_per_hz * var.freq
	set var.max_v = var.accel * var.t_seg
	;echo >>"/jobs/vtest.gcode" "M204 P" ^ {var.accel}
	echo >>"/gcodes/vtest.gcode" "M204 P" ^ var.accel
	set var.L = 0.5 * var.accel * (var.t_seg*var.t_seg)
	set var.nX = (var.sign * var.L)
	;echo "freq " ^ var.freq ^ " t_seg " ^ var.t_seg ^ " accel " ^ var.accel ^ " max_v " ^ var.max_v ^ " L " ^ var.L ^ " nX " ^ var.nX ^ " {nX} " ^ {var.nX}
	;echo >>"vtest.gcode" "G1 X" ^ {var.nX} ^ " F" ^ {var.max_v*60}
	echo >>"/gcodes/vtest.gcode" "G1 X" ^ var.nX ^ " F" ^ var.max_v*60
	echo >>"/gcodes/vtest.gcode" "G1 X" ^ -var.nX
	set var.sign = -var.sign
	set var.old_freq = var.freq
	set var.freq = var.freq + (2. * var.t_seg * var.hz_per_sec)
	if floor(var.freq) > floor(var.old_freq)
		echo "Testing " ^ var.freq 
echo >>"/gcodes/vtest.gcode" "G90"	
echo "total time " ^ state.upTime - var.stime

@pfn There are quite a few fixes post beta6: https://github.com/Duet3D/RepRapFirmware/commits/3.4-dev

Some of these may impact the problem you are seeing...
https://github.com/Duet3D/RepRapFirmware/commit/37b4e02726993763b477181b6aa918089e2210b4
https://github.com/Duet3D/RepRapFirmware/commit/1e0e6c99252dee6aa20194f212aca3be6e68415a

0 dc42 committed to Duet3D/RepRapFirmware

Fixed heater fault detection while heating up

Also shortened the M307 response so that it fits in the reply buffer

0 dc42 committed to Duet3D/RepRapFirmware

Fixed bug in calculation of heater PID parameters

@o_lampe It looks like the code for this will be on the 3.5-dev repo. I will at some point be picking that code up and providing an STM32 version, so hopefully we will be able to contribute to the testing of this new feature. I usually try to track new developments reasonably closely so hopefully it will be possible to do that again.

@Kiolia You may want to keep any eye on these two threads:
https://klipper.discourse.group/t/modification-of-pressure-advance-for-high-speed-bowden-printers/13053/13
https://klipper.discourse.group/t/pressure-advance-smooth-time-skews-pressure-advance/13451

It would seem that the jury is still out on PA smoothing at higher speeds....

@dc42 There is a further 32K that is used for NVM emulation to hold the stack/registers after a reset. This is rather wasteful but on the chips we currently support not really an issue.

Some other things are also a little different in that we have additional code to support any mixture of TMC2208/2209/5160 drivers. A software based UART (for TMC drivers) and software SPI. I'm also pretty sure that our CoreN2G has rahter more in it than strictly needed.

@droftarts As a further data point I use E3D 0.9 steppers with both TM2209 and TMC5160 drivers on a coreXY setup. In both cases I'd say that although they work for me, they are certainly much noisier than the 1.8 motors they replaced and it was also much harder to get sensorless homing configured with them, the range of settings in which the motor would actually move but would also stall when needed seemed to be much smaller.

I operate the drives in Stealthchop all of the time at relatively modest speeds. Print speed max 60mm/S non print moves max 200mm/S. I'm running lower steps/mm than those quoted here mine are 180steps/mm.

All of the above testing was using the RRF STM32F4 port on a Bigtreetech SKR Pro.

@Toastinator Probably best to follow DC42's request and create a new thread for your problem.

@joergs5 The current source already contains code to allow various features to be optional including some of these kinematics:
https://github.com/Duet3D/RepRapFirmware/blob/3.4-dev/src/Movement/Kinematics/HangprinterKinematics.cpp#L10

/*
 * HangprinterKinematics.cpp
 *
 *  Created on: 24 Nov 2017
 *      Author: David
 */

#include "HangprinterKinematics.h"

#if SUPPORT_HANGPRINTER

By default these optional items are enabled:
https://github.com/Duet3D/RepRapFirmware/blob/3.4-dev/src/Config/Pins.h#L221

// Optional kinematics support, to allow us to reduce flash memory usage

....

#ifndef SUPPORT_HANGPRINTER
# define SUPPORT_HANGPRINTER	1
#endif

So it is just a case of disabling (or enabling) the support in the board configuration files (or build system), so for instance the Duet3Mini4 build has some/all of them disabled:

// Disable the kinematcs we don't need to save flash memory space
#define SUPPORT_LINEAR_DELTA	0
#define SUPPORT_ROTARY_DELTA	0
#define SUPPORT_POLAR			0
#define SUPPORT_SCARA			0
#define SUPPORT_FIVEBARSCARA	0
#define SUPPORT_HANGPRINTER		0

Of course as time goes on the problem may be finding a combination of settings that supports all of the features you want but that still fits in flash memory.

@BDPrinters Did you remove the S0 from the G30 command in your homez.g file?

@ajdtreyd said in Comparing klipper and RRF input shaper data collection:

When viewing the resulting .csv file in the Accelerometer plugin the sampling rate (from the last line of the csv file) is auto-set to 28. This is too low and the "Analyze" button does not activate (the minimum appears to be 400). I assume I should change this to 1320 (from "var datarate=1320" in the script) but I have to wonder why the M956 command is writing "Rate 28" to the end of the csv.

See my notes above:
"To allow me to collect the larger volume of data needed for the klipper runs I had to modify RRF (in this case the STM32 port) to allow more than 64K of samples and also to fix an overflow problem in the data rate calculation when there are a large number of samples being saved."

What you are seeing is the effect of the overflow I mentioned in this. I've drawn it to DC42's attention and hopefully it will be fixed in a future version of RRF (it will certainly be fixed in the next release of the STM32 port).

Thanks for the fix, to the variable axis code, this was a late addition and had not been tested when I posted the code!

Part two of the previous post:

As an experiment I have implemented a grbl/Klipper style junction deviation algorithm (they are both very similar, the major difference is that Klipper specifies the allowed junction deviation in terms of square corner velocity, which I think is probably a better way to express what is happening). Using this algorithm with the square corner velocity set to 5mm/s (and with the m204 settings from above) I get the following results for the square:

X 1.00e+2 Y 0.00e+0 start 0.00e+0 end 5.00e+0 ts 1.00e+2 rs 1.00e+2 acc 8.00e+3 dec 8.00e+3 dist 1.00e+2
X 1.00e+2 Y 1.00e+2 start 5.00e+0 end 5.00e+0 ts 1.00e+2 rs 1.00e+2 acc 8.00e+3 dec 8.00e+3 dist 1.00e+2
X 0.00e+0 Y 1.00e+2 start 5.00e+0 end 5.00e+0 ts 1.00e+2 rs 1.00e+2 acc 8.00e+3 dec 8.00e+3 dist 1.00e+2
X 0.00e+0 Y 0.00e+0 start 5.00e+0 end 0.00e+0 ts 1.00e+2 rs 1.00e+2 acc 8.00e+3 dec 8.00e+3 dist 1.00e+2

Here you can see that the start/end speed for the right angle corners is indeed being limited to 5mm/s (which is slower then the same corners using RRF jerk settings). If I then run the circle test:

X 1.40e+2 Y 9.02e+1 start 0.00e+0 end 6.20e+0 ts 1.50e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.66e+2
X 1.41e+2 Y 8.90e+1 start 6.20e+0 end 7.26e+1 ts 1.30e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.42e+2 Y 8.79e+1 start 7.26e+1 end 7.21e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.44e+2 Y 8.71e+1 start 7.21e+1 end 7.27e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.80e+0
X 1.46e+2 Y 8.64e+1 start 7.27e+1 end 7.20e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.47e+2 Y 8.60e+1 start 7.20e+1 end 7.25e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.80e+0
X 1.49e+2 Y 8.57e+1 start 7.25e+1 end 7.24e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.80e+0
X 1.51e+2 Y 8.57e+1 start 7.24e+1 end 7.24e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.53e+2 Y 8.60e+1 start 7.24e+1 end 7.25e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.80e+0
X 1.54e+2 Y 8.64e+1 start 7.25e+1 end 7.20e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.80e+0
X 1.56e+2 Y 8.71e+1 start 7.20e+1 end 7.25e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.58e+2 Y 8.79e+1 start 7.25e+1 end 7.25e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.80e+0
X 1.59e+2 Y 8.90e+1 start 7.25e+1 end 7.24e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.60e+2 Y 9.02e+1 start 7.24e+1 end 7.23e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.62e+2 Y 9.16e+1 start 7.23e+1 end 7.26e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.63e+2 Y 9.31e+1 start 7.26e+1 end 7.21e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.80e+0
X 1.63e+2 Y 9.47e+1 start 7.21e+1 end 7.22e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.64e+2 Y 9.64e+1 start 7.22e+1 end 7.28e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.64e+2 Y 9.82e+1 start 7.28e+1 end 7.19e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.64e+2 Y 1.00e+2 start 7.19e+1 end 7.29e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.80e+0
X 1.64e+2 Y 1.02e+2 start 7.29e+1 end 7.19e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.80e+0
X 1.64e+2 Y 1.04e+2 start 7.19e+1 end 7.28e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.63e+2 Y 1.05e+2 start 7.28e+1 end 7.22e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.63e+2 Y 1.07e+2 start 7.22e+1 end 7.21e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.62e+2 Y 1.08e+2 start 7.21e+1 end 7.26e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.80e+0
X 1.60e+2 Y 1.10e+2 start 7.26e+1 end 7.23e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.59e+2 Y 1.11e+2 start 7.23e+1 end 7.26e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.58e+2 Y 1.12e+2 start 7.26e+1 end 7.21e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.56e+2 Y 1.13e+2 start 7.21e+1 end 7.27e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.80e+0
X 1.54e+2 Y 1.14e+2 start 7.27e+1 end 7.20e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.53e+2 Y 1.14e+2 start 7.20e+1 end 7.25e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.80e+0
X 1.51e+2 Y 1.14e+2 start 7.25e+1 end 7.24e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.80e+0
X 1.49e+2 Y 1.14e+2 start 7.24e+1 end 7.24e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.47e+2 Y 1.14e+2 start 7.24e+1 end 7.25e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.80e+0
X 1.46e+2 Y 1.14e+2 start 7.25e+1 end 7.20e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.80e+0
X 1.44e+2 Y 1.13e+2 start 7.20e+1 end 7.25e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.42e+2 Y 1.12e+2 start 7.25e+1 end 7.25e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.80e+0
X 1.41e+2 Y 1.11e+2 start 7.25e+1 end 7.24e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.40e+2 Y 1.10e+2 start 7.24e+1 end 7.23e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.38e+2 Y 1.08e+2 start 7.23e+1 end 7.25e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.37e+2 Y 1.07e+2 start 7.25e+1 end 7.32e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.77e+0
X 1.37e+2 Y 1.05e+2 start 7.32e+1 end 7.12e+1 ts 1.41e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.82e+0
X 1.36e+2 Y 1.04e+2 start 7.12e+1 end 7.28e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.36e+2 Y 1.02e+2 start 7.28e+1 end 7.19e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.36e+2 Y 1.00e+2 start 7.19e+1 end 7.29e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.80e+0
X 1.36e+2 Y 9.82e+1 start 7.29e+1 end 7.19e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.80e+0
X 1.36e+2 Y 9.64e+1 start 7.19e+1 end 7.28e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.37e+2 Y 9.47e+1 start 7.28e+1 end 7.12e+1 ts 1.40e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.79e+0
X 1.37e+2 Y 9.31e+1 start 7.12e+1 end 7.33e+1 ts 1.41e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.82e+0
X 1.38e+2 Y 9.17e+1 start 7.33e+1 end 7.65e+1 ts 1.38e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.67e+0
X 1.40e+2 Y 9.02e+1 start 7.65e+1 end 0.00e+0 ts 1.34e+2 rs 1.50e+2 acc 8.00e+3 dec 8.00e+3 dist 1.89e+0

The start/end speeds are now much more consistent (for why they are not identical see below), as is the top speed. I tried to choose the square corner velocity setting to make the speeds match the speeds obtained using RRF on the circle test as well as I could, which on my printer produces "smooth sounding motion", interestingly this ended up being the value that Klipper uses by default.

I'm not totally sure what to conclude from this. Personally I think that junction deviation provides a better overall way of managing the velocity at a junction than the current RRF jerk system, with a slower speed being used at sharper corners and a more consistent speed on the shallow corners of the circle. I appreciate that the curve used may not be "correct" for all printers, but the nice thing about the grbl algorithm is that it seems to be reasonably efficient (and has been tested on a wide variety of machines). If we plan to replace jerk I'd certainly suggest that we use something that can be applied to the velocity of the move rather than to the motors/drivers (though perhaps the current jerk mechanism could be used as a per motor upper limit rather like m201 acceleration is used when combined with M204 limits).

NOTE 1: I'm currently not 100% sure why the start/end speeds are not identical when using the junction deviation code. I suspect it is mainly down to the variation in segment length (this circle was taken from slicer generated gcode). It may also possibly be caused by the type of approximation used by the grbl based code?

Note 2: Amusing to see that it looks like the forum considers "jerk" to be a "rude" word!

@jayt In your M203 and M566 line you have E9000.00:E9000.00 (note two "E"s), I think that should be E9000.00:9000.00
You may also want to post your config.g file so folks can check it.

@cdoe A quick update, it looks like this is actually a bug in RRF. The rp2040 expansion boards are actually operating in pio mode, but RRF is losing track of that information. It's only obvious if you have a rp2040 based board or are using a mainboard in expansion mode. Current Duet toolboards do not use dma for the led output so they will generate a pause anyway.

The fix is here: https://github.com/Duet3D/RepRapFirmware/commit/5127e951e9b89b9d213de74b66e0dfc261a8ea40 and should be included in furure releases.

However it is almost certainly a good idea to reduce how often you set the led state if you can.

0 dc42 committed to Duet3D/RepRapFirmware

Fixed clearing of DMA-capable flag in M150 to CAN-connected boards

@baird1fa Looking at the source code it would seem that the maximum feedrate for a G0 move is indeed fixed at 18000mm/min. See the code here:https://github.com/Duet3D/RepRapFirmware/blob/3.4-dev/src/GCodes/GCodes.cpp#L1497

// Set up the extrusion and feed rate of a move for the Move class
// 'moveBuffer.moveType' and 'moveBuffer.isCoordinated' must be set up before calling this
// 'isPrintingMove' is true if there is any axis movement
// Returns nullptr if this gcode is valid so far, or an error message if it should be discarded
const char * GCodes::LoadExtrusionAndFeedrateFromGCode(GCodeBuffer& gb, bool isPrintingMove) THROWS(GCodeException)
{
	// Deal with feed rate, also determine whether M220 and M221 speed and extrusion factors apply to this move
	if (moveState.isCoordinated || machineType == MachineType::fff)
	{
		moveState.applyM220M221 = (moveState.moveType == 0 && isPrintingMove && !gb.IsDoingFileMacro());
		if (gb.Seen(feedrateLetter))
		{
			gb.LatestMachineState().feedRate = gb.GetSpeed();				// update requested speed, not allowing for speed factor
		}
		moveState.feedRate = (moveState.applyM220M221)
								? speedFactor * gb.LatestMachineState().feedRate
								: gb.LatestMachineState().feedRate;
		moveState.usingStandardFeedrate = true;
	}
	else
	{
		moveState.applyM220M221 = false;
		moveState.feedRate = ConvertSpeedFromMmPerMin(DefaultG0FeedRate);	// use maximum feed rate, the M203 parameters will limit it
		moveState.usingStandardFeedrate = false;
	}

and here:https://github.com/Duet3D/RepRapFirmware/blob/3.4-dev/src/Config/Configuration.h#L221

constexpr float DefaultG0FeedRate = 18000.0;			// The initial feed rate for G0 commands after resetting the printer, in mm/min

I'm not sure where that default/maximum value comes from though. Perhaps @dc42 could comment?

Hi,
I've just noticed that the M915 documentation has...

Snnn Stall detection threshold (-64 to +63, values below -10 not recommended). Lower values make stall detection more sensitive. S3 is a good starting point for many motors.

However boards that use the TMC2209 device actually accept a value that has a range of -128 to +127 see: https://github.com/Duet3D/RepRapFirmware/blob/3.4-dev/src/Movement/StepperDrivers/TMC22xx.cpp#L996

You might also want to update the references to TMC2660 and TMC2130 to also include TMC2209 and TMC5160 (and possibly other devices if you have boards that include them).

@o_lampe @oliof The thing with projects like RRF and Klipper is that innovation tends to happen early on in a products life-cycle. At that stage it is easy to make big changes that may stop existing features from working or that cause problems for one or two of the folks that are using the software. Early in a product's lifespan the users tend to be enthusiasts and will put up with changes, they are also knowledgeable and can contribute to fixes and new features. However as time moves on if a product is successful then there are more and more users, using the product for more "important" things and those users tend not to like having things not work. It gets more and more difficult to make those big changes. More and more developer time is spent identifying and fixing issues and less on those new features.

I'd say that RRF on the Duet ecosystem is well into that later phase these days and to some degree RRF on other hardware is getting there. Marlin has probably been there for some time (and also suffers from supporting a huge range of diverse hardware). Klipper I'd say is now also now entering this phase of its lifetime. I think you can see evidence of that in terms of the main klipper repository. Getting new features and changes accepted by Kevin has become increasingly hard as he concentrates more on the bigger range of systems he has to support and is prioritising stability. You can see evidence for this in the rise of "danger-klipper" and to some degree in the number of pleas for what the route is to get new code accepted. It will also be interesting to see what happens to Klipper now we have a lot more commercial products shipping with it as standard, will the makers of those products support the firmware going forward, what do they have in place to support some of the forks they have created? It's a tricky thing to fork an open source project and keep things up to date with fixes etc. but it is also not easy to support customers who expect a product to "just work" if those customers are also pulling new updates from a project over which you have little input or control.

Having an extruder (or any driver) in spreadcycle mode all of the time may also mean that they are "hissy" when not moving, so maybe using stealthchop with a very low speed switchover is better.

Oh and don't forget that if you are using sensorless homing then the driver must be in stealthchop mode during the homing process, you can set it to other modes once homed.

I run all my drivers in stealthchop all of the time, but I don't tend to use particularly high speeds.