I finally got around to trying this out. I printed the test print for the famous collapsible sword. I felt this was a good test since it prints 3 cylinders, nested in each other. The file size was 2.9mB and became .3mB.
The front part of the cylinders looks like they had a slight improvement. However, the back, where the z seam is located, appears to be much worse. Hopefully the pictures show it, but it almost seems like some kind of under extrusion right before the z seam.
And the strangest thing is that in the before-arc print, the nozzle would just go back and forth in the circle in very smooth motions. However, on the arc-enabled print, it would make a circle, but when it started to approach the z seam it would noticeably start slowing down over the course of about 2 seconds. Because of this, the print took a few minutes longer. Whatever that slowdown was is what caused the poor print quality but I’m not sure what made it do that. Could it be linear advance?
These 2 pictures are the same thing, but one of them, I am blocking the light with my hand to reduce glare. The top ones in each picture are the arc-enabled prints.
You aren't the first person to report this unfortunately. I'm trying to figure out what is going on, but I suspect some firmware issues unfortunately. I think what we need is the smallest possible gcode file necessary to replicate the issue. Maybe you could creat an issue on GitHub, or join in in the existing one, and help me create a test gcode file?
Edit: it could be linear advance (set k=0 to disable), junction deviation, or other firmware settings. It doesn't seem to happen with every printer. Figuring out exactly what the issue is will be the first step to fixing this. I wish it were the gcode itself, but i have seen no evidence of that so far.
Could this be it? If so, it would be extremely easy to swap out 0.0 for seg_length in g2_g3.cpp!
Edit:. The latest code only uses 0 for the final segment length. The commit was quite recent.
I don’t know if that is it. My slow downs and speed ups are no where near that jerky. It’s pretty smooth.
But I can definitely test if you need me to.
Ok. So it looks like those 2 settings you guys were discussing in the firmware might have caused the problem. I just had the defaults for those for marlin 2.0.5.3. I changed the mm one to what you suggested and the other was 24 and I bumped it to 64. Not sure which. But the quality is perfect now.
64 is a bit high for very small circles, so you may see stuttering in other prints. Try 24-36 if yo see any slowdowns cornering tight radiuses.
Seems logical to use something with arc (or maybe segment) in it but at the same time describe it's function. Is the primary intention is to reduce the size of GCode or to produce better quality prints? If the former maybe ZipArc or ArcZipper or Arcer if the latter ArcSmooth or SegmentSmooth or just Smoother.
I guess you'd want to append OctoPrint_ if it's implemented as an OctoPrint plugin.
FWIW which frankly isn't much, I think a standalone slicer post-processor makes more sense. Why burden OctoPrint with files that are twice as big as they need be. Also you'd get a whole bunch more users that way. If it's a good as the results so far slicers will add an option to output via your app.
I have posted working console versions on github, just no binaries yet. There is even an inverse processor (convert g2/g3 back to g1) i have been using to test some marlin modifications i have been working on.
Any chance to get this as simple slicer post processing script too?
You can as long as you can compile it. Check my GitHub repositories for ArcWelderLib. It is the ArcWelderConsole project that contains the code necessary to build the executable. Otherwise I will post the binaries once i have a chance to build them for all environments. I am currently doing some debugging.
Thirteen parts @ 4+ hours.
Before: 11,017,132 bytes
After: 5,235,468 bytes
1 Like
@FormerLurker Just saw you posted an update on GitHub. Does this mean that both relative and absolute extrusion modes will work?
Yes, it should. Be sure to read the release notes before installing otherwise you may miss a lot of goodies that have been added. Fyi, the software update check isn't working right, so I will probably amend that release since nobody will be getting update notifications.
Absolute extrusion should work perfectly since I stripped out extrusion adjustment. Turns out the adjustment was really too small to make any noticable difference, and perhaps more importantly, no firmware I have seen performs any adjustments when interpolating arc segments. That means an unadjusted extrusion value will be closer anyway. Removing the adjustment also speeds up processing by around 20-30%.
This is because your releases are pre-release and not full releases in the github repo. If you make that a full release the software update will pick it up I think. Not sure when there is other stuff in the release name, ie 0.1.0rc1.dev2 might not work, but 0.1.1 should. You're doing things I've never seen before in the plugin_version in setup.py though, so not sure.
I have the release, maintenance and development channels all set up, but the semantic check is failing. I've added commit info to the version to help me figure out who is using what when ppl use non-release (i.e., install from a branch or something), and that messes up the built in checks. I know the capability exists to use other version comparisons, but am still figuring that out. I'll have to update octolapse too eventually.
Hey, there is a retraction issue in the release.. Please uninstall if you've installed it. I'm removing the release now.
Interesting. I was under the impression that plugins couldn't hook into pre-release channels, etc. the way that OctoPrint can, and based on the docs some of the pieces you're providing aren't documented, ie prerelease.
https://docs.octoprint.org/en/master/bundledplugins/softwareupdate.html#sec-bundledplugins-softwareupdate-hooks-check-config
Yeah, I was trying to mimic OctoPrint as closely as possible, including the Versioneer commit info. Minus the Versioneer stuff, it's been working in Octolapse for a long time. Basically, it's looking at the software update settings and switching branches based on that. Then I just have to make sure that I update each branch appropriately when i do releases. It respects the 'prerelease' tags in github, so i can release for ppl who are tracking devel rcs or maintenance rcs so they get updates sooner.
1 Like
I posted a fix to the rc/devel branch. I will re-release once my test prints finish (face masks, hooray!). I used a less than instead of equal to by mistake in the c++ code that determines if an E parameter is needed. I didn't notice it because I was working with absolute extrusion, and forgot about the impact to relative extrusion, lol.
So I've successfully printed a few face shields using code sliced in different ways using relative extrusion, which verifies that the retraction issue has been solved. I will re-release as soon as I get the software update stuff working. You could install from the rc/devel branch if you want an early copy.
1 Like
