Hello, I’ve updated to CAN bridge mode and I see I have a problem with FIRMWARE_RESTART. Firmware version: v0.12.0-8, BTT Octopus plus Fly Mellow SB2040 CAN toolhead. I use canboot mode in 2040 toolhead (no canboot in main board).
my mcu configuration:
[mcu]
canbus_uuid: 0692bed3a983
[mcu SB2040]
canbus_uuid: 40120b79508a
I realized that the problem is with resetting of main MCU. It works on second attempt (sometimes). I played with the python code and found that adding a delay after reset of main CPU solves the problem (not sure if it is proper solution, probably just a workaround only):
file mcu.py:
++ import time
.
.
.
def _firmware_restart(self, force=False):
if self._is_mcu_bridge and not force:
return
if self._restart_method == 'rpi_usb':
self._restart_rpi_usb()
elif self._restart_method == 'command':
self._restart_via_command()
elif self._restart_method == 'cheetah':
self._restart_cheetah()
else:
self._restart_arduino()
++ time.sleep(1)
Do you have allow-hotplug can0 set at /etc/network/interfaces.d/can0 or auto can0?
The latter is wrong for a klipper mcu can bridge setup and is a pretty common misconfig.
Do you mean hardware issue of BTT Octopus? I doubt. I have it for some years and problem appeared after I loaded CAN bridge mode klipper firmware into it. Just to be sure: do you have the same main mcu hardware (BTT Octopus) and do you use can bridge mode?
OK, I wanted to report a bug. I found it is impossible on klipper’s github, tried various channels including this one, I’ve provided all the info to reproduce the problem. So really nobody cares?
You haven’t provided a log demonstrating the problem, only a description. I don’t run in bridge mode anymore, but when I did, I did not have this problem so it may be something specific to your hardware/configuration. Without a log it’s impossible to debug.
When it was? Month ago? Year ago? Years ago? Do you mean that any problem couldn’t be introduced between while?
I am sorry for sarcasm, I am C/C++ developer for last 25+ years. The attitude “the problem must be on your site” is something I am familiar with
If you’re an experienced developer who’s used to pushback, then why don’t you prove @jakep_82 wrong and provide the klippy.log as he requested?
To be honest, after looking over the thread, you really haven’t provided all the necessary information nor is it organized in a fashion that would make it easy to help you.
I’m sure, as a developer with a quarter century of experience, you know the importance of a user providing all information in as an organized fashion as possible.
Well as you can read in my first messages, I don’t need a help, I’ve helped myself by implementing a workarround in mcu.py. In fact I supposed that I am going try to help to others (and to developers) thus I’ve dedicated some of my time into an effort to let somebody know about the problem. The only who replied was a guy of “not reading carefuly” kind and just spammed my thread by not related messages (I am sorry that is just my point of view)
Just looked over your klippy.log. You said you rolled back your “fix”?
A couple of comments right from the start:
Your version is “dirty” which means that some parts of Klipper are not standard. If you look back at other posts, you’ll see that unless the version comes back clean, you won’t get support.
I don’t see the [virtual_sdcard] statement in your config. Going further, I don’t see a reference to “Moonraker”. It is my understanding that both are required for proper operation of Klipper.
I don’t see the macros automatically put in by the [include mainsail.cfg] including [gcode_macro pause] which are required by both Mainsail and Fluidd.
Based on your comments and approach you’re showing here, it seems you are not running a standard Klipper configuration.
We’re here to help, but we need complete information regarding your set up.
BTW, I’m running an Octopus V1.1 in CAN bridge mode with a Voron-SB2040 on my Voron 2.4 without any issues and have been for almost a year without any kind of shutdown or unexplained failure. Klipper version: v0.12.0-207-g6cd17420
I don’t want support, I am just reporting a bug, if you are not Klipper developer, please ignore me. If you look carefully at my messages, you can see also info about my workaround which can be used for deduction of the cause of problem
Are you joking? Virtual SD card as necessary part and Moonraker also? Have you heard about Octoprint? I am sorry things you are mentioning are absolutely unrelated to problem
I never say anything about “kind of shutdown”. The problem is when I issue FIRMWARE_RESTART command, often resp. cca each second time the main CPU will not get restarted properly. I am also mentioning that I am running CANBOOT in SB2040 MCU (nor sure if this is related to problem, just an idea). Do you also use CANBOOT there?
I use Katapult in both the Octopus and the SB2040. I started with Canboot and then transitioned when the name changed.
Sorry, I should have noted that I have never had an issue with any of my printers when it comes to FIRMWARE_RESTART. I’m currently running four printers with CAN bridge (three Manta M8Ps and one Octopus). Two of the M8P printers have BTT42 toolhead controllers while one has a Mellow Fly42. All four have Katapult on both the main controller and the toolheads.
On two of the printers, I may have gone over a year without doing a firmware restart on two of them - I just did it now on a couple of them and here is the result:
Again, nothing like you’re reporting. I jumped in because I wanted to understand your configuration as I felt that the information provided was lacking (despite what you think).
As a word of advice, the Klipper software base is very solid and this is especially true when it comes to CAN. Personally, if I was in your situation, having a problem after updating my system with a feature new to me my first thought wouldn’t have been that there was a Klipper problem that only I could fix.
This would have been a much more positive experience for you if you put in your printer’s information in “General Discussion” along with the issue and let us work with you on it.
Well minimally this creates a difference to my configuration: if you read my first message of this thread, I wrote that I use CANBOOT in the toolhead only. Again not sure if it is CANBOOT related at all
All that are your (false) assumptions. You don’t know how much time I’ve spend on this problem, searching on forums, trying… I’ve found there used to be a problem with CAN bridge and FIRMWARE_RESTART command not so far ago (look at “Still” word in the caption of thread). I’ve replied originally to the thread of original problem. The only one I’ve made excited was a forum purity guard which promptly locked that “old” thread. Thus I’ve started to look inside the fix of previous case and tried some modifications of klippy python code. What I did is for sure not a proper fix but just a workaround, so no I am not the only who could fix that (and certainly I don’t think that about myself ). On the other hands I have some background in software development and embedded systems / electronics including their troubleshooting…
BTW the last message on your screenshot is “Klipper state: Disconnect” thus the picture tells nothing about whether it works after FIRMWARE_RESTART or not: did it get connected and does it work then? Because this is exactly my problem: I issue FIRMWARE_RESTART and klipper in main (BTT) MCU reacts but doesn’t restart correctly in next (e.g. chamber lights will not get ON, not connected state, not reacts). I need to issue another FIRMWARE_RESTART and then it usually gets alive…
