[FR] Y or opposite X options in k-factor tuning gcode generator

[bjarchi]

[FR] Y or opposite X options in k-factor tuning gcode generator

[Sineos]

See #105
Hope this solves your issue.

[Sineos]

Many thanks for the feedback!
Indeed the prime extrusion was very conservative (calculated like a standard line). I just pushed an update to increase the prime extrusion by x2.5.
For my printer I usually prime on 100 mm move with E10. Now the default setting pattern will prime for a 125 mm move with E12.4

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.

[bjarchi]

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?

[Sineos]

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 <[email protected]> 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)

[bjarchi]

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.

[bjarchi]

@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.

[Sineos]

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 you find time, please test it. My printer currently is down for maintenance and I'm waiting for some spare parts.

If it works like intended, then I'll add an option to activate the frame and create a pull request.

[bjarchi]

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?

[Sineos]

In the current version it is always enabled. When it works I'll add a setting to enable it.

[bjarchi]

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.

[Sineos]

New approach: https://github.com/Sineos/MarlinDocumentation/tree/rotate_pattern

• Adds an option to rotate the test lines in 45° step (clock wise). This should allow you to move the pattern out of the second extruder's path. Rotating by 180° would effectively give a R to L print.
• Option to print a frame. Two lines on each side. Test pattern overlaps with one line on full line width
• Option to control the spacing between the test lines

If you have the chance to test it, some feedback would be welcome.

[bjarchi]

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 ^_^

Adds an option to rotate the test lines in 45° step (clock wise). This should allow you to move the pattern out of the second extruder's path. Rotating by 180° would effectively give a R to L print.

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.

[Sineos]

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.
The new pattern IMO makes only sense for a small k-factor range with an increase test line spacing.

For the frame and the test line adhesion, we could try to increase the extrusion factor, especially on the frame:

; print anchor frame
;
G1 X49.8096 Y92.9148 F7200 ; move to frame start
G1 E1
G1 X89.4075 Y132.5128 E2.23508 F1200
G1 X89.747 Y132.1734 E0.01916 F1200
G1 X50.149 Y92.5754 E2.23508 F1200
G1 E-1
G1 X106.7175 Y36.0068 F7200 ; move to frame start
G1 E1
G1 X146.3155 Y75.6048 E2.23508 F1200
G1 X146.6549 Y75.2654 E0.01916 F1200
G1 X107.0569 Y35.6674 E2.23508 F1200
G1 E-1
;

This code in the k-factor.gcode prints the frame. If you multiply all Exx, e.g. with 1.1, it will increase the extrusion by 10%. Alternatively you could use the Extrusion Factor, which does the same but it will also affect the Test Lines.

Unfortunately my printer is still down and I'm waiting for some Chinese spares, so your testing help would be really appreciated.

[bjarchi]

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.

[Sineos]

No worry :-)
The new pattern is fully selectable. There is just one thing: The new script partially relies on jquery and css, which both are only available under buildroot. The pure html + js will look crappy and and some details will not work. So if you have the chance test it under buildroot.

I would be interested in feedback to:

• How does the alternate pattern work in terms of adhesion and k-factor determination. I guess the general range is better determined with the standard pattern and fine tuning could be done with the alternate one.
• Is the line spacing of the double frame ok?
• Does the double frame improve adhesion?
• Would the frame profit from a higher extrusion? In the last commit I changed to Extrusion Multiplier to be only applicable to the frame. You can now play with a higher extrusion right from the html settings.

[bjarchi]

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?

[bjarchi]

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:

• I didn't have much luck with the alternate pattern, but only a couple of attempts so far and I now think it was some kind of machine error on my part. It looked at first like there was under-extrusion in the pattern, but closer inspection revealed that I was way too low in Z and intermittently blocking flow by hitting the bed. Could be an old setting that got pulled from EEPROM but I'm still investigating... using a probe and UBL so it was some kind of probe inconsistency or z-offset issue that only seemed to affect my trials with the new pattern (the g-code looks fine though). More feedback on the new pattern this weekend.

  • It does seem like having the corners will be another useful window into how well linear advance is working, and in theory that pattern should give better adhesion as well (as long as no lines break)

• Line spacing on the double-line frame looks great, and the double frame does seem to help with adhesion and priming

• I don't think added extrusion in the frame is necessary, but it's nice to have that knob to tune.

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.

[Sineos]

Additional question: I do not use any ABL and as such currently it is only triggered with a G29. Is this ok?

[bjarchi]

Indeed the prime extrusion was very conservative (calculated like a standard line). I just pushed an update to increase the prime extrusion by x2.5.
For my printer I usually prime on 100 mm move with E10. Now the default setting pattern will prime for a 125 mm move with E12.4

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!

Additional question: I do not use any ABL and as such currently it is only triggered with a G29. Is this ok?

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 G29 to:

G29 L1         ; Load mesh from slot 1
G29 J          ; Do 3-point probe to 'tilt' mesh

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.

[Sineos]

Latest update doubles the extrusion length. With the 2.5 factor on E this effectively gives x5 the amount primed we initially had.

[Sineos]

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.

I could add a selector for ABL or UBL. Just would need some direction on the most universal gcodes to send.

[Sineos]

@Roxy-3D, it would be nice to get your comment on the most universal way to add bed levelling.

[bjarchi]

@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!

[bjarchi]

@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.

[Roxy-3D]

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> .

[Sineos]

@bjarchi
Good catch. Thanks.

@Roxy-3D
I can add a selector for various bed leveling schemes. Would you please propose the correct gcodes to send for ABL, UBL etc?