@dc42 - thanks for the clarification.

@p8blr in that example you would divide your E steps/mm by 1.0036.

The best fit line in the graph in your earlier post showed an intercept of 0.9194 so if using that to provide the parameters you would multiply the steps/mm by 0.9194.

So it looks like the Z stepper was bad, replaced it with an identical one and the mesh compensation is now working properly.. I'm guessing all the z-axis movement during the mesh compensation process was causing more missed steps then the simple repeat probes and non-mesh compensation prints that I did.

@Triet You would need to send a M92 E... command. See https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m92-set-axis-steps-per-unit
This is in steps per mm. It's the only way to adjust the extrusion rate apart from M221. If you want it in some other unit, or as a percentage, you could write a macro to convert it for you.

You can change the mixing ratio with M567 on tools with multiple extruders, I'm not sure if you can use it with a tool with only one extruder, and the result wouldn't be much different from using M221.

Ian

@droftarts thank you for the reply and sorry for the late reply.

After sending the message I continued tinkering and searching for clues of why that happened, and I've discovered what was the problem:

By using the BLV mgn profile on Cura, the special option "Set Relative Extrusion" is disabled, meaning that when I was applying the "set relative extrusion" command inside the gcode, the acual extrusion values inside the print gcode were still absolute and exponentially told the machine to extrude more and more filament, more than it could do.

By removing the relative extrusion command, the printer worked like a charm.
After that, I've tried using other slicers like Orca, and it managed to convert to relative extrusion with no problem, with also a lot more of options for me to customize. So I'll probably stick to it from now on.

That was genuinely my bad to not have thought of that before, tomorrow I'll set this post to resolved for the posterity.

@kivlow Please post your full config.g and the response to M122.

Generally, in order of most likely to least likely, spiky temperature readings are caused by:

intermittent wiring - loose connections, poor crimping, frayed wires, dry solder joints. It may only happen when the wiring moves, or when temperature changes. failing temperature sensor - may only show when at temperature Electrical interference - usually from heater or motor wiring running very close to the temperature sensor wiring. Generally shows when machine is operating Power supply issues - faulty or failing power supply, external power spikes (eg large/noisy dc motor on the same electrical circuit starting/stopping) Hardware issues - faulty Duet board. Firmware bug - least likely because this is heavily tested, and would be reported by other users.

Ian

@Phaedrux, feedback: I put it to the test and it works ! thanks again !

@dc42 @oliof

Hi Guys,

Thank you for your replies and confirming.

Very grateful.

Dizzwold.

@o_lampe little late, but yeah, Mirror mode does print a copy mirrored, it also eliminates inertia just on the axis the IDEX is set up.(either X or Y)

@droftarts thank you!
While you were writing, I was researching this very documentation.
Thank you very much.

I don't know yet how to mark a topic as resolved. Should I wait for the administration or can I do it myself?

@Fuzionline did you test this with 3.6beta2 to see if its resolved or not?

@Polyneutron21 change the direction (S value on M569) on the z drivers going in the wrong direction

@Phaedrux said in Printer goes past endstops:

Is it actually homing?

Can you send M581 T1 and report back with what it says?

You may also want to upgrade your firmware to 3.5.3 so that we're on the same firmware page.

M581 T1 Trigger 1 fires only when printing on a falling edge of endstops/inputs X Y

It homes like normal. I updated my firmware to 3.5.3 and no change.