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!

@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.

@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.

@cncmodeller Perhaps you could place your M80 in a start.g file, I think that gets run before any of the gcode in the file being printed....

What exactly do you mean by having "dwc off"? In all of these tests you need to have your rPi running and connected. If you did not that would explain why G28 was not do anything when you typed it from putty. You can't use the SBC version of RRF without having the rPi/DSF connected.

It is getting pretty late here, so I've got to go.

You should probably set the option in the putty terminal settings:
Implicit CR in every LF
makes the output easier to read.

I'd still like to see the directory listing of your /opt/dsf/sd/sys directory.

Please reboot your LPC board. Make sure that DWC is connected and then connect using putty over USB (keep the rPi on and DWC running) then enter:
M111 P3 S1
M111 P16 S1
G28
M122
and post the output.

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.