search

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.34k stars 19.26k forks source link

[BUG] StealthChop not on? #13092

Closed Core3dTech closed 5 years ago

Core3dTech commented 5 years ago

Stealthchop does not seem to come on. Installed TMC2130 on KFB2.0 board

selected TMC2130 for all 4 drivers (X/Y/Z/E0)

in configuration_adv.h have 

  #define STEALTHCHOP_XY
  #define STEALTHCHOP_Z
  #define STEALTHCHOP_E

When I run M122 I get:

        X   Y   Z   E
Enabled     false   false   false   false
Set current 604 604 800 604
RMS current 581 581 795 581
MAX current 819 819 1121    819
Run current 18/31   18/31   25/31   18/31
Hold current    9/31    9/31    12/31   9/31
CS actual       9/31    9/31    12/31   9/31
PWM scale   0   0   0   0
vsense      1=.18   1=.18   1=.18   1=.18
**stealthChop   false   false   false   false**
msteps      16  16  16  16
tstep       max max max max
pwm
threshold       0   0   0   0
[mm/s]      -   -   -   -
OT prewarn  false   false   false   false
OT prewarn has
been triggered  false   false   false   false
off time        2   2   2   2
blank time  24  24  24  24
hysteresis
-end        -2  -2  -2  -2
-start      1   1   1   1
Stallguard thrs 0   0   0   0
DRVSTATUS   X   Y   Z   E
stallguard      X   X   X
sg_result       453 416 258 0
fsactive
stst        X   X   X   X
olb     X   X   X   X
ola     X   X   X   X
s2gb
s2ga
otpw
ot
Driver registers:
        X   0xE1:09:01:C5
        Y   0xE1:09:01:A0
        Z   0xE1:0C:01:02
        E   0xE0:09:00:00

I also get the high whining that I believe is associated with SpreadCycle.

Am I missing something?

Schachner commented 5 years ago

I experience the same problem with TMC2208 drivers on X and Y axis on a MKS GEN V1.4 board. I can switch to StealthChop by sending "M569 S1 X Y" via terminal.

boelle commented 5 years ago

@Core3dTech still working on this?

Core3dTech commented 5 years ago

I'm not working on it. I just reported it as an issue. I've moved back to version 1.1.9 bug fix release. It works fine with TMC2130 8 bit board

boelle commented 5 years ago

and you used 2.0 when you reported it?

Core3dTech commented 5 years ago

Actually not sure

Core3dTech commented 5 years ago

Yes this is under the 2.0 32 bit thread

boelle commented 5 years ago

could you attach your 2 config files as a zip file?

and edit title so that it becomes [BUG]StealthChop not on?

then @thinkyhead have a small chance of trying to figure out

i know you added a small section of the config, but having both files is better

Core3dTech commented 5 years ago

attached Marlin.zip

boelle commented 5 years ago

and that is the 2.0 config?

Core3dTech commented 5 years ago

yes?? #define CONFIGURATION_H_VERSION 020000

Marlin_bugfix-2.0.x

aSpellman commented 5 years ago

Same thing here with gen L board and 2208's with the latest bugfix. Stealthchop is labeled as false. X and Y sound like they are running in stealthchop though, my E is loud as hell as it is chattering away, but that is a seperate issue I'm trying to nail down.

cad435 commented 5 years ago

This is also an Issue with ArduinoMega+RAMPS; #define STEALTHCHOP_XY/E won't enable Stealthchop, high pitched noise as mentioned could be heard.

Configuration can be found here: https://github.com/cad435/Marlin/tree/Akimbo_cad435_2.x/Marlin

cad435

wap32 commented 5 years ago

I experience the same problem with TMC2208 drivers on X and Y axis on a MKS GEN V1.4 board. I can switch to StealthChop by sending "M569 S1 X Y" via terminal.

I'm seeing the same issue. The problem seems to be that if the configuration is loaded when the power is off (and thus so are the TMC drivers), it has no effect at all. If I reload the configuration (w/ M501 or M502) after power is on, or adjust the setting live via M569, then things work as expected. The same issue is seen also when trying to get the current stepping mode via M503/M569. M569 will always report spreadCycle when power is off, and M503 will report nothing at all with power off. Example: 

Send: M81
Recv: ok P31 B3
Send: M501
[...]
Recv: echo:Driver stepping mode:
Recv: echo:ok P31 B3
Send: M569
Recv: X driver mode:    spreadCycle
Recv: Y driver mode:    spreadCycle
Recv: Z driver mode:    spreadCycle
Recv: E driver mode:    spreadCycle
Recv: ok P31 B3
Send: M80
Recv: ok P31 B3
Send: M501
[...]
Recv: echo:Driver stepping mode:
Recv: echo:  M569 S1 X Y Z
Recv:   M569 S1 T0 E
Recv: ok P31 B3
Send: M569
Recv: X driver mode:    stealthChop
Recv: Y driver mode:    stealthChop
Recv: Z driver mode:    stealthChop
Recv: E driver mode:    stealthChop
Recv: ok P31 B3

