-
Notifications
You must be signed in to change notification settings - Fork 776
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] Y or opposite X options in k-factor tuning gcode generator #104
Comments
See #105 |
It certainly should, thank you! I'm going to show my ignorance of web coding now - I want to test to verify that swapping axes doesn't cause any unforeseen issues before closing the issue. Is there an easy way to do this before the PR has been merged? Or will it require going through the whole process described in Readme.md (re: install jekyll and buildroot)? Also, I'm interested in contributing to the project and I think documentation is a good place for me to start (so yes, I'll have to go through the jekyll setup eventually). Would it be helpful for me to add some documentation of this tool to the main linear advance page? |
Either you wait until it is merged or you go through the process of setting up the buildroot. Under Win 10 and Ruby 2.2 it worked quite painlessly.
Am 18. Nov. 2017, 20:30, um 20:30, Jonathan Barchi <notifications@github.com> schrieb:
…It certainly should, thank you!
I'm going to show my ignorance of web coding now - I want to test to
verify that swapping axes doesn't cause any unforeseen issues before
closing the issue. Is there an easy way to do this before the PR has
been merged? Or will it require going through the whole process
described in Readme.md (re: install jekyll and buildroot)?
Also, I'm interested in contributing to the project and I think
documentation is a good place for me to start (so yes, I'll have to go
through the jekyll setup eventually). Would it be helpful for me to add
some documentation of this tool to the main linear advance page?
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#104 (comment)
|
Super, thanks. I guess buildroot it is! I'm on OSX but homebrew should make it painless enough. I'm looking into updating the UBL pages for current 1.1.x so I'll have to do it eventually, anyway. |
@Sineos I got the doc preview environment installed and had a chance to test this now. It's definitely a major improvement! I was able to get most of a useable test line set in PETG on the first try; didn't have any success with the original pattern direction. I think going R to L would be even better for dual extruder machines because there's still the chance for the idle nozzle to catch the end of a line... But I think the real problem here is that single extrusion lines are super fragile and easy to lift off the bed, no matter what you do. I'm wondering if it might help to add a 'frame', or even a pair of perpendicular double-extruded lines at each end of the test lines - so the pattern is more like a really dense ladder - to anchor the start and end of each test line (something like 50% overlap of linewidth maybe...). What do you think about this? I'm happy to close the issue as sufficiently resolved at this point, though. I suspect the tool will evolve with more use. |
Glad that it improved for you. I have added on option to print a frame in my repo: https://github.com/Sineos/MarlinDocumentation/tree/frame If it works like intended, then I'll add an option to activate the frame and create a pull request. |
Great, thanks! I will test ASAP. I'm doing some work on the docs for UBL right now but I should be able to test by EOD and give some feedback. Is the frame enabled by default on that branch, or do I have to do something to ensure it's added to the gcode? |
In the current version it is always enabled. When it works I'll add a setting to enable it. |
Ok I had a chance to test (both orientations) It's definitely closer, but still not there for PETG at least. Still too much chance for the frame lines to get disturbed/dragged - although in the places where they don't it definitely helps the test lines. I think if we keep following this the way to go would be to do a full rectangle for the frame, and more than one pass. Kind of like a 2+ line brim around the region where the test lines are going, with the test lines still anchored at the ends. |
New approach: https://github.com/Sineos/MarlinDocumentation/tree/rotate_pattern
If you have the chance to test it, some feedback would be welcome. |
Sounds like a good approach, and I will definitely test and provide feedback when I have a chance. Maybe today, definitely by the end of the weekend ^_^
FWIW, I'm not sure this is exclusively a dual extrusion issue anymore. PETG seems particularly bad about having the first mm or two of a line curl off the bed, and I've now seen those curls hanging up on other parts of my head - for example the bolt on the bottom of the (active) block that secures the heater. I think these changes, once we've got them figured out, will help everyone - even with single extrusion machines - when tuning for some of the more finicky materials out there. Thanks for the time you're putting into this! Despite my issues with PETG it's a much cleaner solution than the current 'print a bunch of cubes' recommendation in the docs. It's going to be great when we can just say 'print this pattern, find the line that has the most consistent width.' I'll let you know if I have any more thoughts about how to improve the adhesion issue in the meantime. |
I have pushed another update. Most notable change is an additional pattern. This one adds another printing zone, which goes from 0 to fast printing speed and back again to 0. The idea behind is to show the k-factor effect not only for speed changes but also for 90° edges where the head effectively decelerates to 0. For the frame and the test line adhesion, we could try to increase the extrusion factor, especially on the frame:
This code in the k-factor.gcode prints the frame. If you multiply all Unfortunately my printer is still down and I'm waiting for some Chinese spares, so your testing help would be really appreciated. |
Hey, sorry I didn't have a chance to do more testing this weekend. I had my printer running pretty much full-time on parts for work, and things were printing well so I didn't want to break out of that zone while I had work to build. I'll be able to test out the new changes and give feedback in the next couple days. Is the new pattern you describe part of the overall test, or something that's selectable? I don't have a branch check-out on this machine. |
No worry :-) I would be interested in feedback to:
|
OK! I've been previewing everything under buildroot since I got it set up for working on the UBL docs, so I will use that for testing. I'll give you feedback on your questions soon, hopefully this evening. So far I've been testing with PETG, which as I said I have found to be particularly difficult for beginning-of-line adhesion. Would it be helpful for me to give feedback on PLA or a more 'normal' material as well? |
I was able to do some more extensive testing of the tuning patterns today, finally, and things are MUCH improved. For feedback on your specific questions:
The only issue that I'm still seeing somewhat consistently is insufficient priming. This is probably, again, due to PETG - it tends to run a lot before extrusion starts - but I suspect it would be helpful to lengthen the priming line and maybe double or quadruple it. Doesn't waste much filament, and also probably makes it easier to clean off the bed at the end of a test. Cleaning is another place the frame (esp. double frame) helps a lot - I'm now consistently able to remove a whole test pattern from my bed intact for most runs. |
Many thanks for the feedback! I was also thinking about longer prime or a fixed position prime but that would kill the prime being relative to the pattern size / position and may cause trouble with the bed sizes. |
Additional question: I do not use any ABL and as such currently it is only triggered with a |
I think the simplest solution might be to just do the priming line a couple/few times, the same way you doubled the frame lines. Increasing the extrusion should help too, but I know that on my setup with PETG I was frequently not getting a fully primed nozzle until partway through the frame lines, and a couple of times (esp. with the alternate pattern) not until after starting the test lines. I would say 4x the prime lines - same length, just do the same little +/offset/-/offset... sequence like you do for the frame lines - would be very conservative (in the direction of over-priming, if anything) without wasting much space since the lines are so narrow. @Roxy-3D - your feedback on my following comments would be helpful!
I think it's fine for the majority of use cases, and probably the most 'generally correct' option available. I don't think it will work alone for UBL (?) but it should (I think) correctly trigger all of the other ABL variants. For UBL, which I use, there are different sets of commands people use in their startup scripts and it's a little harder to get a generally correct answer. Personally I just edit the generated g-code and change the
But different people do it differently. I think I'm probably in the minority by using a |
Latest update doubles the extrusion length. With the 2.5 factor on E this effectively gives x5 the amount primed we initially had. |
I could add a selector for ABL or UBL. Just would need some direction on the most universal gcodes to send. |
@Roxy-3D, it would be nice to get your comment on the most universal way to add bed levelling. |
Good thinking... I meant to suggest asking Roxy about the best way to do this :) Sorry I haven't been so active here. Trying to track down a couple of firmware bugs, and at the moment I'm stuck with a printer that doesn't home. I'll try the new changes ASAP, although from your comment above I suspect we're good on priming now! |
@Sineos I've still been hosed with work, not many cycles in the past week to play with this. Hopefully this weekend, if not then definitely next week. I did notice one thing when going through some of the generated gcode files that I want to mention - this is a very quick bugfix (or a problem in the Marlin documentation for M204). Your code generator creates a line that does: |
I apologize for not seeing this thread. (It is over in the Documentation
area...)
But different people do it differently. I think I'm probably in the
minority by using a G29 J variant to probe the bed on each print;
a lot of people just load a mesh or use the active one. Again I don't
think G29 alone will activate UBL, but I'm not sure that any
other variant of G29 with arguments would be accepted by the other
leveling options.
With UBL enabled... A G29 with no other commands does nothing. I
don't think there is any common command set across the various bed leveling
systems.
…On Thu, Dec 14, 2017 at 6:12 PM, Jonathan Barchi ***@***.***> wrote:
@Sineos <https://github.com/sineos> I've still been hosed with work, not
many cycles in the past week to play with this. Hopefully this weekend, if
not then definitely next week.
I did notice one thing when going through some of the generated gcode
files that I want to mention - this is a very quick bugfix (or a problem in
the Marlin documentation for M204). Your code generator creates a line that
does:
M204 S500 ; lower acceleration to 500mm/s2 during the test
But this doesn't match the documentation for M204. According to its doc
page, I think you want M204 P500 to change the printing accel.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#104 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIA9YuObHNqeFOprtmUN7js5ifXE-_q1ks5tAblSgaJpZM4Qi5mk>
.
|
Feature request:
First, I want to thank whoever recently added the k-factor tuning G-code generator - this is AMAZING. I've only recently started playing with linear advance, and it definitely lowers the barrier to entry with respect to tuning.
Since I have zero experience with HTML or JS, my request is this: I would love to see an option to do one (or either?) of the following:
The reason is this: I have a dual extrusion machine, with the primary nozzle on the right side. With the default motion (L to R in most coordinate spaces, I think), this means that the inactive nozzle is dragging right over the beginning of each line.
With some materials this isn't so bad - PLA for example - but I've tried numerous times to print test patterns with PETG to no avail. There's too much tendency for the beginning of at least one line to lift a little, then the inactive nozzle grabs it, and I end up with a tangle of filament that kills the rest of the test print since these are all single extrusion, single-layer lines.
In my case, which I think is representative of many dual-extrusion machines, either reversing the direction of the test lines or printing them in Y rather than X should completely solve this problem. This isn't a symptom of poor dual extrusion setup IMO, just a consequence of the fact that sometimes there's a tiny amount of peel at the beginning of an extrusion.
If nobody wants to jump on this maybe it will be an excuse to learn a bit of JS... but real life is keeping me pretty busy right now, and I'm hoping to contribute to the project and documentation in other ways.
The text was updated successfully, but these errors were encountered: