input shaper with SB2040 - 'mcu' shutdown

[Flob74]

 

Hi everyone,

I integrated the SB2040 from Mellow Fly on my Stealthburner toolhead. Everything run just fine (I couldn't resist trying a print), but I can't use the on-board ADXL345 to run the klipper input shaper measure.

I got the following error :

I got an BTT Octopus and a Rapsberry PI 3B. The octopus works as a CAN bridge with the SB2040 and I flashed both bootloader with CANBoot. The Canbus was set at 500kbps.

 

The accelerometer seems online because I get datas with ACCELEROMETER_QUERY

I run TEST_RESONANCES AXIS=X on the console, the toolhead move, the frequency increase and at around 100Hz... mcu shutdown.

When I decrease the microsteps in the printer.cfg file, I can reach an higher frequency. For example, at 128 microsteps, I reach around 50Hz, and at 16 microsteps I reach around 100Hz.

Here are my thoughts:

• On Mainsail, all CPU/MCU load seems ridiculously low during the test, so I don't think that it's a CPU/MCU bottleneck.
• Maybe the can bus has a not enough data bandwidth. Is it possible to enhance the bandwidth to 1000kbps ? Has anyone ever tried this ?
• I doubt that the bottleneck comes from the cable. Even if it's not a shielded cable, it's a twisted pair hand-welded to the RJ11 connector.
• I also doubt that the bottleneck comes from  the microSD card, because it's a SanDisk Ultra 32Gb
• Maybe it's the USB-C cable between the octopus and the RPi (source from the formbot kit). I will try this evening with a trustly cable from ugree.

If someone has already experience this before, or you have another ideas, thank you for your answer.

 

Edited November 23, 2022 by Flob74

[Flob74]

Sorry for the late answer.

 

It work for me.

• I reduced to 16 microsteps according to atrushing 's post.
• I increase the CanBus speed to 1Mbps. A little tricky to flash the SB2040 but after a bit of insistence, it worked.
• I desactivated the LED_EFFECTS during probing (I use just static led effects). Because the response time is not quick enought and cause time probing errors. Turn of led_effects also during the test resonnance.

Edited January 30, 2023 by Flob74

[claudermilk]

I was going to ask about the baud rate. I have no personal experience with CAN, but both Nero and Steve have builds using it right now. Both have noted (and were advised in chat) to run at least 500000. I think Steve set his to 1000kbps and it booted. So yes, I'd say try that. Worst case is it errors, right?

[Flob74]

1 hour ago, claudermilk said:

I think Steve set his to 1000kbps and it booted. So yes, I'd say try that. Worst case is it errors, right?

I just risk to spend some time to reflash both bootloader and klipper. I will try as soon as possible and keep this post updated.

Thank you.

[smirk]

1 hour ago, claudermilk said:

think Steve set his to 1000kbps

I'd second that set it to 1Mbps - if you're getting better rates by hobbling the stepper speed that (to me) definitely points to a sampling rate/bandwidth issue.

[Flob74]

Hello everyone,

So, some news since my last message.

I updated the Canboot and the klipper config on my two MCU to reach a 1 Mbps on the CanBus and a txqueuelen of 256 bits. I keep 16 microsteps for all steppers configuration and I managed to end the X and Y test resonnances at 133hz !

But, I got two new issues :

• I still can't use 256 microsteps for my drivers an run a test resonnance ("Timer too" close error)
• I can't run a quad gantry level with the rainbow led effect ("Communication timeout during homing" probe error). But it desapear when I desactivate the led effect (weird , maybe a staturation of communication between the pi and the octopus due to multiples led's color changes)

I will try to increase the txqueuelen. It seems logic that the faster the Canbus, the longer the txqueue.

[claudermilk]

Why are you trying to run 256 microsteps? I think most of us are running 32 or 16 which is plenty.

[Flob74]

Why not ? Higher is better (Except when it overload the mcu or the bus communication bus).

It's a bit overkill, and I think that I will reduce it.

[smirk]

4 hours ago, Flob74 said:

Higher is better

Beyond the marleting wolrd , when it comes to microsteps, not necessarily. They're not "real" steps and things are relying on controller magic to hold the stepper motor's rotor between actual physical steps and there's no accurate way to do that (in the sense that a microstep will never really be precisely 1/x (fraction) of a whole step it's a really bad approximation). I think where the supposed improvements (and probbaly the true benefit of using microstepping) come from are smoother/quieter operation which in turn might lead to an artificial (or perceived) improvement in quality or accuracy as the set up is not vibrating as badly when the stepper motor would naturally go klunk-klunk between the actual teeth/steps on the rotor (if it were doing 1:1 microstepping).

As you observe, using higher microstepping will increase the overall workload on the processor (in the case of Klipper) or MCU (in the case of something like Marlin). Whilst microsteps might not be "real" steps (in my parlance) they do still require real processor instructions.

[atrushing]

14 minutes ago, smirk said:

Beyond the marketing wolrd , when it comes to microsteps, not necessarily.

Before 3D printing got so big and Trinamic drivers became a standard, the premium drivers for hobby CNC machines were GeckoDrives. They would max out their microstepping at 10 and had logic in their drivers to switch to full stepping above a set speed threshold to maximize power at speed.

Every motor has a speed/torque curve showing how torque drops off as speed increases but there are also charts on torque/microstepping like this one from Faulhaber:

[Flob74]

Wow !

I knew there were a torque drop as the number of microsteps increase, but I never look further. Indeed, 16 microsteps seems a good compromise between silency and holding torque performances (even if the chart is for another stepper motor than mines). (Moreover, it won't increase the worload on the MCU).

I had been wondering why Vorons kits included TMC2209 with if everyone use 16 microsteps. But it seems that it's more for the silency and current than the microsteps limits.

Thank you for these so complete answer.

[OpenDelta]

Did you fix this problem?
I have the same problem with SB2040.

I get up to 133 Hz and the MCU shuts down. 
Changing the microsteps didn't do anything for me.

 

[kleopaq]

Same problem with SB 2040 with Octopus 1.3 (host Orange Pi) occured after I have installed scirts, bottom panel and fans on my Voron 2.4.  Will try to increase the Canbus speed to 1 Mbps and check the temperature.

Edited February 14, 2023 by kleopaq

[Glengus]

thank you very much for this, already had canbus on 1000000 with my octopus pro bridge mode, ebb36, pi3b+ setup and it was doing the timer error at around 100mHz. Dialed back from 32 microsteps to 16 on everything and it now runs the full program!