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.

@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

@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

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

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

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

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

@Blackpart Has this setup been working for some time or is it a new build? Either way that error usually indicates either a problem with the wiring to the sensor or a problem with the sensor itself.

@tristanryerparke What version were you using before when this worked ok? What board are you using?

@graybilldustin I'm glad you have it working, but I'd still recommend that you use the probe to set the Z=0 point if you plan to use a bed mesh. Doing it that way will avoid a lot of potential problems with the mesh having an offset from the bed especially if you make sure the probe point you choose aligns with one of the points in the bed mesh.

@graybilldustin That is exactly what the auto levelling is designed to handle, what makes you think it is not suitable?

@graybilldustin https://docs.duet3d.com/User_manual/Connecting_hardware/Z_probe_auto_levelling

@graybilldustin said in Quad Z Sensorless Homing + BLTouch:

I am using rods, this is the first I have heard anyone mention it being harder to do than with belts. My prusa minis use sensorless homing on the Z axis with rods. What in particular makes it harder to do?

See for instance:
https://forum.duet3d.com/post/300230
https://forum.duet3d.com/topic/17314/sensorless-homing-stall-detection-lead-screw
https://www.klipper3d.org/TMC_Drivers.html#limitations

I'm sure if you spend a little time searching you will find other similar comments.

I'm still not sure why you want to home the bed this way, if you have a probe why not use that?

@graybilldustin You also don't seem to be actually setting stall detection on Z only on X and Y? Also you seem to be setting the Z position to zero with G92 Z0 but surely that will be at your max Z height if the motors have just stalled? Also If you are going to use a mesh, I'd strongly suggest that you use the probe to set your Z=0 position and ideally use one of the same points that you probe during creation of the mesh.

Finally are you using belts or threaded rods for your Z axis? Using stall detection on threaded rods can be very tricky to get working.

@JADoglio Please post the output from running M122 so we can see what the versions are of the firmware you are running. It would also probably help if you post your config.g file. Also what version of DWC are you using? What has happened to your setup since it was working ok? Have you upgraded anything? Changed the WiFi router etc? Added something new to your network? How are you reserving the IP addresses you are using for your printers to ensure that your router is not giving the same address to another device?

Do you have any other printers on the same network using RRF are they working ok?

@jens55 Did you watch the video link? Surprising what you find sometimes!

@jens55 It may not be as big a problem as people think... https://www.youtube.com/watch?v=uyWolKFzb-A

Certainly when you unplug the cable you may get a discharge and spark from the collapsing magnetic field in the motor. As to possible damage this probably comes down to how well the driver/board has been designed. See: https://electronics.stackexchange.com/questions/345003/why-does-disconnecting-a-stepper-motor-while-powered-on-damage-the-driver

I guess it depends if you are feeling lucky.