[SOLVED] MCU Turtle_1 TTC

[reef scroll]

So I printed for like 4 hours before that error occured. The BT is actively cooled with the 3010fan. The can use wiring is also fine

<@&1304550334839918672>

[fast shale]

are you up to date with Klipper/Kalico?

[cold patrol]

AFAIK GSTAT: 00000001 is the result of overtemperature, undervoltage or a short.

@reef scroll: what's your ambient temperature?

[reef scroll]

I can update it

[reef scroll]

Round about 26c I. The room

[sour crest]

We’ve also seen this GSTAT error being tied to static buildup, you can try tying your Stepper motor bodies to a GND pin if updating doesn’t resolve it

[fast shale]

There was an update a couple weeks ago that helps with TTC

[reef scroll]

For Klipper?

I am updating it rn

[fast shale]

yes, I don't remember when it was exactly but it helps

[reef scroll]

But as the BT is over the printer myb the temps are higher

[cold patrol]

Unless your BT sits directly on top of your printer and gets hot because of that, you should be fine temperature-wise. I have similar temperatures and don't even have a fan in the BT.

[reef scroll]

It once got to 56c but without the top panel installed on the printer

[sour crest]

The highest I’ve ever seen a turtle is around 45-50c while running on top of a 60c chamber… they don’t get hot without a fan

[reef scroll]

Now with the panel it doesn't get hotter than ~50c

Myb I install the cb1 customization from printables, it should help the cb1

[cold patrol]

@reef scroll: the klipper logfile doesn't show any TTC error. Just a few warnings about GSTAT: 1. Do you have a complete log including the error?

[reef scroll]

It was before I went to school

I downloaded the log afterwards

[cold patrol]

You're using Kalico, so maybe you have log rotation on restart (of Kalico, not the Pi) activated. In that case you'll have to find the previous log file.

[reef scroll]

Might be, where could I find the file

[cold patrol]

In the same folder. It has klippy.log and some timestamp in its file name.

[reef scroll]

sadly there are only the newest ones

[reef scroll]

i might be in the wrong path

[cold patrol]

On my printer all logs end up in that path. Can you execute ls -la to see when klippy.log was created?

[cold patrol]

And a ls -laU please.

[cold patrol]

So definitely new files. I have no idea why you don't have the old klippy logs in this folder.

[reef scroll]

me neither

I really dont want to start a new print which when fails after 95%

I can also trigger one with overloading it/running commands behing verry fast

[cold patrol]

Can you reproduce this even after updating to the newest Kalico?

[reef scroll]

ill try wait

[sour crest]

Don’t do a large print, run a torture turtle to see if it’ll reproduce it

Torture turtle is the serial print btw

[reef scroll]

it only occured for longer prints

the tt worked fine and other like 2h prints also worked grate

[cold patrol]

You might want to look at this page as well: https://canbus.esoterical.online/troubleshooting/timer_too_close.html
Maybe one of the listed scenarios fits your circumstances.

[reef scroll]

it might be as it sometimes also occures for the mcu mcu after the printer is running for a long time like idle or so

ill try in some time

[cold patrol]

Yeah, try if up-to-date Kalico solves it. If not, we'll need to find out how to get old logs files.
If noone here has an idea, maybe jump over to the Kalico Discord and ask there (regarding the logs).

[sour crest]

If Kalico is deleting logs at startup there’s likely no way to retrieve, if they’re archiving the most recent bunch, there might be

[cold patrol]

It should not delete them. At least not by default.

But I'm not sure if it even has a cleanup functionality 🤷

[sour crest]

I don’t run Kalico atm personally, so I have no clue either

[cold patrol]

I do run it, but I don't know every single feature 😉

But they have a Discord and are very willing to help.

[sour crest]

Yeah, I’m gonna set it up on a machine soonish cause there’s some stuff I do want to use that mainline doesn’t have. Anyways, back to help thread

