Possible issue with print output after being processed by ArcWelder #74
Comments
|
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. |
|
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: Screenie of statistics: Currently running: |
|
Ah - also, current config for that run might help: |
|
Hey, can you post your marlin config (the adv) file? This could be firmware settings related. |
|
I don't have a copy of it for what I've built - however the base would have been from here: As such, those ARC settings would be used. |
|
So you just enabled arc support and left the defaults in there? |
|
Yep - I don't normally know what these do in detail, so I leave the defaults... |
|
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? |
|
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... |
|
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? |
|
OH, and sorry for the flurry of questions. These issues are often pretty perplexing. Sometimes I figure out what's going on, lol! |
|
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? |
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. |
|
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%... |
|
Woot! This is an ideal example of how a GitHub issue should work! Thank you! Am anxiously awaiting the results. |
|
Well, not really - as after printing the non-AW processed file, it still has similar notches:
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 ;) |
|
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) |
|
@FormerLurker, what is your preferred tool to review toolpaths with? |
|
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. |
|
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... |
Re: MarlinFirmware/Marlin#22571
Could this issue in Marlin be why I see this on certain prints?
I'm not sure what else would cause the differences in the edge...
The text was updated successfully, but these errors were encountered: