FormerLurker / ArcWelderPlugin

A plugin for OctoPrint used to convert G0/G1 commands to G2/G3 commands. Reduce the size of your gcode files, and reduce number of gcodes per second sent to your printer.
Other
445 stars 26 forks source link

Feedback - V1.0.0 #40

Closed FormerLurker closed 3 years ago

FormerLurker commented 3 years ago

If you have any feedback for the initial Arc Welder release, I'd LOVE to hear it. Let me know what you like, what you love, what you hate, or any ideas about the future of Arc Welder. If you believe you have found a bug, feel free to mention it here. I may ask you to create a new issue.

Thank you in advance for your contribution!

mild-lemon commented 3 years ago

I do understand the idea and I admire the effort put into this Arc Welder.

However, when looking at the full processing chain from .stl to physical object, I have yet to grasp why I would want to re-weld the arcs in post-processing the gcode after slicing? Wouldn't patching the slicer do the trick to produce arcs in the first place?

KapJI commented 3 years ago

I wonder if this can be turned into Cura post processing plugin. Those are also written in python and can access and modify the whole gcode. I think local computer should have much more horsepower than raspberry pi. Example of such script: https://github.com/Ultimaker/Cura/blob/master/plugins/PostProcessingPlugin/scripts/PauseAtHeight.py

cp2004 commented 3 years ago

.stl

re-weld

Here lies the problem, and likely the reason this hasn't been implemented by slicers. STL files are made of a bunch of triangles, which are therefore straight lines. If you were to open what you thought was a curved surface, then it is actually made of straight lines. So there is not re-welding, but just regular welding since they were not curves in the first place.

You are correct, it makes far more sense for a slicer to do this, but they won't so it has become a great OctoPrint plugin. (in fact, the most sense would be to use something other than STLs as a file format, but that's a massive unrealistic goal at this point...)

CRCinAU commented 3 years ago

There's been open requests for ARC support in Cura for at least 7 years: https://community.ultimaker.com/topic/1920-arc-support/

and later on here: https://github.com/Ultimaker/CuraEngine/issues/429

Yes, the slicer would be a better place to do this work - but the reality is, it probably will never happen...

As such, given that Cura is a known factor, and we know how it behaves, it's perfectly acceptable to re-process that gcode into another known factor - which is exactly what ARC Welder does - and does very well.

I've tested the output of ARC Welder on everything back to the original 8 bit boards, and the results always speak for themselves.

As such, I want to thank @FormerLurker for his hard work in making this plugin - and I recommend it to everyone who has issues printing curves - because it really does what it says on the tin...

FormerLurker commented 3 years ago

There is a console version guys, so you can add it to whatever slicer you want. I linked to it in the plugin repo page.

The octoprint plugin part of this project was cake compared to the algorithm. Also, it does weld automatically after upload, so it isn't like it takes any effort.

FormerLurker commented 3 years ago

Oh, I wanted to mention something about post-processing within the slicer. Although it is much faster than processing via the OctoPrint plugin, only Simplify3d seems to be able to correctly visualize the resulting GCode. In other words, the object will look VERY wrong in Cura, Slic3r, and PrusaSlicer. I recommend using Simplify3D (this slicer handles G2/G3 perfectly) or ncviewer.com to visualize the resulting gcode (ncviewer can show some artifacts that don't exist, but it is pretty good). Actually, even the visualizer within OctoPrint has a few G2/G3 bugs.

I think this is one of those, "if you build it, they will come," scenarios. I expect G2/G3 support to improve in both firmware and the various visualization programs. There has already been some movement, like recent additions to Marlin, and partial G2/G3 support in the Octoprint visualizer.

foxylion commented 3 years ago

I just tried this plugin on an Ender 3 v2 with a custom Marlin firmware (2.0.7.2, increased buffer sizes, 250.000 baudrate). I used the #3DBenchy to test it out. It works great so far. The quality is similar to printing from SD card. Before, without Arc Welder, the surface was messed up with zits/blobs.

Thank you a lot for your efforts, that really improves printing with OctoPrint.

One minor thing: An option to automatically select the created file after generation completes would be great. As this would optimize the following workflow:

Compared to the "current situation":

FormerLurker commented 3 years ago

@foxylion,

Hmm, it is supposed to select the new file after processing. Congratulations, you found the first bug! And it only took a little less than 24 hours :)

