M207 Zlift problem
-
I wait for a confirmation from @dc42 and then I will see how to proceed.
I guess this problem also applies to DUET3 boards -
@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 -
@Marco-Bona said in M207 Zlift problem:
=== Move ===
Hiccups: 43985(0), FreeDm: 150, MinFreeDm: 139, MaxWait: 0msNot 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 -
@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? -
@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
Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth
-
@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?
-
@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
Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth
-
@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 -
@Marco-Bona I still think you may have problems moving both Z motors at 20mm/s, whatever the microstepping, by the way!
Ian
Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth
-
@droftarts ,I try to reduce it to 16mm / s
