RRF v3.3/Mini 5+ Wifi - Major problems with layer shifting

Gixxerfast

I need some help please. My RRF/Duet setup isn't working.

I have a corexy Voron2.4 300x300 setup with a fixed bed and a flying gantry controlled by 4 z-motors.

There are two z-probes:

1 fixed z-pin mounted to a bed extrusion which has a calibrated distance to the bed surface.
Klicky Omron toolhead probe used for quad gantry leveling, auto-z correction and bed mesh calibration

The boards are the Duet Mini 5+ wifi with a v1.1 1LC toolhead board running in standalone mode

I have major problems with scraping and layer shifting.

The prints looks IMHO really nice besides the obvious layer shifts.

Since my printer suffers from the normal y-extrusions bimetallic heat expansion I am applying a bed mesh

I used to run Klipper and didn't have any problems.

The A/B-motors run at 1A, I used to run them at 0.8A but trying to fix the problem by increasing the current. The A/B motors are the 0.9 LDO 42STH40-2004MAC.

During the print I hear a lot of scraping and it feels like it is when going over the infill.

I can't really figure out what is going on here as it looks to me as if the mesh is applied correctly since the first layer is looking nice and Z-dimensions looks spot on even while layer shifted.

My macro files are starting to look a little bad since I have been trying everything to correct this problem

