TMC2130 drivers not working with Arduino Due MCU #435
Comments
|
Same for me... has anybody the TMC2130 running with SPI on the DUE with Klipper? |
|
My TMC2130 drivers work fine with the DUE on the Cruwaller fork of Klipper, but I would really like to run the main branch. I assume it's something simple, but I haven't been able to figure it out. |
|
U can acknowledge that the main branch is not working with SPI? |
|
If I run the Cruwaller fork my drivers work fine with SPI. If I run the main branch with the appropriate changes to printer.cfg but the same driver and CS pin definitions, the drivers do not work with SPI. |
|
@KevinOConnor do you have any idea? Did it maybe never worked with the DUE? |
|
For reference, this is the basic config file that works on the Cruwaller fork. |
|
@jakep82 could you provide a log of such a non-working session? What means "do not work"? |
|
On Wed, Jun 27, 2018 at 09:14:30PM -0700, jakep82 wrote:
I'm using an OULWare board (http://www.oulware.org/index.php/Printer_Controller) with a Due as the MCU. I have everything working except my TMC2130 drivers on X and Y. I've tested these same pin definitions on Cruwaller's fork and they work fine there, but I'm unable to get these drivers to work on the main Klipper branch. G28 for X and Y simply times out with no movement or indication that the drivers have initialized. Perhaps I'm doing something wrong? Log file attached.
I don't know why that would be. Nothing has changed recently in the
TMC2130 code nor in the Arduino Due code. I looked and the sam3x8e
SPI code on the cruwaller repo seems identical to the code on the main
branch.
I put up a test branch that you could try running the new DUMP_TMC
command on:
cd ~/klipper ; git fetch ; git checkout origin/work-tmc2130-debug-20180630 ; sudo service klipper restart
However, this debugging code hasn't itself been tested, so I'm not
sure how helpful it will be.
…-Kevin
|
|
FYI, I've pushed the new DUMP_TMC command to the master branch and I have removed the work-tmc2130-debug-20180630 branch. -Kevin |
|
All it returns is missing stepper.
|
|
@jakep82 I notice in your config you use ; to comment out instead of # I dont know if that is correct maybe it is, I only see in configs the use of # to comment a line out |
|
Just as a note with dump_tmc The command format is Also as a note, if your TMC drivers are not working issue a |
|
On Sat, Jun 30, 2018 at 04:52:50PM -0700, jakep82 wrote:
All it returns is missing stepper.
> Recv: !! Error on 'dump_tmc': missing STEPPER
There should be a STEPPER parameter with the name of the tmc2130 that
is being queried. For example: DUMP_TMC STEPPER=stepper_x
There's a little bit of info in docs/G-Codes.md.
…-Kevin
|
|
Results below. I've tried restart, firmware_restart, changing my power up sequence, etc. Nothing seems to give me functioning drivers for X and Y.
|
|
After attempting to home X, the GCONF value changes, but I get no movement on either stepper.
|
|
Random question, have you tried upping the current to the drivers as a test? |
|
Changing the current makes no difference. I've tried setting the run and hold currents to 1 amp. I've also tried reducing the stealthchop threshold. The drivers simply don't initialize, and I get zero indication of movement or power to the motors. |
|
The fact you are getting values back from dump_tmc means they are getting powered and your CS pins are correct you'd be getting 0 for everything. Klipper seems to be doing what it should be. I'd suggest checking your pin out and wiring, if you've not already. |
|
I run my DUE now without the TMC2130 and need the printer for some parts. Tomorrow I ok get a new due and will go in with some test to verify jakep82 problems. My last tests also didn’t power up the motors (no click if I try to move the motors for the fist time) like death drivers. No movement at all. On my MKS Board i didn’t had that problem before. They worked as aspected. |
|
On Sun, Jul 01, 2018 at 08:10:07AM -0700, jakep82 wrote:
After attempting to home X, the GCONF value changes, but I get not movement on either stepper.
> Send: G28 X0
Recv: !! Failed to home x: Timeout during endstop homing
Recv: ok
[...]
Send: DUMP_TMC STEPPER=stepper_x
Recv: // GCONF: 209609
Recv: // GSTAT: 0
Recv: // IOIN: 1000000
[...]
Recv: // TSTEP: 4000000
This definitely looks like an SPI problem. My first guess is that
there is an issue in the Due spi code, but I don't see any difference
in that code with the code on the cruwaller branch. What version of
cruwaller's code were you previously using?
One thing you could try - modify the 4000000 to 100000 in the
following line of code in klippy/extras/tmc2130.py:
self.mcu.add_config_cmd(
"config_spi oid=%d bus=%d pin=%s mode=%d rate=%d shutdown_msg=" % (
self.oid, 0, cs_pin_params['pin'], 3, 4000000))
then run "sudo service klipper restart".
If that doesn't work, another thing you could try is commenting out
your fan section. (The ar10 pin on the DUE is, oddly, also connected
to the NPCS0 pin..)
…-Kevin
|
|
I was running his OULWare specific fork at the link. I'll try the 2 things you mentioned tonight and see how it goes. |
|
I tried both of these things and neither worked. I'm going to boot back into the OULWare/Cruwaller SD card I have and make sure the drivers are still working, but last time I checked they still worked on his fork. Not sure why they aren't working here. |
|
I switched back to the OULWare fork, and the drivers are working perfectly there. Not sure why they work there, but not on the main Klipper branch. The pin definitions are the same, and I think I have everything else set up correctly in my printer.cfg file for the main branch. |
|
On Mon, Jul 02, 2018 at 06:38:14PM -0700, jakep82 wrote:
I switched back to the OULWare fork, and the drivers are working perfectly there. Not sure why they work there, but not on the main Klipper branch. The pin definitions are the same, and I think I have everything else set up correctly in my printer.cfg file for the main branch.
I'm not sure why.
What branch revision of OULWare are you using? (git describe --tags)
What does DUMP_TMC report when using the slower spi rate?
Are there other SPI devices on the board (like thermocouples)? If so,
try adding output_pin sections to force their cs pins high.
I can't see any significant changes on the OULWare branch, so I can't
explain why you would see a significant difference. That said,
there's tons of "cosmetic" changes on that branch, so anything could
be hiding in there.
…-Kevin
|
|
After changing the SPI rate to 100000 and restarting Klipper I get the info below. I don't have a thermocouple.
On the OULWare branch the output of git describe --tags is below.
|
|
If you pull the latest code and reflash the micro-controller, does it help? If it does not help, could you try disabling the thermocouple in your oulware branch and see if that has any impact on the oulware operation? -Kevin |
|
This fixed it! Thanks for looking into this issue. I've got my drivers running with sensorless homing now. I'm about to do a test print, but everything seems 100% functional so I'm going to close this issue. |
I'm using an OULWare board (http://www.oulware.org/index.php/Printer_Controller) with a Due as the MCU. I have everything working except my TMC2130 drivers on X and Y. I've tested these same pin definitions on Cruwaller's fork and they work fine there, but I'm unable to get these drivers to work on the main Klipper branch. G28 for X and Y simply times out with no movement or indication that the drivers have initialized. Perhaps I'm doing something wrong? Log file attached.
klippy.log
The text was updated successfully, but these errors were encountered: