teemuatlut
commented
6 years ago If you can, please provide a picture of your soldered driver and the bridged pads.
Closed FelixHauser closed 5 years ago
teemuatlut
commented
6 years ago If you can, please provide a picture of your soldered driver and the bridged pads.
viper93458
commented
6 years ago If these are generic clone tmc2208s, I had the same issue and maybe able to help. First, do not power up the board with usb (5v) unless you do it at the same time as applying 12v power. If the AVR board Powers up before the 12v power feed, the drivers won't bring in the uart values.
The way I resolved it was to modify the USB cable between my host and the AVR by clipping the red (5v) wire so that it is a data only cable now. Then the AVR stays unpowered until you apply the 12v power which runs everything.
Also, M122 will only show you the last tmc2208 values and not all of them. This is a known issue and the developers will resolve it in time. Basically the bug only affects READING from the drivers, not the writing fuction.
William
viper93458
commented
6 years ago Also remove all jumpers below those stepper drivers as the 3rd one prevents it from working as well. They aren't needed when programming via uart and that 3rd jumper causes the issue.
William
FelixHauser
commented
6 years ago @teemuatlut I'm sorry but my phone's camera isn't the greatest. If the doubt is regarding the solder pads, I tested them with my multimeter. Everything is OK as far as I know.
@viper93458 thanks for your input. I was aware of both all issues you commented and I tested again the setup upon learning about it.
viper93458
commented
6 years ago My apologies if you already tried those items. One last comment is that I run 2.0 bugfix and not 1.x.
William
FelixHauser
commented
6 years ago Thanks, @teemuatlut I just tried that, being also very careful to first power up the PSU and then the USB as @viper93458 suggested. No change, unfortunately.
AletheianAlex
commented
6 years ago Double check your pin assignments, you may have CS assigned to the same pin as serial. You can add a little switch like:
or just assign the cs to -1 if you are not using it
melvinisken
commented
6 years ago I recommend to test the drivers using the library only (not using Marlin). Upload an example sketch from https://github.com/teemuatlut/TMC2208Stepper and test if the driver is working in general. That eleminates all potential issues caused by your Marlin setup. Be sure to remove the belt from the Motor since it does not respect endstops then.
FelixHauser
commented
6 years ago @AletheianAlex just done it, the same result. @melvinisken I´ll do that right now. Seems like a good idea. Thanks.
FelixHauser
commented
6 years ago Well, as suggested by @melvinisken I just run the 3 examples on the tmc2208 library. Of the 3 examples, I could only compile and run the "SoftwareSerial". The other 2 examples wouldn´t even compile (see attached screenshot). Running the SoftwareSerial example, starts spinning the motor and nothing else. I don´t know if it is the expected outcome.
melvinisken
commented
6 years ago You can add a driver.shaft(false); before driver.toff(0x2); this should reverse the turning direction (or a true statement reverses, need to test).
AletheianAlex
commented
6 years ago Don't worry about the other two sketches, they won't compile. The software serial sketch should work, and if you can control a motor over uart from that sketch, then your driver and cable are fine.
FelixHauser
commented
6 years ago Well, that's good news, I guess... I've just seen this issue here: https://github.com/teemuatlut/Marlin/issues/19 it seems exactly what I'm experiencing. I'll try to use v0.1.1 of the library and see what happens...
teemuatlut
commented
6 years ago Add an ampersand before the instance argument:
TMC2208Stepper driver = TMC2208Stepper(&Serial1);
I'll fix this today.
I tried wiring a brand new SilentStepStick 2208 and it worked fine for me. Valid registers and correct movement and all. This is with version 0.2.0 of the library.
EDIT: v0.2.1 released to fix examples.
AletheianAlex
commented
6 years ago @marcalcc You are right. I pulled down a fresh copy of 1.1.8, installed the files you zipped, and my TMC2208 are not working. I then re-installed whichever older version I was using, and they work fine again. (using 0.2.0 lib, which is working fine). I am going to pull another fresh copy of 1.1.8 and configure from scratch to see if that is working... I'll report back when I get a chance to do that.
FelixHauser
commented
6 years ago Many thanks @AletheianAlex for the time you're investing in this. I greatly appreciate it.
Actually I also pulled down a fresh copy of Marlin 1.1.8 and without copying anything but setting the TMC2208 from scratch, it did also not work.
AletheianAlex
commented
6 years ago No problem.
I could not get 1.1.8 to work, BUT I set up 1.1.x-bugfix with minimal options from scratch and my TMC2208 are working fine via UART.
Try pulling down a fresh bug fix and only setting up the trinamic sections and see if you have communication. Unfortunately, that means systematic troubleshooting, so If the stock setup works, set up the extra features you have one at a time and see which one is breaking things. I skimmed through your setup and saw like, bed leveling, sd card, LCD, so leave all that and whatever else is not stock setup disabled at first.
FelixHauser
commented
6 years ago Well I´ve been able to replicate @AletheianAlex ´s observations:
and it worked. The M122 command recognizes the microsteps and the axis moves the distance I asked to. The register shows me this:
Driver registers: X = 0xC0:0C:00:00
So, what should we call that? A bug on the 1.1.8 version?
melvinisken
commented
6 years ago So, what should we call that? A bug on the 1.1.8 version?
Yes and no. It's already known that it does not work on 1.1.8. In your original post you already mentioned my issue where it was stated, that this bug will only be fixed for 1.9+ and 2.0:
As said above, there will be a fix after the release of 1.1.9 and I'll be targeting the 2.0.x branch. This only affects SW read capabilities from the drivers.
FelixHauser
commented
6 years ago Oh, well... a very long issue and I might have missed it. Anyway I understood that you fixed it by reassigning the TX/RX pins as in the scheme d of your post. Since it didn't work for me and in all the info I saw, people were using 1.1.8... I thought it was something new.
boelle
commented
5 years ago @FelixHauser
This Issue Queue is for Marlin bug reports and development-related issues, and we prefer not to handle user-support questions here. (As noted on this page.) For best results getting help with configuration and troubleshooting, please use the following resources:
After seeking help from the community, if the consensus points to to a bug in Marlin, then you should post a bug report.
Before posting a bug report please test with bugfix-2.0.x to check if problem is gone
FelixHauser
commented
5 years ago @boelle thanks for your info, nearly one year after the issue was open. It reminded me of closing it as I was solved with the 1.1.9 release of Marlin,
github-actions[bot]
commented
4 years ago This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Hi all,
I installed two TMC2208 drivers (Z and Extruder only) on my RAMPS 1.4 board. I followed some very good step by step tutorial/s:
No matter what I do, they don't work as expected.
What I did is as follows:
No matter what I did, the motor moves twice as much as requested. Although I set up 1/16 microstepping, the same I had with my Pololus, I performed the reverse calculation to find out that the actual microstepping on the driver is 1/8. Which would fit the RAMPS Jumper configuration, I guess... The issue seems to be that the Driver is not recognized at all by the Marlin/Board. Thinking that it was a problem with the TX/RX communication, I dig into the available info out there and I found that:
https://github.com/MarlinFirmware/Marlin/issues/9396
I proceeded to change the assigned pins for serial RX/TX, but everything is exactly de same. I tried different Arduino (original), another RAMPS board and even the 1.1.x and 2.0 bugfix branches from Marlin. It seems that the driver is on "legacy" mode and software manipulation is not possible. Although I went through the steps to enable it. When sending a M122 via the console, the msteps value is always 256, which I learned it means lack of communication. It doesn't recognize the value (16) I have on Configuration_adv.h. It does recognize the value of current for the driver, though.
I took another driver and I just soldered the pins and plugged it in with the jumpers matching a 1/16 microstepping configuration. Then I adjusted the current via the driver's potentiometer. When doing so, the driver works ok and the axis moves the requested distance.
I contacted Watterott regarding the issue as I thought it could be a defective lot #. They kindly ask me to test them in Legacy mode and if the driver worked as expected, it meant that it was ok and the problem must be software related. I double checked more times than I cared to admit. I made sure that my Arduino IDE has the libraries, that everything that has to be commented out actually is, I made sure that the UART cable is in working conditions and that the pins are correctly assigned.
Curiously, I've been able to install TMC2130 on the X and Y axis without any problem. files.zip
Attached you can find some files.