Duet3D Logo

    Duet3D

    • Register
    • Login
    • Search
    • Categories
    • Tags
    • Documentation
    • Order
    1. Home
    2. gloomyandy
    • Profile
    • Following 0
    • Followers 7
    • Topics 9
    • Posts 840
    • Best 215
    • Controversial 1
    • Groups 0

    gloomyandy

    @gloomyandy

    301
    Reputation
    132
    Profile views
    840
    Posts
    7
    Followers
    0
    Following
    Joined Last Online

    gloomyandy Unfollow Follow

    Best posts made by gloomyandy

    • Comparing klipper and RRF input shaper data collection

      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:
      acc2.png
      The second is the klipper style data:
      acc4.png
      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:
      acc2.png
      The klipper style data gives:
      acc4.png

      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.

      posted in Beta Firmware
      gloomyandy
      gloomyandy
    • RE: Comparing klipper and RRF input shaper data collection

      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:
      acc5.png
      and the data as processed by klipper:
      acc5.png

      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
      
      posted in Beta Firmware
      gloomyandy
      gloomyandy
    • RE: The most helpful post you'll read today

      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.
      
      posted in General Discussion
      gloomyandy
      gloomyandy
    • RE: Heater fault on heated bed because it's rising to slow.

      @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
      posted in Tuning and tweaking
      gloomyandy
      gloomyandy
    • RE: Comparing klipper and RRF input shaper data collection

      @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
      
      posted in Beta Firmware
      gloomyandy
      gloomyandy
    • RE: Beta testers for multiple motion system support

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

      posted in Beta Firmware
      gloomyandy
      gloomyandy
    • RE: Displayed incorrect values of Extruder settings

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

      posted in PanelDue
      gloomyandy
      gloomyandy
    • RE: Duet 2 Hangprinter, 5-bar Scara, Polar, Rotary Delta kinematics

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

      posted in General Discussion
      gloomyandy
      gloomyandy
    • RE: Missing Steps - Cant Print SpreadCycle StealthChop tuning help

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

      posted in Tuning and tweaking
      gloomyandy
      gloomyandy
    • RE: RepRapFirmware 3.3beta1 now available

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

      posted in Beta Firmware
      gloomyandy
      gloomyandy

    Latest posts made by gloomyandy

    • RE: Heater 1 fault: failed to read sensor: sensor open circuit

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

      posted in Duet Hardware and wiring
      gloomyandy
      gloomyandy
    • RE: [3.5.0-rc.1] Premature execution of G54/G55

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

      posted in Beta Firmware
      gloomyandy
      gloomyandy
    • RE: Quad Z Sensorless Homing + BLTouch

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

      posted in Tuning and tweaking
      gloomyandy
      gloomyandy
    • RE: Quad Z Sensorless Homing + BLTouch

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

      posted in Tuning and tweaking
      gloomyandy
      gloomyandy
    • RE: Quad Z Sensorless Homing + BLTouch

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

      posted in Tuning and tweaking
      gloomyandy
      gloomyandy
    • RE: Quad Z Sensorless Homing + BLTouch

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

      posted in Tuning and tweaking
      gloomyandy
      gloomyandy
    • RE: Quad Z Sensorless Homing + BLTouch

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

      posted in Tuning and tweaking
      gloomyandy
      gloomyandy
    • RE: Duet WiFi 2 and Duet 5 +5Mini Connect to DWC Issues

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

      posted in Duet Web Control
      gloomyandy
      gloomyandy
    • RE: Killing a stepper driver

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

      posted in Duet Hardware and wiring
      gloomyandy
      gloomyandy
    • RE: Killing a stepper driver

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

      posted in Duet Hardware and wiring
      gloomyandy
      gloomyandy