TMC5160 implementation considerations

[hasenbanck]

Currently I'm designing a TMC5160 board and I wanted to get some feedback from you, since Marlin is the main target of the board and you lead the integration of the stepper library.

I'm currently considering if I should also support the encoder interface (as opposed to the SD interface) and dcStep. This would need 5 additional pins for each stepper.

Do see any merit in using the ENC mode over SD mode with Marlin (leaving out the question if it is/will be supported)?

If not, this would enable me to support both TMC2160 and TMC5160 (since the TMC2160 are TMC5160 without the encoder interface).

I also looked at the dcStep interface to the microcontroller. It seems that most implementations simply deactivate dcStep by pulling DCEN low (TMC2130 based boards like the Einsy / or the Wattenrott driver) and not routing DCIN/DCOUT.

It would be nice to hear your thoughts on this topic.

[teemuatlut]

I asked Trinamic about using dcStep a while back and this is what they had to say:

I think, dcStep is not good for 3D printers, because it will modify the velocity dependent on the motor load. It is more, when interaction with external forces or mechanical problems lead to higher demand for torque. The intended use is something like paper forward in printers, so that it is even possible to move when paper jams.

---

The encoder might be interesting but getting it supported both in software and hardware might be a bit much. I think the safest bet would be to go with TMC2160 and stick with the traditional system. At least for the first revision until someone has a proof of concept working with these new features.

[teemuatlut]

Btw, slightly unrelated but as you're designing a board with TMC drivers this might interest you. I'm working on a few features that will reduce the number of required pins to drive the motor. Homing can be done by polling the driver through SPI -> No need for wiring the diag pin Driver enable/disable can be done through SPI -> No need for an EN pin This would reduce the required pins to Step + Dir + SPI, so 15 pins total on MCU side for 4 drivers.

Nothing is merged in yet but they seem to be working on my end.

[hasenbanck]

Thank you for the feedback. I will leave dcStep disabled and won't implement the required hardware for the encoder interface for now. That would be quite nice, since that would mean I could support both TMC2160 and TMC5160 (if one or the other chip, for whatever reason, is not available at assemble time).

Do you plan to upstream the "no enable" and "no diag" pin feature in the foreseeable future? I plan to build the first prototype of the board ("heteromycin", of course open source) at the beginning / mid November. Having to use less pins is always nice, since routing gets a lot easier that way.

[teemuatlut]

Dangerous to give time estimates but most of the changes I've made over the summer I plan to get merged in before the end of the year. And I do typically upload/push everything as a public alpha access for those who want to try something new or perhaps there's a fix implemented to some issue they're having.

[hasenbanck]

Yeah, that's fine I guess. Since it's just a developer board and not a commercial product I think that risk is fine. I will reach out to you when I have something to work with and could act as a tester.

[hasenbanck]

@teemuatlut I just release the first version of my TMC5160/TMC2160 based board using your feedback (https://github.com/hasenbanck/heteromycin). I will start building the first development board in the next couple of weeks, so I think I will take your offer to test the new features soon.

[alexxy]

I'm going to use tmc5160 or tmc2160 for closed loop motor (playing with tle5012b encoders, looks fine)

[ghost]

That's a nice board hasenbanck. I love the STM32F4's and above, MUCH prefer them to LPC or Atmel MCU's.

And TMC5160's as well ! .. perfect

Wonder what price you'll sell them all ?