TMC5160 w/SKR v1.3 using 24v causes driver shutdown during print - timing issues?

[Nandox7]

Hey,

So I was running the TMC5160 over SPI on a SKR v1.3 for quite some time without any issue. Due to a heatbed upgrade I moved to a 24v PSU and problems started.

Using the exact same klipper settings and same exact gcode that printed well before. Few minutes into the print (1 or 2) one of the axis drivers shutdown in error, either Y or X.

Example from the DUMP_TMC command for the Y driver example. [After ERROR] 11:55:47.966: // ========== Write-only registers ========== 11:55:47.966: // COOLCONF: 00020000 sgt=2 11:55:47.966: // IHOLD_IRUN: 00060303 IHOLD=3 IRUN=3 IHOLDDELAY=6 11:55:47.967: // PWMCONF: c40d001e PWM_OFS=30 pwm_freq=1 pwm_autoscale=1 pwm_autograd=1 PWM_REG=4 PWM_LIM=12 11:55:47.967: // TPOWERDOWN: 0000000a TPOWERDOWN=10 11:55:47.967: // ========== Queried registers ========== 11:55:47.971: // GCONF: 00000004 en_pwm_mode=1 11:55:47.974: // CHOPCONF: 14410153 toff=3 hstrt=5 hend=2 tbl=2 tpfd=4 MRES=4(16usteps) intpol=1 11:55:47.980: // GSTAT: 00000007 reset=1(reset) drv_err=1(ErrorShutdown!) uv_cp=1(Undervoltage!) 11:55:47.986: // DRV_STATUS: 81036000 s2vsb=1 stealth=1 CSACTUAL=3 stallGuard=1 stst=1 11:55:47.991: // FACTORY_CONF: 0000000c FACTORY_CONF=12 11:55:47.995: // IOIN: 300000c0 SD_MODE=1 SWCOMP_IN=1 VERSION=0x30 11:55:47.999: // LOST_STEPS: 00000000 11:55:48.003: // MSCNT: 000000e8 MSCNT=232 11:55:48.007: // MSCURACT: 002300f4 CUR_A=244 CUR_B=35 11:55:48.011: // OTP_READ: 0000000c OTP_FCLKTRIM=12 11:55:48.015: // PWM_SCALE: 00000014 PWM_SCALE_SUM=20 11:55:48.019: // PWM_AUTO: 000d009f PWM_OFS_AUTO=159 PWM_GRAD_AUTO=13 11:55:48.023: // TSTEP: 000fffff TSTEP=1048575 11:55:48.023: ok

GSTAT: 00000007 reset=1(reset) drv_err=1(ErrorShutdown!) uv_cp=1(Undervoltage!)

I could assume it would be some hardware issue but after testing many things ended up installing marlin and it works fine with it. So it has to be a software (or driver configuration - more about it bellow).

I did noticed when setting Marlin that it includes settings for trinamic depending on the voltage so it leads me to conclude that either the drivers or the controller will work differently depending on the supply voltage. I'd expect that for the currents but check briefly scanning the code it also change other parameters.

/**

• Optimize spreadCycle chopper parameters by using predefined parameter sets
• or with the help of an example included in the library.
• Provided parameter sets are
• CHOPPER_DEFAULT_12V
• CHOPPER_DEFAULT_19V
• CHOPPER_DEFAULT_24V
• CHOPPER_DEFAULT_36V
• CHOPPER_PRUSAMK3_24V // Imported parameters from the official Prusa firmware for MK3 (24V)
• CHOPPER_MARLIN_119 // Old defaults from Marlin v1.1.9
• Define you own with
• { <off_time[1..15]>, <hysteresis_end[-3..12]>, hysteresis_start[1..8] } */

  define CHOPPER_TIMING CHOPPER_DEFAULT_24V

So it seems there are some timing issues that should be accounted for when using higher voltage supply, so far I did not find such settings in klipper.

[klipper-gitissuebot]

Hi @Nandox7,

It did not look like there was a Klipper log file attached to this ticket. The log file has been engineered to answer common questions the Klipper developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions).

Unfortunately, too many people have opened tickets without providing the log. That consumes developer time; time that would be better spent enhancing the software. If this ticket references an event that has occurred while running the software then the Klipper log must be attached to this ticket. Otherwise, this ticket will be automatically closed in a few days.

For information on obtaining the Klipper log file see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

