@Damien said in Auto Bed Leveling Mesh made easy??:

Nothing about what to do when your height map is not centered on your bed, but offset because of the parameters you put in for the map to compensate for the offset.

I don't understand what you mean by this part. Can you give us some more information? Showing your gcode files would be helpful as well. config.g, homing files, bed.g. Maybe a screenshot of your height map as it is displayed now.

What PID tuning command are you using?
What fault do you get?
What firmware are you running?
What kind of heater is it?
What is it heating?

@Phaedrux thanks, i hope this help other in the future

@john345463563, you should run true bed levelling (G32) before you run mesh bed compensation (G29). Otherwise the mesh will compensate for the bed as it was before you ran G32 to level it.

The order in which you have defined Z motors in M584 must be the same as the order in which you have defined leadscrew positions in M671. Try running G32 more than once and look at the reported corrections. They should reduce with each run. If they increase instead, you have defined those two sets of parameters in different orders.

@dc42, that was my understanding as well but in real life, the net result was that the bed temperature gradually dropped during the roughly 2 hours that a full probe (441 points) of the surface took. Since the temperature kept dropping (slowly) I eventually decided to take the one set of measurements with a cold bed without attempting to heat the bed. I did not attempt to try a smaller sample size and then compare just the data points of the smaller set with each other. I will give a smaller sample set before I try the manual method that @droftarts suggested.
Thanks!
BTW, this is a very large bed slinger and I probe very slowly (and do up to 10 repeats) which is why it takes 2 hrs to do the full scan.

@thomas-weiss something else to check is there are no speed limit setting commands in the job file from your CAM processor.

You can send M203 from the command line in DWC to confirm the setting, then try moves from one end of your longest axis to the other with F4000 and F6000, sending them directly from the console. e.g.

G1 X0 ;start at 0 G1 X150 F4000 G1 X0 F4000 G1 X150 F6000 G1 X0 F6000

@Adamfilip First, see https://docs.duet3d.com/User_manual/Connecting_hardware/Sensors_endstops#multiple-endstops-on-one-axis

RepRapFirmware only supports one endstop per motor per axis. If your axis only has one motor, you can only have one endstop. If your axis has two or more motors, you can have an endstop per motor, if the motors are plugged into their own stepper driver, and the motors can be homed individually to their own endstop. To do this, see the 'Axis levelling using endstops' section of Bed levelling using multiple independent Z motors

Then see https://docs.duet3d.com/User_manual/Connecting_hardware/Z_probe_auto_levelling#axis-levelling-using-endstops
This describes using two endstops on the Z axis, but it's the same for two endstops on any other axis with two motors.

Ian

I'm no expert on linear rails unfortunately. Though I do know that typically in industry when rails are used the surface they are mounted to must be flat to begin with.

I think you're on the right track though, if you know how the rail bends, you can try and force a counter bend with shims.

@Phaedrux Added M558 with just the H parameter to my G29 macro and now it works perfectly. Thank you.

@thetazzbot
That'll do it 👍

@Phaedrux This is a heat cartridge 24V 65W

Some pictures :
head1.png
head2.png

Thank you for that fast support. I appreciate it so much . 😊

When mapping as a new axis make sure to gives those new axis all the corresponding values for speeds, currents, steps/mm, etc.

@mrehorstdmd

Thank you for quoting LibreOffice, I've got it up and running now (on my Mac).

@gloomyandy
Yes, I think 2.49mm/min would be correct to get you a feed rate of 2mm3/s.
I think you are on to something with the 0.5mm/s rate, if that's being enforced that would explain the too fast extrusion and it indeed matches the 20 seconds I'm seeing, I'll give "M203 Innn" a go, thanks.

@dc42, cool, thanks !

Super volcano is pretty hefty and well insulated so it doesn't behave as the model expects during the cooling phases with the fan. Tuning as a heater should work fine in this case since you don't have the temp drop issues that tuning as a tool+fan is meant to mitigate.

@gloomyandy

Hi Andy, yes my M208 Z0 , i only found this out when i had changed my tool head which has a different Z offset , I just found it strange that the Z head was increasing once passed the offset should it have just stopped at Z0 , not then changed the direction of the baby stepping?

thanks for the reply

@justus2342 1.7 because it's tan(60). It assumes the 'rule of thumb' that the delta arms will be at a maximum of 60 degrees from vertical, and with that configuration the motor runs tan(60) times faster than the head is moving directly towards that tower, by geometry.

You can see this for yourself (roughly) knowing nothing more than pythagoras and sin/cos:

Suppose you have 400mm long arms, at 60 degrees from horizontal, extending directly away from a tower. Therefore, the tip of the arm will be offset 400 x sin(60) = 346.41mm horizontally from the tower end, and 400 x cos(60) = 200.00mm vertically.

Suppose the carriage now moves 1mm towards the tower, so the horizontal offset is now 345.41. The arm length obviously doesn't change so is still 400. By pythagoras therefore the vertical offset must now be sqrt(400^2 - 345.41^2) = 201.72mm That is, the head moved 1mm horizontally and the carriage moved 1.72mm.

If your delta has different geometry at extreme reach, you could/should use a different factor, but 60 degrees is the norm.

@droftarts
I made a file with relative extrusion in PruisaSlicer, it didn't change anything.
For the purity of the experiment, first I do an "emergency stop" of the machine and its "reboot", after that I upload the file and see the problem.
link