MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.22k stars 19.22k forks source link

[BUG] [bigfix-2.0.x] SKR 1.3 Linear Advance not behaving as expected #14538

Closed coreyfaure closed 5 years ago

coreyfaure commented 5 years ago

Description

Linear Advance is not producing any good lines during the K-Factor Calibration Test on my SKR 1.3 board even though printer did produce viable lines on my previous Melzi board.

Steps to Reproduce

  1. Install TMC2208 drivers for X Y and Z. Installed A4988/DRV8825 (tested both) on E0
  2. Setup drivers and enable linear advance in Marlin configuration.
  3. Run K-factor Calibration Pattern from 0 to 0.6 in 0.02 increments.
  4. Look for the most consistent line.
  5. Use this K-Factor in a 1-perimeter test cube (no infill)

Expected behavior: I expected to find a consistent line width around the K0.1 - K0.15 area for PLA. This was a value that worked on my Melzi board.

Actual behavior: None of the lines are consistent. Even at 0.02 the line width is messy. Printing with 0.02 (the cleanest looking line, short of K0) resulted in horribly bulged corners and missing filament from the last 3 millimeters of each perimeter.

Additional Information

Image of pattern generated. Each line (starting at 0 from the bottom) moves up a 0.02 increment for the K-Factor image

Glod76 commented 5 years ago

I get the same with the mks sbase with stock drv8825s. and its a bowden setup

coreyfaure commented 5 years ago

To add some slightly better pictures, here are some slightly better contrast colors and USB microscope pics. I went down to 0.01 steps for my K value this time. I also enabled SQUARE_WAVE_STEPPING as an experiment. Neither resulted in an ideal line either.

(image was on mirror, so I blacked out line reflections to avoid visual confusion) image

Pictured: K=0 (bottom), K=0.01 (top) image

K=0.02 (bottom), K=0.03 (top) image

coreyfaure commented 5 years ago

Further testing results:

I switched off 256 step interpolation on the TMC2208s on the X and Y axis to see if anything changed. The pattern did change, but the lines were even less consistent. I saw exactly one solid line at K0.1, but when I chose the value and printed a test cube with it, I got the same nasty looking cube:

image

coreyfaure commented 5 years ago

Update: I ordered TMC2209s to eliminate the issue of the TMC2208s and the same issue is present, nothing has changed. I replaced the SKR 1.3 with a new one in case something was wrong, and this didn't fix it either. MINIMUM_STEPPER_PULSE adjustment doesn't help the issue. SQUARE_WAVE_STEPPING and S_CURVE_ACCELERATION makes no difference with this issue either.

gloomyandy commented 5 years ago

You are not going to like this, but ideally you need to switch back to your old board and try that again (ideally with the same version of Marlin) so folks can see a direct comparison.

boelle commented 5 years ago

@coreyfaure is the issue still there?

coreyfaure commented 5 years ago

@coreyfaure is the issue still there?

I'll check within the next few days if this is still an issue. I gave up on diagnosing it a while ago and just turned it off.

boelle commented 5 years ago

Lack of Activity This issue is being closed due to lack of activity. If you have solved the issue, please let us know how you solved it. If you haven't, please tell us what else you've tried in the meantime, and possibly this issue will be reopened.

coreyfaure commented 4 years ago

Apologies for the long time without an update. Life happened.

Unfortunately I can't locate my old Melzi board for testing anymore. It DID work on the ADVi3pp project by Andrivet when he enabled linear advance controls, but I have no evidence on hand to confirm that.

I just updated to the most recent version of bugfix-2.0.X and updated my TMCStepper library to 0.6.1. This is every line I changed from default:

Configuration.h changes:

#define STRING_CONFIG_H_AUTHOR "Ben's SKR 1.3 Config"
#define SERIAL_PORT -1
#define MOTHERBOARD BOARD_BIGTREE_SKR_V1_3
#define CUSTOM_MACHINE_NAME "The Creator"
#define DEFAULT_NOMINAL_FILAMENT_DIA 1.75
#define TEMP_SENSOR_BED 1
#define DEFAULT_Kp 24.72
#define DEFAULT_Ki 1.65
#define DEFAULT_Kd 92.54
#define PIDTEMPBED
#define DEFAULT_bedKp 52.96
#define DEFAULT_bedKi 4.94
#define DEFAULT_bedKd 378.87
#define X_MIN_ENDSTOP_INVERTING true
#define Y_MIN_ENDSTOP_INVERTING true
#define Z_MIN_ENDSTOP_INVERTING true
#define X_DRIVER_TYPE  TMC2209
#define Y_DRIVER_TYPE  TMC2209
#define Z_DRIVER_TYPE  TMC2209
#define E0_DRIVER_TYPE TMC2209
#define DEFAULT_AXIS_STEPS_PER_UNIT   { 160, 160, 400, 280.6 }
#define DEFAULT_MAX_FEEDRATE          { 450, 450, 20, 25 }
#define DEFAULT_MAX_ACCELERATION      { 1000, 1000, 100, 1000 }
#define DEFAULT_ACCELERATION          650
#define DEFAULT_RETRACT_ACCELERATION  800
#define DEFAULT_TRAVEL_ACCELERATION   800
#define INVERT_X_DIR true
#define INVERT_Y_DIR false
#define INVERT_Z_DIR true
#define X_BED_SIZE 184
#define EEPROM_SETTINGS 
#define PREHEAT_1_TEMP_HOTEND 215
#define PREHEAT_1_TEMP_BED     50
#define NOZZLE_PARK_FEATURE
#define PRINTCOUNTER
#define SDSUPPORT
#define REVERSE_ENCODER_DIRECTION
#define INDIVIDUAL_AXIS_HOMING_MENU
#define SPEAKER
#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

Configuration_adv.h changes:

#define X_HOME_BUMP_MM 4
#define Y_HOME_BUMP_MM 4
#define QUICK_HOME
#define LONG_FILENAME_HOST_SUPPORT
#define BABYSTEPPING
#define BABYSTEP_MULTIPLICATOR_Z  4
#define BABYSTEP_DISPLAY_TOTAL
#define LIN_ADVANCE
#define FWRETRACT
#define RETRACT_LENGTH 0.5
#define RETRACT_FEEDRATE 35
#define RETRACT_RECOVER_FEEDRATE 20
#define ADVANCED_PAUSE_FEATURE
#define FILAMENT_CHANGE_UNLOAD_LENGTH      110
#define CHOPPER_TIMING CHOPPER_DEFAULT_24V
#define MONITOR_DRIVER_STATUS
#define SQUARE_WAVE_STEPPING
#define TMC_DEBUG

Results of the update and the following config: Nothing different. Same as above problem when I first posted unfortunately.

coreyfaure commented 4 years ago

I should note that the title is no longer accurate. The extruder is now a BTT TMC2209, along with all other axis.

dp250f commented 4 years ago

I have been struggling with this issue ever since I upgraded from 1.19 on my i3 MK3S which I upgraded to a 32-bit controller. I think I finally nailed down what causes it.

I would print Marlin K calibration pattern and determine the best one (usually about 0.05). When printing things, any K factor over 0.02 would end up with terribly inconsistent line widths (like the cube coreyfaure posted on July 21).

This printer uses TMC2130's and really weak stepper motors, so Acceleration and Junction Deviation are usually set very conservatively (950, 0.05). I had been putting typical Jerk values in my slicer configs (10, 10, 2, 2.5). It occurred to me that since the firmware doesn't use those for xyz, I would put those values to equal my max travel speeds for each axis except for E (175, 175, 12, 2.5).

Long story short: setting insane jerk values in your slicer for xyz seems to fix linear advance for Marlin 2.0.x

