Mesh bed leveling and bl touch
-
After successful probing, the height map is automatically saved to heightmap.csv unless you specified another file, and automatically loaded.
The two height maps you posted show significant differences, in particular a significant Z offset between them. This could mean that you have an inconsistent Z homing trigger height. Are you doing Z homing with an endstop switch or with the Z probe? If you are doing it with the Z probe, are you moving the probe to the centre of the bed before doing the G30 command? If you are homing with a switch, make sure that you do not re-home the printer after doing bed probing and before the print starts.
-
I have an FT5 so dual z motors on lead screws. (in series on board) I use a sensor for homing z. If I am reading the script correctly, i home all then start mesh level so i think i am ok as far as process goes. I do not home Z after. I think my bed gets crooked somehow and as previously mentioned am working on a single motor z upgrade that will tie both lead screws to same belt and hopefully put an end to all this. On a side note, i did a print job this morning with 6 small parts. skirt printed perfect and 1st layer on the 1st 2 parts was perfect but ph moved to 3rd part and started printing in mid air a full mm or more above deck (inside of skirt that printed fine). I fear it is not just an inconsistent Z sensor (already replaced 3 times )but movement issue movements not equal on both sides all the time. Is that possible? I thought that was only an issue when motors were off and something gets moved. Z runs on 2 small belts which are tight so doubt they are slipping. i did change my z offset this morning so here is the latest with another fresh map. Hopefully you will see something i clearly am not but yup i agree something is up with either z movement or homing, maybe both…ugh
; BLTouch
M307 H3 A-1 C-1 D-1
M558 P5 X-22 Y-9 Z4.05 H3 F200 T5000
G31 X-22 Y-9 Z1.1RepRapFirmware height map file v1 mean error 0.08 deviation 0.19
xmin xmax ymin ymax radius spacing xnum ynum
10 260 10 240 -1 25 11 10
0.685 0.511 0.425 0.333 0.248 0.18 0.128 0.068 0.004 -0.045 0
0.512 0.457 0.37 0.286 0.207 0.131 0.065 0.011 -0.039 -0.067 0
0.446 0.384 0.303 0.249 0.145 0.075 0.055 -0.03 -0.083 -0.107 0
0.397 0.316 0.273 0.17 0.12 0.053 -0.014 -0.029 -0.117 -0.15 0
0.332 0.261 0.207 0.126 0.075 0.009 -0.051 -0.042 -0.111 -0.178 0
0.291 0.226 0.155 0.096 0.025 -0.002 -0.067 -0.111 -0.144 -0.177 0
0.276 0.212 0.152 0.1 0.018 -0.024 -0.011 -0.107 -0.128 -0.176 0
0.235 0.2 0.121 0.064 0.001 -0.043 -0.102 -0.122 -0.173 -0.178 0
0.233 0.178 0.122 0.063 0.021 -0.05 -0.093 -0.117 -0.147 -0.167 0
0.182 0.142 0.105 0.043 -0.011 -0.053 -0.098 -0.121 -0.16 -0.096 0 -
It could well be that your Z motors have been getting out of sync. However, i am planning to implement bed levelling using multiple Z motors very soon, so there may be no need to change to a single Z motor. To use this facility you will need to connect each Z motor to a different driver output. Not a problem if your E1 motor output is spare.
-
Outstanding news. and as always outstanding support! I know there is a thread for dual z end sensors (FT5 forum and mks board from factory) Any point in that with the upcoming change for dual motor support? i might be bias but, your solution sounds much better than that.. What about linking the z lead screws with a 2nd belt? would that be a good idea to keep thing level or would dual motor mesh be better? I guess what i am asking is, can it get out of alignment while running? If so, i suppose that would be a hardware issue, right? I can live with manual bed leveling for a little longer no worries.
on a side note, i have been trying to pay it forward and help when i can in the forums but good lord there are some serious brains on here (besides you) and i am still just a newbie so….
-
i forgot, I have dual Y motors too so e1 is in use already… i guess it is time to look into an expansion board
-
I guess what i am asking is, can it get out of alignment while running? If so, i suppose that would be a hardware issue, right?
It's common for multiple Z motors to get out of sync when you power off and on again, because each motor has to jump to the nearest multiple of 4 full steps that matches the current, and the motors may jump in opposite directions. I have some firmware work planned to reduce the likelihood of this too. However, they should not get out of step during printing.
-
Good Morning and good to know thanks! i figured as long as power was applied motors would maintain position but with a few spectacular jams in the early days, have seen it tilt the bed under power. Maybe over torque when bed hits PH? I may have some insight into my bl touch failing at start of mesh. my Z home sensor is on the left middle of the bed but 1st probe point is front right corner. it appears for 1st probe, it tries to trigger z home sensor, is that right? is there a way to move the 1st probe point to a different spot?(sorry about all the 101 questions, still learning )maybe closer to z home sensor. as it is now, it homes all then deploys probe but on 1st trigger bltouch errors out. i am wondering if that is because it triggers before z end sensor does. It drives the print head into the bed 1 time then errors. script clears alarm and it runs correctly on 2nd pass.. short version is, does bltouch look for z home on 1st trigger point?
-
I am sure you recall, i had a hell of a time getting bltouch working so was and am reluctant to trust it. I am worried about the issue where PH hits bed at start of probe sequence. Probe is triggering before this happens but appears to be ignored 1st time at least until z home lights up. without out end stop sensor, i fear what would happen… It is pretty scary to watch entire PH mount flex and it appears to stop when z end stop triggers which is well after ph hits bed... manual level is pretty close at start so no idea why it appears to be off by about 1 to 2mm when probing starts other than possible dual z motors getting offset at startup somehow.
BTW, Great idea on the Y and Z motor swap. Can't believe i did not think of that already!... I was planning on going to single z motor so i can eventually get dual PH running. As it is now, i would have to add expansion board. I was considering a single Y motor mod too. Moving Y to Z would be a very simple change. Only question i have is, am i giving anything up by going to 1 motor on Z. seems like torque is not an issue as new motors appear more than strong enough. z is in series any way so power should be the same with just 1 motor right? (both share 1.5 amps now so single at 1.5 should be about same) all mine are .9 degree 2 amp max ( nema 17 17hm19-2004s)so decent upgrade from stock and may be strong enough for this.
What i am wondering is, does the 1st probe point look for z sensor trigger? seems like they would not be related as probe could be substituted for sensor but might explain this odd behavior.
I tend to lean towards hardware solutions over software whenever possible but in this instance, that may not be the best way to go...
-
@CaLviNx:
Good Morning and good to know thanks! i figured as long as power was applied motors would maintain position but with a few spectacular jams in the early days, have seen it tilt the bed under power. Maybe over torque when bed hits PH? I may have some insight into my bl touch failing at start of mesh. my Z home sensor is on the left middle of the bed but 1st probe point is front right corner. it appears for 1st probe, it tries to trigger z home sensor, is that right? is there a way to move the 1st probe point to a different spot?(sorry about all the 101 questions, still learning )maybe closer to z home sensor. as it is now, it homes all then deploys probe but on 1st trigger bltouch errors out. i am wondering if that is because it triggers before z end sensor does. It drives the print head into the bed 1 time then errors. script clears alarm and it runs correctly on 2nd pass.. short version is, does bltouch look for z home on 1st trigger point?
Can I ask why you are using both a switch and the probe when the probe can be used for homing purposes ?
If you see the quote from the wiki below you can make the z probe land anywhere on the bed you want for homing the z axis
Homing Z using a Z probe
Z homing is normally done using the Z probe. Here is a typical homez.g file:G91 ; relative mode
G1 Z4 F200 ; raise head 4mm to ensure it is above the Z probe trigger height
G90 ; back to absolute mode
G1 X100 Y100 F2000 ; put head over the centre of the bed, or wherever you want to probe
G30 ; lower head, stop when probe triggered and set Z to trigger height
Adjust the X and Y coordinates in the second G1 command according to where you want to probe when Z homing. You need to have set up the Z probe type, trigger height and threshold as described earlier.i would need to add a deploy probe to this right? still kicking it around and will play with that this weekend. MUCH APPRECIATED!
-
Thanks again for sharing Calvinx! I will definitely give that a try this weekend! Last time i tried it, it left a rut in the pei sheet about 6 inches long from head crash and move so yikes lol hand will be on power button whole time
-
yup, lessons learned… but mine is not quite as dramatic as yours is LOL
-
@CaLviNx:
I am planning to implement bed levelling using multiple Z motors very soon, so there may be no need to change to a single Z motor. To use this facility you will need to connect each Z motor to a different driver output. Not a problem if your E1 motor output is spare.
David
You have just thrown up a question with this statement, if you remember I asked about motor connectors in relation to driver numbers in another thread which you clarified.
In relation to my FT-5 build it would be nice to use the coming feature to level the bed, as the FT-5 uses dual Y motors, would it be feasible im this case to transfer the twin Y motors to the Duets twin Z output connectors and then put the x2 independent Z motors into the Y & E1 connectors and remap everything to allow me to implement the upcoming levelling feature ?
Yes you can swap the Y and Z motor connectors over using M584 X0 Y2 Z1 E3:4. Or with the Z motors connected separately to the Y and E1 outputs, M584 X0 Y2 Z1:4 E3.
Regarding your bltouch issues, unless you are deploying it when it is too low so that it triggers immediately, I suspect it is faulty. But I've never used a bltouch so perhaps there is some other explanation.
