-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FR] Modify the Bed Mesh Validation feature to support printers which have been converted to DIrect-Drive and/or All-Metal Hotends #303
Comments
Below are some comments and photos of testing I have carried out with the G26 Mesh Validation Pattern at the request of @Thinkersbluff . For the sake of my own sanity, I'll put everything here under a single post and link to FRs/issues as needed. GeneralIn all tests, the printed pattern seems over-extruded: at the end of arcs there is a noticeable excess of material, and the printed lines of corners, arcs and full circles are ridged, indicating over-extrusion. There was no visible stringing between pads, sometimes stringing occurred but was contained within pads. I know from experience that a single layer print onto a bed with good adhesion (e.g., PEI flex plate) generally results in something that is quite difficult to remove, so there has to be a balance. While this test pattern is over-extruded, it is at least easy to peel off. There are 4 test sections below. I ran Tests 1-3 multiple times throughout the course of this testing. My hotend is stock aside from 2 small modifications: a different bowden tube coupler where the tube meets the top of the heatbreak, and a larger (quieter) fan blowing across the heatbreak that is still accommodated within the stock hotend shell. My extruder is not stock, it is an aluminium dual gear extruder upgrade kit, same as those for the CR-10, Ender 3 etc. https://www.amazon.co.uk/gp/product/B07WGGR8CL Test 1 - Community Firmware release 6.1 G26 Mesh ValidationThe 2mm initial prime did not always produce output. Obviously it depends what happened at the end of your last print. My usual end gcode for real prints has a hefty retraction, followed by a large prime in my usual start gcode as this keeps the nozzle pretty much always clear of oozing for ABL/homing. When running multiple G26s in succession there was some output, presumably because it is not retracting at the end of the G26 print. Test 2 - G26 Mesh Validation Pattern starting away from left corner - FR #301I used the following commands to run G26 starting near the middle of the bed, retaining the default 2mm prime amount:
Again, it was variable whether or not the 2mm initial prime produced any output and the small prime line was also variable (one of them was quite good, as per photo below). The priming square was always ok and starting printing near the middle of the bed always resulted in the front-left corner pad printing correctly. Test 3 - G26 Mesh Validation Pattern with 15mm initial prime - FR #302I used the following commands to run G26 starting near the middle of the bed with an initial prime of 15mm:
The 15mm initial prime was easy to grab with tweezers. All prime lines and pads printed well. I also ran this same test using a firmware.bin file supplied to me by @Thinkersbluff that uses the bed dimensions divided to determine the centre position, rather than hard-coded values, and it worked as expected. Test 4 - G26 Mesh Validation Pattern with 15mm initial prime starting in left cornerFor the sake of completeness, I used the following commands to run G26 with a 15mm initial prime and starting in the front-left corner of the bed to see what would happen with the first pad:
The 15mm initial prime was again easy to grab. The small prime line and priming square printed nicely. The front-left pad did not print properly. I cancelled the print shortly after. ConclusionsStarting near the middle of the bed always results in all pads printing ok, whatever initial prime value is used. Increasing the initial prime to 15mm makes it easy to grab with tweezers and improves the printing of the small priming line. The retraction Q value of 4 appears to work quite well for my particular setup, as there is no significant stringing. |
Thank you for the rigorous tests and detailed report! That firmware.bin I sent you also included reducing the Q factor to 1.0, instead of 4.0, as proposed in this FR. That final string at the end happens every time on my system, also. I share your suspicion that G26 does not retract at the end of the pattern. I have a video of the nozzle dragging filament upward as it lifts at the end of each arc. I need to edit the size from 93mb to 10mb or less, to post it here. I’ll try. It looks like ether the extrusion continues a tad longer as the nozzle lifts, or the nozzle pulls the last extruded bit free of the bed. When my Z Offset is “spot-on”, each arc ends in a little round “ nozzle noseprint.” When the offset is suboptimal, those same strokes produce “torn ends” |
You're welcome, happy to help. That's interesting that you see differences in the ends of the arcs. Mine were always like your second photo. I wonder if my Z-offset is too low? I'll experiment a bit more. Update: Increasing my Z-offset by 0.1mm has made the pads appear much neater. I'll try a real print with this new offset and report back. Update 2: The print wouldn't stick, it was too far away. If I run the Z-offset adjustment procedure with the extra 0.1mm there is no grab at all onto a piece of paper. |
I found a difference of +/- 0.01mm was enough to go from "nose-prints" to "shredded ends", in my experiments. Interesting that the validation pattern would adhere when there was no grip on the paper. Perhaps a function of the extrusion flow rate of that function overcoming the additional gap. Definitely still need to calibrate Z Offset "the usual way". For now, those "noseprints" are a curiosity, but "babystepping" the first layer is probably a more "mainstream" and practical tactic. BTW - fun studying those patters so close up, ain't it? |
Is your feature request related to a problem? Please describe.
The current Bed Mesh Validation pattern feature warns that it is only compatible with printers which can tolerate 6mm of retraction or more.
That means that CF users who have converted their printers to Direct Drive extruders and/or all-metal hot ends should not be using that feature, or they risk creating a clog in the cold zone of their hotend.
Yes, I see (now) that there are several lines of fine print at the top of that screen, warning users that their systems must tolerate 6mm of retraction. My personal experience, however, is that users may not stop to read all of that & may not realize their converted systems should not be using the higher retraction settings, even if they do read it...
Line 72 of MeshValidationHandler.cpp actually sets the Q (retraction multiplier) factor to 4 (so tolerating 4mm of retraction would be ok).
To be compatible with Direct Drive systems, that factor should be 1 or less, as it is currently specified to be, in the default CF6.1-Final Configuration.h file.
[NOTE: Watching the pattern being printed, it seems clear that whatever retraction G26 is doing, it is not helping draw a string-free pattern, so making this change may not impact the performance of this feature on Bowden systems anyway...]
Are you looking for hardware support?
Yes.
Direct-drive conversions and All-Metal Hotend conversions are particularly and increasingly popular.
Some (many?) new users of 3D printers are not aware that retraction settings such as Cura's default 6.5mm retraction present a risk of hot end clogging. Those individuals will then also not know that they should not be using this feature for the same reason.
Modifying line 72 of MeshValidationHandler.cpp to change Q4 to Q1 will make this feature safe for users of all CR6 configurations.
Alternatively, modifying the firmware to use the Q value programmed into Configuration.h - although a more complex software edit - would preserve the option of using configuration-specific values of Q, for those able to compile their own firmware.
Describe the feature you want
I want to be able to use the Bed Mesh Validation pattern with my Direct Drive Dragon HF/Orbiter CR6-SE.
NOTES:
The text was updated successfully, but these errors were encountered: