Printer Model: Voron v2.4r2
MCU / Printerboard: Octopus pro v1.1 with Nitehawk 36
Host / SBC: BTT pi 2
klippy.log (4.5 MB)
I am having an issue where the nitehawk 36 or octopus pro loses communication with klipper. It usually happens at around the 1 hour print time mark. I have already rewired everything trying to solve this to try and get rid of any interference on the data lines. I also disconnected the webcam as I read that can cause issues.
I think it’s your nitehawk witch disconnects.
line 6165: Timeout with MCU ‘nhk’ (eventtime=4413.054794)
line 6166: Transition to shutdown state: Lost communication with MCU ‘nhk’
line 6167: [cartographer] Stopping stream
Looks almost the same here
Why is your bandwidth suddenly going down? I would trying a new log and catching the nhk temperature.
That is a useful graph, I have graphed the temperature of the nitehawk with the log uploaded in the original post. And it does slightly increase in temperature at around the same time bandwidth drops, it reaches about 50C and then drops down again. The increase in temperature does coincide with shortest layers on the model I was printing. So I suppose it might be a cooling issue, though it is weird that the shutdown happens after it cools down.
I use https://sineos.github.io/ and should have seen it, sorry. Nitehawk-36 Toolboard uses RP2040, so 50°C shouldn’t be an issue. Did you change something shortly (SW) before this happened the first time? Any updates? I have no helpful idea, sorry.
The only thing I remember changing before the issue is enabling skew compensation, but that shoulnt be an issue. I have taken a further look, and the cartographer peaks in temperature before dropping off right at the time of the bandwidth drop, so it might be related.
I was suspicious about cartographer, but I don’t use it. So I don’t know. All I can say is. When reading in this forum, cartographer is often mentioned for unexpected issues.
I have looked into the logs a bit deeper, and I suspect the btt pi 2 might be the cause of the issues. The sysload is well over 1.0 leading up the crashes in the logs I have gathered, so I am going to try putting in my spare raspberry pi instead, to see if that solves my issue.
I don’t think Carto is related to the log; only the NHK lost connection to the host.
It is questionable why. Where Carto didn’t experience any issues.
Normally, if I’ve mentioned carto in the log it is because it was connected to the same shared canbus with the toolhead, and so, there are unknown source of the error.
(For example both MCUs carto + toolhead lost connection).
It is pretty easy to flash it and get rid of the plugin, but I guess it is something related to the USB stack (dmesg) and/or rp2040.
-Timofey
I think the carto might’ve just been lucky. The carto and nitehawk share a cable. As the cartographer is connected to the nitehawk’s usb expansion slot.