In short, when power is off, loading the settings w/ M501 shows no stepping mode and M569 wrongly reports stealthChop, and doing exactly the same after turning on the power results in the expected behavior.

I'm not too familiar with the source code, but I was curious to dig a bit deeper, and compared to 1.9, the relevant change in 2.0 seems to be that stepping mode can be changed on the fly and thus all operations on stepping mode rely on the TMCStepper library functions, en_pwm_mode(bool) to set the mode, and en_pwm_mode() to get the mode.

Looking at en_pwm_mode(bool) in TMCStepper/src/source/GCONF.cpp shows that setting the mode should be no issue, since the value is written to GCONF_register.sr, and then this is written to the driver register. Writing to the driver register will fail but this is okay since the value is stored in GCONF_register.sr and will be written out when M80 issues stepper*.push(). However, for reading the status, en_pwm_mode() will call GCONF() to get the current value, which reads the current driver register values, updates GCONF_register.sr with these values (which are invalid when power is off), and returns the relevant value. Updating GCONF_register.sr seems to be the issue here.

So, in short, if en_pwm_mode() is called with power off, any previously set pwm_mode will be overwritten to zero.

To try this out, I changed get_stealthChop_status() in tmc_util.h to not call en_pwm_mode() and instead return stored.stealthChop_enabled, and the issue disappeared. I'm sure this isn't the best solution, but it seems to prove that en_pwm_mode() is the issue.

There are other places where en_pwm_mode() is used that I did not change, for TMC_DEBUG for example, and in fact, if I call M122 with power off, then when power is turned on, stealthChop is again disabled.

EDIT: seems en_pwm_mode() is only used in tmc_util.h, where I replaced it with the stored value as mentioned above, and in tmc_util.cpp, where I pulled in powersupply_on and replaced en_pwm_mode() with (powersupply_on ? st.en_pwm_mode() : false). Now M122 doesn't disturb the stepping mode and things seem to work as expected.

ManuelMcLure commented 5 years ago

Please test this with the newest version of TMCStepper (delete your .pio directory to ensure it gets downloaded and built) and close the problem if it's fixed.

shitcreek commented 5 years ago

House cleaning. LMK if issue still exists and thread needs to be reopened.

mate-cmd commented 4 years ago

I am afraid that still problem exist:

From my config (skr 1.3+TMC2209+MARLIN-BUGFIX-2.0.X) and after that I have:

19:31:56.186 : stealthChop false false false false

JRHeaton commented 4 years ago

I am having this issue as well with the exact same hardware as @mate-cmd (TMC2209 + SKR 1.3). I am powering the board up via the power supply as in normal operation.

thinkyhead commented 4 years ago

This seems to be a problem of SKR boards being kind of sketchy. Anyway, if you want to diagnose further, you can try manipulating the power-up delay to see if it has any effect. As always, use today's bugfix for all testing.

mate-cmd commented 4 years ago

@thinkyhead Ok, I will, but, we should re-open bug or?

Core3dTech commented 4 years ago

My SKR does not exhibit this issue.

