Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedback - V1.0.0 #40

Closed
FormerLurker opened this issue Oct 24, 2020 · 24 comments
Closed

Feedback - V1.0.0 #40

FormerLurker opened this issue Oct 24, 2020 · 24 comments
Labels
Feedback Tell me what you love, hate, would like to see, or anything else related.

Comments

@FormerLurker
Copy link
Owner

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!

@FormerLurker FormerLurker added the Feedback Tell me what you love, hate, would like to see, or anything else related. label Oct 24, 2020
@mild-lemon
Copy link

mild-lemon commented Oct 25, 2020

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
Copy link

KapJI commented Oct 25, 2020

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
Copy link

cp2004 commented Oct 25, 2020

.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
Copy link

CRCinAU commented Oct 25, 2020

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:
Ultimaker/CuraEngine#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
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link

foxylion commented Oct 25, 2020

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:

  • Click "Send to OctoPrint" in Cura
  • The printer receives the file and Arc Welder automatically converts the file & deletes the original file
  • The file is automatically selected
  • Click on the link in Cura that opens the OctoPrint web UI
  • Click on the "Print" button

Compared to the "current situation":

  • Click "Send to OctoPrint" in Cura
  • The printer receives the file and Arc Welder automatically converts the file & deletes the original file
  • Click on the link in Cura that opens the OctoPrint web UI
  • Scroll through the long list of GCode files
  • Click on the title to view the print details
  • Click on the "Print" button

@FormerLurker
Copy link
Owner Author

@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
Copy link

@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
Copy link

gluap commented Oct 26, 2020

@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
Copy link

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
Copy link

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
Copy link

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
Copy link
Owner Author

@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
Copy link
Owner Author

@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
Copy link

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
Copy link
Owner Author

@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
Copy link

@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
Copy link

j-be commented Oct 27, 2020

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! 👍

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
Copy link

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
Copy link
Owner Author

@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
Copy link

@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
Copy link

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
Copy link
Owner Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feedback Tell me what you love, hate, would like to see, or anything else related.
Projects
None yet
Development

No branches or pull requests