New firmware 1.21RC1 available
-
The firmware looks for 2 consecutive readings to differ by no more than the tolerance. So perhaps the best figure to show is the lowest difference seen between consecutive readings.
-
I have just updated from 1.20 to 1.21RC1 and not sure why the mesh bed compensation shows a rectangular bed instead of a circular bed for my delta. I didn't change my config.g, maybe I missed something that I should change?
I have M558 P1 R0.4 X0 Y0 Z0 H1.5 F100 T3000 I0 in my config.g and M557 R100 S15 in my bed.g
-
The firmware looks for 2 consecutive readings to differ by no more than the tolerance. So perhaps the best figure to show is the lowest difference seen between consecutive readings.
Sounds good
-
Maybe should add: All working fine here as far as I can see on my Dual E3D BigBox. 1.21RC1 with DuetWifi 1.0 and duex5.
-
Maybe should add: All working fine here as far as I can see on my Dual E3D BigBox. 1.21RC1
Thanks for the feedback.
-
Would it make sense to use the new multi-tap feature and modify it to do e.g. 3 taps and average them?
My BLtouch has quite large variance in its probe distance. So I think taking the average of multiple points could be used to counteract this - or am I missing some important math/statistics here? -
Installed on corexy running duetwifi printing now no issues. Printed fine, also installed on delta no issues.
-
Not sure if this is a bug or that is intended, but it's something that worked differently to what I was expecting
I've noticed that G31 Z is not adjusted "live" even if I change it, I mean, I setup a Z offset (while printer is idle), then I do a mesh level (G29 S0), and I make a test print… if I stop because I want to change Z offset, that Z offset is not applied until I do a new mesh level or I restart the printer, even though the machine properties reflect the new offset.
This is not new to this RC, I noticed it during some testing I was doing several days ago, but I wasn't sure until today, when I performed a test (configure Z at -0.14, print, check, stop print, configure Z at -1.14, print, check<<same result="">>, refresh mesh, print<<1mm higher than before>>).
Regards</same>
-
You are correct, changing the G31 Z values has no effect until you probe again. To make a temporary change to Z offset, use baby stepping.
-
You are correct, changing the G31 Z values has no effect until you probe again. To make a temporary change to Z offset, use baby stepping.
Just the Z probe is required, or do I need to do the complete mesh?
-
Just finished a 30h print with 1.21RC1 on my corexy+BLTouch+single v6+Titan printer. No problems.
-
Hi, im new to the duetWifi board.
Did a update of the Firmware today.FW dirst..then Duet Wifi then the Web interfache from the page of Christian HAmmacher..Versions are now:
FW: 1.21RC1
WiFi: 1.21RC1
Web: 1.20I read something about to simulate the print but cant find anything in the Web interface…wrong version of the Interface? or something that i have to activate?
-
Hi, im new to the duetWifi board.
Did a update of the Firmware today.FW dirst..then Duet Wifi then the Web interfache from the page of Christian HAmmacher..Versions are now:
FW: 1.21RC1
WiFi: 1.21RC1
Web: 1.20I read something about to simulate the print but cant find anything in the Web interface…wrong version of the Interface? or something that i have to activate?
In the G-code file menu, navigate to the file you want to simulate. RIGHT click it. Select simulation.
-
lol..thx alot…looked for a button all day long..sometimes its can be so complicated
-
Would it make sense to use the new multi-tap feature and modify it to do e.g. 3 taps and average them?
My BLtouch has quite large variance in its probe distance. So I think taking the average of multiple points could be used to counteract this - or am I missing some important math/statistics here?My first interpretation of the function was that the "A" set the number of measured values to average and the "S" tolerance was the max allowed difference to include the measured swarm… But that would only work if you had one more parameter which is maximum retries and a smart algorithm to handle the fault cases that:
-
no number, are within the tolerances
-
some but not all, are within the tolerances
Suddenly this is not a small simple function. This is not unsolvable but will require much more work and at least for me this is a good middle way.
I really like the SMD version of the Z IR sensor you can buy on there page. Running the repeat-ability script really shows how nice this is. If the BL-touch is not as repeatable I would seriously consider changing it to something with better repeat-ability.
I think this is a good start (if not good enough), maybe this function could be improved. Especially when bed leveling, more important to be accurate than fast in my book.
Just compared a reason print to one very early in my BB life… It is amazing what i rise in quality I made since switching from Marlin to Duet. Thank for the good work.
-
-
I agree: if BLTouch doesn't give reproducible results, don't use it. Or find a slower probing speed or harder bed surface or a better make (if you are using a clone) or whatever it takes to get consistent readings from it. Trying to use a Z probe that doesn't give sufficiently consistent results when you probe the same point repeatedly is a waste of time. Except that if it's only the first probe after deployment that is out, you can do a dummy probe after deployment or use the multi-cap functionality to allow for that.
However, as there is currently no mechanism to abort G32 bed probing and whatever may have called it if probing fails, I'll probably change the next RC firmware version to print a warning but take the average of all readings, if the maximum count was reached without being within the tolerance.
-
I've been noticing some oddities with bed leveling, even before this release.
I run compensation, and average level is above 0, run it again, it's below, run it again, it's above, etc. It's like it's using old values every time it runs. I tracked this down and fixed it with G29 S2 at the top of bed.g, but shouldn't bed leveling disregard old values anyway?
also great work w/ the new bed leveling averaging. Going to test the pressure advance stuff for stupid slicers now. I've been harassing simplify3d to fix their broken g-code, but they're dense.
-
@nyt:
I've been noticing some oddities with bed leveling, even before this release.
I run compensation, and average level is above 0, run it again, it's below, run it again, it's above, etc. It's like it's using old values every time it runs. I tracked this down and fixed it with G29 S2 at the top of bed.g, but shouldn't bed leveling disregard old values anyway?
Please post your bed.g file.
-
I ran my printer for a good 30+ hrs over the weekend after the upgrade and didn't run into any bugs or issues.
The only thing I think could be happening is slower uploads when I load gcode files? Maybe its my imagination but it seems like the upload speeds are half as fast now? I thought I was seeing 700+ speeds but now 400 is the fastest I have seen.
1. I'll try resetting my router tonight.
2. I can revert back to 1.20 to make sure but I'm really happy with this version so far.Great work dc42! Thank you.
-
@nyt:
I've been noticing some oddities with bed leveling, even before this release.
I run compensation, and average level is above 0, run it again, it's below, run it again, it's above, etc. It's like it's using old values every time it runs. I tracked this down and fixed it with G29 S2 at the top of bed.g, but shouldn't bed leveling disregard old values anyway?
Please post your bed.g file.
Just added the G29 S2 which fixed it…
G29 S2 ; clear height map
M376 H10 ; correction taper after 10mm
M557 X10:394 Y4:390 S55:52
G28 ; home
G1 X0 Y0 ; move to 0,0
M400 ; wait for move to complete
G29 ; probe bed
G1 Z5 ; position
