search

FormerLurker / ArcWelderLib

A collection of projects used to convert G0/G1 commands to G2/G3 commands.
363 stars 38 forks source link

Possible issue with print output after being processed by ArcWelder #74

Open CRCinAU opened 3 years ago

CRCinAU commented 3 years ago

Re: https://github.com/MarlinFirmware/Marlin/issues/22571

Could this issue in Marlin be why I see this on certain prints?

image

I'm not sure what else would cause the differences in the edge...

FormerLurker commented 3 years ago

You are awesome 😎! I obviously have lots on my plate, as you know, but will be be responding in detail with a few questions here soon.

CRCinAU commented 3 years ago

Not awesome at all - these things are waaaaay above my head - but dumbing it down to me to understand, I think I understand the 10,000 mile high view.

As its likely to help, I'll attach: STL: Stand_1.stl.zip Sliced G-Code from PrusaSlicer 2.3.3: Stand_1_0.2mm_PLA.zip After processing with ArcWelder 1.1.0rc2 on Octoprint: Stand_1_0.2mm_PLA.aw.zip

Screenie of statistics: image

Currently running: FIRMWARE_NAME:Marlin bugfix-2.0.x (Aug 10 2021 01:53:14)

CRCinAU commented 3 years ago

Ah - also, current config for that run might help: image

FormerLurker commented 3 years ago

Hey, can you post your marlin config (the adv) file? This could be firmware settings related.

CRCinAU commented 3 years ago

I don't have a copy of it for what I've built - however the base would have been from here: https://github.com/MarlinFirmware/Configurations/blob/bugfix-2.0.x/config/examples/Creality/Ender-3/BigTreeTech%20SKR%20Mini%20E3%202.0/Configuration_adv.h#L2057

As such, those ARC settings would be used.

FormerLurker commented 3 years ago

So you just enabled arc support and left the defaults in there?

CRCinAU commented 3 years ago

Yep - I don't normally know what these do in detail, so I leave the defaults...

FormerLurker commented 3 years ago

Ok, I did try all these files out, and I'm not sure what's going on. The toolpaths look perfectly fine. I can't tell from your pic if this is a toolpath problem, or an over/under extrusion issue. Can you remember when you built this version? Perhaps the algorithm has changed somewhat since you flashed it?

CRCinAU commented 3 years ago

Yep - it was built on Aug 10 2021 01:53:14 from bugfix-2.0.x

I'm not exactly sure either - its strange that its only on some layers, and I'm not quite sure the reason myself... It just seemed like it could have been something related to the discussion re segment lengths of arcs...

FormerLurker commented 3 years ago

Well darn. That's pretty recent.... And you're using relative extrusion. Have you printed the original (no g2/g3) gcode, and did it come out the same?

FormerLurker commented 3 years ago

OH, and sorry for the flurry of questions. These issues are often pretty perplexing. Sometimes I figure out what's going on, lol!

CRCinAU commented 3 years ago

To be honest, I haven't printed the non-AW'ed version - as my printing pipeline is basically PrusaSlicer -> Octoprint and then automatic AW processing.

Would it be helpful to try the same output with the same non-AW gcode posted here and see what happens?

FormerLurker commented 3 years ago

Would it be helpful to try the same output with the same non-AW gcode posted here and see what happens?

I hate to ask, but yes it would be very helpful. If the same artifacts show up, then we can at least rule out arcwelder. If they don't appear, it will be back to the drawing board.

CRCinAU commented 3 years ago

It's printing now - so it'll take a few hours.... I think I might have reduced the feed rate on the original print I did, but as this seems to be sticking fine, I'm just letting it go at 100%...

FormerLurker commented 3 years ago

Woot! This is an ideal example of how a GitHub issue should work! Thank you! Am anxiously awaiting the results.

CRCinAU commented 3 years ago

Well, not really - as after printing the non-AW processed file, it still has similar notches:

image

It does look like each of the 'notches' are level with par of the hex pattern in the rest of the print - as such, it probably isn't an AW issue....

I don't exactly know what it could be... Maybe linear advance isn't working the same on each corner? I dunno - but it doesn't seem to be AW and I've just been making noise ;)

ignisf commented 2 years ago

Hi @CRCinAU, the bug you mentioned seems to be fixed in Marlin. Are you still experiencing the issue? (I am investigating an issue of my own which may or may not be this)

ignisf commented 2 years ago

@FormerLurker, what is your preferred tool to review toolpaths with?

FormerLurker commented 2 years ago

I use sumplify3d stand alone, ncviewer.com (some gcode modification may be required) for layer-by-layer analysis, and pretty gcode viewer for octoprint.

Also, this issue is common in marlin 1 forks, solved in latest marlin 2, if it is what I think it is.

CRCinAU commented 2 years ago

Honestly, I forgot all about this and don't remember where I got to....

I figured that if it was happening without processing with AW, then its not related to AW...