That’s an interesting about the twisted pairs - I’d be interested in seeing your CAN cabling, especially at the connector ends.
However, I’m more interested in seeing what happens if you remove/comment out the macros that are running in you system.
The ones I’m wondering about (going from your latest klippy.log) are:
M300
SET_PAUSE_NEXT_LAYER
SET_PAUSE_AT_LAYER
SET_PRINT_STATS_INFO
_CLIENT_EXTRUDE
_CLIENT_RETRACT
I believe that these macros are continuously active and I’m wondering if they’re contributing to your overall system load (which is causing the problem). I don’t believe that they are required for operation of your printer.
Something else that I’m curious about is the use of
[mcu rpi]
serial = /tmp/klipper_host_mcu
I’m skeptical that this contributes to the overall system load but this is something in the systems of other people that are having the same problem.
I’m asking this because I’m working with somebody who has the same problem in a printer with a CAN toolhead and also has macros that I’m wondering are adding to the overall system load that results in a “Timer Too Close” error.
On the other side of things, I have never experienced a “Timer Too Close” even though I have six printers running with a CAN toolhead. The characteristics of my systems are:
They all use main controller boards with integrated CAN
They all connect to the host using USB
There are a variety of hosts (CM4, Raspberry Pi 4B, Raspberry Pi 5B, CB1, CB2 and Orange Pi CM4)
OSes are all Debian based generally running Bookworm with some Bullseye. For each of the hosts, except the Orange Pi CM4, I started with the minimum OS and added Klipper using KIAUH. For the Orange Pi CM4, I used the Klipper version of Debian and, using KIAUH, removed everything but Klipper/Moonraker/Mainsail
Klipper is kept up to date with main controller board and toolhead firmware updated every two-three months
Toolheads are EBB 42, FLY SHT 36, SB2209
Cabling is Tensility 30-02482 (Twisted pair and foil shielded 28AWG + 2x 22AWG non twisted/shielded)
Other than the mainsail.cfg macros, I only run my sensorless homing macro which lowers the motor current during homing
The only significant difference I see between my systems and those like yours, which have problems, is that I don’t have any macros that can execute during a print.
So, could I ask you to take out your macros, put back in the CAN toolhead functions and run a test? I understand that these macros are performing functions that you consider necessary but, as I said, I’ve seen a number of people with CAN issues and macros seem to be a common feature of the systems.
The USB cable you’re seeing is connecting the MCU with the host.
Second, I may not be understanding how exactly klipper works, but why do you think the listed macros are continuously active? Shouldn’t they be executed only when called?
Regarding this line:
[mcu rpi]
serial = /tmp/klipper_host_mcu
I admit that I don’t know what it does and why is it there… I removed it.
In the mean time, I commented out the above macros and started the test print. However, why do you think it could be related? I did comment out the connection to the toolhead and the print was successful, so shouldn’t I be looking in the direction of the CAN connection?
Anyway, while typing this the print crashed “failed to connect to MCU”. It is not able to connect anymore…
I’m looking at differences between our systems that could be significant. When working with people I’ve found that they often get macros from other sources and don’t understand their operation.
There are many that can operate at any time because they override basic system operations (ie changing the behaviour of a g-code).
They’re also a variable that’s pretty simple to eliminate - usually just comment out the include file line.
Could you post your latest klippy.log?
Are you able to reconnect? If so, do you:
Wait a few moments/minutes and hit the “Reconnect” button in Mainsail/Fluidd?
Press the physical SKIPR/Toolhead MCU “Reset” button?
Power down/power back up?
Honestly, there’s a fair chance it’s a cable, but when I’ve helped other people with this problem, we’ve worked to get a perfect CAN cable solution and there are still failures - that’s the reason why I’m hesitant to say fix the cable and everything will be fine.
OK, sorry for the confusion I caused. Yes, the SKIPR has it all combined on a single board. The USB cable connects the host side with the MCU side. The only way we figured it can work is in CAN bridge mode - there appears to be no internal connection between the host and MCU sides.
No, I am not able to connect anymore and nothing fro your list seems to help.
OK, I see what you mean and considering it can’t even connect although it used to be able to so, I think it could be something beyond the cable indeed. It should at least be able to connect I mean.
Okay thanx - it looks like your CAN interface is not working. I see the MCU connection, I don’t see the same for the MKS_THR.
If nothing else has changed, then most likely it’s a wiring connection problem. Saying that seems a bit ironic.
Are there any LEDs on the MKS_THR that you can check its operation with?
Thank you - I would have thought the SKIPR would have an internal USB connection like the Manta boards.
Let’s see if we can figure out how to get your connection back up and then go back to the original problem.
Could you check your cable and make sure there’s a connection between the SKIPR and MKS_THR? From there, you might want to try burning the firmware into the MKS_THR again (noting that the connection between the Host and the SKIPR’s MCU seems to be good).
Guess what - after the failures to connect yesterday, I turned it on today and it connected right away… lol.
Actually, this behavior started after I (in an attempt to find a fix) reflashed the MCU with a Clock Reference of 16Mhz (instead of 8Mhz). It failed to connect and then I flashed it back with 8Mhz and right away it still failed to connect. Following this I reflashed it a couple of times thinking it did not flash correctly, but as we can see it seems to persist. Of course could be (like often it happens in life) a coincidence and the real thing to blame is still the cable connection lol.
So anyway, I disconnected the connector from the main board and inspected it for any signs that could indicate a bad connection. It looked fine to me and I put it back. Also I checked the screws on the terminal on the THR36 board:
All were in tact and tight. The bottom screw I was able to give it another turn and a half though. In hopes that this was the issue I have started the test print (all above macros are still disabled). Will report further…
But the most important thing is that the print has SUCCESSFULLY FINISHED!
So my guess is that it was indeed a bad cable connection. So thank you very much for insisting on checking it again! Probably that one little screw with its additional turn and a half did the trick.
I am now going to uncomment all the macros. Although I don’t know what they are meant for and what is it they are doing. Most of the (actually all but the M300) were in the mainsail.cfg file. If you have any idea, please let know.
WOW! Just thank you very much again! I am slowly realizing it might be the end of this never ending untraceable issue… lol. THANK YOU!
