Mechaduino support (and "Smart Stepper", and their clones)

[KevinOConnor]

This adds experimental support for Mechaduinos (and similar). The "Mechaduino" is an integrated stepper motor, micro-controller, h-bridge, and magnetic hall sensor chip. With this support, Klipper runs directly on the micro-controller, and all movements are scheduled in advance and transmitted from host to micro-controller via USB.

This code is very "raw" - it's a very early release of the code.

There is some documentation available on the branch at: https://github.com/KevinOConnor/klipper/blob/work-mechaduino-20181205/docs/Mechaduino.md

I've only tested this on a clone (the genuine Mechaduino that I purchased hasn't arrived yet).

-Kevin

[KevinOConnor]

FYI, I received the genuine Mechaduino that I purchased, and I can confirm that it runs okay on this development branch.

-Kevin

[jourjine]

hi

Is it possible to make control of Mechaduino as TMC2208 using Tx and Rx intended for it

I ordered and wait for 4 Mechaduino
now i use - Fysetc F6.

Regards

[KevinOConnor]

@jourjine - this particular development branch is specific to installing Klipper on the Mechaduino and then commanding that Mechaduino via USB.

Unfortunately, I haven't had time to do further work on this branch. This development branch isn't particularly useful yet, as any real world usage would require PID control of the Mechaduino current. (Without pid control, the stepper drivers on the mechaduino would likely get too hot.)

-Kevin

[KevinOConnor]

FYI, there is still interest in running Klipper directly on these types of "servo steppers". However, interest has waned on devices using the a4954 stepper motor driver, as that driver runs too hot to run in "open loop mode". In order to manage the heat, they really need to have "closed loop PID control of motor current" - but that PID control can lead to "salmon skin effects" on prints.

Going forward I think we'll have much more luck on devices that are good in both open loop and closed loop mode.

Separately, I understand Arksine has made some updates to the code on his branch at: https://github.com/Arksine/klipper/tree/work-mechaduino-updated

At some point, I do plan to update this branch to the latest code, but likely not in the short term.

@aaalex2021 - FYI.

-Kevin

[xerootg]

I wrote a driver for the tle5012b encoder used on the current generation BTT s42b devices. The simplefoc project in the repo with my hacky driver needs work to be a viable 'drop in' for any other driver out there, but I think the s42b 2.0's would be great klipper candidates. They have CAN transceivers and a stm32f103cbt6! I know the dual a4950 isn't desirable, but I sure would like to see these cheap boards run klipper, and anything would be better than the BTT firmware they ship with.

https://github.com/xerootg/btt-s42b-simplefoc

[KevinOConnor]

I think the s42b 2.0's would be great klipper candidates.

Interesting. I can't find a schematic for that board though. Does the board actually have a CAN transceiver, or did they just route the mcu CAN lines to a plug?

The a4950 drivers aren't great - they'll run hot. (The a4950 has a Rdson of 0.6 ohm - that's better than the a4954's 0.8 ohm, but no where near as good as the tmc2209's 0.17 ohm.) They also look like they have high complexity to control as they require manual selection of fast-decay vs slow-decay modes.

-Kevin

[xerootg]

I get that a4950's aren't great. I have an all-leadscrew printer with 8mm of pitch that I use them on, but printing faster than say 50mm/s means I need some feedback to inform all moves to avoid lost steps. I run mine around the clock too, and they don't run any hotter than anything else. The CAN transceiver is a PCA82C251 and its on PA11 and PA12. I'd happily throw together some CAN POC firmware on one of mine to make sure that the chip... you know... works?

[KevinOConnor]

Interesting. Is there a schematic for the board? Do you know what mcu pins are routed to the tle5012? How is current control implemented by the mcu?

-Kevin

[xerootg]

There's no schematic that I am aware of. The TLE5012B is on SPI1, running the stock pin assignment. The current control is implemented in pwm duty cycle, 100% being max current. The A4950 itself has current feedback but I have not quite figured out if the BTT engineers hooked it up since it does not appear the (poorly written) stock firmware does not use that feedback to hone its duty cycle or even report it. It seems almost set and forget. Here's one such implementation of current control, that said, I'm not sure if the project has good control over the A4950's yet since its a rewrite from scratch Intellistep's motor driver

[rmie]

@xerootg I'm not sure if the current feedback is required in this case at all. Usually motor current is used to get an estimation about the load on the motor. From my limited understanding, it should be safe to reduce the current (duty cycle of the driver) once the motor reached its position or follows the given trajectory close enough.

[viappidu]

@KevinOConnor got something new for you... https://github.com/makerbase-mks/MKS-SERVO42C

[KevinOConnor]

As per the guidelines in the updated CONTRIBUTING document, I'm no longer going to track this experiment here on the main Klipper3d github repo. I'm moving discussion to https://klipper.discourse.group/t/mechaduino-experiment/1685 .

-Kevin