Thank you for your feedback.

foxylion commented 3 years ago

@FormerLurker Just tried it again manually uploading a file via OctoPrint UI. Didn't work there too. So yes, it looks like a real bug. :-) But to be honest, this the plugin is not less awesome with this bug!

Just printed again with the use of this plugin and the default configuration for Marlin 2.0.7.2 on an Ender 3 v2. -> Perfect result!

gluap commented 3 years ago

@foxylion

  • Scroll through the long list of GCode files

Just a small mitigation: the list of g-code files can be sorted by file date which at makes the scrolling unnecessary (newest up top). I actually think that having it sort by date may make more sense than alphabetically in most cases. For me, octoprint remembers the order so you only need to set it once per browser.

war4peace commented 3 years ago

Feedback: I have not installed the plugin yet, however I have tested the commands on my printer and it supports them. I have a Creality CR 10 MAX with TinyMachines3D 2.0.5 firmware - so you could add this combo to the supported list. Note: I will not upgrade the firmware anymore because I plan to switch to Duet 3 soon.

calebmah commented 3 years ago

I just upgraded to v1.0.0 and am facing an issue with arc welder messing up the skirt in a print. I am using cura v4.6.1 to slice and sending the gcode directly to octoprint from cura using the octoprint connection plugin. I had been using earlier versions of arc welder without issues.

The first file is the original gcode as sent to octoprint, with arc welder disabled. You can see the skirt around the print. The second file is the gcode after being uploaded with arc welder enabled. The skirt has become a small dot and when printing the printer extrudes a huge lump of filament at that location. I have attached images as well as links to the gcode. My settings for arc welder are also below.

A side note, it seems like arc welder also causes more travels within the circular areas, I am guessing that is because the arcs no longer align with each other? Either way, it would be nice to reduce that as well. Thanks for the great plugin!

image File 1 - original

image File 2 - welded

image Arc welder settings

war4peace commented 3 years ago

I found a bug as well. When performing star infill inside a circular shaped model, the nozzle extrudes in a straight line at expected speed until it reaches the edge of the model, then slooooowly moves following the curvature of the model until it reaches the point where it needs to go back across the layer to lay down another infill line. It only happens on one side of the shape, not both.

GCode here: https://drive.google.com/file/d/1zNAy_NOukkugZuJofqBfKqFfHPxth7GM/view?usp=sharing

FormerLurker commented 3 years ago

@calebmah, It looks like your visualizer doesn't handle G2/G3 commands properly (most don't). Here is what I'm seeing in Simplify3D for your welded file:

image

As you can see, the skirt appears properly. The travel moves appear normal too (shown in red):

image

The skirt has become a small dot and when printing the printer extrudes a huge lump of filament at that location.

That is very strange. I extracted the skirt code and ran it through ncviewer to get a second opinion, and this is what I see:

image

A side note, it seems like arc welder also causes more travels within the circular areas, I am guessing that is because the arcs no longer align with each other?

No, the endpoints of ever arc that Arc Welder produces lines up exactly with a point from the original gcode file. There should be no changes to any travel moves because Arc Welder is only modifying gcode with extrusion/retraction.