The log can still be attached to this ticket - just add a comment and attach the log to that comment.

Best regards, ~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[Arksine]

The timing configuration is available in Klipper. In marlin it appears that CHOPPER_TIMING is referring to the TOFF, HEND, and HSTRT registers,

#define CHOPPER_DEFAULT_12V  { 3, -1, 1 }
#define CHOPPER_DEFAULT_19V  { 4,  1, 1 }
#define CHOPPER_DEFAULT_24V  { 4,  2, 1 }
#define CHOPPER_DEFAULT_36V  { 5,  2, 4 }
#define CHOPPER_PRUSAMK3_24V { 3, -2, 6 }
#define CHOPPER_MARLIN_119   { 5,  2, 3 }

typedef struct {
  uint8_t toff;
  int8_t hend;
  uint8_t hstrt;
} chopper_timing_t;

static constexpr chopper_timing_t chopper_timing = CHOPPER_TIMING;

But be careful, because it appears that Marlin is offsetting the hstrt and hend values before applying:

#if HAS_DRIVER(TMC5160)
  template<char AXIS_LETTER, char DRIVER_ID, AxisEnum AXIS_ID>
  void tmc_init(TMCMarlin<TMC5160Stepper, AXIS_LETTER, DRIVER_ID, AXIS_ID> &st, const uint16_t mA, const uint16_t microsteps, const uint32_t thrs, const bool stealth) {
    st.begin();

    CHOPCONF_t chopconf{0};
    chopconf.tbl = 1;
    chopconf.toff = chopper_timing.toff;
    chopconf.intpol = INTERPOLATE;
    chopconf.hend = chopper_timing.hend + 3;
    chopconf.hstrt = chopper_timing.hstrt - 1;

Best I can tell, their settings at 24V for the TMC5160 are: driver_TOFF: 4 driver_HEND: 5 driver_HSTRT: 0

[wesk-ms]

That GSTAT error is present at all times on my SKR 1.1 Pro with TMC5160s all around. Doesn't matter if it is before homing, after homing, while printing, or immediately after turning on the printer. That error is always present...on each driver.

From what I can tell, the GSTAT register never gets initialized correctly, so it always returns a bogus status.

I'm seeing a similar issue where my Z axis stops advancing randomly during a print. In my case, the build plate stops lowering away from the nozzle. I have a coreXY printer with two nema 23 Z axis steppers driven with independent TMC5160 drivers. When the Z steppers stop working, Klipper doesn't detect any kind of error condition, so the printer still continues to print. Sometimes the Z steppers will start working 10-15 layers later, but at that point the nozzle has already knocked the print loose and has buried itself in a ton of melted filament that's still being extruded. Frustrating!!

I'm also using 24V for the steppers. The TOFF, HEND, and HSTRT registers only pertain to Spreadcycle mode and not Stealthchop. I have stealthchop_threshold set to 200 and only print at 100mm/s, so I'm always printing in Stealthchop mode (assuming Klipper is setting the TMC5160 registers correctly).

This weirdness has been reported several times now and there was a pull request that wasn't ever committed that should have fixed the GSTAT issue. Apparently, the author disengaged since the pull request was never committed and recently closed.

1952

1797

2243

Some common workarounds in these issues have been to reduce the microsteps, which makes me think there might be a data throughput issue. But I would there would be plenty of headroom using Klipper on the newer 32bit boards.

[schnello]

@Nandox7

Same problem here but not exacly the same config. TMC2208 via UART SKR Pro 1.1 Motor V: 24V

DUMP_TMC stepper_z
========== Write-only registers ==========
IHOLD_IRUN: 00081814 IHOLD=20 IRUN=24 IHOLDDELAY=8
TPOWERDOWN: 00000014 TPOWERDOWN=20
TPWMTHRS:   00000177 TPWMTHRS=375
========== Queried registers ==========
GCONF:      000001c0 pdn_disable=1 mstep_reg_select=1 multistep_filt=1
GSTAT:      00000003 reset=1 drv_err=1(ErrorShutdown!)
IFCNT:      00000005 IFCNT=5
OTP_READ:   0000000c OTP_FCLKTRIM=12
IOIN@TMC220x: 20000150 DIAG=1 PDN_UART=1 SEL_A=1(TMC220x) VERSION=0x20
FACTORY_CONF: 0000000c FCLKTRIM=12
TSTEP:      000fffff TSTEP=1048575
MSCNT:      00000144 MSCNT=324
MSCURACT:   019b00e1 CUR_A=225 CUR_B=-101
CHOPCONF:   03030053 toff=3 hstrt=5 TBL=2 vsense=1 MRES=3(32usteps)
DRV_STATUS: c0140010 s2vsa=1(LowSideShort_A!) CS_ACTUAL=20 stealth=1 stst=1
PWMCONF:    c80d0e24 PWM_OFS=36 PWM_GRAD=14 pwm_freq=1 pwm_autoscale=1 pwm_autograd=1 PWM_REG=8 PWM_LIM=12
PWM_SCALE:  0000001e PWM_SCALE_SUM=30
PWM_AUTO:   000f002f PWM_OFS_AUTO=47 PWM_GRAD_AUTO=15

But in my case i have this issue the first time after the upgrade to the latest version. ATM i checked out a 2 weeks old state and perform some test prints (c36fe76d692754d0244059a729e147c688c96062)

Edit: Testprint 1 OK Testprint 2 OK Testprint 3 OK Back to the latest Version Testprint failed...

[Nandox7]

@Arksine yep that was my first approach. Try and calculate the values from the code and I did notice that offset applied to the TMC5160. Still no luck or I just got the rest of the values wrong. So I moved ahead and installed Marlin just to get them right and to test.

Got this:

23:57:26.756: Y
23:57:26.757: GCONF 0x00:00:00:04
23:57:26.757: IHOLD_IRUN 0x00:0A:10:08
23:57:26.757: GSTAT 0x00:00:00:05
23:57:26.757: IOIN 0x30:00:00:D2
23:57:26.757: TPOWERDOWN 0x00:00:00:80
23:57:26.758: TSTEP 0x00:0F:FF:FF
23:57:26.758: TPWMTHRS 0x00:00:00:00
23:57:26.758: TCOOLTHRS 0x00:00:00:00
23:57:26.759: THIGH 0x00:00:00:00
23:57:26.759: CHOPCONF 0x14:00:82:84
23:57:26.759: COOLCONF 0x00:03:00:00
23:57:26.759: PWMCONF 0xC8:0D:0E:24
23:57:26.759: PWM_SCALE 0x00:00:00:08
23:57:26.760: DRV_STATUS 0x80:08:40:00
23:57:26.760: Testing Y connection... OK

23:59:00.359: Y
23:59:00.359: Enabled false
23:59:00.359: Set current 580
23:59:00.360: RMS current 572
23:59:00.360: MAX current 807
23:59:00.361: Run current 16/31
23:59:00.361: Hold current 8/31
23:59:00.361: Global scaler 133/256
23:59:00.361: CS actual 8/31
23:59:00.361: PWM scale 8
23:59:00.362: stealthChop true
23:59:00.362: msteps 16
23:59:00.362: tstep max
23:59:00.362: pwm
23:59:00.362: threshold
23:59:00.362: [mm/s]
23:59:00.362: OT prewarn false
23:59:00.363: off time 4
23:59:00.363: blank time 24
23:59:00.363: hysteresis
23:59:00.363: -end 2
23:59:00.363: -start 1
23:59:00.363: Stallguard thrs 3
23:59:00.364: DRVSTATUS Y
23:59:00.364: stallguard
23:59:00.364: sg_result 0
23:59:00.364: fsactive
23:59:00.364: stst *
23:59:00.364: olb
23:59:00.365: ola
23:59:00.365: s2gb
23:59:00.365: s2ga
23:59:00.365: otpw
23:59:00.365: ot
23:59:00.365: Driver registers:
23:59:00.366: Y 0x80:08:40:00
23:59:00.366: Testing Y connection... OK

In terms of timing you say Klipper has that option?

@wesk-ms the error I mention is: drv_err=1(ErrorShutdown!) the other two yes are always there.

TMC5160 datasheetstate that when there is a error to look into the DRV_STATUS register.

DRV_STATUS: 81036000 s2vsb=1 stealth=1 CSACTUAL=3 stallGuard=1 stst=1 In this case I see s2vsb=1 that states "short to supply indicator phase B "

I'm assuming this is down to the timing settings of the driver or something with klipper timings when running on 24v as with 12v it does not happen. I also have the Z loosing some steps in one side and I'm using single driver but that is over long time. In this case is quite noticeable as you her this "click" noise and the stepper stops moving. The print continues as there is no error in Klipper but of course is all going bad as i does not move out of place on the Y or X axis. I after have to restart the firmware so the driver state gets reset.

About the Stealthshop settings check if you have the latest code version I notice in the changelog a recent commit to fix a problem setting Stealthchop hreshold setting. https://github.com/KevinOConnor/klipper/commit/7d76067ff9efaf75808b05f768dfef4295251ede

[Arksine]

Marlin's "timing" settings reference the hysteresis and toff registers, so yes, you can configure those registers in Klipper. However @wesk-ms is correct, if you are running in Stealthchop mode those settings do not apply, they are used for Spreadcycle.

FWIW, its unlikely that this issue is related to throughput. Klipper pulses the step pin like it would any other driver, the SPI interface is only used during configuration and when the user initiates a query (such as DUMP_TMC). This issue sounds similar to the issue the TMC2208 has in stealthchop mode.

https://github.com/KevinOConnor/klipper/blob/master/docs/FAQ.md#my-tmc-motor-driver-turns-off-in-the-middle-of-a-print

[Nandox7]

I tried to increase the stealthchop_threshold to a value quite high.

Initial: stealthchop_threshold: 250 after stealthchop_threshold: 5000

That I believe it will prevent stealthshop from get used, done this because reading other logged issue there was reports of steps skipped when the driver makes the transition between spreadcyle <> stealthchop.

[Nandox7]

Update: Followed the same idea as @schnello and reverted to a old commit of Klipper. Went a bit far back, Dec 1st: https://github.com/KevinOConnor/klipper/commit/41dd53f62ccd94e6ebb621b7de269887182ef433

And it printed well, first full print I can do at 24v as before all attempts failed 100% of the time. Setting now to print a second time just to make sure I wasn't just lucky.

Update 2: Second print went fine as well. I'll move to a slightly newer commit to see if I can still get it printing. As well as diff the TMC and TMC5160 files to spot any big change.

[schnello]

@Nandox7 With stealthchop_threshold: 250?

[Nandox7]

Yes, This is the settings I have now, pretty much all default and that wasn't working with the latest code.

[tmc5160 stepper_y]
cs_pin: P1.15
spi_software_miso_pin: P0.5
spi_software_mosi_pin: P4.28
spi_software_sclk_pin: P0.4
diag1_pin: !P1.27
driver_SGT: 4
microsteps: 16
interpolate: True
run_current: 0.800
hold_current: 0.500
stealthchop_threshold: 250

[wesk-ms]

The stealthchop_threshold setting controls the speed at which the driver switches FROM stealthchop TO spreadcycle. Not the other way around.

Setting stealthchop_threshold: 5 would keep you in spreadcycle 100% of the time, most likely.

[Nandox7]

But I think that was the way I understood it, setting it quite high stealthchop would never be used and it would remain always in spreadcycle. I'll set to 5 in X and Y and give it a try.

Either way using last December Klipper code kept the printer printing well all day yesterday. Today I'll try to advance a bit more and use early January code to see what happens.

[schnello]

@Nandox7 If you want disable the stealthchop mode... use stealthchop_threshold: 0

stealthchop_threshold: 0
  The velocity (in mm/s) to set the "stealthChop" threshold to. 
When set, "stealthChop" mode will be enabled if the stepper motor velocity is below this value.
The default is 0, which disables "stealthChop" mode.

[GarthSnyder]

@Nandox7, you might find git bisect helpful. It automates the process of hunting for a change in behavior. You still make the determination for each commit, but git keeps track of all the bookkeeping.

[Nandox7]

@schnello ok, so is the inverse. Thanks

@GarthSnyder that will be helpful thanks. I'll check that feature. Better than my current method "visual binary search".

Quick check of tmc.py and tmc5160.py against the repo head ddin't show much. For tmc5160.py the change is minimal and for tmc.py there was the introduction of code that I uses the GSTAT register as a homing sensor. (instead of the diag1 pin for stalguard).

[BoHoehne]

I can confirm this behavior for a SKR Pro v1.1 and TMC5160. I have a titan extruder. By placing my finger between the big gear and the filament string, i recognized that the extruder motor seems to "fall asleep" on parts with little or intermited extrusion.

Funny thing is, i can wake it (the extruder) up by pushing the gear slightly.

Unable get any print done successfully.

[wesk-ms]

@BoHoehne, That is interesting. What you're describing sounds like there's little to no holding current on your extruder stepper. Is that correct?

I've noticed that while printing, I can easily rotate my Z axis ballscrews between layer changes, which shouldn't be possible due to the holding current. I believe that Klipper's default IHold setting is equal to the IRun setting, unless you specify otherwise by setting hold_current: in the config. I think we all need to test a bit more to see if this issue is related or possibly a new issue.

[BoHoehne]

@wesk-ms These are my settings: run_current: 0.85 hold_current: 0.5 microstepps: 16

[Nandox7]

@BoHoehne, sounds like a different issue. In my case the driver shuts down during print and does not move anymore. Only way to make it work again is to reset Klipper so the TMC init() process runs again, usually I do it using FIRMWARE_RESTART.

Has reference I also have a Titan extruder with a 0.9deg/step stepper. And I have it running with about the same settings. run_current: 0.8 hold_current: 0.5

[BoHoehne]

I observed the very same behavior described. The stepper driver on the extruder is also a 5160 @ 24v.

My only workaround to avoid it was to change the model to have less detail, rotate the z axis of the model and disable stealthchop entirely:

[tmc5160 stepper_x] cs_pin: PA15 spi_bus: spi3a diag1_pin: ^!PB10 microsteps: 16 run_current: 0.800 hold_current: 0.500 stealthchop_threshold: 0 sense_resistor = 0.075 driver_SGT: 2

After doing that, i ran into the problem i described earlier. The extruder being:

[tmc5160 extruder] cs_pin: PB3 spi_bus: spi3a diag1_pin: PE15 microsteps: 16 interpolate: True run_current: 0.850 hold_current: 0.500 stealthchop_threshold: 0 sense_resistor: 0.075

I event tested different microstep settings to see if the behavior changed. Only to discover that the torque applied is getting weaker when reducing the microsteps to less than 16 microsteps (strange). I also tried disabling the interpolation, which did not change anything.

To my impression the extruder "falling asleep" is kind of the little sister of extruder shutdown.

[schnello]

I performed now "some" testprints.

My result is: Bisecting: 0 revisions left to test after this (roughly 0 steps) [67b285224952749583d7bb3af3eb6397f63b492e] tmc: Query the stepper step_distance from the stepper object

After the commit 67b285224952749583d7bb3af3eb6397f63b492e iam unable to print. Can anyone confirm that?

[KevinOConnor]

After the commit 67b2852 iam unable to print. Can anyone confirm that?

Can you provide a log file from a failed print, along with the log file of a successful print? Without log files, there's very little we can do.

FYI, there was an issue with commit 67b2852 that should have been fixed with commit 7d76067f.

-Kevin

[schnello]

Attached a error log.

Log with a successful print and a log with the latest version is in work. klippy_bad.log

klippy_good.log

[schnello]

@KevinOConnor Sorry for the delay: Here the log with the latest rev and failed. Inter. point: The first print was ok but with the non default setting driver_TPOWERDOWN: 40. The second print with default driver_TPOWERDOWN was failed.

Note: all other logs are done with driver_TPOWERDOWN: 40 latestrev_bad.log

Edit: A third try with the latest rev and driver_TPOWERDOWN: 40 are failed now

[KevinOConnor]

@schnello - your drivers are tmc2208 and not tmc5160. I'd guess you're hitting the issue described at https://www.klipper3d.org/FAQ.html#my-tmc-motor-driver-turns-off-in-the-middle-of-a-print . I'm not sure what speed your print is at, but you may want to try reducing your maximum XY velocity to 100 and set the stealthchop_threshold to 110 (the stealthchop velocity needs to be larger than the [printer] max_velocity and it needs to be only slightly larger than it). You may also want to consider disabling stealthchop entirely.

-Kevin

[schnello]

@KevinOConnor I fall back again to c36fe76d692754d0244059a729e147c688c96062 and it works fine.

If i remember right i disable already also the stealthchop. Didnt help. The print himself is not a ultra fast speed. 30-60mm/s, the max is the travel speed with 90 mm/s. So from my view... its a TMC problem in the code.

Edit: Set to Vel to 100 and stealthchop_threshold to 110.. failed. Next try with stealthchop_threshold 0

[KevinOConnor]

@schnello - I've now fully reverted 67b2852 (with commit e03f75e7).

-Kevin

[schnello]

Thanks. Testprint startet and OK with the old settings.

[BoHoehne]

Ok here comes my result:

klippy.log.zip

The print was aborted after 5%, because it made no sense anymore. The hotend was not blocked at any time.

[schnello]

@BoHoehne Any reason why you use stealthchop_threshold = 30 for the first extruder and stealthchop_threshold = 0 for all others.

[BoHoehne]

Just testing whether it made a difference. The result is the same if stealthchop_threshold is 0 for the first extruder. I tested that last night.

[BoHoehne]

Just to summarize: 24v SKR Pro 1.1 5x tmc5160 1x tmc2130 (z-axis)

Logfile and foto for stealthchop_threshold=0 comming soon.

[BoHoehne]

klippy.log.zip

This is the stealthchop_threshold: 0 version. Btw i tested it with a bigtreetech 5160 v1.2 and a watterott 5160 on extruder with the same results.

[Nandox7]

Didn't had much time before but was able to test it now. Checking the code with the latest commit e03f75e is working., so far did three prints (~2hrs each) without any axis driver stopping. Before it would stop after 2/3min into the print (it would be during the same movement(s))

[BoHoehne]

Could you share your config file ?

[BoHoehne]

Unable to reproduce @Nandox7 pls share your config files.

[Nandox7]

Still convinced the problem you have is different. This is what I have per driver:

[tmc5160 stepper_y]
cs_pin: P1.15
spi_software_miso_pin: P0.5
spi_software_mosi_pin: P4.28
spi_software_sclk_pin: P0.4
diag1_pin: !P1.27
driver_SGT: 3
microsteps: 16
interpolate: True
run_current: 0.600
hold_current: 0.500
stealthchop_threshold: 5

[BoHoehne]

@Nandox7 what i meant was the extruder configuration.

I just opened a new Issue #2551 for that problem.

[Nandox7]

@BoHoehne is the same, only stealthchop_threshold I kept at 250, I'll try later with 5.

[tmc5160 extruder]
cs_pin: P1.8
spi_software_miso_pin: P0.5
spi_software_mosi_pin: P4.28
spi_software_sclk_pin: P0.4
#diag1_pin: P1.28
microsteps: 16
interpolate: True
run_current: 0.600
hold_current: 0.500
stealthchop_threshold: 250

[klipper-gitissuebot]

It appears the Klipper log file was not provided. I'm closing this now, sorry. Feel free to attach the log to this ticket sometime in the future, or create a new issue once you can provide the log file.

[Nandox7]

Dumb bot. :) How does this get re-opened while further testing is done.