Recv: FIRMWARE_NAME:Marlin 2.0.3 (GitHub) SOURCE_CODE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:C3Dt/dz 0.19 EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
Recv: Cap:SERIAL_XON_XOFF:0
Recv: Cap:BINARY_FILE_TRANSFER:0
Recv: Cap:EEPROM:1
Recv: Cap:VOLUMETRIC:1
Recv: Cap:AUTOREPORT_TEMP:1
Recv: Cap:PROGRESS:0
Recv: Cap:PRINT_JOB:1
Recv: Cap:AUTOLEVEL:1
Recv: Cap:Z_PROBE:1
Recv: Cap:LEVELING_DATA:1
Recv: Cap:BUILD_PERCENT:0
Recv: Cap:SOFTWARE_POWER:0
Recv: Cap:TOGGLE_LIGHTS:0
Recv: Cap:CASE_LIGHT_BRIGHTNESS:0
Recv: Cap:EMERGENCY_PARSER:0
Recv: Cap:PROMPT_SUPPORT:0
Recv: Cap:AUTOREPORT_SD_STATUS:0
Recv: Cap:THERMAL_PROTECTION:1
Recv: Cap:MOTION_MODES:0
Recv: Cap:CHAMBER_TEMPERATURE:0
Recv: ok
Send: M21
Recv: echo:SD card ok
Recv: ok
Send: M155 S2
Recv: ok
Send: M20
Recv: Begin file list
Recv: JULIA_~3.GCO 11865037
Recv: TWISTE~2.GCO 521360
Recv: BABY-Y~1.GCO 25992122
Recv: JULIA_~1.GCO 11865036
Recv: DEADPO~1.GCO 12881374
Recv: TRILOG~3.GCO 1619418
Recv: TRILOG~1.GCO 917542
Recv: 2MASK_~1.GCO 11721501
Recv: 2MASKS~1.GCO 11339945
Recv: 8MASKS~1.GCO 45830851
Recv: BOTTOM~1.GCO 20042452
Recv: BOTTOM~2.GCO 13729823
Recv: BECM-M~1.GCO 6839064
Recv: BECM-X~1.GCO 8607979
Recv: BECM-X~2.GCO 5402867
Recv: BECM-X~3.GCO 5136244
Recv: End file list
Recv: ok
Send: M122
Recv:       X   Y   Z   E
Recv: Address       0   0   0   0
Recv: Enabled       false   false   false   false
Recv: Set current   900 1450    1000    800
Recv: RMS current   879 1436    962 795
Recv: MAX current   1239    2025    1356    1121
Recv: Run current   20/31   18/31   22/31   18/31
Recv: Hold current  10/31   9/31    11/31   9/31
Recv: CS actual 10/31   9/31    11/31   9/31
Recv: PWM scale 12  11  13  11
Recv: vsense        1=.18   0=.325  1=.18   1=.18
Recv: stealthChop   true    true    true    true
Recv: msteps        16  16  16  16
Recv: tstep     max max max max
Recv: pwm
Recv: threshold
Recv: [mm/s]
Recv: OT prewarn    false   false   false   false
Recv: OT prewarn has
Recv: been triggered    false   false   false   false
Recv: off time  4   4   4   4
Recv: blank time    24  24  24  24
Recv: hysteresis
Recv: -end      2   2   2   2
Recv: -start        1   1   1   1
Recv: Stallguard thrs   0   0   0   0
Recv: DRVSTATUS X   Y   Z   E
Recv: stst      *   *   *   *
Recv: olb
Recv: ola
Recv: s2gb
Recv: s2ga
Recv: otpw
Recv: ot
Recv: 157C
Recv: 150C
Recv: 143C
Recv: 120C
Recv: s2vsa
Recv: s2vsb
Recv: Driver registers:
Recv:       X   0xC0:0A:00:00
Recv:       Y   0xC0:09:00:00
Recv:       Z   0xC0:0B:00:00
Recv:       E   0xC0:09:00:00
Recv: 
Recv: 
Recv: Testing X connection... OK
Recv: Testing Y connection... OK
Recv: Testing Z connection... OK
Recv: Testing E connection... OK
JRHeaton commented 4 years ago

This seems to be a problem of SKR boards being kind of sketchy. Anyway, if you want to diagnose further, you can try manipulating the power-up delay to see if it has any effect. As always, use today's bugfix for all testing.

@thinkyhead I would like the understand the problem and the associated firmware logic at hand in more qualitative detail; if SKR boards are "sketchy," what does what mean exactly? And for which revisions? It seems to be the most widely used 32bit board due to the price and the video/blogs with guides online for configuring Marlin for SKR & TMC don't seem to have any problematic results, so I fear there may be either a single unit issue on my end, a regression in Marlin, or a user error on my part.

As for diagnosing and debugging further -- I would like to get to the root of this issue so that I can contribute back the solution, whether in knowledge, documentation, or a code fix PR so that this issue can be either eradicated or perhaps warned/guarded against. I'm not sure what the best approach is without looking at your current coding conventions within.

One important detail of my scenario is that I'm turning the board on by means of the PSU switch, no USB connection/power prior, so this is not an issue with M80 initialization. Regarding your comment about power up delay, I do see PSU_POWERUP_DELAY in the config header, but it is only enabled and applicable when you are controlling the PSU with the PS_ON pin and M80, from what I can gather. This leaves me confused on how to add some delay into the system for my use case to wait for the drivers, if this is in fact the issue.

Lastly, my drivers all but one report the same register values, and I'm not familiar with what that value actually is, but if it is supposed to be an addressable ID of some kind, this could be another issue, I'm not sure.

SENDING:M122
        X   Y   Z   E
Address     0   0   0   0
Enabled     false   false   false   false
Set current 580 580 580 650
RMS current 550 550 550 642
MAX current 776 776 776 905
Run current 17/31   17/31   17/31   20/31
Hold current    8/31    8/31    8/31    10/31
CS actual   8/31    8/31    8/31    10/31
PWM scale   10  10  10  12
vsense      1=.18   1=.18   1=.18   1=.18
stealthChop false   false   false   false
msteps      16  16  16  16
tstep       max max max max
PWM thresh. 98  98  658 283
[mm/s]      100 100 3   30
OT prewarn  false   false   false   false
triggered
 OTP        false   false   false   false
off time    4   4   4   4
blank time  24  24  24  24
hysteresis
 -end       2   2   2   2
 -start     1   1   1   1
Stallguard thrs 0   0   0   0
DRVSTATUS   X   Y   Z   E
sg_result   0   0   0   0
stst
olb
ola
s2gb
s2ga
otpw
ot
157C
150C
143C
120C
s2vsa
s2vsb
Driver registers:
        X   0x80:08:00:00
        Y   0x80:08:00:00
        Z   0x80:08:00:00
        E   0x80:0A:00:00
Testing X connection... OK
Testing Y connection... OK
Testing Z connection... OK
Testing E connection... OK

@Core3dTech Which revision SKR board do you have, and which version of Marlin? UART or SPI? And are you powering up the board with the PSU directly, or USB power + M80?

JRHeaton commented 4 years ago

@thinkyhead @Core3dTech THANK YOU BOTH in advance, I would really like to start contributing to Marlin and becoming more savvy with the code now that I'm out of work (COVID) and have a lot of extra time. I come from MacOS/iOS application development, with a history in working on bootloader exploits back in the days of old (jailbreaking). Getting very tired of frontend development and really would like to pivot to something more embedded/systems-oriented, and I think working on improving Marlin could both help me and the project :)

JRHeaton commented 4 years ago

A resolution has been reached! The problem was a small but insidious one: somehow, settings were stored in EEPROM for the motor configuration, which was overriding what was set in firmware. The user "Randell" on the Discord graciously walked me through the logic of how the firmware chooses which to configure the drivers with, and ultimately the fix was as simple as running M502; M500 and letting the firmware reconfigure things. I am so grateful for his help, and for both of your guys' help and time. I hope that this assists somebody in the future!

Core3dTech commented 4 years ago

SKR 1.3 TMC2209 UART Direct power up from PSU

thinkyhead commented 4 years ago

With the newest Marlin bugfix-2.0.x code you can set a longer power-up delay. This is meant to help with TMC steppers that take some time to get the current trickling from a cold PSU.

m4ly86 commented 4 years ago

With the newest Marlin bugfix-2.0.x code you can set a longer power-up delay. This is meant to help with TMC steppers that take some time to get the current trickling from a cold PSU.

You mean this line?

> /**
>  * Minimum delay before and after setting the stepper DIR (in ns)
>  *     0 : No delay (Expect at least 10µS since one Stepper ISR must transpire)
>  *    20 : Minimum for TMC2xxx drivers
>  *   200 : Minimum for A4988 drivers
>  *   400 : Minimum for A5984 drivers
>  *   500 : Minimum for LV8729 drivers (guess, no info in datasheet)
>  *   650 : Minimum for DRV8825 drivers
>  *  1500 : Minimum for TB6600 drivers (guess, no info in datasheet)
>  * 15000 : Minimum for TB6560 drivers (guess, no info in datasheet)
>  *
>  * Override the default value based on the driver type set in Configuration.h.
>  */
> #define MINIMUM_STEPPER_POST_DIR_DELAY 20
> #define MINIMUM_STEPPER_PRE_DIR_DELAY 20

Should I put 20 on POST and PRE dir? Sorry - I'm rockie / noob on this - just start using VSCODE and Marlin 2 days ago ;)

randellhodges commented 4 years ago

No, he is referring to this section, specifically the #define PSU_POWERUP_DELAY 250 line. Assuming you have a power supply that you can turn on/off thru your controller board. That is, you power your controller board over USB then you use the controller to turn on your main power supply (the one that supplies the big voltage to your board)

/**
 * Power Supply Control
 *
 * Enable and connect the power supply to the PS_ON_PIN.
 * Specify whether the power supply is active HIGH or active LOW.
 */
//#define PSU_CONTROL
//#define PSU_NAME "Power Supply"

#if ENABLED(PSU_CONTROL)
  #define PSU_ACTIVE_HIGH false     // Set 'false' for ATX, 'true' for X-Box

  //#define PSU_DEFAULT_OFF         // Keep power off until enabled directly with M80
  //#define PSU_POWERUP_DELAY 250   // (ms) Delay for the PSU to warm up to full power

  //#define AUTO_POWER_CONTROL      // Enable automatic control of the PS_ON pin
  #if ENABLED(AUTO_POWER_CONTROL)
    #define AUTO_POWER_FANS         // Turn on PSU if fans need power
    #define AUTO_POWER_E_FANS
    #define AUTO_POWER_CONTROLLERFAN
    #define AUTO_POWER_CHAMBER_FAN
    //#define AUTO_POWER_E_TEMP        50 // (°C) Turn on PSU over this temperature
    //#define AUTO_POWER_CHAMBER_TEMP  30 // (°C) Turn on PSU over this temperature
    #define POWER_TIMEOUT 30
  #endif
#endif
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.