Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FAQ] SPI Stepper Driver Defect #23

Open
chrissbarr opened this issue Jun 2, 2020 · 1 comment
Open

[FAQ] SPI Stepper Driver Defect #23

chrissbarr opened this issue Jun 2, 2020 · 1 comment
Labels

Comments

@chrissbarr
Copy link
Contributor

chrissbarr commented Jun 2, 2020

The purpose of this issue is to put info on this problem in one place for easy reference.

What is the problem?

As has been discussed in several issues in this repository and others, there is a design defect with the SPI pinout in the stepper driver sockets that prevents bidirectional SPI communication with stepper drivers from working properly. Because of this, SPI support for stepper drivers in Marlin and other firmware does not work correctly.

Interestingly, this was not detected in initial testing because the tests I did with Trinamic drivers only involved sending commands (set current, set microstepping - etc.) and did not depend on any response from the drivers. However, most firmware seems to require a response, otherwise, you'll see quite a few error messages (and reasonably so).

Which boards are affected?

This issue is present on all board versions from v1.0A to v1.0E. For reference, v1.0E is the only revision sold by Aus3D to date (the earlier revisions were only used for internal development). I have seen some vendors selling clones based on v1.0D, so I am trying to cover my bases by describing all models, whether they have been sold by Aus3D or not.

At the moment, all clone boards from other vendors seem to be based on either v1.0D or v1.0E, and this issue is present in all those boards that I have seen. This includes MKS's modified RUMBA32 board (currently v1.0), which looks to be derived from v1.0E.

V1.1A will be the first model without this fault. I am currently producing the prototype of this revision, after which it should be available for sale through Aus3D.

Fixes?

If you want to get SPI-based drivers working, the following instructions describe one method:

R32_SPI_mod_instructions_v1b

MKS describes a slightly different method in their FAQ here, in which the SLP and RST pins are soldered together. This should get the SPI signals to the correct pins, but it also puts one of the signals on another pin - whether or not all models of stepper driver will work correctly with this is unclear to me.

Another option is to make a small jumper capable of bridging the outer two pins, as shown in this comment here: #12 (comment)

@chrissbarr
Copy link
Contributor Author

Other discussions on this issue:

First discussed in this issue: #12 (comment)
Discussed in MKS RUMBA32 issues here: makerbase-mks/MKS-RUMBA32#2

@chrissbarr chrissbarr pinned this issue Jun 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant