M207 Zlift problem

Marco Bona

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?

Phaedrux

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.

Marco Bona

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

Phaedrux

@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

Marco Bona

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?

droftarts

@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

Marco Bona

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.

droftarts

@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

Marco Bona

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

droftarts

@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

Marco Bona

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

droftarts

@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

Marco Bona

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.

Marco Bona

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

droftarts

@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

Marco Bona

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?

droftarts

@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

Marco Bona

@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?

droftarts

@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

Marco Bona

@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