[Boffgithub]

@Nandox7 I think you tagged the wrong person :o)

[Mosher23]

so i have same issue. i have skr 1.4 with 5 TMC5160 and 2 Drivers connected to 2 Z steppers turn off during printing. Both of them report "Error_shutdown" klippy (1).log

[schnello]

@Mosher23 Should be solved with the latest version so update Klipper

[Mosher23]

@Mosher23 Should be solved with the latest version so update Klipper

i have installed my Klipper just yesterday

[schnello]

@Mosher23 Your log tells that the version is not up2date

Git version: 'v0.8.0-131-g00fd6223

[Nandox7]

Look into the FAQ: How to upgrade the code. https://github.com/KevinOConnor/klipper/blob/master/docs/FAQ.md#how-do-i-upgrade-to-the-latest-software

You using the latest package that is from Oct'19.

[Mosher23]

just updated the Klipper and tried printing. same issue! klippy-2.log

[wesk-ms]

Perhaps you should read the section in the FAQ about how to update Klipper to the latest software. Your most recent log still shows that you are running a build from last October. Git version: 'v0.8.0-430-gfc627ec4' CPU: 4 core ARMv7 Processor rev 3 (v7l) Python: '2.7.16 (default, Oct 10 2019, 22:02:15) \n[GCC 8.3.0]

Follow these steps: How do I upgrade to the latest software?

When you see (default, Apr 24, xx:xx:xx) in your klippy log, then you're on the latest version.

[Mosher23]

So i did it like in that FAQ and now i have 'v0.8.0-433-g9730be8e' What you are referring to is Python: '2.7.16 (default, Oct 10 2019, 22:02:15)

So perhaps you should not comment, if you have no idea