Stall detection setup - nothing but false stalls



  • Hi all,

    I've suffered a few too many skipped steps, so I'm setting up stall detection and following the guide in the wiki, except that I'm tuning in reverse order (it seems that the S parameter has the greatest impact, and tuning the M906, M211 and M566 has lesser impact).

    I started with S3, and got lots of stall warnings, so I gradually increased that parameter to S7, then S20 and now S60, but this has had no effect on the frequency of stall warnings.

    The machine is a coreXY with these motors at 1500mA. Target speeds are 150mm/s but i've also tried reducing that (via the speed factor slider) to 50% with no effect.

    Oddly, setting M915 R2 had no effect either - I expected it to pause the print when it stalled, but it didn't. It just reported the stall and kept going

    One other observation is that EVERY stall was reported on driver 0 and 1 at the same time - never one driver only.

    This doesn't feel very promising - any suggestions?

    Thanks in Advance



  • Hi,

    Suggestions?

    Yes, install hardware end stop sensors. Easy, cheap and reliable.

    Frederick



  • Hi Frederick - I'm looking to use stall detection to detect skipped steps, not for sensorless homing. Have I missed something? Are they mutually dependant? I can't have limit switches and stall detection?


  • Moderator

    Can you provide the results of M122 please?



  • Hi Phaedrux,

    I've parked this momentarily, and started another print, so I don't know how useful the M122 output will be. Here it in in any case:

    =================================

    M122
    === Diagnostics ===
    RepRapFirmware for Duet 2 WiFi/Ethernet version 2.05 running on Duet WiFi 1.02 or later + DueX5
    Board ID: 08DJM-9178L-L2MSD-6JKD6-3S86K-19D2N
    Used output buffers: 3 of 24 (20 max)
    === RTOS ===
    Static ram: 25712
    Dynamic ram: 94352 of which 28 recycled
    Exception stack ram used: 448
    Never used ram: 10532
    Tasks: NETWORK(ready,628) HEAT(blocked,1232) DUEX(suspended,160) MAIN(running,3752) IDLE(ready,160)
    Owned mutexes:
    === Platform ===
    Last reset 00:34:17 ago, cause: software
    Last software reset at 2020-11-13 10:39, reason: User, spinning module GCodes, available RAM 10540 bytes (slot 2)
    Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
    Error status: 0
    Free file entries: 9
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 3.4ms, max retries 0
    MCU temperature: min 35.1, current 36.1, max 36.7
    Supply voltage: min 11.4, current 11.5, max 12.3, under voltage events: 0, over voltage events: 0, power good: yes
    Driver 0: ok, SG min/max 0/491
    Driver 1: ok, SG min/max 0/420
    Driver 2: standstill, SG min/max not available
    Driver 3: standstill, SG min/max not available
    Driver 4: ok, SG min/max 0/72
    Driver 5: ok, SG min/max 0/568
    Driver 6: ok, SG min/max 0/488
    Driver 7: ok, SG min/max 0/1023
    Driver 8: ok, SG min/max 0/1023
    Driver 9: standstill, SG min/max not available
    Date/time: 2020-11-13 11:14:11
    Cache data hit count 4294967295
    Slowest loop: 90.29ms; fastest: 0.07ms
    I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
    === Move ===
    Hiccups: 0, FreeDm: 156, MinFreeDm: 116, MaxWait: 579021ms
    Bed compensation in use: mesh, comp offset 0.000
    === DDARing ===
    Scheduled moves: 4019, completed moves: 3996, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
    === Heat ===
    Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
    Heater 0 is on, I-accum = 0.4
    Heater 1 is on, I-accum = 0.3
    === GCodes ===
    Segments left: 1
    Stack records: 2 allocated, 0 in use
    Movement lock held by null
    http is idle in state(s) 0
    telnet is idle in state(s) 0
    file is doing "G1 X238.265 Y386.36 E0.02739" in state(s) 0
    serial is idle in state(s) 0
    aux is idle in state(s) 0
    daemon is idle in state(s) 0
    queue is idle in state(s) 0
    autopause is idle in state(s) 0
    Code queue is empty.
    === Network ===
    Slowest loop: 18.11ms; fastest: 0.01ms
    Responder states: HTTP(2) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
    HTTP sessions: 1 of 8

    • WiFi -
      Network state is running
      WiFi module is connected to access point
      Failed messages: pending 0, notready 0, noresp 0
      WiFi firmware version 1.21
      WiFi MAC address cc:50:e3:e3:b1:11
      WiFi Vcc 3.28, reset reason Turned on by main processor
      WiFi flash size 4194304, free heap 16864
      WiFi IP address 192.168.0.112
      WiFi signal strength -45dBm, reconnections 0, sleep mode modem
      Socket states: 0 4 0 0 0 0 0 0
      === Filament sensors ===
      Extruder 0: pos 1.02, errs: frame 0 parity 0 ovrun 0 pol 2 ovdue 0


  • @Gerrard said in Stall detection setup - nothing but false stalls:

    Hi Frederick - I'm looking to use stall detection to detect skipped steps, not for sensorless homing. Have I missed something? Are they mutually dependant? I can't have limit switches and stall detection?

    Sorry - my bad - I thought you were talking about sensorless homing.

    So that lead me to another question: If you get stall detection working what benefits do you see that it will provide?

    Once steps have been skipped I cannot think of anyway to get everything back in sync - is there some way?

    Thanks.

    Frederick



  • @fcwilt There's one reason why stall detection will help - see pic attached.
    If skipped steps are effectively detected I can a) pause the print to avoid wasting filament and/or b) re-home (with physical switches) the hot end carriage and continue printing.

    20201113_120954.jpg

    This mess equates to most of a roll of filament, and about 24hrs print time wasted. Both skipped, and continued printing. If they stopped when the skip was detected, then they would have been salvageable.


  • Moderator

    @Gerrard said in Stall detection setup - nothing but false stalls:

    I don't know how useful the M122 output will be. Here it in in any case:

    M122
    === Diagnostics ===
    RepRapFirmware for Duet 2 WiFi/Ethernet version 2.05 running on Duet WiFi 1.02 or later + DueX5

    That's fine. I just wanted to know what Duet and firmware you're using.

    Can you also post your full config.g and whatever macros you're using to setup the stall detection, if any.

    Is there a pause.g in your /sys folder?


  • Moderator

    @fcwilt said in Stall detection setup - nothing but false stalls:

    Once steps have been skipped I cannot think of anyway to get everything back in sync - is there some way?

    Well if the stall is detected by the driver it can either pause the print and wait for you to decide what to do or rehome XY and continue printing under the assumption that it will return to the same position as it was when originally homed before the stall.

    @Gerrard said in Stall detection setup - nothing but false stalls:

    If skipped steps are effectively detected I can a) pause the print to avoid wasting filament and/or b) re-home (with physical switches) the hot end carriage and continue printing.

    Ideally, yes, but but detecting the stall isn't as good as preventing the stall in the first place. If steps are being lost on a regular basis there's something wrong. Either motor current not adequate, mechanical binding, or prints curling up due to lack of cooling. Solving those root causes will be far more effective than detecting the stall afterwards, because if you catch it and resume, another stall could be just around the corner.

    Regardless, it can be a useful feature and it should be working. Once you share your config files we will have a better idea of what's going on.



  • @Gerrard said in Stall detection setup - nothing but false stalls:

    @fcwilt There's one reason why stall detection will help - see pic attached.
    If skipped steps are effectively detected I can a) pause the print to avoid wasting filament and/or b) re-home (with physical switches) the hot end carriage and continue printing.

    20201113_120954.jpg

    This mess equates to most of a roll of filament, and about 24hrs print time wasted. Both skipped, and continued printing. If they stopped when the skip was detected, then they would have been salvageable.

    Interesting.

    I've never had the kind of a mess while printing BUT being a cautious person I stay near the printer when powered on.

    Normally things only go wrong when you are not around - seems to be a law of the universe. 😉

    Thanks and good luck.

    Frederick



  • @fcwilt Those prints take 30-40hrs or more, so i'm not hanging around that long. The part you see in the background is almost 500mm long for reference.

    @Phaedrux
    config.g is below.


    ; Configuration file for Duet WiFi (firmware version 2.03)
    ; executed by the firmware on start-up
    ;
    ; generated by RepRapFirmware Configuration Tool v2.1.8 on Mon Mar 30 2020 11:14:18 GMT+1000 (Australian Eastern Standard Time)

    ; General preferences
    G90 ; send absolute coordinates...
    M83 ; ...but relative extruder moves
    M550 P"Point Zero CoreXY" ; set printer name

    M667 S1 ; select CoreXY mode

    ; Network
    M552 S1 ; enable network
    M586 P0 S1 ; enable HTTP
    M586 P1 S0 ; disable FTP
    M586 P2 S0 ; disable Telnet

    ; Drives
    M569 P0 S1 ; physical drive 0 goes backwards
    M569 P1 S1 ; physical drive 1 goes forwards
    M569 P5 S0 ; physical drive 5 goes backwards
    M569 P6 S0
    M569 P7 S0
    M569 P8 S0
    M569 P4 S0 ; physical drive 3 goes backwards
    M584 X1 Y0 Z5:6:7:8 E4 ; set drive mapping
    M671 X200,400,200,400 Y-60,-60,875,875 ; Set location of z leadscrews for independant bed levelling.
    M350 X16 Y16 Z16 E16 I1 ; configure microstepping with interpolation
    M92 X80.00 Y80.00 Z1600.00 E412.0 ; set steps per mm
    M566 X600.00 Y600.00 Z20.00 E1200.00 ; set maximum instantaneous speed changes (mm/min) *** PREVIOUS VALUES X&Y:600 Z12 E900
    M203 X8000.00 Y8000.00 Z400.00 E1500 ; set maximum speeds (mm/min)
    M201 X800.00 Y800.00 Z100.00 E600.00 ; set accelerations (mm/s^2) *** PREVIOUS VALUES X400 Y400.00 Z10.00 E150.00
    M204 P1200 T4000 ; print and travel acceleration
    M906 X1200 Y1200 Z800 E1200 I30 ; set motor currents (mA) and motor idle factor in per cent
    M84 S30 ; Set idle timeout
    M593 F80 ; Set Dynamic Acceleration Adjustment
    M572 D0 S0.05 ; Set extruder pressure advance
    ;M915 P0:1 S3 F1 H200 R1 ; Set up stall detection

    ; Axis Limits
    M208 X0 Y0 Z0 S1 ; set axis minima
    M208 X860 Y800 Z750 S0 ; set axis maxima

    ; Endstops
    M574 X1 Y1 Z1 S0 ; set active high endstops
    M591 D0 P5 C3 R5:120 E20.0 S1 ; Configure Laser filament sensor for extruder drive 0.

    ; Z-Probe
    M307 H3 A-1 C-1 D-1 ; disable heater on PWM channel for BLTouch
    M558 P9 H5 F120 T6000 ; set Z probe type to bltouch and the dive height + speeds
    G31 P500 X-21.6 Y9.4 Z3.2 ; set Z probe trigger value, offset and trigger height - **PREVIOUS Z VALUE = Z1.35
    M557 X40:800 Y40:760 S78 ; define mesh grid - AS DESIGNED
    ;M557 X270:530 Y270:530 S52 ; define mesh grid - FOR TESTING ONLY
    M376 H5 ; Set bed compensation taper (layers to fade out bed compensation)
    G29 S1

    ; Heaters
    M307 H0 B0 S1.00 ; disable bang-bang mode for the bed heater and set PWM limit
    M305 P0 T100000 B4138 R4700 ; set thermistor + ADC parameters for heater 0
    M143 H0 S120 ; set temperature limit for heater 0 to 120C
    M305 P1 T100000 B4138 R4700 ; set thermistor + ADC parameters for heater 1
    M143 H1 S280 ; set temperature limit for heater 1 to 280C
    M305 P2 T100000 B4138 R4700 ; set thermistor + ADC parameters for heater 1
    M143 H2 S280 ; set temperature limit for heater 1 to 280C

    ; Fans
    M106 P0 S0 I0 F25000 H1 T45 ; set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned on
    M106 P1 S1 I0 F500 H-1 ; set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned off

    ; Tools
    M563 P0 D0 H1 F0 ; define tool 0
    G10 P0 X0 Y0 Z0 ; set tool 0 axis offsets
    M563 P1 D0 H2 F0 ; define tool 1
    G10 P1 X0 Y20 Z0 ; set tool 1 axis offsets
    G10 P1 R0 S0
    G10 P0 R0 S0 ; set initial tool 0 active and standby temperatures to 0C

    ; Custom settings are not defined




  • @Phaedrux I have just aborted the last print installed 2x new Nema17 motors on A/B axis (the courier dropped them off since I posted this problem earlier this morning), they're 50% larger than the ones I had before, and using the hand-ometer they feel MUCH more firm in terms of holding torque. The whole system is quite large, so there's no surprise that the smaller motors were out classed.

    The stall detection was a hail-mary, but I think these larger motors will make the problem a non-issue - I'll know in about 30hrs...



  • @Gerrard

    M305 P0 T100000 B4138 R4700 ; set thermistor + ADC parameters for heater 0
    M305 P1 T100000 B4138 R4700 ; set thermistor + ADC parameters for heater 1
    M305 P2 T100000 B4138 R4700 ; set thermistor + ADC parameters for heater 1

    B4138 is the default and wrong for your thermistors. look up the correct value in your thermistor documentation


  • Moderator

    @Gerrard said in Stall detection setup - nothing but false stalls:

    ; Axis Limits
    M208 X0 Y0 Z0 S1 ; set axis minima
    M208 X860 Y800 Z750 S0 ; set axis maxima

    Yes that's a very large corexy machine. That will make tuning stall detection even harder as at that size you've got a lot of compliance in the belts and long extrusions. Detecting a stall during a print would be difficult.

    Hopefully your new motors are better suited and it becomes a non issue.



  • Well, I let the print run over night and awoke to find another spaghetti mess.
    I've re-tried tuning the stall detection with the bigger motors and it seems to be working better - far fewer false stalls - so I'll keep tweaking this until I'm happy.

    However, after looking long and hard at the print that failed, and the console logs, it looks as though it stalled because the z height drivers failed (overheat), and the print continued causing an inevitable crash scenario... I'll explore this a little more and post a separate thread if I can't find a solution.


  • Moderator

    Motor currents should be around 80% off rated max. Did you change the config for the new motors?

    Is the nozzle getting caught on curling print?


Log in to reply