Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login
    1. Home
    2. Argo
    3. Best
    • Profile
    • Following 0
    • Followers 2
    • Topics 21
    • Posts 281
    • Best 61
    • Controversial 1
    • Groups 0

    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
      Argoundefined
      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
      Argoundefined
      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
      Argoundefined
      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
      Argoundefined
      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
      Argoundefined
      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
      Argoundefined
      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
      Argoundefined
      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
      Argoundefined
      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
      Argoundefined
      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
      Argoundefined
      Argo
    • RE: Issues with pressure advance since RRF 3.4

      I've found a work around for the issue.

      Super slicer has this fancy feature called "Between extrusion role change G-Code".

      So I've added the following code for PLA:

      {if extrusion_role=~/ExternalPerimeter/};[extrusion_role]                   ;  ExternalPerimeter
      M572 D0 S0.080 ; Pressure Advance
      {elsif extrusion_role=~/Perimeter/};[extrusion_role]                        ;  Perimeter
      M572 D0 S0.080 ; Pressure Advance
      {elsif extrusion_role=~/OverhangPerimeter/};[extrusion_role]                ;  OverhangPerimeter
      M572 D0 S0.080 ; Pressure Advance
      {elsif extrusion_role=~/InternalInfill/};[extrusion_role]                   ;  InternalInfill
      M572 D0 S0.05 ; Pressure Advance
      {elsif extrusion_role=~/TopSolidInfill/};[extrusion_role]                   ;  TopSolidInfill
      M572 D0 S0.05 ; Pressure Advance
      {elsif extrusion_role=~/SolidInfill/};[extrusion_role]                      ;  SolidInfill
      M572 D0 S0.05 ; Pressure Advance
      {elsif extrusion_role=~/BridgeInfill/};[extrusion_role]                     ;  BridgeInfill
      M572 D0 S0.05 ; Pressure Advance
      {elsif extrusion_role=~/GapFill/};[extrusion_role]                     ;  GapFill
      M572 D0 S0.05 ; Pressure Advance
      {elsif extrusion_role=~/Skirt/};[extrusion_role]                     ;  Skirt
      M572 D0 S0.05 ; Pressure Advance
      {elsif extrusion_role=~/SupportMaterial/};[extrusion_role]                     ;  SupportMaterial
      M572 D0 S0.05 ; Pressure Advance
      {elsif extrusion_role=~/SupportMaterialInterface/};[extrusion_role]                     ;  SupportMaterialInterface
      M572 D0 S0.05 ; Pressure Advance
      {elsif extrusion_role=~/ThinWall/};[extrusion_role]                     ;  ThinWall
      M572 D0 S0.05 ; Pressure Advance
      {else};[extrusion_role]                     ;  Unknown generic handling
      M572 D0 S0.05 ; Pressure Advance
      {endif}
      

      Result are strong infill and sharper corners.
      The "solution" feels like a hammer though 🔨
      But at least I can use the printer again for functional parts.

      posted in General Discussion
      Argoundefined
      Argo
    • RE: Displaying current extrusion volume possible?

      +1 that’s the only thing I‘m missing right now in the web interface 🙂

      posted in Duet Web Control wishlist
      Argoundefined
      Argo
    • RE: Issues with pressure advance since RRF 3.4

      @ctilley79

      I'd say it's a 80% improvement to before and compared to my printers with Klipper or Bambu X1.
      So it was definitely a step in the right direction.

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

      Just wanted to report that with RRF 3.6 (beta) the issue is gone. Pressure Advance works as intended with input shaping.

      posted in General Discussion
      Argoundefined
      Argo
    • RE: filament-error#.g usage help? Avoid pausing on sensorerror?

      @clegg78

      I too get a sensor error every 20h or so and I did just put this into filament-error.g:

      if sensors.filamentMonitors[0]status != "sensorError"
              M25
      
      posted in Filament Monitor
      Argoundefined
      Argo
    • RE: Variable Enclosure Fans based on Temperature (no heater)

      I would use daemon.g with that and conditional gcode. Already read through the Duet documentation about the topic?

      posted in CNC
      Argoundefined
      Argo
    • RE: Mesh Bed Compensation not compensating?

      I think those limits are only for gcode commands and not for the firmware itself.
      But I'll test it anyway.

      posted in Tuning and tweaking
      Argoundefined
      Argo
    • RE: Duet 2 wifi , Duet 3 HC , Duet 3 mini 5+ which to get ?

      For a classic bendslinger printer like yours a Duet 3 Mini 5+ is imo the best choice with modern stepper drivers (TMC2209) that have StealthChop.
      Duet 2 WiFi and Duet 3 is more suitable for setups with higher current motors or more motors in general.
      Not worth the money if you don't use their possibilities and your prints won't also look better.

      posted in General Discussion
      Argoundefined
      Argo
    • RE: Filament runout switch delayed pause after tripped

      @cooknadam

      Maybe something like this?

      if sensors.gpIn[4].value == 0
      	var triggerheight = move.extruders[0].position + 200 - move.axes[2].machinePosition
      	set var.triggerheight = move.extruders[0].position + 200 - move.axes[2].machinePosition
      	while move.extruders[0].position < var.triggerheight 
      		if sensors.gpIn[4].value == 1
      			break
      	if sensors.gpIn[4].value == 0
      		M226     ; calls pause.g
      

      Needs some testing though.

      posted in Firmware wishlist
      Argoundefined
      Argo
    • RE: New Input Shaping plugin v3.4.1-b1

      Nice! Thanks a lot for the effort 🙂

      posted in Plugins for DWC and DSF
      Argoundefined
      Argo