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.
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
Ok, so I finally got things fixed and have gotten a successful release! If you've been watching the repo, I'm sure you've seen all the various deleted and re-created releases. I was having some trouble with the software update plugin, the link to github, and versioneer. All that has been (hopefully) fixed. You can install that release, but be sure to uninstall and clean your current instance. It will probably work without doing that, but no need to take chances.
I think you'll enjoy the new release. It's got lots of goodies now 
2 Likes
The release looks great. However, I’m printing what is essentially a cylinder about an inch in diameter. With the plugin generated GCode, it goes what seems like half the speed compared to running it with the regular GCode.
I have edited my firmware to use the values you suggested.
Any ideas why that is happening?
Probably still firmware issues. See this issue on github.
Edit: feel free to chime in on that issue, btw. I think that is the best way to gather information about the problem.
I just installed this and ran it on my current print, as I had stuttering .. now its just slow on printing where I had the stuttering before .. im on Marlin 2.0.5.3, Creality CR10s.
What can I provide that helps on improving the plugin?
A note on print time on the UI (not the actual):
original gcode: 6.5 hours
AW gcode: 3.5 hours
So I would need to adapt Marlin as well besides the plugin or am I missing something?
Yes, the slowdown is (probably) not caused by incorrect gcode, but rather some issues with segment interpolation within Marlin. One of the two issues (incorrect segment length calculation) has been corrected already within the marlin source. The other issue we found in the thread I linked on github. Feel free to comment in that thread about this issue so that we can keep all the information in one place.
1 Like
quick note though arc_support is enabled in my Marlin I will make future comments on the Github thread
1 Like
Just wanted to say Thank You for making this plugin. I've been chasing some Z-banding issues on my Hypercube for a couple of weeks now. I thought I had it completely solved until I tried to make a cylindrical lead screw coupler earlier this week.
Quick info: I'm printing with Overture PETG, using Cura 4.6.1, on my custom built hypercube running a 32-bit EZboard from TH3d, firmware based on Marlin 2.0. (235 nozzle, 65 bed)
My normal geometric prints had great walls, even ones with curves, but complete cylinders showed some really weird artifacts. I tried printing directly from the SD card, and the print had the exact same artifacts in the exact same locations as the one that came from Octoprint, so I knew it had to be a G-Code issue
Then I tried disabling "Compensate Wall Overlaps" in Cura, which helped a bit, but also introduced some other weird artifacts. Then I tried your plugin, and immediately could see the difference.
Here is a photo (I'm a new user, so I can only post one image)
Nearly perfect walls again, but there is a weird issue I noticed that I think is happening during layer changes.
It looks like the print head pauses for a bit (or just travels really slowly) at layer changes, which can create a blob. The first print with Arc Welder lead to some bad blobbing at the corners where layer changes were happening. I relocated the z-seam to better hide them, but the pauses still happen during the printing.
I was able to mostly hide the blobs created by the print head pausing by moving the z-seam around.
here is a video showing the pauses happening on the final printed cylinder.
1 Like
Well, mostly excellent!? Why don't you join the party over in this issue in the Arc Welder plugin repository. That thread was originally started by someone with Prusa firmware, but others with Marlin 2.0 started to chime in (I may yet separate the two). Some issues were found with the G2_G3.cpp file that have been fixed for some users. One of those two issues has already been committed in the official Marlin 2.0 repo. Check out the gist I posted about that file and feel free to chime in within the thread.
Also, for anyone else having issues with the Prusa firmware (no stuttering, but small curves come out flat), I'm working on getting a pull request approved now that will hopefully help.
2 Likes
Just spotted this in the Marlin GitHub...
Not helpful... 
I intervened.
4 Likes
Someone is always trying to raise the difficulty level it seems Thank you for your support quashing that issue.
I understand the purpose of that pull request, but in my opinion targeting old severely constrained boards with the default settings is not an appropriate path for growth.
It isn't, and neither is refusing heartbeat messages on serial because they would "spam humans connecting through minicom" but that's how things are done here... 