Arc fitting disabled in orca, but receiving unknown command G3/G17 errors

General Discussion
1

Basic Information:

Printer Model: Troodon 2 Pro
MCU / Printerboard: STM32F407
Host / SBC Raspberry Pi
klippy.log
klippy (2).zip (1.1 MB)

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

Describe your issue:

… Hello, I’ve been familiarizing myself with this printer for a few days now. I switched to Orca slicer yesterday to utilize the built in calibration tools. Through most of the calibration tests, everything went well. Then I went back to do the temp tower after I finished everything else and felt I had decent settings. During this print and another after, I started seeing ‘Unknown command:’ errors, with “G3” or “G17” following.

I did some searching around, here and elsewhere, and it seems because I have not enabled arcs these errors are populating. Trouble is, in Orca, Arc fitting is not enabled, so I am not sure why these codes are present.

The prints themselves have turned out as expected.

Any ideas/suggestions?

Thanks you

2

What flavour did you set Orca?

Can you provide a shot gcode file?

3

Klipper flavor, here’s a gcode file.

Screwed Up Filament Clip_PETG_24m19s.gcode (2.9 MB)

Thanks

4

As for the gcode file, Arc is definitiv still turned on.

Or do you have some certain addons in the frontend you use?
Or in the slicer start gcode section?

5

No add-ons that I know of. The troodon is out of the box, only changes I’ve made to the config are I’ve tried to activate [exclude objects], and change the probe lift speed to 100.

This is the machine start gcode…

SET_PRINT_STATS_INFO TOTAL_LAYER=[total_layer_count]
M104 S0
M190 S0
M140 S[first_layer_bed_temperature]
M190 S[first_layer_bed_temperature]
START_PRINT
M104 S[first_layer_temperature]
M109 S[first_layer_temperature]
NOZZLE_PRIME

If there’s a different start gcode section, I’m not aware of it.

Totally new to this…

Thank you for trying to help…

How can you tell that arc is still turned on?

Is this the only place that setting exists?

arc fitting
arc fitting553×681 22.2 KB

6

grafik
grafik780×154 10.2 KB

From your gcode file.

Have you looked on layer change in the slicer?

7

Under machine G-code, before layer change is:

;BEFORE_LAYER_CHANGE
;[layer_z]
G92 E0

layer change is:

;AFTER_LAYER_CHANGE
;[layer_z]

I’ve been stuggling to get a PETG setting calibrated today, but I’ve run a bunch of prints, and only a few times(1-2 of 10+) have I gotten the errors from G3/G17. Same test prints, never touched the arc fitting settings.

8

Filament properties?

9

The filament is a Polymaker Polylite PETG, white.

I’ve got the temp(s) above what is recommended by the manufacturer, at 260/90 first layer, and 255/90 other, those are the best results I’ve seen so far while printing a 15mm X 5mm disc. Going super slow on first layer(was at 10mm/s, now going down to 5mm/s).

I’m struggling to get the first layer to stick to the bed(PEI Textured) and not gunk up the nozzle.

Now if you’re asking if I’ve got a setting for arcs under the filament profile. I don’t know that one exists. The start and end gcodes are simply:

; filament start gcode

; filament end gcode

I’m close to giving up on this Polymaker for now and either move on to our ESD filament, or do some more tests with the Creality PETG to make sure it’s not a different issue.

10

I have noticed a bug on OrcaSlicer that was throwing me off big time like in your case. Maybe it’s the same.

This happened to me (about a different setting) when importing a model from a Prusa Slicer 3mf project.

There was a setting that would stubbornly persist despite of what I set in OrcaSlicer, it would still follow the setting that was defined in Prusaslicer.

To fix it, I exported the STLs from Prusa and created a new project in Orca. Then imported the model from STL instead.

1 Like
11

I was beginning to think it might possibly be a bug, but I feel like I don’t really know enough to even suggest that.

It just doesn’t/didn’t make sense that it seems to happen randomly. I’ve never clicked the arc fitting box.

It hasn’t happened in my last 6 print attempts or so, so I suppose I can just chalk it up to a bug and move on.

Thank you

12

