FormerLurker
-
Posts
20 -
Joined
-
Last visited
-
Days Won
2
Content Type
Forums
Events
3D Prints
Posts posted by FormerLurker
-
-
17 hours ago, ScoutParamotor said:
Not trying to be rude just annoying when 3D printing doesn't go your way. Everything is stock on my ender 3 V2 PRO and firmware is version 1.0.2. Just doesn't want to work. 😔
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.
-
58 minutes ago, JRANGER said:
Reported error: G2/G3 bad parameters
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).
QuoteI don't see any G2 codes being sent but a lot of G1 codes in my OctoPrint
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.-
2
-
-
3 hours ago, ScoutParamotor said:
When I enable Arc welder on my printer (ENDER 3 V2 PRO USING CURA) it just freaks out. it over extrudes by like 500 % and doesn't even print the model. Can SOMEONE PLEASE RESPOND to this post because this problem is really annoying. I think the code contains so many bugs..... very disappointing 😑😡
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.-
3
-
-
@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.
-
2 hours ago, brunoosti said:
There you go.
Maybe it's just the graphical representation,? But this is what i see in NC viewer:
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.-
3
-
-
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!
-
1
-
1
-
-
@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.-
1
-
-
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 🙂-
1
-
1
-
-
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.-
2
-
-
@cuq, either works. One is shorthand, the other is a bit more verbose. This is a standard feature of the command line parameter library I am using.
-
So, I made an executive decision and renamed allow---z-axis-changes to --allow-3d-arcs. I figure that's easier to understand, and better to do it now than later. The artifacts should be rebuilding as we speak.
Also, there is no raspberry pi console app in case anyone is wondering. I can build one, but still working to get a self hosted runner so that it's automatic.-
2
-
-
@Cuq, it looks old because I haven't updated the master branch. Find the most recent artifacts here. You can see which branch they are associated with on the right. Find 'ArcWelder' or 'ArcWelder.exe' in the bin folder of the zip and run with the --help flag for documentation. Let me know how it goes!
-
1
-
-
I can't seem to edit my post yet, but here is a correction to the firmware compensation parameters:
--mm-per-arc-segment=1 --min-arc-segments=12
I had a dash where it should have been an equal sign. -
So, I wanted to mention two changes to Arc Welder:
1. Vase Mode (3D arcs) seems to be working well so far. I've printed several, and haven't had any issues However, I'd still love to have a few testers if anyone is interested. Here is a link to the original feature request.
2. I added two new settings that enable Firmware Compensation for printers that do not have all of the goodies in Marlin 2, like MIN_ARC_SEGMENTS. Typically these printers have only one real arc interpolation adjustment: MM_PER_ARC_SEGMENT, which is typically set to 1mm. This is producing the flat edges that @Cuq saw. It simulates the MIN_ARC_SEGMENTS setting (I suggest setting this to 12) at the cost of producing fewer arcs. See this link for details and photos showing the differences of having this enabled vs not.
For the console application, you can enable 3D arcs with either of these two flags: --allow-z-axis-changes, -z
I'm thinking of changing the parameter to --allow-3d-arcs since that is more intuitive. Let me know if this seems reasonable.To enable firmware compensation BOTH of these flags must be included and must be greater than 0: --mm-per-arc-segment and --min-arc-segments (or -s and -a if that's the way you roll!)
For most firmware that has the 'flat arc' issue, adding this will suffice: --mm-per-arc-segment=1 --min-arc-segments-12
Also, the code for both of these enhancements is in the devel branch of both the ArcWelderPlugin and ArcWelderLib.
Thanks to @fieldOfView for getting this done! It would have been a couple of months before I would have gotten around to it, and I'm sure it would have taken me 10x longer to do :)
-
5
-
Arc Welder Anti Stutter plugin
in UltiMaker Cura
Posted
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.