Oids already allocated

General Discussion
1

Basic Information:

Printer Model: Voron 2.4
MCU / Printerboard: Octopus Pro with H723
klippy.log

Fill out above information and in all cases attach your klippy.log file. Pasting your printer.cfg is not needed
Be sure to check our Knowledge Base and in particular this and this post

Describe your issue:

Any restart of klipper I get this:

MCU 'mcu' shutdown: oids already allocated
Once the underlying issue is corrected, use the
"FIRMWARE_RESTART" command to reset the firmware, reload the
config, and restart the host software.
Printer is shutdown

I have to do a full power cycle to get it to work (i.e. the mcu has to be power cycled)

klippy (1).log (4.3 MB)

2

https://www.klipper3d.org/MCU_Commands.html

I got it, sorry.

3

Sorry, not following?

4

I dont see “Closing raw can socket” in your logs, something about how you are restarting it seems.

This is from a FIRMWARE_RESTART in my logs,

Attempting MCU ‘mcu’ reset command
mcu ‘BTT_SB2240’: got {‘oid’: 10, ‘next_clock’: 3820747487, ‘value’: 14562, ‘#name’: ‘analog_in_state’, ‘#sent_time’: 9820.055811941, ‘#receive_time’: 9820.838992712}
Attempting MCU ‘BTT_SB2240’ reset command
Closing raw can socket
Restarting printer
Start printer at Mon Apr 24 21:52:40 2023 (1682398360.4 9822.1)
===== Config file =====

5

I have the default restart. If I use the by command, same issue.

It’s installed using USB.

It appears to be an issue with the support for the H723 because I have an older Octopus that doesn’t have this issue with the same settings.

6

This looks like a logging statement from the python socketcan module. So it’s coming from the klippy server not the MCU, but it does appear it may be related to how you are connected to the MCU, is this over CAN as well? USB?

7

The Octopus Pro is USB.

I then have an EBB2040 over CAN separately connected using an UC2 controller. The error seems to be the Octopus Pro via USB?

8

It’s the fact that on shutdown the can socket isn’t being closed, can you make sure your klipper source directory is the latest commits from master (GitHub). You may have to reflash your devices.

I have the same setup but with an Octopus V1.1 (F446)

9

They’re both flashed to the same version: v0.11.0-175-gcba119db

Was there a change in v0.11.0-188-gb17ae55f that would have fixed this?

10

Not a Klipper Dev, so I can’t be sure. Also not sure where you are getting those release tags from, I run klipper from a clone of the GitHub Repo and I dont see gcba119db or gb17ae55f as commit hashes. But I am running of the master branch and there were some recent commits the last few days for optimizations for Can Bus and USB scheduling.

So I would say it wouldn’t hurt.

11

Grabbed the very latest 11.0-191 pull from git (git pull on master) and flashed both the ebb sb2040 and the octopus pro to it.

Same issue.

12

That’s certainly odd.

I’m not sure if you have found a solution for the issue.

The logs seem to indicate that the stm32h723 cpu was not able to reset itself. Double check that the chip on the board matches the chip you have compiled for. Otherwise, you may want to grab the latest code, make sure you haven’t made any code modifications, reflash all the boards, and upload that log here.

-Kevin

13

Update: Grabbed the latest and flashed the stm32 and still has the same issue.