Duet3D Logo

    Duet3D

    • Register
    • Login
    • Search
    • Categories
    • Tags
    • Documentation
    • Order
    1. Home
    2. Argo
    • Profile
    • Following 0
    • Followers 2
    • Topics 18
    • Posts 264
    • Best 58
    • Controversial 1
    • Groups 0

    Argo

    @Argo

    75
    Reputation
    48
    Profile views
    264
    Posts
    2
    Followers
    0
    Following
    Joined Last Online
    Location Germany

    Argo Unfollow Follow

    Best posts made by Argo

    • Input Shapers: 2HUMP_EI & 3HUMP_EI + Auto Tuning

      Since yesterday I'm testing Klipper at one of our printers. In particular the input shapers and their auto tuning with a ADXL345 accelerometer woke my interest.

      IMG_5303.jpeg

      It turns out my bed slinger printer (Bear Frame with Bondtech Extruder) has different resonance frequencies on each axis.

      After the auto calibration /measurement it recommended:
      Recommended shaper_type_x = 3hump_ei, shaper_freq_x = 61.4 Hz
      Recommended shaper_type_y = 2hump_ei, shaper_freq_y = 57.4 Hz

      I see there are input shapers on the way for RRF but I couldn't find exact infos what shaper will be used and if it will be possible to enter a shaper frequency for each axis separately.

      To sum it up, here are my wishes for RRF 3.4+:

      • support for a accelerometer (preferable ADXL345 as it's easy to find and buy) to measure the needed frequency. The input shapers 2HUMP_EI & 3HUMP_EI may need this as it can't be easily measured
      • Input shapers: 2HUMP_EI & 3HUMP_EI
      • separate frequencies and dampening for each axis (at the moment RRFs DAA uses the same frequency for both axis)
      posted in Firmware wishlist
      Argo
      Argo
    • RE: Firmware 3.3 beta 1 - extruder skipping steps

      I've compiled a stable 3.2.2. firmware (Duet 3 Mini 5+) with the TMC22xx.cpp fix from 3.3b1, so sensorless homing does work without loud crashing 😃
      Now, after 2-3 full days of experimenting, time to enjoy this nice new board a bit.

      If anyone needs it, here you go: https://www.file-upload.net/download-14505164/Duet3Firmware_Mini5plus.uf2.zip.html

      posted in Beta Firmware
      Argo
      Argo
    • RE: Software bundle 3.4.0 stable released!

      @dc42

      Differences I see compared to Klipper right now:

      • separate shaper frequency for each axis

      • automatic resonance testing (with a accelerometer): Klipper firmware generates vibrations from lower to higher frequencies and tests each shaper for it‘s effectiveness at each frequency. The results and recommendations are then displayed in a graph. It also recommends maximum acceleration values.
        Example:

      721e564d-2a11-405f-a5e4-4aaa59d925df-image.png https://www.klipper3d.org/img/calibrate-y.png

      posted in Firmware installation
      Argo
      Argo
    • RE: Pinda 2 probe with temperature compensation

      The PINDA 2 has 4 cables.
      White is the thermistor. You can connect it to Thermistor 2 on your Duet Wifi board.
      Black is the signal for the probe and goes into Z Probe in.
      Blue is ground an brown is +5V which you can "steal" from anywhere. I did chose to used the 5V/GRND from the expansion PINs on the board because they are right to each other.

      If you use the stock PINDA position you can use my config code:

      ; Z-Probe PINDA
      M574 Z1 S2 ; Set endstops controlled by probe
      M558 P5 C"^zprobe.in" I1 H0.7 F1000 T6000 A20 S0.005 ; PINDA
      M308 S2 P"e1_temp" A"PINDA" Y"thermistor" T100000 B3950
      G31 P1000 X23 Y5 Z0.985 	                 ; PEI Sheet Offset C0.0010 S20 H2	
      ;G31 P1000 X23 Y5 Z1.315 					; Textured Sheet Offset
      M557 X24:221 Y10:195 P9                     ; Define mesh grid
      

      As for the temperature compensation.
      For G31 there are S and C parameter available for that.

      From the documentation:

      Cnnn Temperature coefficient^2
      Snnn Calibration temperature^2
      
      2Optional parameters 'S' (temperature in oC at which the specified Z parameter is correct, default is current temperature) and 'C' (temperature coefficient of Z parameter in mm/oC, default zero) can be set. This is useful for probes that are affected by temperature. In RRF2 the bed temperature reading is used. In RRF3 you must specify which temperature sensor to use in the H parameter.
      

      Unfortunately there is no example or way described how to use those parameters exactly.
      What I did was, I chose a location where I expect no warping of the heat bed, removed the sheet and probed directly over the bottom left screw. That is the location the Prusa stock FW does also do it's temperature calibration.
      Then I did measure my Z height at 35°C, 40°C, 45°C and 50°C PINDA temperature.
      The problem then I had was that the inaccuracy wasn't linear but I think the "Temperature coefficient" parameter assumes that it is.
      That is why PRUSA does save a specific Z offest value for the specific temperatures in a table and uses it when the temperature has been reached.

      I already posted a possible solution in another thread:
      https://forum.duet3d.com/topic/13516/conditional-gcode-and-object-model-variables/64?_=1592403073563

      TL:DR

      if PINDA_Thermistor <25°C {
      G31 P1000 X23 Y5 Z0.995
      }
      else if PINDA_Thermistor >=25° AND PINDA_Thermistor <30° {
      G31 P1000 X23 Y5 Z1.005
      }
      else if PINDA_Thermistor >=30°C AND PINDA_Thermistor <35° {
      G31 P1000 X23 Y5 Z1.020
      }
      .
      . and so on...
      else {
      G31 P1000 X23 Y5 Z2.0 ; safety height
      }
      

      What we need are the variables to make proper use of the thermistor of the PINDA.

      posted in Duet Hardware and wiring
      Argo
      Argo
    • M220 - new parameter to exclude travel (non printing) moves

      At the moment M220 S20 (sets speed to 20%) does also slow down travel moves.
      But what if we could choose whether to slow down travel moves with M220 or not.
      Slowing down travel moves has a big drawback as this can increase the chance for stringing and blobs.

      For example: M220 T1
      The new parameter "T(1)" would then mean, that it does exclude travel moves. This setting can be set in config.g and when there is M220 Sxx in a gcode file it uses the set parameter (T1) from the config.g unless it gets overwritten with T0.

      Use cases would be modifier in the slicer software. For example a print has very fine details between specific layers so we could set M220 S50 for those layers but without slowing down travel moves.

      Another use case is the Palette 2 multi color unit and their Octoprint plugin. The multi material unit needs to do splices between colour changes and printing too fast may cause a failed print as the buffer cannot keep up. That's why the Plugin has a feature to slow down prints during splicing actions with M220 which does also slow down travel moves and can cause stringing / blobs.

      posted in Firmware wishlist
      Argo
      Argo
    • RE: M558 Feature request....

      @dc42

      That is what I do at the moment. Here is my workaround bit in bed.g:

      ; bed.g
      
      M574 Z1 S1 P"io6.in"						; Z endstop switch
      M558 H10 F250:100 T6000 A20 S0.003  		; Klicky Probe settings
      
      ; bed.g script
      while iterations <=1                                       	                                        ; Perform 2 passes.
      	G30 P0 X0 Y25 Z-99999 F6000 								; probe Z left front
      	G30 P1 X0 Y270 Z-99999 F6000      							; probe Z left rear
      	G30 P2 X275 Y270 Z-99999 F6000 							; probe Z right rear
      	G30 P3 X275 Y25 Z-99999 S4 F6000 						; probe Z right front
      	;G1 H2 Z5 F2600 											; raise head 4mm to ensure it is above the Z probe trigger height
      	M400 													; finish move, clear buffer
      	
      M558 H1.5 ; Probe  height to 1.5
      
      while move.calibration.initial.deviation >= 0.005                                   ; Perform additional leveling if previous deviation was over 0.01mm.
      	G30 P0 X0 Y25 Z-99999 F6000 								; probe Z left front
      	G30 P1 X0 Y270 Z-99999 F6000      							; probe Z left rear
      	G30 P2 X275 Y270 Z-99999 F6000 							; probe Z right rear
      	G30 P3 X275 Y25 Z-99999 S4 F6000 					         ; probe Z right front
      	;G1 H2 Z5 F2600 											; raise head 4mm to ensure it is above the Z probe trigger height
      	M400 													; finish move, clear buffer
      
      echo "Gantry deviation of " ^ move.calibration.initial.deviation ^ "mm obtained."
      
      
      M913 X100 Y100 Z100                   ; Z current back default
      
      
      

      You see for the first while loop I use a higher probing height so the probe won't drag over the bed.
      In M558 we do already have two F values for speed. It would be nice to also have another height which then is used with the second speed set in F. Lowering speed and height does also improve accuracy.
      Usage example: M558 F250:100 H10:1.5

      posted in General Discussion
      Argo
      Argo
    • RE: PINDA V2 thermistor configuration

      I've upped my Config. You can copy the things you need.
      https://www.file-upload.net/download-14164086/Config.zip.html

      If you intent to use the whole config: You will need to add this in your start gcode in your slicer software for the filament runout sensor:

      ; Prime Filament Sensor for Runout
      M581 P1 T2 S-1 R0 ; Filament Sensor P1 triggers Trigger2.g always (R0)  TRIGGER OFF
      M950 J1 C"nil" ; Input 1 e0 Filament Sensor 
      M591 D0 P2 C"e0stop" S1 ; Filament Runout Sensor
      

      The reason for this is that I wrote a filament autoload script and you can't have runout detection and autoload enabled at the same time without conditional code.

      For the PINDA:
      Black is the signal for the probe and goes into Z Probe in.
      I connected 5V and GRND to the expansion port pins.
      Thermistor is connected to E1

      You can read out the PINDA thermistor temperature but we'll have to wait for conditional code being implemented as the temperature compensation feature as it is right now assumes that the inaccuracy is linear.

      posted in Duet Hardware and wiring
      Argo
      Argo
    • RE: Input Shapers: 2HUMP_EI & 3HUMP_EI + Auto Tuning

      @cncmodeller

      Yes that's the sensor.

      Input shaper ZVD(D) paper:
      https://www.researchgate.net/publication/316556412_INPUT_SHAPING_CONTROL_TO_REDUCE_RESIDUAL_VIBRATION_OF_A_FLEXIBLE_BEAM

      EI2 input shaper:
      http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.465.1337&rep=rep1&type=pdf

      Most simple explanation: It basically cancels out ringing frequencies.

      @dc42
      Defining a minimum and maximum acceleration range might be good approach for input shaping.
      With Klipper's (automatic) calibration measurement you can set a "max smoothing target" as too much acceleration may lead to losing fine details. It then recommends to stay below a specific acceleration, depending on the used shaper the value differs.
      What Klipper does not offer though is to set a specific acceleration range. Meaning, if printing small details, the acceleration slows down as needed, so the shaper works properly.

      Speaking of pressure advance. Is some sort of pressure advance smoothing planned?

      posted in Firmware wishlist
      Argo
      Argo
    • RE: Issues with pressure advance since RRF 3.4

      @dc42

      Looks like I’m not alone with the issue anymore. Any news of an possible fix? And if possible, can we somehow assist in collecting more data (debug firmware with more logging?) for you to fix the issue?

      posted in General Discussion
      Argo
      Argo
    • RE: Input Shapers: 2HUMP_EI & 3HUMP_EI + Auto Tuning

      The Accelerometer saves so much time and filament finding the best frequency even for the basic DAA shaper.

      M593 off

      172857436_484248419285771_3287639408536478198_n.png

      And with DAA:

      173012038_3450598945041134_8942595974283612962_n.png

      Can't wait for the "real" shapers 🙂

      posted in Firmware wishlist
      Argo
      Argo

    Latest posts made by Argo

    • RE: Issues with pressure advance since RRF 3.4

      @Monteaup

      It seems some extruder / hotends cause issues with the PA implemenation we have atm with RRF.
      With Klipper you also would need to play around with "PA smooth time" so PA does work properly. Maybe we'll see such implementation in RRF anytime soon.

      posted in General Discussion
      Argo
      Argo
    • RE: Issues with pressure advance since RRF 3.4

      I already tested different slicers and settings also different RRF versions.

      Only thing that helped with my machine was connecting Klipper (Pi).
      I suspect that PA smooth time is the factor (feature) that is RRF missing to improve this.

      But the reasons why my bedslinger (also RRF with Duet 3 Mini) produces better corners? I don't know. My Voron (printer with the issues) uses a different kind of hotend which is also not compatible with the PID algorithm RRF uses as PID tuning only works when calibrating the hotend as heater and not as a tool But that's another issue I already reported in another thread.

      posted in General Discussion
      Argo
      Argo
    • RE: Issues with pressure advance since RRF 3.4

      @Heartleander81

      I see.

      I know from another Klipper user that he also only could get nice corners by playing around with the smooth time setting. Pressure advance alone did not help much.

      Maybe extruders / hotends are so particular nowadays that we need this setting to get nice corners?

      Here is the example from the user I'm talking about:

      unknown.png

      He has a bowden setup and needed to increase the smooth time in order to get nice corners. PA alone did not the trick.

      @dc42
      How high are the chances we might get this feature for RRF? I think this might very much help those who are having problems with PA at the moment.

      posted in General Discussion
      Argo
      Argo
    • RE: Issues with pressure advance since RRF 3.4

      @Heartleander81

      So altering the smooth time value did improve your corners and PA alone did not?

      posted in General Discussion
      Argo
      Argo
    • RE: Issues with pressure advance since RRF 3.4

      @jay_s_uk

      Did you already have the time to print a comparison between RRF and Klipper on your setup?

      posted in General Discussion
      Argo
      Argo
    • RE: Issues with pressure advance since RRF 3.4

      @CCS86

      Yes it’s far from optimal. But at least parts are usable again. Though I had Klipper flashed and it hasn’t the flaws I’m not really into using Klipper. Just a personal preference. But wouldn’t wonder if someone switches because of that.

      posted in General Discussion
      Argo
      Argo
    • RE: Issues with pressure advance since RRF 3.4

      @gnydick

      Latest official statement is that the Duet team can't reproduce the issue so I assume there won't be a fix. That's why I'm glad I found a partial fix by using Super Slicer extrusion roles:
      https://forum.duet3d.com/post/298231
      At the moment I'm using 0.052 PA for every role except perimeter which use 0.075 PA (PLA filament).

      posted in General Discussion
      Argo
      Argo
    • RE: Issues with pressure advance since RRF 3.4

      @gloomyandy

      BulgeCheck.gcode

      For Klipper itself nothing fancy.
      square corner velocity = 5 mm/s
      max feedrate = 350 mm/s
      max acceleration = 5000 mm/s

      Slicer speed settings:
      9bd79d70-e1af-4b57-bedb-6a01d69502b7-image.png

      posted in General Discussion
      Argo
      Argo
    • RE: Issues with pressure advance since RRF 3.4

      @gloomyandy

      Bumped PA up from 0.05 to 0.052. I think maybe 0.054 could be the optimal value.
      Decreased flow a tiny bit to improve top layer quality.

      image2.jpg
      (Klipper)

      The result is quite comparable to what I get with RRF with "dynamic PA" (0.05 -> 0.08).
      Sorry that I had to switch color. The bright green is empty after tons of testing.

      posted in General Discussion
      Argo
      Argo
    • RE: Issues with pressure advance since RRF 3.4

      @gloomyandy

      I can but not for weeks as it’s quite the mess here and not really safe to print unattended. 😄
      I can print the test again with adjustments to flow and PA. I’ll post the results soon.
      Inputshaping does not decrease print quality with Klipper as long you stay within the recommended acceleration settings.

      posted in General Discussion
      Argo
      Argo