If the only error is a GSTAT stepper error after all this, look at tying your motor bodies to a GND pin to eliminate static buildup

It’s something we’ve been seeing with the dry air and the 2mm ID Bowden inside the turtles

[tidal tiger]

Kalico has the option to rotate logs but this has to be manually set, and it keeps atleast the last 5 logs

[reef scroll]

im going to print this and lets see

and btw, is there any way to sea a real estimate?

with the afc toolchanges?

[tidal tiger]

Set these values in your printer settings

[reef scroll]

<@&1304550334839918672> I got the error again

So after some time I started a new print and voila

[sour crest]

Provide klippy.log

[reef scroll]

Omw

Here you go

It failed at this stage

[sour crest]

I can’t look at it atm, someone else may be more free to do so though

I’ll look when I get home if nobody else does

[tidal tiger]

Hmm this log is not really helpful, you set something up in kalico so it does not log as much stats?

[reef scroll]

Not as far as I know

Minimal logging was on in the danger options to help reduce the load but didn't seem to bring anything

I turned it off and I'll start another print

[reef scroll]

ive now got the log

hope its detailed enough

[cold patrol]

Yeah, the log is detailed enough.
It shows absolutey no transmissions problems before the TTC, so I think it's unlikely to be a problem with bad cabling.

Please have a look at this site: https://canbus.esoterical.online/troubleshooting/timer_too_close.html
Maybe one of the listed scenarios matches your situation.

If not: you're using a CB1, right? That is known to be prone to TTC errors, as it's just too slow. So if none of the listed fixes in the page I linked helps, you should consider upgrading to more powerful hardware.

[reef scroll]

yeah

a cb4 maybe?

or ill reinstall the os with the new 3.0 one from bq

[cold patrol]

I can't really give you a recommendation. I've only ever used a Pi4.

[reef scroll]

ive got a pi4 in my other printer

[cold patrol]

You could try transferring the SD card from the CB1 over to the Pi4 temporarily.

[reef scroll]

i dont think that works as the cb1 image is really custom

[cold patrol]

Ah, too bad.

[reef scroll]

i could backup everything and install the new 3.0 os and ill see

is ther a good backup option

[cold patrol]

If you have a second SD card, something like balena edger should work to clone the orignal SD card to the new one.

[reef scroll]

So what i can say for now is, that it always happens after the filament is retracted beyond the filament sensore and should be unloaded

[long lynx]

another thing whihc i think has helped some folks is to reduce the max travel distance on fast moves.

(by reducing max_move_dis to something less than your bowden length setting, e.g. maybe 500)

[cold patrol]

There are a few other interesting options as well. See #1341221680399384647 message ; this could apply to your problem as well.

[reef scroll]

I changed it as said but I already set the trysinc timeout to 0.07 in the calico danger options

[reef scroll]

Maybe that helps

I'll see tomorow

[reef scroll]

So I'm back and reinstalled my cb1....

Now I'm getting this error after startup just behind the first lane prepping...

<@&1304550334839918672>

[vestal isle]

you are using an afc-lite board correct ? yes you do.

from the logs it seems the stepper driver are not communicating 🤔

[reef scroll]

The 1st motor moved correctly

And it worked before 🙃

[cold patrol]

Can you please execute this shell command on your host: ls -la /home/biqu/printer_data/config/AFC. And ls -lad /home/biqu/printer_data/config/AFC (nearly the same, but not exactly).

[reef scroll]

I'll do it in the evening when I'm back home and then ping u

[reef scroll]

@cold patrol

[reef scroll]

I found the problem , it was a wrong file path

[cold patrol]

Yeah, that's what I thought, as /home/biqu appeared in the logs. Where did you have to change it?

[reef scroll]

In the AFC.cfg or so

I'll look it up

It was the path to the vars file

[reef scroll]

so it all didt help

still got the ttc error

[cold patrol]

Is this still with a CB1?

[reef scroll]

