setting up tmc2209 drivers in DEV2
So I am getting ready to try DEV2 on my printer and have a question about settings for 2209 drivers. I am only using them for X and Y. In the define line for stepper motors
STEPPER_TMC2209_HW_UART(name, stepPin, dirPin, enablePin, serial, rsense, microsteps, currentMillis, stealth, hybridSpeed, slaveAddr, stallSensitivity, fclk, minEndstop, maxEndstop)
I am not sure what value to use for serial, it isn't covered in the docs. Is that the pin on the control board used to communicate with the driver. Also for the slaveAddr i assume that I would assign say X with 1 and Y with 2? is that correct?
If I am correct with both, does that mean that 2209's can be daisy chained together from the same pin? Thanks!
STEPPER_TMC2209_HW_UART(name, stepPin, dirPin, enablePin, serial, rsense, microsteps, currentMillis, stealth, hybridSpeed, slaveAddr, stallSensitivity, fclk, minEndstop, maxEndstop)
I am not sure what value to use for serial, it isn't covered in the docs. Is that the pin on the control board used to communicate with the driver. Also for the slaveAddr i assume that I would assign say X with 1 and Y with 2? is that correct?
If I am correct with both, does that mean that 2209's can be daisy chained together from the same pin? Thanks!
Comments
slaveAddr is something I never used. I think they are 0 and 1, but you need to define driver for it I think. Never used it as I only had one chip for testing. That I just send the info to the driver library used.
What do you mean by send the info to the driver library? How do I do that?
I don't know very much at all about code so I apologize if these are simple questions, thanks for the help.
>What do you mean by send the info to the driver library? How do I do that?
Our firmware includes a library for controlling the drivers, we did not write it on our own. There is a field for slaveAddr which gets the value. When you see in the TMC2209 datasheet you see that they also have that as address. Not sure, if your stepper board has a pin to select an address. In that case it would always be 0 and you need one serial per driver then. One of the reasons I prefer the SPI version where only a chip select pin is required and any pin would do.
I believe the error is from putting 3 for serial, is there something else I have to define to make it work? I tried from 0-3 for serial as that's how many tx/rx pins I have on the DUE. I also tried typing serial3 as well as d14 and 14 which is the digital pin number.
this my configuration.h and then configuration_io.h
CONFIGURATION_IO.H
https://docfirmwarev2.repetier.com/GCodes/motion_gcodes#m122
It shows settings read from driver. You should first ensure communication is working and best test is to see your settings. You can test changing microsteps and see if they changed for example.
Regarding wiring serial - you know that for serial connection TX goes to RX and vice versa? In my test with one driver I did not use a resistor. Assumed stepper board would include that if required.
For Z motor check if it is blocking at startup and loose after motion. If so your need to invert the enable pin.
I tried m122 and microsteps do not change so I think my wiring is wrong. I will change my wiring to how I described it above if that is what you mean.
I inverted enable for z motor and it started working.
Thank you.
Yes there was something. Been a few years ago I did that. You need to have special wiring with that right? Normal serial is as I wrote and that is what hardware serial uses. 2209 has single wire uart so ther eis no RX/TX at all on that chip - they get converted somehow, but I forget how. But it sounds like you already know how. It's the same library as marlin uses so same wiring I'd say.
This is what I have setup up for endstops. I have tried inverting them with no luck. I've varied sensitivity all over the place. does sensorless homing need to be defined somewhere? Thanks again for all the help!
#define TMC2130_TCOOLTHRS_X 1048575
I saw that in another discussion on here. I would assume if is that I would have to change TMC2130 to TMC2209.
There is no setting for minimum speed. Homing speed must just be fast enough to work. 10-20mm/s should do fine.
There is a parameter stallguard sensitivity that defines the required motor response to trigger.
I checked the sources in stepper.cpp
would be responsible to enable/disable it. As you see in 2209 it is empty.
While for tmc2130 where I tested it with I have this code
I think that is the main reason it does not work. Can you try copying the code from 2130 to 2209 and see if it compiles. Especially the driver->diag1_stall(true); is resposible in 2130 that it gets enabled.
As you see it is only enabled for homing and nothing else.
If you have some programming skills you might try to figure it out. It is just these 2 function that need to be modified to enable and disable the mode. The question is which driver functions to call.
I tried putting this into stepper.cpp to the best of my ability. I keep getting an error on compiling in HAL.h that says '__disable_irq' was not declared in this scope. I'm not sure what this means. Here is how I wrote it out
You used restore_stealth which does not exists. I wonder why they do not need to enable diag1 here to report it, but maybe it does always anyway. Would explain why that function does not exist and why also marlin only calls it for tmc2130 and not 2209.
__disable_irq is normally regular part of it. Please copy full error report for that error if it still exists with my code version. That function is used for due at many places so normally works and is present.
// Called before homing starts. Can be used e.g. to disable silent mode
Since I don't have a system with sensorless homing I never had the problem so not implemented, but easy to add.
In file MotionLevel1.cpp the function
is responsible for homing a single axis.
A delay of 300ms can be added by
Now question is where. There is a mode called safe homing which also requires that sensors untrigger after moving back. Here you would also get same problem. So I think the delay should correctly be added after every back move in that function.
So for first test you should add it here
HAL::delayMilliseconds(300); // <---------------------------------------
Adding simple delay is not best solution, but good for a test now. Please report if it helps and I add a perfect solution to pull. But as long as delay does not get too high it is no real problem. Only temperature management does not work during delay so delays up to 1s should be no problem at all. The improved solution will then get a config option and delay with update.
but may also come from older upload in eeprom, so check that as well or reset to config value
M502
M500
For moving the release move end stop test gets disabled in simpleHome:
So I hope reason is that the back distance was just too low.
into
Then setting rehome distance to 0 disables second check. But I do not think that solves the issue. The back move does not test end stop but when switching to y and the diag pin is still triggered it will stop y move directly. Guess that is what you see?
You might try sending
M111 S70
before homing. This enables end stop debugging so you get a list of state changes when pin changes. Should help to see if and when the sensor gets untriggered. Saw also some threads where it was a problem that the sensor did not untrigger.
In datasheet I read for diag pin
DIAG 11 DO Diagnostic and StallGuard output. Hi level upon stall detection or driver error. Reset error condition by ENN=high.
ENN is motor enabled signal. So as a test with above single test homing run
G28 X0
M84
G28 Y0
M84
And see if that works. With end stop debugging the signal should change the moment power gets disabled. A bit awkward to reset signal by disabling motor as that might move motor as well.
Yes. When testing g28, I have a meter connected to endstop and it seems that the diag pin goes low between the first and second check but stays high after the second check which stops the y move directly.
I will try m111 s70 when I get home to see if that is truly the case. I will also try
G28 X0
M84
G28 Y0
M84
That would contradict that it stays high until enable gets disabled. But if that is the case it would be good and moving back same distance the second time should then also disable it. It might require a number of steps to disable the signal, so something to test as well.
I think I figured it out. The RETEST_REDUCTION_FACTOR needs to be set to 1 for both X and Y to keep the same speed for the second test. it seems that stallguard sensitivity is pretty finicky with the set speed for homing. When the homing speed changed on the second test it would technically need a different stall value. Setting that correctly and setting BACK_ON_HOME to at least 10 have given me perfect homing every time I have tried so far. I am not sure why the reduction factor was affecting when X stops and Y starts but it has made the issue go away, at least in the testing I have done so far.