2021-10-07 07:33:16	m122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.3 (2021-06-15 21:46:11) running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: H1668-Y296U-D65J0-40KMA-KR03Z-RK6ZH
Used output buffers: 3 of 40 (19 max)
=== RTOS ===
Static ram: 102724
Dynamic ram: 115912 of which 192 recycled
Never used RAM 22020, free system stack 114 words
Tasks: NETWORK(ready,43.8%,240) HEAT(delaying,0.6%,344) Move(notifyWait,20.7%,272) CanReceiv(notifyWait,0.7%,773) CanSender(notifyWait,0.8%,357) CanClock(delaying,0.2%,338) TMC(delaying,37.4%,106) MAIN(running,374.4%,408) IDLE(ready,3.1%,29) AIN(delaying,26.7%,264), total 508.6%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 11:31:27 ago, cause: power up
Last software reset at 2021-10-06 12:12, reason: User, GCodes spinning, available RAM 24252, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
MCU revision 3, ADC conversions started 41481060, completed 41481058, timed out 0, errs 0
Step timer max interval 1143
MCU temperature: min 24.4, current 28.9, max 32.2
Supply voltage: min 23.9, current 24.0, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/44, heap memory allocated/used/recyclable 2048/1406/836, gc cycles 8
Driver 0: position 96800, standstill, SG min/max 0/408, read errors 0, write errors 0, ifcnt 96, reads 35582, writes 96, timeouts 0, DMA errors 0
Driver 1: position -800, standstill, SG min/max 0/410, read errors 0, write errors 0, ifcnt 96, reads 35582, writes 96, timeouts 0, DMA errors 0
Driver 2: position 12562, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 9, reads 35669, writes 9, timeouts 0, DMA errors 0
Driver 3: position 0, standstill, SG min/max 0/62, read errors 0, write errors 0, ifcnt 99, reads 35579, writes 99, timeouts 0, DMA errors 0
Driver 4: position 0, standstill, SG min/max 0/58, read errors 0, write errors 0, ifcnt 98, reads 35580, writes 98, timeouts 0, DMA errors 0
Driver 5: position 0, standstill, SG min/max 0/60, read errors 0, write errors 0, ifcnt 99, reads 35579, writes 99, timeouts 0, DMA errors 0
Driver 6: position 0, standstill, SG min/max 0/64, read errors 0, write errors 0, ifcnt 100, reads 35578, writes 100, timeouts 0, DMA errors 0
Date/time: 2021-10-07 07:33:13
Cache data hit count 4294967295
Slowest loop: 1000.47ms; fastest: 0.07ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 4.2ms, write time 2.3ms, max retries 0
=== Move ===
DMs created 83, maxWait 1769406ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 725422, completed moves 725422, hiccups 0, stepErrors 0, LaErrors 0, Underruns [10075, 163, 13], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.3
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
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
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== CAN ===
Messages queued 1494156, received 501531, lost 0, longest wait 2ms for reply type 6049, peak Tx sync delay 382, free buffers 17 (min 3), ts 207440/207439/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 206.57ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- WiFi -
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.26
WiFi MAC address f0:08:d1:02:eb:c9
WiFi Vcc 3.36, reset reason Power up
WiFi flash size 2097152, free heap 22544
WiFi IP address 192.168.1.70
WiFi signal strength -53dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0
```[print_start.g](/assets/uploads/files/1633590300433-print_start.g) [heightmap.csv](/assets/uploads/files/1633590300397-heightmap.csv) [config (1).g](/assets/uploads/files/1633590300387-config-1.g)

Gixxerfast

@gixxerfast

print_start.g heightmap.csv config (1).g

PCR

@gixxerfast are you sure that the AB are 0.9 LDO 42STH20-1004AS ? if you are using the normal Voron LDO Kit then you can give the AB about 1350 mA

Gixxerfast

@pcr No, sorry. I will correct that typo. Sorry

T3P3Tony

@gixxerfast can you start with a cube (say 303030) in the centre of the bed printed with the settings you have been using. Check the height of the cube to see if it is correct (within 1 layer height).

PCR

@gixxerfast But increase your M906

This is a config from @Argo https://github.com/Argolein/Voron-2.4---RepRapFirmware-Config-Duet-3-Mini5-/blob/main/sys/config.g

Gixxerfast

@t3p3tony

Yes, that was my first print and also the parts above are very dimensionally accurate in Z (20 mm)

Gixxerfast

@pcr said in RRF v3.3/Mini 5+ Wifi - Major problems with layer shifting:

M906

I don't have those motors. Those are the OMC BOM version.

I have these: LDO 42STH40-2004MAC

And they should not need that much current. The normal Klipper config with these are 800mA run current and 700mA idle

T3P3Tony

@gixxerfast ok that's great, so the test cube in that image is printed with the slicer and firmware settings you are currently using? I don't see any layer shifts. Can you show an image with the issue please.

Gixxerfast

@t3p3tony
Thanks for the answer

Yes, it's with my normal ASA slicer profile.

The pictures in the main post shows the layer shifts. I can add some more

I have reprinted these parts more thean five times now so I have a bunch of failures to show.

And I have tried to rearrange tho order of how I apply the mesh, but so far the same result whatever I do.

The problem isn't with small parts in the middle of the bed. The problems seem to be that is scrapes heavily over the larger infill parts of the prints above and I can't understand why.

Usually when I have scraping it's over extrusion or if the bed is wrong the first layer is crap. But here the extrusion factor seems OK and the first layer is great.

Gixxerfast

@t3p3tony
Here is one more picture. Thanks for helping

In the top part I lowered the extrusion factor to see if that helped. The bottom part is from tonight.

PCR

@gixxerfast said in RRF v3.3/Mini 5+ Wifi - Major problems with layer shifting:

42STH40-2004MAC

OK. But mostly your Layershifts are due to the current or some loose grub screws.

FYI Klipper Current is RMS RRF is Peak.

so 800ma on klipper is about 1130mA in RRF.

Gixxerfast

@pcr That's very interesting.

I tried to read about that but I must have missed that. So in my config I should have about 1200 mA to match the Klipper 800mA?

I would be very very happy if the solution to the problem is that easy

Gixxerfast

@pcr

This is in the M906 documentation:

NOTE: As a rule of thumb, the recommendation is to set M906 to use 60-85% of the rated maximum current for the motor.

So inbetween 1A and 1.4A then. I'll try that

Gixxerfast

@gixxerfast
Btw, is there somewhere I can see the bed mesh compensation "work". The displayed Z and the one in the object model doesn't show the adjusted Z. Is it possible to see that somewhere?

As it's so small adjustments, below .1 mm so it is very hard to notice these by looking (or feeling) at the steppers I guess.

engikeneer

@gixxerfast if you send M122, there is a line that will say 'bed compensation in use: Mesh', or 'none'

If you just was to check it, you can manually edit a couple of the heightmap points so that it will move enough to see

T3P3Tony

@gixxerfast I can feel the lead screws on my z motors moving slightly if mesh compensation is working. Also what does DWC report for mesh compensation?

Looking at the files you shared the print_start.g has a lot going on in it. Potentially interesting are your bed.g (as you run that) and this M98 P"/macros/autoz/autoz.g"

Other thoughts: For the parts where you have the layers squashed as you have shown and the layer shifts, are they still the correct Z height across the whole part?

As there is a lot of different things going on here I would like to simplify things down to the bare minimum. I can propose a couple of tests to help isolate what the issue is

create a cube test that recreates the problem so you have a quick print. An example coupld be a 30x30x30 print (not that complicated test print, just a simple cube) placed in one corner of the bed,
once you have a quick reproducible issue, try the same print with mesh compensation turned off. You will probably need a with a larger first layer height and ( maybe will not get a not perfect first layer). Don't use your print-start.g at all and edit the start gcode of your test file to remove all references to things that effect bed levelling or mesh compensation.

Depending on how out of level your bed is you will need to be close to the emergency stop if its really out of level. If it is then you may need to run G32 manually before starting the print.

The idea is to see if its mesh bed levelling or something else causing the issues.

dc42

@gixxerfast I understand the Vorons are all CoreXY machines. Are the layer shifts always along one diagonal, the same one each time? If so then it suggests that the motor isn't providing enough torque. Possible reasons include:

Bad crimp in the cable connecting the motor to the driver
Motor current accidentally set too low for that driver. Send M906 without parameters during printing, to confirm that the motor currents are correct, and send M913 to confirm that the current is 100% of that value.
Loose grub screw on motor pulley
Mechanical issue with that belt/pulley system
Running the driver in stealthChop mode without executing the proper tuning move during homing. You can use M569 P# D2 to force spreadCycle mode (where # is the driver number), to see if this might be the problem - do this for both XY motors. Note, in stealthChop mode the drive is less able to respond to sudden increases in load, such as when hitting a filament blob or curl-up.
Bad driver. Try swapping the X and Y motor connections over on the Duet, and swap X and Y in your M584 command. If the problem moves to the other diagonal, it's a bad driver.

T3P3Tony

@gixxerfast so you now have two approaches - looking at the XY motion as @dc42 suggested to ensure that is right, and then looking at Z as I suggested.

I did not think it was XY at first because the layers looked squished in the pictures however it is worth checking to eliminate that as an issue.

Gixxerfast

@t3p3tony
Big, thanks for helping with this problem.

I will do as you say and try that.

Given that what's said above about motor current and if with a max motor current of 1.68A that a m906 current of 1.2A is OK, then I'll try that first

The prints are dimensionally accurate in z overall.

The autoz macro is calculation a correction factor between the Z-pin and the bed height and then adjusts the baby-steps.
The value it determines varies by how warm the chamber is and how long it has been warm. The last print it determined the baby step value to -0.08 mm.

I can post it later. The bed.g macro is just a standard four point quad gantry leveling.