yah, but the newer image and lower load overall#

[reef scroll]

htop also looks better

[cold patrol]

What did you/the printer do when the TTC occurred?

[reef scroll]

i just had the web ui open and the printer unloaded filament as far as i know

it says it in the logs as long as i can read

[cold patrol]

Ok. Did you try reducing max_move_dis already?

[reef scroll]

yes

[cold patrol]

How low did you set it?

Er, I just realized I could check the logs to figure that out without asking you 🤣

[reef scroll]

all fine

its easier to ask me i guess

[cold patrol]

You know what's interesting? It doesn't appear in the log file.

[reef scroll]

thats wired

i just uploaded my backup from yesterday

[cold patrol]

Can you restart Klipper and send a new log?

[reef scroll]

do i then need to start a new print?

[cold patrol]

No. I just want to see the configuration, which is embedded in the log file.

[cold patrol]

Ah, now it appeared. So your previous print was done without max_move_dis.

[reef scroll]

oh

does it change much?

[cold patrol]

I've heard that it helped in some cases.

[reef scroll]

ok ill try it out

if this doesnt work ill buy a cb2

[cold patrol]

There's also another setting you could try. Let me quickly search for it.

In [AFC], add trsync_update: True.

May also help. But also may not help 🤷

I think it's worth trying (both options).

[reef scroll]

ill start a print

i also set the trysinc timeout in the danger options to 0.1

[cold patrol]

Yeah, I've seen that you increased a timeout there. But as far as I understand, that's another timeout. There are enough different timeout values for everyone 😄

[reef scroll]

dough

klipper is clomplicated

[cold patrol]

It is, yes.

[tidal tiger]

You running dev afc as well

[reef scroll]

nah not on that installation

its the default as i reset my cb1

[tidal tiger]

Then you need to put the max_move_dis under each AFC_stepper config

[reef scroll]

oh

[reef scroll]

Yeah I updated and now I'll see

It only does the 500mm at once now

[reef scroll]

till now im in 2 hours

seems promising

[reef scroll]

So some good news and bad news, this time I had no TTC so that seems to be fixed but now the filament sensors didn't work/was stuck in the triggered state.... So the print failed again at like 96%. I don't know, if there is a way to resolve this error or to make the sensors more reliable or to dual use the buffer as ram sensor and check if the toolhead sensors is wrong/faulty.... Or if I should reprint the part a 4th time with this time a bigger floating area for the ball?

[reef scroll]

<@&1304550334839918672>

[cold patrol]

What exactly happened? Did it unload for a filament change but the switch did not change?

I can't say anything about FilAmatrix and making the sensor more reliable, as I don't use FilAmatrix. Maybe @long lynx can help here.
If you can't get it to work, but have a TN or TNpro, then you can configure ramming instead of using a toolhead switch. If you go that way, make sure to add a rubber band to the TN that tries to compress the buffer; it should be very reliable then.

[reef scroll]

Yes the filament was behind the sensor like 10cm above the extruder

[reef scroll]

I'll try it

[cold patrol]

I had similar issues with my toolhead in the past. Had to enlarge the hole for the steel ball.

If it's too tight, the ball gets stuck, with exactly these consequences.

[reef scroll]

I can't really drill it out as it's Angeles for the g2e one

I may try it with the buffer while I'm at home

[long lynx]

I don't have a ton of experience with the G2E body ... it's almost a direct rip from the G2E-Filametrix repo with a few changes to allow for the fully threaded m2.5x16 screw to pass.

if the ball is sticking when trying to trigger with filament i would say that is likely a print tolerance issue, either with shrinkage or with too high an extrusion multiplier/flow

@sour peak was looking into POM ball bearings I think because of the steel ball sticking in his, was hoping a more slippery surface would help but I don't konw where he is with that.

[sour peak]

Waiting on payday.

[reef scroll]

for now it works with the buffer

[reef scroll]

It printed successfully