Timer Too Close as soon as print loads, every single time with this one file.

[halcyon parrot]

I've been running prints on my 2.4 without a single problem for weeks now. All of a sudden I send this one file with 80 instances of a little clip in it, and EVERY single time I try to start this print, the printer doesn't respond for about 5-8 seconds, then it begins running the print start, starts homing X for half a second before throwing Timer Too Close.

Of course my suspicion is that it's taking too long to process the 80 excludable objects in this print but figured I'd get a second opinion and if there's recommended ways to fix this. Attached the gcode in case it's useful.

[shy badge]

how are you starting the print? directly from the slicer?

[halcyon parrot]

This happens when starting the print via the web interface

[shy badge]

try adding default_metadata_parser_timeout to the [file_manager] section in moonraker.conf and setting it to something like 30 to give the parser time to process the 80 instances

[rancid skiff]

which single board computer are you running?

[halcyon parrot]

I'm assuming I should add a [file_manager] section if it doesn't exist?

[halcyon parrot]

Looks like a BTT Pi v1.2

[shy badge]

correct

[halcyon parrot]

Restarted firmware and Moonraker and still same timeout.

[shy badge]

ok, it was worth a go

as it only appears to be this print, maybe print in smaller batches?

[halcyon parrot]

Lol I appreciate the attempt. I did end up dropping the count in half and it did complete successfully.

[slender hound]

Yea this is a thing with the lower-powered SBCs apparently. Someone else had the same problem a little bit ago. Had the same thing happen to me at one point.

In my case i just ended up upgrading the SBC but this pre-processor was suggested to me also. It does the exclude_object processing in the slicer before it hits klipper

https://github.com/kageurufu/preprocess_cancellation

im not sure if it supports orca though

[shy badge]

fyi, orca adds the EXCLUDE_OBJECT_DEFINE ..., EXCLUDE_OBJECT_START ... and EXCLUDE_OBJECT_END ... commands to the emitted g-code if you have "exclude objects" enabled

[halcyon parrot]

What did you end up upgrading to? I've been debating about doing this anyway but hadn't come across a compelling reason to yet. Maybe this is the final push to get me to do it.

[slender hound]

I ended up with a pi4b and it's been substantially more stable than anything else

With the exception of wifi being totally broken but I gave up trying to diagnose whatever the hell was going on there and just hardwired it

[halcyon parrot]

Awesome, I'll be on the lookout then. Just need to tack on a 5v power source to feed it

[slender hound]

eh, most MCU boards have enough of a regulator on it you can steal power from them

[halcyon parrot]

Oh? Well then I'll need to look into that then!

[slender hound]

what mcu you got?

[halcyon parrot]

If I recall correctly it's the Octopus Pro 1.0

[slender hound]

ah yea thats got more than enough 5V rail to run a pi

most kits that ship with those don't even include a 5V supply, they just steal from the octopus

most stuff seems to steal from the UART2 header since its got two 5V and two ground pins exposed

running two wires in paralell for each to the pi's GPIO to help with voltage drop

could also steal from the probe port or an always on fan port if you set the jumper to 5V too