Filament Amount changed drastically resulting in print fail

[gsteffek]

Hey all,

tried to print something using ArcWelder for the first time and thought I had the perfect object to do that. After 2 failed prints I noticed the amount of extruded filament between the 2 GCodes was changed drastically: Original: 3.64m AW file: 0.22m and as you can imagine, all I got was a bit of spaghetti. The print itself is a very simple and very round object, supposed to have 1 wall line thickness and printed with a .6mm nozzle at .7mm extrusion width. For slicing I used PrusaSlicer.

GCode files.zip

GCode Files attached.

[FormerLurker]

What firmware? The exact version would be great. Also, if you have a copy of your configuration file or a link to the firmware source, that would help a lot, thanks!

[FormerLurker]

So, I processed your original gcode in OctoPrint and here's what I saw:

Where did you see the 0.22m filament value? I think there was a calculation issue for G2/G3 that was fixed in a recent OctoPrint release.

My initial guess is that either arc support is disabled in your firmware. Do you have the failed print around, and could you maybe attach a snapshot?

FYI, here is what that object looks like if G2/G3 is disabled in the firmware:

It would have definitely failed massively without arc support. You should be able to test to see if arc support is enabled by sending a G2 command through the OctoPrint terminal, and see what the printer returns.

[gsteffek]

Hi,

thanks for your response. The 0.22m Filament value is, what OctoPrint showed me when I loaded the gcode, therefor I don't think it's a firmware issue (which is Klipper running on a Sidewinder X1). Can G2/G3 be enabled/disabled in OctoPrint itself?

I don't have the print around anymore, but it was just a bit of spaghetti that looked like someone extruded mid-air and moved the nozzle around. Amount was also low, so I think it fits to the picture you showed above.

I'm currently not around the printer but will provide an update in 1-2 days with more information about what Octoprint shows/reports.

Thanks!

[gsteffek]

Here the picture from Octoprint (it's the same file as above, I had it just renamed before uploading). And this is what OctoPrint shows me for the non-AW file:

Now the weird part: If I look at the AW-File in the Octoprint GCode Viewer it gives me exactly the same amount per layer as the non-AW version does (8.85mm for the full circle layers), just with mostly 5 GCodes per layer instead of 100+.

[FormerLurker]

What version of OctoPrint are you using, and what version of Kilpper are you using? You can send an M115 command to get the klipper version (paste in the entire response here please):

And you can look at the bottom left hand corner of your browser to find the Octoprint version:

I REALLY need both of these to figure out what is going on, especially since the gcode looks good to me.

Also, please check Klipper to make sure that arcs are enabled. You can manually send the following code from the OctoPrint terminal:

G90
G28 X Y
G0 X0 Y0
G2 X40 I20 F800

Send these commands one at a time. When you send the final G2 command, switch to the control tab and see if your printer moves in a smooth arc. If it does not more, or if you get an 'unknown command' error in the terminal, there is a problem.

Bottom line: It really doesn't matter what Octoprint is showing in terms of filament usage. The gcode appears to be correct, so I suspect a firmware issue that is fixable. Klipper definitely supports arcs, especially in the most recent version. However, arc support can be disabled in Klipper, and some older versions either have no arc support, or there are bugs.

I'm working on a firmware checker button as we speak to help detect these issues.

[gsteffek]

I reprinted the GCode I posted above, this is what it looks like: It moves in a circle at the bottom but doesn't extrude any significant amount of filament. Then moves straight up for 8-10mm, extrudes a little blob (you can see it in the left part of the picture) and moves straight up for several centimeters where it starts to go back and forth extruding filament here and there (the spaghetti doesn't reflect the movement as it's mid air und just curls up and falls down from time to time). I have the feeling it extrudes/retracts very fast, because I hear some squeeching from the printer (Sidewinder X1) which I usually don't hear.

Running the G2 command I get an "Unknown command: G2" error.

Octoprint version: OctoPrint 1.4.2 Python 3.7.3 OctoPi 0.17.0 Klipper version: Send: Recv: ok FIRMWARE_VERSION:v0.8.0-700-ge4f3f60e FIRMWARE_NAME:Klipper

Again, thanks for the support!

[FormerLurker]

That pic looks a lot like my simulation shot above of what would happen if G2/G3 is not enabled. You are running Klipper 0.8.0, but you probably should upgrade to 0.9.0 (arc support is better), and make sure you enable arcs. Can't print arcs if g2/g3 doesn't work :)

[FormerLurker]

Also, I should have mentioned that the :Running the G2 command I get an "Unknown command: G2" error. response means you can't print arcs. I'm still working on the firmware checker function so that it's obvious what is wrong, but here's what it says about your version so far:

I'm pretty sure (but I can't test it yet) that it would say 'Arcs Enabled': NO, and would have an error message if you were to run this on your machine. Maybe when I get this finished I'll send you an install link.

[gsteffek]

I updated Klipper to the current version now: As you can see, I still get a G2 not supported. I know this is probably more of a Klipper question, but are you aware of anything that needs to be enabled for G2 codes to work in Klipper?