I'm not sure what's going on, but I suspect it is firmware related :(

FormerLurker commented 3 years ago

@war4peace, simplify things these layers are printed at exactly the same speed:

image

If you can point me to a gcode, or perhaps provide a video of the entire layer where the problem is occurring, maybe I can find something.

I also suggest you check for firmware updates just in case.

war4peace commented 3 years ago

Sure thing, I have taken a video of the behavior, currently uploading to Youtube, I am not sure which part of the code is the one exactly at that position, but in the video you can see layer number (it happens at all layers where there is an infill anyway) and nozzle position too. Uploading directly from my phone and it's a 4K video so might take a while. I will update with the URL when it finished processing.

FormerLurker commented 3 years ago

@war4peace, can you create a new issue so we can keep the feedback thread as clean as possible? Please fill in as many details about your printer and firmware as possible. Thanks!

calebmah commented 3 years ago

@FormerLurker Thanks for taking a look and for clarifying! It looks like there isn't a problem with the gcode after all, though it is still strange that my printer printed the same blob as shown in the viewer. I will continue to try out the plugin and maybe make a new issue if the problem happens again more frequently. Thanks!

Some further information, in case you want to dig deeper. I was using the PrettyGCode Plugin to view the gcode files. When I checked using octoprints default gcode viewer the skirt is shown as normal. I am using an ender 3 pro with the TH3d Unified Firmware and octopi 0.17.0, octoprint 1.4.2.

j-be commented 3 years ago

Just gave it a test-ride - ArcWelder is awesome! Reduced a small knob I had from 2.5MB to > 300kB. My Ender 3 Pro flies were it previously stuttered like f**k, it printed perfectly. Apart from the bug of the .aw.gcode not being selected automatically when printing from Cura this is just plain awesome! :+1:

Will report back if I run into any other issue.

In the meantime: Thank you so much, this just made my Ender 3 Pro a whole lot better!

jcharaoui commented 3 years ago

I'm really interested in testing this plugin, I've had a similar problem with my Ender-5. However I don't have a Simplyfy3D license and ncviewer.com isn't working for me. So I can't preview the GCODE that's generated by ArcWelder, which is kind of a deal breaker for me. I'd be happy to know what are other GCODE viewers out there with G2/G3 arc support.

FormerLurker commented 3 years ago

@jcharaoui, send me your welded gcode file (submit to gist.github.com, then leave a link here) and I'll analyze it and see if it looks good. Maybe I can figure out what's up with ncviewer too.

jcharaoui commented 3 years ago

@FormerLurker I fiddled a bit more with ncviewer.com and I figured out that if I zoomed out eventually I could find my model in there! Thanks for the offer, though!

talldonkey commented 3 years ago

The Prusa Mini appears to support Arc Commands via the test Arc Gcode being successful. I believe the firmware is derived from some Marlin 2.0, but not sure if it's been updated to includes 2.0.6 Arc updates. M115 output suggests no.

Here is the test I ran, and heres the M115 output.

G90
G28 X Y
G0 X0 Y0
G2 X40 I20

M115

Send: M115
Recv: FIRMWARE_NAME:Prusa-Firmware-Buddy 4.2.1-final+2072 (Github) SOURCE_CODE_URL:https://github.com/prusa3d/Prusa-Firmware-Buddy PROTOCOL_VERSION:1.0 MACHINE_TYPE:Prusa-mini EXTRUDER_COUNT:1 UUID:<redacted>
Recv: Cap:SERIAL_XON_XOFF:0
Recv: Cap:BINARY_FILE_TRANSFER:0
Recv: Cap:EEPROM:0
Recv: Cap:VOLUMETRIC:1
Recv: Cap:AUTOREPORT_TEMP:1
Recv: Cap:PROGRESS:0
Recv: Cap:PRINT_JOB:1
Recv: Cap:AUTOLEVEL:1
Recv: Cap:Z_PROBE:1
Recv: Cap:LEVELING_DATA:1
Recv: Cap:BUILD_PERCENT:0
Recv: Cap:SOFTWARE_POWER:0
Recv: Cap:TOGGLE_LIGHTS:0
Recv: Cap:CASE_LIGHT_BRIGHTNESS:0
Recv: Cap:EMERGENCY_PARSER:0
Recv: Cap:PROMPT_SUPPORT:1
Recv: Cap:AUTOREPORT_SD_STATUS:0
Recv: Cap:THERMAL_PROTECTION:1
Recv: Cap:MOTION_MODES:0
Recv: Cap:CHAMBER_TEMPERATURE:0
Recv: ok
Send: M155 S2
Recv: ok
Send: M876 P1
Recv: ok
FormerLurker commented 3 years ago

I'm closing this out since I'm getting ready for another RC. Thank you to everyone who provided feedback!