MCU shutdown: Missed scheduling of next digital out event

[Automobilie]

Yep, I would’ve really liked to get CANBus going, but after 3 or 4 months of troubleshooting and a chunk of money it just doesn’t seem to be reliable. At this point, aside from throwing new boards at it I’m pretty well out of ideas

I’ve done new cables, new PSU’s, tied all my shields down, tested different flash settings, checked for overheating, tried different stepper drivers, etc. and it just isn’t reliable. I don’t know if there’s a way to see what is happening on the boards, but if USB will work then I may as well go with that for now and revisit CANBus down the road.

For powering the EBB36, should I cut the ground/power wires from the USB cable? I did read through an interesting article on using the data lines of the CANBus cable (They’re shielded twisted on my cable) and tapping the USB data lines from that:

Upgrade CAN EBB36 to a USB Toolhead

Would there be something to go wrong with doing a setup like that?

[mykepredko]

Could you talk to me about CAN offline?

As for the Lab4450 post - it’s come up here a couple of times and it’s really a disaster in terms of signal integrity.

I’ve never had a problem with CAN - I’m running it on five printers right now, one of them with a Octopus V1.1.

Send me a message and we’ll see about getting it working for you.

[Automobilie]

I’d appreciate that!

[Automobilie]

Alright, want to post an update for future folks looking for solutions to their similar problem (TL:DR currently haven’t gotten CANBus working unfortunately)

Myke and I have:

-Reflashed all three boards according to Esoterical Online for Klipper and Katapult (really good walkthrough btw!) for CANBus with the following settings:

-There’s also a section on adding the can0 interface, 10-can, and 25-can that I hadn’t seen mentioned anywhere else.

-The OS image was reflashed with BTT’s minimal image and then Kiauh was used to install only Klipper, Moonraker, and Mainsail

-Drafted up a wiring diagram:

-Changed some AC wiring at the switches; Neutrals were also being switched, now only the Lives are connected to the two power switches

-Currently testing running minimal Macros with firmware retraction disabled.

-Myke noticed that the process time and system load was considerably higher on my setup vs his CB2/M8P V1.1. I have a CM4 on order I’ll try out, though the CB2 really ought to be able to keep up with everything.

I’m also a bit curious about the EBBCan:Adj looking pretty rough but I’m not well versed enough to understand what I’m seeing:

It has a lower variation for a bit, gradually lowering until suddenly jumping to a +/-10Mhz.

Perhaps some kind of electrical interference? If I can get the house to myself I may be able to shut everything else off (PC’s, fans, etc.) and see what the adjust looks like. It doesn’t really describe why sometimes the error is on the Manta M8p, but maybe there’s something under hood I’m not aware of?

There’s also the option to continue testing USB, as if that doesn’t resolve the issue then that would semi-rule out a CANBus issue.

[mykepredko]

Just a quick datapoint - I replaced the CM4 with a CB2 (Loading in the “CB2_Debian11_minimal_kernel4.19_20240619.img.xz” OS image on the BTT CB2 GitHub site) and ran a failing build for another user without any issues.

Can I ask, have you a [firmware_retraction] statement in your printer.cfg and do you have your slicer producing G10/G11 commands in your GCode file? I’m not sure it means anything but that’s one of the differences we identified and I’m about to run a nine hour test print with this.

[Automobilie]

Yep, normally have Firmware retraction enabled, but have it off for the print that’s on it currently! SuperSlicer was also set to output and add G10/G11’s to the GCode, which is currently off as well.

[enakhala]

I have been having this problem with my new EBB42 setup with a brand new BTT Pi V1.2. Thanks to this thread, I was able to figure out the problem. The movement of the hot-end was causing a slight movement on the power connector of the EBB42 module, thus losing power for milliseconds. I ended up soldering silicon wires to the power cable from one end, and crimping the connector terminals to the other end. Now the silicon wire keeping the power connection made and I am out of the woods.

[Automobilie]

Another update, rebuilt the whole head/hotend, new cable, moved parts around, and going to run a ground wire to the x-gantry, then give it another test run.

If it fails, the CM4 is going in and I’ll test again.

*Hmm, running SHAPER_CALIBRATE and it’s crashing with a 'Timer too close" error at 7Hz during the Y-stage.

Running it through the grapher shows a big spike:

klippy log.zip (1.4 MB)

[nefelim4ag]

I can’t spot anything suspicious in the log.
There is some system load spike, but if you can reproduce it, it is better to look at it with htop.
WebGraph tool is a little broken, for some reason it shows a little too high values for bandwidth.
This is from the klipper’s graphstats.py

Also, you can monitor can bandwidth with nload, I hope it would be pretty neat.

According to this thread CANBUS Missed scheduling of next digital out event - #23 by koconnor, the minimal stable kernel version for CAN is 6.6
From a brief look, you have pretty old Debian, so I can suggest updating the system.

In my personal opinion, it may not be worth it to test and debug, if there is information that something is broken on kernel level with CAN.
So, I suggest upgrading the system, or kernel at least, or reflashing with something fresh.

Hope it helps.

[Automobilie]

Huh, I wonder if that’s been my issue. The CB2 has a custom image from BTT and the Beta they just released says it’s based on debian bookworm (linux kernel 6.1)

*I was able to run the SHAPER_CALBRATE, but only one axis at a time. I’ll probably just put the CM4 in and go from there, the CB2 has been pretty disappointing.

**CM4 is installed and I’m running through calibrations on the machine. Eventually I’ll run a part overnight and we’ll see if the crashing is resolved.

[TreoWayne]

Have you gotten a large part to print with the CM4?

I am facing down similar problems with a Manta M5P, CB2, EBB42, and Cartographer.

[Automobilie]

Haven’t run a long print yet, but the error hasn’t happened with the shorter test prints I’ve run.

Have to redo the berd-air part cooler as the pump overheated and warped, then some vibrations, but otherwise I should be able to run a longer print. The CM4 is a little more powerful, but the big thing is you’re not locked to BTT’s OS image release (64-bit), while the CM4 can use 32-bit.

[Wattie]

What kind of X and Y motor drivers are you using?
External 5160’s?

[Automobilie]

So far haven’t had any crashes, but I haven’t done any prints that were 5-hours before my health took a turn down,

The XY steppers are LDO’s, 1.8*, LDO-42STH482504AC with 5160T Pro drivers being run on 48V, the on-board types that socket into the MCU.

[hcet14]

@Automobilie

before my health took a turn down

Get well. 3D printing can wait!

Get well, hcet14

[Automobilie]

Got another update:

I just finished a 3.5hr print and haven’t had any crashes on any of the shorter prints. It’s hard to pin down which change made the difference, but the big ones were going with a CM4/32-bit OS (Klipper was configured according to the esoteric guide) and adding a grounding wire from the Y-rail-block to the X-gantry (The brackets are carbon fiber, so the hotend was effectively floating from the frame afaik).

The undervoltage with the 5160’s was determined to move with them specifically and regardless of voltage (24v/48v). I suspect it’s something to do with startup as the error would happen when they first activate the steppers.

So for now, I’d suggest just skipping the CB2 and going for a CM4. It has more processing power and doesn’t require only BTT’s specific image, which I suspect was giving me problems, but we’ll see!