coreyfaure commented 4 years ago

Long story short: setting insane jerk values in your slicer for xyz seems to fix linear advance for Marlin 2.0.x

Do you think you could share your configs for me? I tried upgrading to the latest firmware and setting my jerk settings to my max travel speeds but my k-factor calibration test doesn't seem to show any difference.

dp250f commented 4 years ago

I've upgraded to TMC2209 drivers, KYSAN motors, and done more experimenting since my last comment and here's what I know now: I finally got Linear Advance working at fast print speeds, while using S_Curve and Junction Deviation. I've switched from Prusa Slicer to Cura (it doesn't require jerk settings to be set) I set E_Jerk to 30mm/s and now LA works as expected, all the way up to 300mm/s print speed (0.4mm Volcano). Watching it print, even at 300mm/s , 2000 acceleration, E never actually changes velocity anywhere near that fast, but Linear Advance seems to need it set that high or it doesn't work.

coreyfaure commented 4 years ago

I just switched to using S_Curve again and junction deviation with the e_jerk set to 30. No dice for me. My calibration test looks the same. I'm just not sure what's different between my setup and yours at this point.

dp250f commented 4 years ago

Here's my Marlin 2.0.x bugfix configs for both my printers: Marlin Configs.zip

Prusa i3 MK3S with mods (can print PLA up to 300mm/s, LA set to 0.05):

Printrbot Simple Metal with mods (can print PLA up to 250mm/s, LA set to 0.07):

TheMiguelBi commented 4 years ago

Here's my Marlin 2.0.x bugfix configs for both my printers: Marlin Configs.zip

Prusa i3 MK3S with mods (can print PLA up to 300mm/s, LA set to 0.05):

  • BTT SKR 1.4 Turbo
  • 4MB ESP-01S
  • BTT TFT35 v3.0
  • BTT UPS 24V V1.0
  • UART TMC2209 drivers
  • KYSAN 1124090 Steppers
  • 0.4mm E3D Volcano
  • BLTouch

Printrbot Simple Metal with mods (can print PLA up to 250mm/s, LA set to 0.07):

  • BTT SKR Mini E3
  • BTT TFT35 v3.0 E3
  • BTT MK3 Power Panic
  • BTT miniUPS_V2.0 (12V)
  • 0.25mm E3D all metal V6
  • Gear-head extruder
  • Heated bed
  • 12V Mean Well 350W PSU

Hi dp250f, can I ask you if printing from Display BTT_TFT35 the Powerloss recovery function works correctly ?? I see that in both of your configurations you use them.

I'm going crazy getting PLR working using the BTT_TFT35_E3 graphic display with a BTT_UPS_24v. I am using Marlin bugfix-2.0.X (updated 15 days ago) on BTT_GTR card + BTT UART Driver TMC2209.

After several tests today I have come to this point: https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware/issues/644#issue-610793577 I can only operate PLR with the LCD simulation of the display. By connecting it via RS232 the Z axis does not return to the correct position and printing is lost. Thanks!

dp250f commented 4 years ago

@TheMiguelBi, I haven't tried it in host mode, but it did work in Marlin mode when printing from SD. I print in Marlin mode whenever I can since it isn't limited by a 115200 baud rate. As you can imagine, when printing really fast, things like gyroid infill will empty the buffer really quickly when printing via RS232. Also, I'm using the Prusa Power Panic for my power loss signal on both printers. BTT_UPS is used just for the caps so the printer can complete PLR moves before it runs out of juice. I had to buy IEC power plugs anyway, so I just got those with PLR functionality in mind.

TheMiguelBi commented 4 years ago

Prusa Power Panic

Thanks! I didn't know Prusa Power Panic! I hadn't asked myself the problem of Baudrate, My custom doesn't arrive at high speeds, but actually .... I liked the graphical display interface, I will re-evaluate the LCD simulation option. Thanks

github-actions[bot] commented 4 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.