Mainsail doesn't connect to Moonraker after Klipper update

Basic Information:

Printer Model: EnderXY
MCU / Printerboard: BTT SKR Mini E3V3 & Creality 4.2.7
Host / SBC: RPi 4
klippy.log (plus moonraker.log and mainsail-error.log): (1.3 MB)

Describe your issue:

Everything was working fine before I updated Klipper to the most recent version. Now, I can only get Mainsail to connect to Moonraker when the printer is off. Once I power on the mainboards and restart Klipper, Mainsail times-out on “Initializing” and says it can’t connect to Moonraker.

Edit: This seems like a Mainsail issue. I can connect to Moonraker via Mobileraker and KlipperScreen and use the printer normally as long as Mainsail isn’t open anywhere.

What I’ve tried so far:
*Uninstalling/reinstalling Moonraker
*Uninstalling/reinstalling Mainsail
*Rolling back Klipper several versions with KIAUH

  File "/home/pi/klipper/klippy/", line 217, in run
  File "/home/pi/klipper/klippy/", line 292, in run
  File "/home/pi/klipper/klippy/", line 340, in _dispatch_loop
    timeout = self._check_timers(eventtime, busy)
  File "/home/pi/klipper/klippy/", line 158, in _check_timers
    t.waketime = waketime = t.callback(eventtime)
  File "/home/pi/klipper/klippy/", line 496, in _do_query
    res = query[obj_name] = po.get_status(eventtime)
  File "/home/pi/klipper/klippy/extras/", line 110, in get_status
    'enabled': self.steppers[0].is_motor_enabled()}
AttributeError: 'MCU_stepper' object has no attribute 'is_motor_enabled'
Transition to shutdown state: Unhandled exception during run

I was going to ask if you were running custom code but it looks like the manual_stepper class was updated last week and is now throwing an error.

@koconnor - I believe

'enabled': self.steppers[0].is_motor_enabled()}

is meant to be

def get_status(self, eventtime):
    return {'position': self.rail.get_commanded_position(),
            'enabled': self.stepper_enable.lookup_enable(self.steppers[0]).is_motor_enabled()}

But manual stepper doesn’t implement an instance of stepper_enable so I did it the long way in the comment below as a fix. (1.8 KB)

@ron_swan - Drop the Python file in the zip into ~/klipper/klippy/extras.

I changed

def get_status(self, eventtime):
        return {'position': self.rail.get_commanded_position(),
                'enabled': self.steppers[0].is_motor_enabled()}


    def get_status(self, eventtime):
        return {'position': self.rail.get_commanded_position(),
                'enabled': self.printer.lookup_object('stepper_enable').lookup_enable(self.steppers[0]).is_motor_enabled()}

Which I believe was the intention in the first place. It’s a quick and dirty fix.
If it doesn’t work let me know and attach a new klippy.log and I’ll see what’s up.

That didn’t help, unfortunately.

klippy.log (496.3 KB) (1.8 KB)

I caused another error by being quick and dirty, try this one, It reverts the manual_stepper back to before the status function was added (1.8 KB)

Okay, dealers choice, the previous one reverts back to before the change.

This one actually corrects the issue.

@koconnor - Sorry for the double tag, but I can confirm the newest update to manual_stepper (the status function) causes Mainsail to hang when the webhooks try to get the stepper status cause there is an error.

I’ve messed with my branch of Klipper so don’t want to put in a PR and have to mess with another branch and making sure I take out unintentional changes.

I changed the following lines…

34         self.stepper_enable = self.printer.lookup_object('stepper_enable')


    def do_enable(self, enable):
        if enable:
            for s in self.steppers:
                se = self.stepper_enable.lookup_enable(s.get_name())
            for s in self.steppers:
                se = self.stepper_enable.lookup_enable(s.get_name())


    def get_status(self, eventtime):
        return {'position': self.rail.get_commanded_position(),
                'enabled': self.stepper_enable.lookup_enable(self.steppers[0].get_name()).is_motor_enabled()}

This one worked! Thanks Giggler!

Unfortunately, there was a defect in PR #6527. I reverted that PR in commit 4cfa266e. Sorry for the delay.


1 Like

Updated to 4cfa266e and can confirm the bug is no longer present for me.

1 Like

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