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

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.

Gixxerfast

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

You can use M569 P# D2 to force spreadCycle mode

Thanks DC, I was going to ask about this I don't want to run in stealthchop anyway.

Looking at the failed prints it seems like they shift in a diagonal fashion.

I will up the motor currents, make sure that stealtchchop is disabled and also do the testprints as Tony suggested.

I will have to do that tonight and I will report back the results.

Thanks again all