G0 move seizes when G29 S1 active, fine when G29 S2
-
So I have a custom built gantry on a fixed bed-style printer. I have my axis tuned with nema 17 on everything except the y (which moves the gantry). This uses a nema 23 driving a hub on a fixed leadscrew. Great torque and power, I can accelerate at 700mm/s^2 to 30 mm/s and change direction instantly all day moving a ~50lb gantry.
Here's the issue: when the mesh bed leveling height map is loaded (G29 S1), and I do a G0 rapid move controlling X Y and Z, the y axis stepper seizes and emits a high whine after its accelerated to 30mm/s and moved for ~200mm.
I have repeated the Identical G0 rapid move without the mesh bed level active (G29 S2 in command console before G0 move) and it works flawlessly.
This issue is unfortunately critical is its the move generated by Cura in between start Gcode and print code
Other supporting info for my Y axis:
Nema 23 269 oz-in 2.8 amp
2272 steps per mm
x16 interpolation (tried x1 but too rough for smaller moves)
420 mm/min jerk
600 mm/s^2 accel
1800 mm/s max speedIs it possible I'm hitting a saturation point of either current or processing power because of all 4 motors moving simultaneously? (double motor for Z axis, 2 screws)
I was trying to view the code behind a G29 S1 but couldn't figure out how to see it.
Thanks in advance! -
with mesh bed leveling active it needs to move y and z
if z can not move at the same speed, you will see slowdowns.
-
So I need to bump up my Z speed so it works together? Bit confusing as the G0 X450 Y850 Z0.5 F1800 is called when position is X200 Y40 and Z15. So it would seam like Z has plenty of time to complete the moves, and my mesh bed points are spaced 200 mm apart. If Z were to lag due to stiction or something, would that impact the other axis from completing its move? Thank you for the help!
-
Please post the results of M122 and your entire config.g
-
Not sure if M122 has to be after i replicate the failure.
Thanks!
11:44:32 PMM122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.05.1 running on Duet WiFi 1.02 or later
Board ID: 08DGM-917NK-F2MS4-7JTDL-3SJ6S-TWUNH
Used output buffers: 3 of 24 (7 max)
=== RTOS ===
Static ram: 25712
Dynamic ram: 93076 of which 0 recycled
Exception stack ram used: 440
Never used ram: 11844
Tasks: NETWORK(ready,764) HEAT(blocked,872) MAIN(running,3736) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 00:36:28 ago, cause: software
Last software reset at 2021-01-28 23:08, reason: User, spinning module GCodes, available RAM 11836 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 27.1, current 27.3, max 28.9
Supply voltage: min 22.3, current 24.1, max 25.8, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max 0/280
Driver 1: standstill, SG min/max 0/1023
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 2021-01-28 23:44:30
Cache data hit count 4294967295
Slowest loop: 15.78ms; fastest: 0.06ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 160, MinFreeDm: 154, MaxWait: 72615ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 36, completed moves: 36, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = -1 -1 -1 -1, chamberHeaters = -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
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 idle 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: 15.48ms; fastest: 0.01ms
Responder states: HTTP(0) 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.23
WiFi MAC address 60:01:94:2e:d0:ab
WiFi Vcc 3.37, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 22896
WiFi IP address 192.168.1.115
WiFi signal strength -56dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
- WiFi -
-
post a picture of the height map
M201 X100.00 Y500.00 Z5.00
also your accelerations for z is really low
-
@jackstack said in G0 move seizes when G29 S1 active, fine when G29 S2:
Not sure if M122 has to be after i replicate the failure.
ideally, but I mostly just wanted to see if there were hiccups being reported. But you're using x16 microstepping so I think that is unlikely.
As Veti notes, your Z accel is quite low. Is it that low for a mechanical reason? Raising it to ~100 should be a bit better for mesh compensation adjustments.
You're also trying to use 2800ma on the Y motor. That will be capped at 2400ma which is the max for the Duet2. Do be sure your board as active cooling.
-
Important to preface that the bed is massive, unheated and fixed, and I'm not using ABL sensor. It's manually generated mesh map with a Z end stop below the bed about 3mm. I couldn't find any recommendation for resetting Z0 datum manually, but single axis moves have been fine with G29 S1 eg. moving from X min to x max Z has responded and maintained consistent height above bed and in the slicer it compensates down to initial layer reference to the mesh bed.
-
@Phaedrux Huh, I thought Duet 2 wifi was listed as 3A max for stepper. Is it current limiting to 2400 or do I need to set it to 2400. Based on the stepper motor sizing forum page, the only "not ideal" setting of the nema 23 I'm using is its 5.4 mH.
-
all i can think of when i see that heighmap is. no
-
The deviation on that heightmap isn't too bad given the size. But there shouldn't be such an extreme offset from Z0.
Can you post your homing files? bed.g if used?
And can you give a better explanation of how you're using the "probe"?
Given the large amount of adjustment being requested you may need to reduce the initial layer speeds quite a bit. Plus you're saying that it's the Y axis that is stalling on that first rapid move. The high steps per mm of the Y axis may require reduced max speeds and lower acceleration.
-
@jackstack said in G0 move seizes when G29 S1 active, fine when G29 S2:
I'm not using ABL sensor
is it planned? it would make it a lot easier
-
Yes, not using a ABL was planned. I have some adjustment for the Z end stop so I can decrease that ~3mm offset and do a more consistent job of generating the mesh bed. The scale of the display does make it seem horrible but I'm using a large nozzle so theres margin here compared to a .4mm nozzle.homeall.g
In terms of Y stepper, i was actually having worse performance running a lower acceleration for Y, speed is reasonable due to diminished torque at higher RPM but the G0 also failed at F1200 mm/minbed.g
As for "probe" I don't have one. I have a Z end stop that sets min axis point. M558 P0 H5 F120 T1200 "P0" sets it to no probe and it prompts you to manually job the z down to touch the bed.
-
you can use something like this. (i use it on my delta)
https://de.aliexpress.com/item/32838312776.html
cheap and works well.
just probe the bed once and remove it.
-
G1 H2 Y5 F1000 ; go back a few mm
G1 H1 Y-1923 F360 ; move slowly to Y axis endstops once more (second pass)
G1 H1 X-915 F1800 ; move quickly to X axis endstops and stop there (first pass)
G1 H2 X5 F1800 ; go back a few mmDon't use H2 on the XY moves to back away from the endstops. otherwise the homeall looks ok.
-
@Phaedrux Should it just be omitted then? H0 explicit but also default.
Thanks!
-
yes, H0 is the default if no H parameter is supplied.
-
@Veti Imma have to check those out! way easier than manually measuring lol Mechanically my printers designed as a set and forget for at least several prints.
