FormerLurker

8 bit is fine. However, I have quite a bit of experience dealing with that fork. Most of this issue was spent figuring that out. At that point, it turned out arcs were disabled in the firmware. In this issue on the firmware repo a few settings problems were identified and fixed in this commit. However, I do not know if the arc fixes from Marlin 2.0.6+ have worked their way into that fork. You may want to post on knutwurst's repo and ask about this.

I understand things can be frustrating, and appreciate your being reflective. It is very important that you make sure Arcs are enabled on your printer, though. I have seen this issue 100s of times, and it's usually Creality printers or custom built firmware. Also, to be clear, I am NOT putting down your printer, any creality printer, or any other printer at all, just pointing out that this is relatively common. In fact, I bought my folks an Ender3, and am happy with it. Disabling arc support is usually done to save memory so that other features can be added. If memory is not an issue, generally arcs are not disabled. Trying to print an Arc Welded file without arcs enabled is like trying to run Cyberpunk 2077 without a GPU, it just won't work. If arcs are disabled, your printer simply won't understand the commands it is sent, even if the commands themselves are correct. G2/G3 (arc commands) will simply be skipped in this case by your firmware. If you are using relative extrusion, you will get just a mess of spaghetti around all curves, and the infill might even look (mostly) fine. If you are using absolute extrusion in your slicer (definitely possible) that will cause huge blobs, nasty sounding noises from your extruder, and all kinds of other issues. What you will be left with is a total mess. Since that's pretty much what you are describing, I'm almost certain you would need to enable arcs in your firmware to get arc welder working. Again, I'm saying this because of my experience helping dozens and dozens of users with the exact same issue.

@brunoosti, Those settings look fine, but the slowdowns are concerning. What version of marlin are you running? At least 2.0.6 is recommended, else you may have slowdowns depending on your other settings. There have also been fixes since 2.0.6, but I hear there may be some issues in the latest bugfix branch if you are running OctoPrint, so stick with the stable release for now.

That means they are enabled, so you should be good to go! If you are using OctoPrint, that will disconnect your printer, but that's expected, and causes no harm. Just reconnect and know that empty G2/G3 commands will NOT be generated by ArcWelder (unless there is a bug, lol). Just open the file and search for G2/G3 commands and see if there are any. If you are using OctoPrint, you might want to try out the beta version of the Arc Welder OctoPrint plugin (you can disable it later when you are comfortable). It has a firmware checker, will give you a ton of useful statistics you can use to see what ArcWelder is doing, and has detailed help files explaining all of the settings. That might be useful for you until you are comfortable enough with ArcWelder to switch back to the cura plugin, which is a lot faster and more convenient in many cases. If you are interested, see these instructions and leave any feedback (please do) here. Also, FYI, the new version will not even attempt to re-weld any files that were previously welded, so nothing will happen if you are welding in Cura.

This software is free, was made by people working in their free time, and the source code is open and available to anyone who wants to take a look and help improve it, so please keep that in mind. Second, your problem is almost certainly due to arcs being disabled in your firmware. I'm guessing you upgraded your printer with a bed leveler, and flashed new firmware for that. I see lots of these firmware forks, and most of them have arcs disabled for creality printers due to limited program space. It's very easy to check to see if arcs are enabled within your printer's firmware by sending the following command to your printer (easiest way is with the OctoPrint terminal) and see how it responds: G2 If it says 'unknown command' or something similar to that, arcs are disabled and you cannot print any gcode that contains arc commands. If it says, "Invalid Parameters", arcs are enabled and the fault is likely with ArcWelder itslef.

@fieldOfView, I noticed that the default options have both 'Min Arc Segments' and 'MM per Arc Segment' filled in. That will kick in firmware compensation. Not sure if that's a good thing or a bad thing. Anyone using Marlin 1.0 (or a fork) will have fewer issues with small arcs, but other users will have less compression around tight curves. I'm wondering if an 'Enable Firmware Compensation' box should be added that shows these two controls when checked? If it is disabled, both options can be set to 0, which will disable firmware compensation. Not sure if it should be enabled by default or not, honestly. Maybe some help could be included? I have this feature documented now in the ArcWelderLib readme. In any case, I thought I'd bring it to your attention. Also, looks like the popularity has spiked over the last week! Hopefully it's bringing you more patrons! I may have to sign up myself 🙂

