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:
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.
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:
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: https://github.com/Aus3D/RUMBA32/issues/12#issuecomment-567540498