Edit: https://github.com/KevinOConnor/klipper/commit/7d8c70363a4241ce7c16868e347d7c0f7855f5f3#diff-71420708e69755e8a44d7e3eac23cf1b Looking at the implementation it appears Klipper re-segments an Arc into straight line moves? Is this done by the other implementations as well or more of a work-around and no real gains can be gained by using G2/G3 with Klipper?

[FormerLurker]

Yes, thet do need to be enabled. I did not realize it was disabled by default. I wonder if maybe that could be changed.

[FormerLurker]

https://github.com/KevinOConnor/klipper/blob/9e1697786d25c8dc1db905f6d41af4d0b73f022e/config/example-extras.cfg#L508-L515

I would set the segment length to 0.5 or 0.1. You want the lowest value klipper can handle without stuttering. I'm pretty sure Klipper can handle 0.5 in most cases, so maybe start with 0.1 and raise it if you have issues. If you can go lower, do so! Let me know what you find.

[robwasteground]

If it helps, I'm running with:

[gcode_arcs]
resolution: 0.1

On an Ender 3 v2 with Klipper, very successfully. In Arc Welder, I have the minimum resolution set to 0.05. With these settings, I get really perfect results. Much better than without arcs (on certain prints, it is very clear that arc support is doing a much nicer job of printing curves than without).

[FormerLurker]

@robwasteground, that is excellent! Klipper really handles arcs nicely. I'm hoping arcs can be enabled in the default configs since there is little reason not to. I may post on the repo. Perhaps there is a good reason for this that I'm not aware of.

[homerisback]

I installed ArcWelder on my Rpi Octoprint server, which went flawlessly. My printer is a Prusa Mini to which I sent a few fake G2 & G3 commands ; that seemed to work fine.

With a Sodastream bottle support almost round everywhere to print, that could be the perfect test, I thought. It ran into a spaghetti from the beginning. ABS filament didn't stick to bed and extrusion was not as usual. Printer's head was too high, like if Z offset had been altered.

I cancelled the job and disabled ArcWelder to give a try to a new print with original G-code : it works great and is still properly printing while I'm writing. I didn't did into ArcWelder parameters yet to change anything, will do later probably.

[gsteffek]

Sorry for leaving this open without responding. @robwasteground solved the problem for me, arcs were not enabled by default (contrary what I think I read in the ArcWelder notes when installing).

Since then my round prints are coming out perfectly fine and feel "smoother".

@homerisback that's weird, at not point did I have a Z height altering going on. What I had is, when Arcs were disabled, that some layers had "no content" and the printer skipped it and moved straight up. Ohter prints came out "close" but it looked like layer shifting going on and the (round) corners were different from what they were supposed to be.

But I don't have a Prusa printer, so can't help with that firmware.

[FormerLurker]

@homerisback, there actually was a bug regarding offsets that you might be running into. Can you send me your original gcode, and if possible the welded gcode? I can run them through the debugging and see if I have fixed this in the devel branch.

[FormerLurker]

@gsteffek,

Glad you got it working!

contrary what I think I read in the ArcWelder notes when installing

Can you explain this? If there are incorrect notes somewhere, I want to get them fixed!

[gsteffek]

@gsteffek,

Glad you got it working!

contrary what I think I read in the ArcWelder notes when installing

Can you explain this? If there are incorrect notes somewhere, I want to get them fixed!

Just checked, and of course the problem came from not reading the notes properly: "Klipper seems to handle G2/G3 commands with ease, as long as the GCode_arcs config section is enabled. G2/G3 support was added on September 13, 2019, so make sure you update Klipper if you are using an older version." Source: https://plugins.octoprint.org/plugins/arc_welder/

So I read the update Klipper part (but I received the printer summer this year, so was sure my version was not from before September 2019) but missed that GCode_arcs is not configured "by default". No fault on your side, just me assuming that support for Arcs in Klipper is out so long, it would have a default value or throw an error if not.

[FormerLurker]

@gsteffek,

No fault on your side, just me assuming that support for Arcs in Klipper is out so long, it would have a default value or throw an error if not.

No worries, I am not concerned about who or what is at fault, only that it can be avoided in the future. I will bold that section to reduce the chances of that happening again.

Also, I have addid a firmware checker tool in the devel branch that shout make these issues much more obvious. Let me know if you would like to check it out and help me test.

[homerisback]

@homerisback, there actually was a bug regarding offsets that you might be running into. Can you send me your original gcode, and if possible the welded gcode? I can run them through the debugging and see if I have fixed this in the devel branch.

Thanks, here are the two gcode files : (https://www.dropbox.com/s/lbanzqsa7b6u8pr/Sodastream%20bottle%20support_0.2mm_ABS_MINI_3h35m.gcode?dl=0) https://www.dropbox.com/s/j5pv73v4n9wbhlm/Sodastream_bottle_support_0.2mm_ABS_MINI_3h35m.aw.gcode?dl=0

[FormerLurker]

homerisback, can you try editing the arc welder settings and setting G90/G91 Influences extruder to true:

Yours might look a bit different since I'm running the devel version, but that setting is in there.

The gcode you sent me looks fine, so I suspect this is a configuration issue, or some oddity with the mini's buddy firmware that I haven't figured out.

[gsteffek]

Closing this because my issue was resolved ( didn't have it properly configured in Klipper). Using Arcwelder ever since for all my prints and love it.