I know the feeling. Both for the frustration of having an issue with a filament and running around circles like the OrcaSlicer bug.
Try tracing back whenever that happens.
For example, you have a reproducible bug. Store the project file away for reference (for the Arc bug).
Now, how did you start the project? Was it like with me, a project that was first created in Prusa Slicer and then moved to OrcaSlicer? Or created on a previous version of OrcaSlicer?

So, the first thing I’d do is export the STL from the slicer, create a fresh project and import it the STL (or if it’s your own design, simply start a new project and import a fresh export from your CAD software). This way you can get rid of any dirty setting that may be lingering in the project file. I know for certain that is definitely possible. STL is a binary model file, unlike 3mf that can store any arbitrary information.

Once.you have done that, verify the sliced gcode and check if the pesky gcode is still there, if it’s not, you have narrowed to the source of the Arc issue.

As for the filament not sticking, sometimes it can be really stupid (ask how I know). For example, I had a similar issue with a very specific filament (type, color and brand). But it had nothing to do with the filament. In that project specifically, I had a nozzle diameter defined as 1mm. I have no idea why that was like that. A fresh project may also help identify that there is some setting in the project creating issues.

Finally, I often get bed adhesion issues and usually boil down to either of these:

  • improper temperature settings: Too high temperature can be a problem and if you’re printing slowly that is specially true as the filament remains cooking in the nozzle for a longer time. I only exaggerate filament temperature when printing very fast or with hardened steel nozzle that is a worse temperature conductor. Similarly, the bed temperature needs to be higher when printing hotter stuff, but that may not work well with PETG that doesn’t have a very high glass transition temperature.
  • nozzle too close to the bed: Some filaments like to take a ride in the tip of the nozzle. So if the nozzle is too close to the bed it may grab the deposited filament. This can get worse depending on the type of the nozzle, like what I have (ruby tip). So form factor can play a role here. I’d swap to a different nozzle to see if there is a relation there as well.
  • wet filament: That speaks for itself, make sure your filament is dry.
  • Flow rate tuning. Sometimes the flow rate is just wrong. Which can be from bad extruder tuning (some filaments are more sensitive than others), improper filament settings, etc. OrcaSlicer has a flow rate calibration tool. I encourage you to use that. In fact, I’d go through all available calibration tools as much as possible.

In the end this is an annoying thing I beleive most of us encounter. The way to go (before blaming the filament) is to try to identify the cause, it usually not the filament, and developing a good debug procedure will save you time and frustration whenever you encounter an issue. Good luck.

2 Likes
13

I know this isn’t much of a solution, more of a bandaid. But if you put [gcode_arcs] into your printer.cfg, those errors don’t show up anymore, even if you have arcs turned on. I’m not sure if it handles it like marlin would, but it’s worked for me ever since

1 Like
14

Good thinkin. I might just do that. Yesterday they hadn’t been popping up much, but they are back again today. I’m thinking they exist in one of the flow rate calibration tools, and I’m guessing they followed to another test print I did because I forgot to start a new project.

Thank you

1 Like
15

What is your z hop set to? Spiral or slope or auto? Spiral Z uses arc commands as does auto when the spiral method is auto selected.

For orca you should enable arc fitting in klipper to allow the more advanced z hop types unless you always force it to use ramp lift.

2 Likes
16

Ever since I did that they never popped up again. Worth a shot anyways and if it actually does the arc commands and makes a proper circle that’s great but I don’t really know if it does. Good way to get rid of the messages though. Let me know if it works!

1 Like
17

Thank you, I had been trying spiral on at least one filament, that’s probably where these codes were generated.

I realized Friday that it wasn’t in the calibration tests like I had suspected, and was back to scratching my head why they were there.

Thanks again.

18

No worries!

Do enable arc fitting in klipper so you can use the more advanced spiral z hop, which eliminates stringing. There is no side effect to it. However as you have, don’t enable arc fitting in the orca quality tab.

1 Like
19

Arcs in Klipper do not have advantages, because these are also calculated on the Klipper host and are sent to the MCU as regular bow/circle sections without arc fitting

20

It does for z hop - it allows you to use spiral z hop in orca vs. Slope or lift.

For extruding, no there are indeed no advantages and the option in orca should be disabled.