Timer too close with SB2040

General Discussion
1

Basic Information:

Printer Model: Voron 2.4 R2
MCU / Printerboard: Raspi4 / 2x SKR1.4 Turbo and SB2024 CAN Head
klippy.log

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:

Hi, I have installed a SB2040 board on my Stealthburner toolhead. Unfortunately I get an “Timer too close” error after some printing time. I use 2x SKR1.3 Turbo, the UTOC and the SB2040 CAN PCB. All connected to a Raspi 4.

Can anyone help me, please. As all prints cancel after ~ 10-30 mins I have to remove all the stuff and go back to the CAN-less version.

klippy(7).log (1.9 MB)

2

Do you know Sineos’ “Knowledge Base”?

Good luck, hcet14

3

Thanks. Yes I know this. I should have written that, sorry.

I have setted up a clean Image, just before the above log was created. No other tasks are running. Voltage is not an issue, I have monitored the voltage with an oszilloscope - no spikes or drops. Disk space is also more than 100 GB available. I use a SSD for the RPI4. I doesn’t matter if I use the 32bit or 64 bit version of the image.

4

I couldn’t find a solution. I’m pretty sure it wasn’t an EMI/CAN hardware level related issue. Nor do I think it was related to the power supply. I think that there is an issue with the software - maybe 2xSKR1.4 via USB + USB2CAN is too much.
Anyway, I decided to remove all the CAN- stuff and switchted back to a hard-wired version. Now everthing is working 100.0 % stable. From my personal experience I can’t recommend the setup I used.

Thanks.
Michael

1 Like
5

Mmmhh, don’t know.

image
image1794×554 18.7 KB

image
image1786×528 34.2 KB

I have the impression, that it’s looking good.

6

Have you tried this fix: zippy-klipper_config/scripts/mcu_timing.sh at master · rootiest/zippy-klipper_config · GitHub

I had this error with a few machines, running USB or CAN it doesnt mater, this script seems to fix the issue for me.

Also I run 2 x control boards, a toolboard, wifi, touchscreen screen and a camera all on usb on a lower powered RKM based host board and the above script fixed the issue me.

7

Well, for debugging I printed a certain .stl file and it was always having a “timer to close” issue at 41% printing state - this is for me an indication that it’s not hardware related (EMI/power supply etc.) - as EMI/power supply etc. would mean that the error is more or less random. My feeling was, the error is related to corner rounding, but this is just a “feeling”. After I changed wiring back to hartk-wiring exact the same .stl file was just printed perfect :slight_smile:
In my mind it seems to be an issue which is software related. But I’m definitely no the one who can judge what is the main reason for this. I saw that there are a lot of “b’Got error -1 in can write: (105)No buffer space available’” errors in the log file. But I have no idea about the root cause.

8

@NexGen-3D. No I haven’t. I did not know this. Now it’s too late, as I have no CAN-Head anymore :frowning:

9

All good, if you decide to test again, maybe give it a shot, I had the same error when using CAN or USB for the tool head.

10

Welcome to the club. I don’t have any clue, maybe someone can help.

Error:
b'Got error -1 in can write: (105)No buffer space available'

But that
No buffer space available
looks like some memory prob.

11

In your case it seems that it would have been as easy as setting

txqueuelen 1024

in the CAN’s interface definition

12

In fact 1024 was my original setting. It did not work. Than I saw the “buffer not available” error messages and I thought I give it a try with a lower value - but it had no effect.

13

Yeah. This brings me to the opinion that it’s software related…

15

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.