TMC2130 support #101
Comments
|
It is mostly compatible, since the board is on a AVR and is RAMPS like. I think only we are missing TMC2130 support. |
|
cruwaller already has a branch with tmc2130 (and a smoothie compatible, or both), I already compiled it and will probably test it at the weekend |
|
Would like to try. Please let me know if you get this working |
|
Hi, i am also interested in testing this somewhere in the next month. Just installed tmc2130 on my megatronics 2 board. Where could i find this cruwaller branch? |
|
Would be amazing if this worked with prusa mk3 + octoprint. The prusa firmware has a bunch of features which I assume would not have equivalences in klipper such as the auto leveling stuff and filament detection/crash detection... |
|
actually cruwaller does not have a tmc2130 branch anymore. I think he deleted it. whats the level of effort for getting klipper to utilize stallguard2 via spi |
|
on 2017-12-26 he merged tmc2130 branch into lpc176x, where he is testing it now, see for example klippy/drivers/tmc2130.py Also, his latest commit in lpc176x branch has the comment |
|
unfortunately he did not answer my questions on his github mail address or in any of my issue comments (explicitly asking @cruwaller). He has a bunch of changes that would be useful, e.g. things like allowing any order of ^! for pin definitions or suppressing some compiler warnings. |
|
@hg42 sorry :( |
|
Others, TMC2130 branch is merges to lpc176x (all my mods are there now). It still supports same MCU as original... |
|
@cruwaller so TMC2130 should now work in ramps config? |
|
@cruwaller I see there is an ss_pin for CS/SS but what about for the diag pin? |
|
from what I know about TMC2130 the diag pin is not needed, because you can write/read values via SPI. Which usage do you mean/want/think of? |
|
my printer is the prusa mk3 which i believe uses the diag pin for the endstop. ive tried setting the endstop pin to use the diag pin but no detection. there are many other issues im having and i doubt i can get this to work correctly without expert aid. |
|
@cruwaller how did you connect the TMC2130? I once had a plan to program the diag pin to signal stalls and simple connect it to an endstop input. |
|
@simonlee not that I currently use the TMC2130, but did you look at the example config files? so you select a function for the diag pins 0 and 1. For example, if you have diag0 connected to the end stop input, then it has to be and either you omit diag1 or you set it like this if you want to assign the temperature warning to it. |
|
I gathered from this file that the max endstop pin is the diag pin: so my config looks like: PK2 is the x diag pin. Not sure if it needs |
|
I would try to find out which diag pin is used, there are 3 pins. |
|
Any progress @simonlee ? I'm stuck in the same position with TMC2130 and RAMPS. |
|
@TunaLatte , I'm not sure where @cruwaller is with his development, but if someone can forward me a schematic of an AVR board with the TMC2130 then I'll take a look at adding basic support for it. (I need a link to the schematics - a simple document describing which pins on the mcu connect to which pins on the TMC2130.) We already support the TMC2100 on the Replicape, so I don't think it's a big deal to add in basic TMC2130 support. |
|
@KevinOConnor : Check page 10 in the datasheet. Is that what you need? |
|
@TunaLatte |
|
I see
Can you please post your config? For ramps I suspect the SS pin to be
different?
Thanks
…On Feb 12, 2018 6:53 PM, "Simon Lee" ***@***.***> wrote:
@TunaLatte <https://github.com/tunalatte>
I've taken a break from this. I tried the above suggestions but no luck.
The steppers do move, but I am not able to figure out how to get it to
detect the endstops via the diag pins.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#101 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AiMQ8ighWReDOrCF3wyUDGtgNgCDp4bvks5tUF6GgaJpZM4RUwuL>
.
|
I did not try to swap the diag0 diag1 as @hg42 suggested though. |
|
Thanks Ill mess around and report asap |
|
@KevinOConnor In a basic scheme this is how mine is exactly wired now + diag1 (upper pin from the triangular pin order in the following picture orientation.) to the S (signal) endstop pin accordingly per each axis for sensorless endstop : |
|
Success! I'll be dry running a 15 hour print now (with nozzle removed so the extruder motor/calculations are still done) and report back. Here is my config for RAMPS1.4 with the same wiring as above including the extra (not visible) enstop pins like this from toms3d: Config: Edit: config was the wrong one, updated. |
|
@TunaLatte what printer are you running and what speeds did you manage? with Marlin I have everything running including sensorless homing but the problem is skipped steps and have to run it at slow speeds. |
|
In Marlin you can override the SPI pins , will it be possible in klipper
/**
|
|
For corexy does it take into account that both X/Y endstops are involved? Just playing with it and it seems pretty touchy and not sure if that may be part of the issue. |
|
On Wed, May 23, 2018 at 05:09:42AM -0700, Douglas Hammond wrote:
For corexy does it take into account that both X/Y endstops are involved? Just playing with it and it seems pretty touchy and not sure if that may be part of the issue.
No, it wasn't doing that. I added some additional code to turn on
stall detection of both steppers if on corexy.
cd ~/klipper ; git fetch ; git checkout origin/work-tmc2130-20180522 ; sudo service klipper restart
…-Kevin
|
|
I'll keep trying. With that change and using the same drive_SGT of 2 I know get |
|
No success with other settings. The changes cause timeouts. |
|
On Wed, May 23, 2018 at 02:47:49PM -0700, Douglas Hammond wrote:
No success with other settings. The changes cause timeouts.
Ah, okay. Thinking about this further, the corexy changes I made were
not valid. The code turned on stall detection for both steppers, and
would stop both steppers if either one stalled. However, the homing
code will wait for both steppers to report a stall - only one has to
stall for the home to be considered complete.
For now, I've backed out the corexy specific code from the
work-tmc2130-20180522 branch. I suspect basic cartesian and delta
sensorless homing will work okay with the current support.
It would require a bit more python code to get corexy sensorless
homing working properly. For now, I think I'll leave that coding to
yourself or someone else with the hardware.
Separately, were you able to confirm the stealthchop threshold works
okay?
…-Kevin
|
|
I have reverted to your most recent changes and all is working. I have enabled stealthchop and tried different thresholds 60 100 200 400. I may not have the best tuned parameters for it. I do hear a different, not quite sure it is kicking in at the correct speed though. I'll have to create a test gcode to do so. Will let you know. |
|
Ok I took the values from marin and added a few more settings to match the marlin such as setting autoscale. It is working well now. Not sure if you are interested in those changes https://gist.github.com/wizhippo/ba9a5ea341c5785c9638bea99312326c. Can say the autoscaling made any huge difference. |
|
When stealthchop_threshold (> 0) is enabled:
When stealthchop_threshold (#) is off:
|
|
@Alexdad76 Not sure if it helps but here are the settings I used and have great success with now. I do have active cooling. [tmc2130 stepper_x] |
|
On Wed, May 23, 2018 at 08:15:02PM -0700, Douglas Hammond wrote:
Ok I took the values from marin and added a few more settings to match the marlin such as setting autoscale. It is working well now. Not sure if you are interested in those changes https://gist.github.com/wizhippo/ba9a5ea341c5785c9638bea99312326c. Can say the autoscaling made any huge difference.
It did make a difference, or it did not make a difference?
Okay, thanks. What if we let the user specify the parameters for
PWMCONF (see updated work-tmc2130-20180522 branch)? The Marlin values
look very close to the chip defaults anyway.
…-Kevin
|
|
On Thu, May 24, 2018 at 03:33:52AM -0700, Alexdad76 wrote:
When stealthchop_threshold (> 0) is enabled:
1. There were crunches when moving diagonally (at any speed).
2. The beginning and the end of the movement became very sharp, like a blow.
When stealthchop_threshold (#) is off:
1. Any movement is almost noiseless.
2. Start and end movement is soft.
CoreXY.
What was your config? I just noticed that the default TOFF was
incorrect (it should have been TOFF=4 not TOFF=1). If you didn't
specify a TOFF manually, you should probably pull the latest code and
retry.
Otherwise, do you think the stealthchop code is incorrect, or do you
think it just needs to be tuned for your motors?
…-Kevin
|
|
AllowIng the user to modify pwmconf is best route. I did not measure forces but I did notice that my sensorless homing seemed not as abrupt and I had to increase the SGT from my first tuning. Great addition again thanks for the project. |
|
I chose the parameters by ear, and by |
|
Your current looks pretty low. Especially the hold current. Usually it’s about %70. I had skipping until after .8 |
|
Is hold_current used during movements? I expected that only for holding in a state without movement. |
|
On Thu, May 24, 2018 at 09:44:30AM -0700, Alexdad76 wrote:
[stepper_x]
step_pin: ar54
dir_pin: ar55
enable_pin: !ar38
step_distance: .01
endstop_pin: ^ar3
position_endstop: 0
position_max: 190
homing_speed: 50
[tmc2130 stepper_x]
cs_pin: ar63
microsteps: 8
FYI, I found a problem with stealthchop_threshold - it wasn't using
the proper microsteps setting - this would have caused an incorrect
velocity to be used. I'm not sure if that would explain the odd
behavior you were seeing though. It should be fixed on the
work-tmc2130-20180522 branch now.
…-Kevin
|
|
I do not know why but when I set tmc2130 on the Y axis burned out ... But I have a couple more :-) |
|
I got the odd clicking, this happens when the movement is on the boarder of the threshold. For example with a threshold of 100 and a movement of 90mms I hear the clicks. The movement is ok, just the audible clicks are heard. The latest tmcbranch is working. @Alexdad76 They burned out? They have over temperature protection. |
|
Yes, I also read this, but the fact is a fact. Looks like melted micro-contacts around the chip. Presumably, low-temperature solder is used (purchased at the FYSETC Official Store) |
|
the chip protects itself, but this doesn't help outside the chip. |
|
On Fri, May 25, 2018 at 02:30:31AM -0700, Alexdad76 wrote:
Yes, I also read this, but the fact is a fact. Looks like melted micro-contacts around the chip. Presumably, low-temperature solder is used (purchased at the FYSETC Official Store)
Ouch!
It doesn't sound like this is due to a software error though, so I've
merged the changes on the work-tmc2130-20180522 branch to the master
branch.
…-Kevin
|
|
I'm going to close this issue, as it seems basic tmc2130 support is now merged and working. |
|
Good afternoon. I've trying to use sensorless homing with the TMC2130 but it seems like the driver is not detecting it has reached the endstop. [tmc2130 stepper_x] [stepper_y] [tmc2130 stepper_y] |
|
This is what I used: [tmc2130 stepper_x] [stepper_x] ^!ar3 means there is a pull up resistor and the signal is inverted.. I have an arduino 2560 with ramps 1.4. I had to remap the CS pins (in Marlin) because I have a display with SD card reader. The display is not needed for Klipper but I'm continiously switching between Klipper and Marlin 2.0 |
|
hi guys, I'm new to Klipper so I went through Alex's guide, Send: G28 |
|
@Ofr3d Please open a new issue and attach your log file. The file you've linked is the python module that enables support for the TMC2130. It is not a config file, and you shouldn't be copying anything from there. All config files are in the config directory, and the TMC2130 example is in example-extras.cfg. |
and others
Hi,
With the release of the prusa mk3 which now has new controlboard which has the option of an on board raspberry pi.
I think it would be nice if slipper could support the mk3
The text was updated successfully, but these errors were encountered: