Reduced accuracy for supports

Features
1

I was foolish enough to buy a FlashForge AD5X printer. It has a combination mainboard. The HOST runs on a 2 core 32bit mips.

The Klipper based firmware is hopeless. Adding Z-Mod Makes it into a surprisingly capable machine. Most models are happy at 3000mm/s2 and 600mm/s

EXCEPT for “tree supports” generated by OrcaSlicer cause “timer_too_close” errors as all the little circles drive the motion planner to overload the CPU.

Is there a way to reduce precision/accuracy when printing supports?

The need is to combine moves. Orca will let me selectively reduce support speed but it seems it would be better to allow the printer to print supports “sloppy” and calculate fewer moves.

2

Firmware should execute gcode, that is it.
You asking the firmware to get the idea what gcode does and do something about it.

So, short answer - no.

Long answer, if your machine running clean mainline, you can open a help request with klippy.log which contains shutdown.
If it is not clean mainline, I guess, you can try to ask for help from the provider.

Strictly speaking, CPU cost of step computation is direct proportional for step count, selected IS and moves count.
Where for tree supports I would expect that there are slow small/short moves, which should not cause any issues, otherwise you should experiencing shutdown on basically any complicated model.

Also, there were multithreaded step computation which merged a while ago, which should help with that.

-Timofey

3

I’ve looked at the “Z-mod” klippy code, it seems fresh and there is only:

  • Exclude objects random pauses
  • Custom load cell
  • TVOC handler
  • Log rotate hacks

So, it seems nothing too suspicious to me.
So, I’m curious to look at the TTC shutdown.

4

No, not even sort of. That’s why I put this topic here and not general discussions.

It is however running current unmodified klippy.py.

The Machine has a MMU that runs a proprietary firmware that connects to a dedicated service process on the host connected via RS485. A couple proprietary Python scrips and a BUNCH of macros pass info to/from Klipper. Fricken magical it works at all.

Thank you for taking the time to educate me. Regular supports print with no issue but are a pain to remove.

5

Here is log file. First “session” is a complete print job of the same model, with normal supports. Last Session is with tree supports.

I’ve included the g-code for the problematic print in case Orca is spitting out nonsense.
Mobius Marble Run heavy_PETG_2h10m.zip (3.9 MB)
printer (8).zip (930.3 KB)

6 
Stats 62330.7 ... print_time=13956.597 buffer_time=0.678 ... sysload=0.49 cputime=11334.602 memavail=384236
Stats 62331.7: ...  print_time=13958.063 buffer_time=1.143 ... sysload=0.49 cputime=11335.125 memavail=384236
Stats 62332.9: ... print_time=13958.063 buffer_time=0.000 ... sysload=0.49 cputime=11336.241 memavail=384272
...
Sent 10 62330.693250 ...
Sent 11 62331.001831 ...
...
Sent 41 62331.178311 ...
Sent 42 62331.372756 ...
...
Sent 64 62331.647547 ...
Sent 65 62332.011338 ...
...
Reactor garbage collection: (62321.53921605, 62218.140442167, 0.0)
...

Hmmm, so the machine looks already pretty heavily loaded.
There are some random pauses during computations, not sure if it is GC.
As it is running under Python 3.8, there should already be a GC freeze. Which should help.

But yeah, otherwise, it is hard to pinpoint what exactly goes wrong, or what I can suggest (newer Python?).

But yeah, it is likely that tiny moves flip the system over the edge:

G1 X150.978 Y114.033 E.00015 ; support material
G1 X150.951 Y113.87 E.00416 ; support material
G1 X150.95 Y113.864 E.00015 ; ...
...
move 121: pt=13957.866896 mt=-0.000000 // ? huh, -0
...
move 126: pt=13957.871399 mt=0.001214
move 127: pt=13957.872612 mt=0.001412
move 128: pt=13957.874024 mt=0.000472
move 129: pt=13957.874496 mt=0.001412 
move 130: pt=13957.875908 mt=0.000537

-Timofey

7

Yes it is. If I’d done any research it wouldn’t be on my bench. But now that it is my goal is to see exactly how far I can push the POS.

Thanks for looking.

8

FWIW OrcaSlicer update seems to have resolved the issue.

I forgot I was on 2.4.0-alpha (as a rule I avoid alpha versions). The upgrade nag popped up, Installed 2.4.0-beta. Resliced same settings and it’s happily printing at full speed.