M207 Zlift problem



  • Hi everyone, I'm having a possible positioning problem when I use the firmware retraction with duet wifi. The configuration of the machine is with double driver on Z axis and it would seem that one of the 2 motors loses its steps causing the extruder to block.
    I'm not sure but it seems that the problem has been with the latest updates since the P parameter was entered in M207.
    Furthermore, with the latest update (RRF3.01 RC5) it has happened on several occasions that only one motor works while moving the Z axis.
      M207 is inserted at the end of config.g (M207 S1.5 F4200 Z0.15), also I have inserted a second M207 in the filament configuration files.
    Now I have downgraded to RRF3.01 RC4 I tried to make a print that had previously failed, with Z = 0 after 7 hours of printing I had no problem.
    Is it a possible bug?


  • Moderator

    Can you post your config.g please?

    Would help to verify that your Z drivers are both getting the correct current.

    It's also possible that your Z jerk and acceleration are too high.

    Or one of the Z motors may be encountering greater mechanical resistance than the other due to binding.



  • I publish the configuration. There is no mechanical resistance of the axis, even the jerks and accelerations are reasonable, I have been printing with these parameters for months, then with M207 Z0 in RRF3.01 RC4 works well, tomorrow I would like to try with RC2 or RC3 to check if I have the same problem.
    config.g


  • Moderator

    @Marco-Bona said in M207 Zlift problem:

    tomorrow I would like to try with RC2 or RC3 to check if I have the same problem.

    Thanks



  • I confirm, the problem with M207 concerns the latest updates. I downgraded to RRF3.01 RC2 and with a print of about 45-50 minutes that had previously failed, this morning did not give any problems.
    If it can help, the error always concerns the second driver on which the axis is remapped, to clarify, it is the one that is hidden with M584 X8 Y9 Z0: 1 U5 V6 W1 E3: 4 P3, in my case it is the driver1.
    Is anyone experiencing the same problem with new builds?


  • Moderator

    @Marco-Bona This is from your config.g:

    M350 X256 Y256 Z256 W256 U16 V16 I0                        ; Configure microstepping without interpolation
    M350 E16:16 I1                                             ; Configure microstepping with interpolation
    M92 X1280.00 Y1280.00 Z12800.00 W12800.00 U37.67 V5245.90  ; Set axis steps/mm
    M92 E415:415                                               ; Set extruder 0 and 1 steps/mm                     
    M906 X2300 Y2300 Z1800 W1800 U1800 V1400 E360:360 I50      ; Set motor currents (mA) and motor idle factor in per cent
    
    ...
    
    M566 X1500.00 Y1500.00 Z200.00 W200.00 U200.00 V50.00 E1000.00:1000.0 P1         ; Set maximum instantaneous speed changes (mm/min)
    M203 X15000 Y15000 Z1200 W1200 U5000 V100 E6000:6000                             ; Set maximum speeds (mm/min)
    M201 X4000.00 Y4000.00 Z500.00 W500.00 U1500.00 V200.00 E1000.00:1000.00         ; Set accelerations (mm/s^2)
    

    You're using x256 microstepping on the main axes, with HUGE numbers of steps per mm (1280 on X and Y, 12800 on Z), and high speeds (X and Y 15000, Z 1200). More than likely this is generating hiccups, where the Duet is unable to keep up the step rate requested (which, at full speed on Z, is 1200/60 = 20mm/s * 12800 steps per mm, so 256,000 steps per second!), so slows down. During a print, send M122 and the hiccup count is in the 'Move' section:

    === Move ===
    Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms
    Bed compensation in use: none, comp offset 0.000
    

    Why hasn't this been a problem before? Because the Duet is handling it, by slowing down movement. Why has it become an issue in 3.01-RC5? I'm not sure, but I think @dc42 may have increased the step limit, and now it's able to send more steps to the Z axis per second, your motor can't cope with it. I've asked dc42 to confirm if this might be the case.

    What can you do about it? Probably the best thing is to reduce the microstepping rate. Realistically, you're not getting much better resolution with x256 microstepping than you would at x16 with interpolation on. You could also try x128 or x64.

    Let me know if that helps.

    Ian



  • I understand, but this limitation is not indicated anywhere, for this problem I was forced to replace the extruders because in all honesty I thought that the problem was due to some construction problem of the extruders, to convert the printer from bowden to direct drive and to throw away a lot of hours of prints.
    If this is really the problem, I would like these limitations to be published in the update notes in the future.


  • Moderator

    @Marco-Bona Without seeing an M122 report, I don't know if it is the problem. What I think is the main problem is that one of your Z motors can't keep up with the step rate. Test them and see what speed they stop working correctly at, by sending something like:

    G91
    G1 Z25 F200
    G1 Z-25 F200
    G1 Z25 F400
    G1 Z-25 F400
    G1 Z25 F600
    G1 Z-25 F600
    G1 Z25 F800
    G1 Z-25 F800
    G1 Z25 F1000
    G1 Z-25 F1000
    G1 Z25 F1200
    G1 Z-25 F1200
    G90
    

    Then set the Z axis maximum speed to what the axis is actually able to do. I think Z lift happens at the maximum speed/acceleration.

    @Marco-Bona said in M207 Zlift problem:

    this limitation is not indicated anywhere

    That's because it's not fixed. It depends on the mechanics of your machine, the motors you have chosen etc etc. It's not entirely within the Duets control. According to https://github.com/KevinOConnor/klipper/blob/master/docs/Features.md#step-benchmarks the Duet WiFi can generate 686,000 steps per second, but that's just a processor test, not a real world test trying to move a stepper motor.

    Ian



  • I wait for a confirmation from @dc42 and then I will see how to proceed.
    I guess this problem also applies to DUET3 boards


  • Moderator

    @Marco-Bona Please post a M122 report after some printing. Then we can see if it's the step rate that's the problem.

    Ian



  • I am publishing the current one even if I'm working with RRF3.01 RC2 and M207 Z0 out of safety. The interpolations remained all with microstepping at X256. I repeat that I am currently not experiencing any problem of losing steps.

    m122
    === Diagnostics ===
    RepRapFirmware for Duet 2 WiFi/Ethernet version 3.01-RC2 running on Duet WiFi 1.02 or later + DueX5
    Board ID: 08DGM-9T6BU-FG3SN-6J9F0-3S46M-9UYZD
    Used output buffers: 3 of 24 (20 max)
    === RTOS ===
    Static ram: 27916
    Dynamic ram: 94988 of which 56 recycled
    Exception stack ram used: 576
    Never used ram: 7536
    Tasks: NETWORK(ready,588) HEAT(blocked,1232) DUEX(suspended,136) MAIN(running,1768) IDLE(ready,76)
    Owned mutexes: WiFi(NETWORK)
    === Platform ===
    Last reset 04:56:34 ago, cause: power up
    Last software reset time unknown, reason: User, spinning module GCodes, available RAM 7856 bytes (slot 3)
    Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
    Error status: 8
    Free file entries: 9
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 21.9ms, max retries 0
    MCU temperature: min 15.4, current 16.1, max 16.4
    Supply voltage: min 23.7, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
    Driver 0: standstill, SG min/max 0/309
    Driver 1: standstill, SG min/max 0/329
    Driver 2: standstill, SG min/max not available
    Driver 3: standstill, SG min/max not available
    Driver 4: ok, SG min/max 0/1023
    Driver 5: standstill, SG min/max not available
    Driver 6: standstill, SG min/max not available
    Driver 7: standstill, SG min/max not available
    Driver 8: ok, SG min/max 0/446
    Driver 9: ok, SG min/max 0/473
    Date/time: 2020-04-01 14:06:42
    Cache data hit count 4294967295
    Slowest loop: 60.46ms; fastest: 0.14ms
    I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
    === Move ===
    Hiccups: 43985(0), FreeDm: 150, MinFreeDm: 139, MaxWait: 0ms
    Bed compensation in use: none, comp offset 0.000
    === MainDDARing ===
    Scheduled moves: 573163, completed moves: 573124, StepErrors: 0, LaErrors: 0, Underruns: 299, 0
    === AuxDDARing ===
    Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
    === Heat ===
    Bed heaters = 0 -1 -1 -1, chamberHeaters = 3 -1 -1 -1
    Heater 0 is on, I-accum = 0.9
    Heater 1 is on, I-accum = 0.4
    Heater 3 is on, I-accum = 0.0
    === GCodes ===
    Segments left: 1
    Movement lock held by null
    http is idle in state(s) 0
    telnet is idle in state(s) 0
    file is doing "G1 F5400 X15.049 Y30.619 E0.05161" 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: 201.28ms; fastest: 0.09ms
    Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(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 1
    WiFi firmware version 1.23
    WiFi MAC address 84:f3:eb:42:b0:9b
    WiFi Vcc 3.41, reset reason Turned on by main processor
    WiFi flash size 4194304, free heap 24288
    WiFi IP address 192.168.1.40
    WiFi signal strength -65dBm, reconnections 11, sleep mode modem
    Socket states: 0 0 0 0 0 0 0 0
    === Filament sensors ===
    Extruder 0: pos -0.40, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
    Extruder 1: pos 0.00, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
    

  • Moderator

    @Marco-Bona said in M207 Zlift problem:

    === Move ===
    Hiccups: 43985(0), FreeDm: 150, MinFreeDm: 139, MaxWait: 0ms

    Not losing steps, but the board is slowing down due to the step rate.

    Ian



  • Okay, after this print I bring the microstepping to X16 and I will publish a report with the subsequent print. He will have a result in the late afternoon.



  • X16 microstep report for XYZ

    m122
    === Diagnostics ===
    RepRapFirmware for Duet 2 WiFi/Ethernet version 3.01-RC2 running on Duet WiFi 1.02 or later + DueX5
    Board ID: 08DGM-9T6BU-FG3SN-6J9F0-3S46M-9UYZD
    Used output buffers: 3 of 24 (19 max)
    === RTOS ===
    Static ram: 27916
    Dynamic ram: 94988 of which 56 recycled
    Exception stack ram used: 512
    Never used ram: 7600
    Tasks: NETWORK(ready,596) HEAT(blocked,1232) DUEX(suspended,136) MAIN(running,1768) IDLE(ready,76)
    Owned mutexes: WiFi(NETWORK)
    === Platform ===
    Last reset 00:13:43 ago, cause: power up
    Last software reset at 2020-04-01 15:09, reason: User, spinning module GCodes, available RAM 7520 bytes (slot 0)
    Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
    Error status: 8
    Free file entries: 9
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 0.0ms, max retries 0
    MCU temperature: min 14.4, current 15.1, max 15.3
    Supply voltage: min 23.8, current 24.0, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
    Driver 0: standstill, SG min/max 0/282
    Driver 1: standstill, SG min/max 0/279
    Driver 2: standstill, SG min/max not available
    Driver 3: standstill, SG min/max not available
    Driver 4: ok, SG min/max 0/1023
    Driver 5: standstill, SG min/max not available
    Driver 6: standstill, SG min/max not available
    Driver 7: standstill, SG min/max not available
    Driver 8: standstill, SG min/max 0/1023
    Driver 9: ok, SG min/max 0/430
    Date/time: 2020-04-01 15:23:26
    Cache data hit count 1358769505
    Slowest loop: 4.55ms; fastest: 0.14ms
    I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
    === Move ===
    Hiccups: 0(0), FreeDm: 167, MinFreeDm: 136, MaxWait: 0ms
    Bed compensation in use: none, comp offset 0.000
    === MainDDARing ===
    Scheduled moves: 4626, completed moves: 4621, StepErrors: 0, LaErrors: 2, Underruns: 5, 0
    === AuxDDARing ===
    Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
    === Heat ===
    Bed heaters = 0 -1 -1 -1, chamberHeaters = 3 -1 -1 -1
    Heater 0 is on, I-accum = 1.0
    Heater 1 is on, I-accum = 0.5
    Heater 3 is on, I-accum = 0.0
    === GCodes ===
    Segments left: 1
    Movement lock held by null
    http is idle in state(s) 0
    telnet is idle in state(s) 0
    file is doing "G1 F3360 X26.236 Y12.23 E1.79933" 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: 199.80ms; fastest: 0.09ms
    Responder states: HTTP(2) HTTP(0) HTTP(0) HTTP(0) FTP(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 1
    WiFi firmware version 1.23
    WiFi MAC address 84:f3:eb:42:b0:9b
    WiFi Vcc 3.40, reset reason Turned on by main processor
    WiFi flash size 4194304, free heap 24512
    WiFi IP address 192.168.1.40
    WiFi signal strength -62dBm, reconnections 0, sleep mode modem
    Socket states: 0 0 0 0 0 0 0 0
    === Filament sensors ===
    Extruder 0: pos 0.02, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
    Extruder 1: pos 0.00, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
    

  • Moderator

    @Marco-Bona Thanks. The important thing is if you notice any motor movement problems, or a reduction in print quality from using x16 microstepping. Did you have inerpolation enabled?

    Ian



  • Yes, I have enabled interpolation. The only thing I'm noticing is that the car "sounds" differently than before, it seems much smoother.
    Should something change at the resolution level?


  • Moderator

    @Marco-Bona said in M207 Zlift problem:

    Should something change at the resolution level?

    Probably not, but it's up to you to decide if your prints look better or worse with more or less microsteps. In the end, the positional accuracy is determined by the error in the motor, which is usually ±5º on the full step. That's why GeckoDrives only microsteps at x10, because any additional microstepping is wasted. See 'SECTION 8: ACCURACY AND RESOLUTION' here: https://www.geckodrive.com/support/step-motor-basics.html

    16x does give an improvement over 8x, and if you're moving the motor slowly (GeckoDrive suggest less than '5 full steps per second'), eg an extruder motor, you may see an improvement using higher microstepping. Interpolation helps to smooth out the movement from one microstep to the next, making things quieter and smoother (as you've noticed).

    Ian



  • @droftarts, for information, I am updating with many difficulties because of Covid to Duet3, since it supports microstepping up to X128 or X256 would you advise me to increase the resolution or leave it to X16 anyway?


  • Moderator

    @Marco-Bona On axes where the motor moves fast, there is little point using more than x16 with interpolation. On axes were the motor moves slowly (extruder mainly), or gearing means there is a low step per mm, there is some justification for increasing microstepping, but you're limited by the mechanical and electrical capabilities of the motor. If you try to move an axis with huge numbers of steps per mm very fast, eventually you'll bump into the step rate limit of the processor, and the axis won't move any faster until you reduce the step rate. Ultimately, it's your machine, you have to decide on the best compromise between speed and quality.

    Switching to Duet 3 won't necessarily let you run high microstepping rates at high speed (though it's more powerful processor should allow it to have a higher step rate), and it won't improve accuracy anyway (because of the positional inaccuracy of the motor). It does have the advantage, like the drivers on the Duet 2 Maestro, that you can turn on interpolation at any microstepping rate (Duet 2 Wifi is limited to interpolation on x16 only). Though we're very happy to sell you another board!

    Regarding why the behaviour has changed in 3.01-RC5, I'm still not sure. When RRF3 was first released, the step rate was reduced from RRF2. However, the only change in maximum step rate was in 3.01beta2; see https://github.com/dc42/RepRapFirmware/blob/v3-dev/WHATS_NEW_RRF3.md#reprapfirmware-301beta2

    The maximum step rate possible was reduced in earlier RRF3 releases. Some of that loss has been restored.

    Nothing else has changed in this regard since then, as far as I am aware. I still don't have an actual number to give you to say "this is the maximum step rate", but then realistically it's irrelevant.

    Ian



  • @droftarts ,Just out of curiosity, I await your news when you are sure that the problem has arisen from the latest updates.
    For the moment I will not change the miscrostepping settings but I will try to return to RRF3.01 RC5 to verify that there is no longer the problem with the axis.
    Thanks for the explanation


  • Moderator

    @Marco-Bona I still think you may have problems moving both Z motors at 20mm/s, whatever the microstepping, by the way!

    Ian



  • @droftarts ,I try to reduce it to 16mm / s


Log in to reply