gloomyandy

undefined

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.

undefined

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

undefined

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.

undefined

@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

undefined

@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

undefined

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

undefined

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

undefined

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

undefined

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

undefined

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

undefined

@MaxGyver One for @chrishamm I think.

undefined

@MaxGyver Standalone mode or SBC?

undefined

@sbNielsen You're missing semicolons in front of some of the comment lines it should look like this...

;homex.g
;called to home the X axis
 
;generated by RepRapFirmware Configuration Tool v3.3.16 on Sat Jul 01 2023 14:29:49 GMT+0200 (CEST)
G91                ; relative positioning
G1 H2 Z5 F6000     ; lift Z relative to current position
G1 H1 X-2015 F4500 ; move quickly to X axis endstop and stop there (first pass)
G1 H2 X5 F6000     ; go back a few mm
G1 H1 X-1015 F360  ; move slowly to X axis endstop once more (second pass)
G1 H2 X5 F6000     ; go back a few mm
G1 H2 Z-5 F6000    ; lower Z again
G90                ; absolute positioning

Note the ";" in front of some of the lines.

If your homey.g and homez.g files are not generating errors, compare them against your homex.g file and check those comment lines.

undefined

@sbNielsen Check the homex.g file in your sys directory. It sounds like the comment character ";" has somehow been removed from some of the lines in that file. Post the contents of the file here for folks to check.

undefined

@MaxGyver said in [3.6.0-rc.2] Code 3 move error:

With the latest binaries, the move 3 error is gone, but now my 1XD-Expansion board (YAxis) looses connection as soon as the printhead moves to print a couple of very short segments (Text) in the first layer.

That sounds like possibly a different problem (though maybe related). Can you post the output from running M122 b# (where # is the board number that lost connection). Hopefully that may provide some clues as to what is going on.

undefined

@droftarts phase disconnection is mentioned here:

Driver warning (e.g. over temperature warning, or phase disconnected, or closed loop driver position difference warning limit exceeded)

on this page: https://docs.duet3d.com/User_manual/RepRapFirmware/Events#events

So it would seem it is indeed a warning that will trigger driver-warning.g

undefined

@dc42 It seems that the latest change has helped with this problem: https://forum.duet3d.com/topic/37913/3-6-0-rc2-error-g30-z-probe-readings-not-consistent

undefined

@caviara See this thread: https://forum.duet3d.com/topic/38033/g30-during-g28-issue It looks like there is a new build of RRF that may have a fix for the problem reported in that thread, so if removing skew correction removes the X offset, you may want to try the builds from that thread.

undefined

@caviara I hope the recovery is going well! You may want to try disabling skew correction:

M556 S100 X0.631

I think another user has reported similar issues with changes in X/Y after probing and that seems to be related to the use of M556.

undefined

@jumpedwithbothfeet If this happened today (the 14th) then the crash in your board 119 log is probably nothing to do with it (as that happened yesterday the 13th). That may have been caused by a static problem, but it is hard to be sure. The board 119 log seems to show that it had been running for almost eight hours when you produced the m122 log. I guess the question is did this happen today or yesterday (which it may not now be possible to establish)? If it happens again make a note of the times. Do you know when you started the print? If that was before 21:00 on the 13th, then it may well be that the crash then caused the CAN-FD problems.

gloomyandy

@gloomyandy

Best posts made by gloomyandy

Latest posts made by gloomyandy