@brunoosti, Sorry if you already mentioned this (I scanned, but could not find this), but what version of Marlin are you running? I know some changes have been made to JD recently, and am curious in case I run across an issue that is related.

@fieldOfView, I got a few issues about UltiGcode, and went ahead and added support in the latest master. Working on a release right now, so no need to deal with this in the plugin.

It is 100% a visualization problem. If you have OctoPrint installed anywhere, I highly recommend using 'PrettyGcodeViewer' to look at these files. It uses a port of Marlin 2.0's arc interpolation algorithm, so you can be sure what you are see is what you will get. Barring that, Simplify 3d is the 2nd best viewer, though it also renders arcs with a relatively low resolution (think scad's facet setting if it is low). It is still very good. NCViewer.com is SO SO close to being great, but it does need a few tweaks, like ignoring some gcodes (it treats progress gcodes like arcs for some reason) and increasing the number of facets per arc.

Also, @fieldOfView, I want to personally thank you again for fielding all these questions. I really appreciate all of the great work you do. I understand the sheer effort it takes, so I'm doubly thankful!

@snarg, I ran your welded gcode through simplify to see what I could find, and it doesn't appear as though the speeds are unreasonable. However, I've gotten a couple reports about your exact printer and firmware doing exactly the same thing. See this issue in my GitHub repo.

@ahoeben, regarding the Ultimaker, should I be considering adding this capability to the ArcWelder console app? If so, can you point me to some reference for how this works, and samples of the gcode header in question? I'm just totally ignorant about ultimakers. If I had one, I would have probably know this, and accounted for it.

> Let's see if pinging @FormerLurker works. It always does 🙂 > The ArcWelder command returning an exit status of -11 means it encountered a "Segmentation vault" I've actually never received a segfault report for ArcWelder before. However, I see in the log this is being generated from OSX, and I've never run on that OS before (I don't have access to it at all). However, perhaps it could be executed from the command line with the following parameter: --log-level=DEBUG That should give me an idea where it is crashing at least. The console output would need to be saved (how does one do output redirection in OSX?) and posted somewhere I can see it.

Fyi @ahoeben, some issues with the binaries you are using have been discovered: 1. In some cases depending on the gcode precision, both I and J can be rounded to 0, which will cause a 'bad parameters' reply from the printer. If running from Octoprint, this will disconnect the user unfortunately 😞 In these cases the radius is so small that simply skipping the command would be fine. In every case I've seen the distance traveled was right around 0.001mm, but due to the disconnect this needed immediate correction. 2. This should not really affect the cura plugin, but in some cases the 'dynamic gcode precision' feature I added a while back can cause the precision to grow beyond what marlin allows in a single line of gcode. I've seen this so far only from a user who ran their gcode through a tool that was producing ridiculously high precision (like 10 decimal places or something). Arc welder saw this and bumped up the precision accordingly, causing the problem. I've added a few parameters to control this, but I think the cura plugin should simply match the output of cura itself. The default is 3 decimals for XYZIJ, 5 for E and 0 for F (integer F), and dynamic precision is disabled. I worked on the above issues for a long time, and was in the middle of some fun performance enhancements. I decided to merge the code after fixing issues 1 and 2. The result is about a 50% reduction in processing time. Still testing all of this. Hopefully these binaries stabilize soon 🙂

Updating this to note that the issues pointed out by @cuq have been resolved. I moved some code around to support counting of arcs aborted due to the firmware compensation, but missed a step. In my haste I just replaced the 1.0.0 release (though in the future I will update the version number appropriately, but have been putting out forest fires recently and breaking my own rules). The new artifacts are available in the 1.0.0 release. There still could be some small glitches with the firmware compensation. Testing that more completely now. @cuq has suggested that a default of 14 for minimum arcs works better than 12, as I had been using. If you are using any version of marlin that does not contain the enhanced arc settings, I highly recommend using the firmware compensation, even if it does reduce compression somewhat.