While stall guard might work on deltas I'm not sure they are precise enough. As you already said for z axis the precision is not top accurate and on deltas all 3 endstops at top define the z height over plate, so they should be accurate. Of course if you can accept small deviations between prints it is ok to spare some euros.
What I think is a better usage here is detecting lost steps during print. At least in V2 we could try adding this. On detection we would then rehome and continue only loosing a few moves. Would still be tricky to implement73, but I'm not trying for V1.
@Repetier I have already worked on a simple code to recover a print in case of power loose and it warked as I wanted , you can check it here https://github.com/taalabash/REPETIER-custom-events (I think this feature is nice if included in v2.0 to make the printer more user friendly)
I was planning to modify backup and restore functions to restore a print if power is accidentally off and also if an endstop is triggered while printing and that will need connecting the diag1 pin of the tmc2130 to the endstop pin (so it will give a signal when a stall id detected) ... it is just an idea right now
but now i don't have any tmc2130 drivers to test so I am just trying to help
@xebbmw Yes, you have to wire a dedicated CS wire to each CS pin of each stepstick. What RADDS pin you tie them to is up to your choice, as long as the pin is not taken by anything else. A good choice is the extension header on the side of the RADDS (long row of pins on the edge).
MAKE SURE ALL THE MICRO-SWITCHES ON THE BACK OF THE RADDS ARE SET TO OFF !!!
If you miss one it's going to pull one of the signals high and block the communication. The SPI pins on the stepsticks are the same as the pins that once tied to these switches for configuration.
Take a look at this diagram which I prepared for an upcoming getting started guide I want to write (maybe over the weekend).
@xebbmw Yes, you have to wire a dedicated CS wire to each CS pin of each stepstick. What RADDS pin you tie them to is up to your choice, as long as the pin is not taken by anything else. A good choice is the extension header on the side of the RADDS (long row of pins on the edge).
Thanks for your photo. I was not sure which pins I should use on DUE. I asked because I am designing a shield for DUE. The shield should accept standard Polulu step drivers but also TMC2130 as per Tom video, in the same socket. There are some jumpers that should be configured for that purpose.
From the discussion here my understanding is that for the moment Repetier accepts either all step drivers are TMC 2130 either none. My printer is a Delta and I would like to have Y, X and Z driven by TMC2130 and a regular step driver for extruder. Probably this will come with new version 2.0.
It can accept as many or little drivers as you need. See my demo video with the RAMPS - I'm only using one TMC2130 on that board, on X.
The way you "enable" a driver in Configuration.h is by adding a line for it's CS pin. For example, the following configures a single TMC2130 on the X axis, it's CS tied to pin 37:
@xebbmw I like the idea of a shield for Due that can support these "smart" drivers natively. One thing that would really be nice if it would also support other variants in Trinamic's range, the UART based TMC22xx series.
I was thinking how to achieve this and one thing to consider is to put a CPLD device on the board. Small ones are only a dollar or two when bought in bulk (or even less). This would allow for routing whatever configuration bus the StepStick uses on those pins to the appropriate MCU pins. Also, it would allow for controlling those pins from the MCU like normal configuration toggles for non-smart drivers like the usual Allegro or TI.
Do you mean two z-motors each with it's own driver or two motors on the same driver?
The first case isn't covered yet because it would clutter the code - there's no standard way to enumerate axes in the current codebase which makes it clunky to support arbitrary combinations of axes. This will really improve in V2 which Repetier is working on at the moment. Until then, unusual configurations are not a priority, to keep the V1 code fairly sane.
On the other hand, I always wondered why I see so many double motor Z-axes, even more so with their independent drivers. It's just simpler in my mind to drive them from the same motor with a belt. One use-case I like is the thing I saw on prusa MK3 where they drive the two z-lead screws independently to level the X-gantry against the frame. Are you doing such a thing?
As long as you do no sensor less homing on z it should work if you use E1 or E2 as second Z axis. If I remember the code it assigns configs to sockets not functions where motors are used, also in plain config these will match.
@xebbmw I like the idea of a shield for Due that can support these "smart" drivers natively. One thing that would really be nice if it would also support other variants in Trinamic's range, the UART based TMC22xx series.
At digikey TMC2130 is more expensive than TMC2208, so using TMC2208 would be cheaper. Do you mean to use CPLD to connect UART for TMC2208? Did you find some links with info how people are using these drivers?
I am trying out your tmc2130 implementation on my Mega-driven delta... when I run the steppers in StealthChop I can't get it to work with normal speeds (I am using the current settings I was using with marlin (which worked there)).
It seems as if the motors are stalling, even if I remove the delta-Arm so, there is no real load to be lifted. They sound as if they are constantly missing steps.
when I trigger the endstops by hand (I'm not using Sensorless homing) and it does the second, slower-speed homing, they seem to work fine.
Do you have an idea what could cause such an behaviour, or with which settings I could play around with to resolve this issue?
Thanks for your great work!
@Repetier Is this the right place to ask such questions, or should I be writing private E-mails?
I think here is a better place since here you have some users using the driver, while I haven't one and no experience on this special problem.
Only thing I can think of is current setting too low. And from reading the drivers doc I know you can adjust settings to your motors a bit, so they work better. Config has also plenty of params to tweak. After all the combination motor - driver and settings must match.
Here is a video of the sensorless homing process in action on my CoreXY platform.
Hi. I tried development brunch (after working marlin-1.7) on my corexy printer and I can't move x or y direction. If I try homing x or y axes one of the motors rotates much faster than the other. Simple moving are not moving too. Can you upload your config file?
@nightdemonx I’m also having some issues building the latest developement branch. I’ll figure out what’s wrong and send you a working config.
Some baseline checks: for CoreXY steps-per-mm and feedrates should be the same on X an Y (if you have the same type of motor). Do you have different ones?
@nightdemonx I’m also having some issues building the latest developement branch. I’ll figure out what’s wrong and send you a working config.
Some baseline checks: for CoreXY steps-per-mm and feedrates should be the same on X an Y (if you have the same type of motor). Do you have different ones?
Yes, all value the same for X and Y motors (200 step per mm, 200 mm/sec max feedrate, 950 mA current, 1/16 microstep and etc.). I use now MKS Gen-L (same RAMPS 1.4+Arduino Mega, only build in one pcb) with TMC2130 on all motors (X,Y,Z,E0). https://1drv.ms/i/s!Ahlsp6SBGCWtp4ou60QkmCkwNsGQ6w
@nightdemonx Thanks for posting the picture of your setup. Would it be too much to ask for another pic with the fan out of the way. I can't really see the wiring well enough in your current picture.
@nightdemonx Thanks for posting the picture of your setup. Would it be too much to ask for another pic with the fan out of the way. I can't really see the wiring well enough in your current picture.
If you think that I made a mistake in connecting, then it is not. I figured out the steps and micro steps and everything worked. But the sound from the engines is much worse than when working on the Marlin firmware.
Hi all, I've managed to get the printer to move with the TMC2130's on RADDS. However I can just get them to move the first bit, as if my speeds are too high. I'm only using X and Y for the trinamics because my Z axis is a dual axis leadscrew where noise isn't an issue. How high would you set the current in the repetier 1.0.0 dev version? I'm already up to 3000mA but I'm afraid to go any higher... Do I need to tweak the potmeter on the board as well? I think I wired the bottom of the radds correctly because the drivers do work. Video I hope you can help. otherwise: great work Alex and Repetier
Hi all, I've managed to get the printer to move with the TMC2130's on RADDS. However I can just get them to move the first bit, as if my speeds are too high. I'm only using X and Y for the trinamics because my Z axis is a dual axis leadscrew where noise isn't an issue. How high would you set the current in the repetier 1.0.0 dev version? I'm already up to 3000mA but I'm afraid to go any higher... Do I need to tweak the potmeter on the board as well? I think I wired the bottom of the radds correctly because the drivers do work. Video I hope you can help. otherwise: great work Alex and Repetier
I have the exact same issue, that you are describing...
I am trying out your tmc2130 implementation on my Mega-driven delta... when I run the steppers in StealthChop I can't get it to work with normal speeds (I am using the current settings I was using with marlin (which worked there)).
It seems as if the motors are stalling, even if I remove the delta-Arm so, there is no real load to be lifted. They sound as if they are constantly missing steps.
when I trigger the endstops by hand (I'm not using Sensorless homing) and it does the second, slower-speed homing, they seem to work fine.
Do you have an idea what could cause such an behaviour, or with which settings I could play around with to resolve this issue?
Thanks for your great work!
@Repetier Is this the right place to ask such questions, or should I be writing private E-mails?
I have played around in the implementation of the drivers and set all the parameters (like PWM_Freq, HSTART, HEND...)(following the quick start guide from the Tmc 2130 Datasheet (but withought an oscilloscope) ), adjusting them as they are in the working marlin FW, but no success... So far.
Im still learning to code (Student), so I don't have to much experience in this field, to further search for the cause of this problem.
Thanks for the great effort of everyone involved in this.
@niocio01 and @PioniSensei
3000mA seems way to high and should not be necessary for a normal 3D printer.
These drivers will move the motors reliably with just 300 mA on a well constructed printer. I have repeatedly printed with 500mA.
However, StealthChop is inherently only meant for slow speeds. I am talking 30 mm/min. Don’t try to use it at higher speeds especially on an untuned printer. Also drop your acceleration a lot (to around 4-500) and try to experiment from there.
My first advice is to start tuning speeds in with stealthchop off. Once you know your speed range try enabling StealhChop and determine reliable speeds for it. They should be lower than the speeds for SpreadCycle.
I am still experimenting myself to determine a good setup procedure and I will document it for everyone to use.
These couple of days I am traveling so am unable to try things out, but will be back home next week.
I'm back with some test results. I've adjusted the potentiometers to be at their max value (for me it was apparently max 0.23V?) with Vref on the TMC and GND on one of my endstops... I've just put it on that highest value and tested on. my X-axis moves quite ok now. just kinda slow. My Y axis has a limit of 30mm/sec... and as I'm typing that just doesn't seem like the speed it goes at (seems way slower) accelerations are currently at X: 200mm/s2, Y: 100mm/s2 Current is also 'correct' now. 500mA for X and 750mA for Y
But what I'm finding now is that changing the steps/mm in repetier 1.0.1dev doesn't change the steps/mm on the TMC. I had that value for Y at 1160 steps/mm with 1/32 microstepping for DRV2285. which just is ridiculous because X has 80 steps/mm. So I wanted to put it at 145 steps/mm at 1/8 microstepping. But if I change that in eeprom the movement also stops at a quarter of what it should be.
A lot of text. and maybe not too helpful, just wanted to keep you guys updated. I'll keep updating my files here for reference: Google drive link
Well... I think my TMC's are dead. I can;t get them to work reliably. a lot of jittering around and testing on an arduino nano only produced coil whine in the motor. @niocio01 I'm very eager to know how far you've come with your setup. I hope the trinamics have some sort of overcurrent protection...
@PioniSensei I have blown some drivers myself as well... I made the mistake to move the axis, which turned the motors, which induced a current, and fried my steppers ;( But I found a solution to this: http://www.watterott.com/de/SilentStepStick-Protector I have not had any problems, (regarding destroying hardware) since then.
when I blew mine, I couldn't get them to do anyting at all. Maybe, try to flash marlin, to check wether they are truly broken, or if it is just a settings issue. btw. I had to fully power off the Printer, and wait a bit until i powered it on again, in order to set the configured settings...
I have not worked on my printer, since my last post.
Comments
What I think is a better usage here is detecting lost steps during print. At least in V2 we could try adding this. On detection we would then rehome and continue only loosing a few moves. Would still be tricky to implement73, but I'm not trying for V1.
(I think this feature is nice if included in v2.0 to make the printer more user friendly)
I was planning to modify backup and restore functions to restore a print if power is accidentally off and also if an endstop is triggered while printing and that will need connecting the diag1 pin of the tmc2130 to the endstop pin (so it will give a signal when a stall id detected) ... it is just an idea right now
but now i don't have any tmc2130 drivers to test so I am just trying to help
Have bookmarked it as a possible module for V2.
MAKE SURE ALL THE MICRO-SWITCHES ON THE BACK OF THE RADDS ARE SET TO OFF !!!
If you miss one it's going to pull one of the signals high and block the communication. The SPI pins on the stepsticks are the same as the pins that once tied to these switches for configuration.
Take a look at this diagram which I prepared for an upcoming getting started guide I want to write (maybe over the weekend).
Here's the demo video:
I'll update the PR shortly with the AVR version. After that I need to cleanup the configuration.h parameters a bit an we should be good for now.
I'll try to put together a "getting started" guide with picture examples for doing the wiring and configuration parameters.
Stay tuned!
From the discussion here my understanding is that for the moment Repetier accepts either all step drivers are TMC 2130 either none. My printer is a Delta and I would like to have Y, X and Z driven by TMC2130 and a regular step driver for extruder. Probably this will come with new version 2.0.
It can accept as many or little drivers as you need.
See my demo video with the RAMPS - I'm only using one TMC2130 on that board, on X.
The way you "enable" a driver in Configuration.h is by adding a line for it's CS pin.
For example, the following configures a single TMC2130 on the X axis, it's CS tied to pin 37:
#define TMC2130_X_CS_PIN 37
#define TMC2130_Y_CS_PIN -1
#define TMC2130_Z_CS_PIN -1
#define TMC2130_EXT0_CS_PIN -1
#define TMC2130_EXT1_CS_PIN -1
#define TMC2130_EXT2_CS_PIN -1
A value of -1 means that axis doesn't have a TMC2130 on it.
What if you have e.g. two z-axis?
One thing that would really be nice if it would also support other variants in Trinamic's range, the UART based TMC22xx series.
I was thinking how to achieve this and one thing to consider is to put a CPLD device on the board. Small ones are only a dollar or two when bought in bulk (or even less). This would allow for routing whatever configuration bus the StepStick uses on those pins to the appropriate MCU pins. Also, it would allow for controlling those pins from the MCU like normal configuration toggles for non-smart drivers like the usual Allegro or TI.
The first case isn't covered yet because it would clutter the code - there's no standard way to enumerate axes in the current codebase which makes it clunky to support arbitrary combinations of axes. This will really improve in V2 which Repetier is working on at the moment. Until then, unusual configurations are not a priority, to keep the V1 code fairly sane.
On the other hand, I always wondered why I see so many double motor Z-axes, even more so with their independent drivers. It's just simpler in my mind to drive them from the same motor with a belt.
One use-case I like is the thing I saw on prusa MK3 where they drive the two z-lead screws independently to level the X-gantry against the frame. Are you doing such a thing?
But Repetier-firmware has options for double or tripple axis afaik.
At digikey TMC2130 is more expensive than TMC2208, so using TMC2208 would be cheaper. Do you mean to use CPLD to connect UART for TMC2208? Did you find some links with info how people are using these drivers?
I am trying out your tmc2130 implementation on my Mega-driven delta...
when I run the steppers in StealthChop I can't get it to work with normal speeds (I am using the current settings I was using with marlin (which worked there)).
It seems as if the motors are stalling, even if I remove the delta-Arm so, there is no real load to be lifted.
They sound as if they are constantly missing steps.
when I trigger the endstops by hand (I'm not using Sensorless homing) and it does the second, slower-speed homing, they seem to work fine.
Do you have an idea what could cause such an behaviour, or with which settings I could play around with to resolve this issue?
Thanks for your great work!
@Repetier Is this the right place to ask such questions, or should I be writing private E-mails?
Only thing I can think of is current setting too low. And from reading the drivers doc I know you can adjust settings to your motors a bit, so they work better. Config has also plenty of params to tweak. After all the combination motor - driver and settings must match.
Some baseline checks: for CoreXY steps-per-mm and feedrates should be the same on X an Y (if you have the same type of motor). Do you have different ones?
If you think that I made a mistake in connecting, then it is not. I figured out the steps and micro steps and everything worked. But the sound from the engines is much worse than when working on the Marlin firmware.
I've managed to get the printer to move with the TMC2130's on RADDS.
However I can just get them to move the first bit, as if my speeds are too high. I'm only using X and Y for the trinamics because my Z axis is a dual axis leadscrew where noise isn't an issue.
How high would you set the current in the repetier 1.0.0 dev version? I'm already up to 3000mA but I'm afraid to go any higher...
Do I need to tweak the potmeter on the board as well?
I think I wired the bottom of the radds correctly because the drivers do work.
Video
I hope you can help. otherwise: great work Alex and Repetier
I have played around in the implementation of the drivers and set all the parameters (like PWM_Freq, HSTART, HEND...)(following the quick start guide from the Tmc 2130 Datasheet (but withought an oscilloscope) ), adjusting them as they are in the working marlin FW, but no success... So far.
Im still learning to code (Student), so I don't have to much experience in this field, to further search for the cause of this problem.
Thanks for the great effort of everyone involved in this.
3000mA seems way to high and should not be necessary for a normal 3D printer.
These drivers will move the motors reliably with just 300 mA on a well constructed printer. I have repeatedly printed with 500mA.
However, StealthChop is inherently only meant for slow speeds. I am talking 30 mm/min. Don’t try to use it at higher speeds especially on an untuned printer. Also drop your acceleration a lot (to around 4-500) and try to experiment from there.
My first advice is to start tuning speeds in with stealthchop off. Once you know your speed range try enabling StealhChop and determine reliable speeds for it. They should be lower than the speeds for SpreadCycle.
I am still experimenting myself to determine a good setup procedure and I will document it for everyone to use.
These couple of days I am traveling so am unable to try things out, but will be back home next week.
Cheers,
Alex
I'm back with some test results.
I've adjusted the potentiometers to be at their max value (for me it was apparently max 0.23V?) with Vref on the TMC and GND on one of my endstops...
I've just put it on that highest value and tested on. my X-axis moves quite ok now. just kinda slow.
My Y axis has a limit of 30mm/sec... and as I'm typing that just doesn't seem like the speed it goes at (seems way slower)
accelerations are currently at X: 200mm/s2, Y: 100mm/s2
Current is also 'correct' now. 500mA for X and 750mA for Y
But what I'm finding now is that changing the steps/mm in repetier 1.0.1dev doesn't change the steps/mm on the TMC. I had that value for Y at 1160 steps/mm with 1/32 microstepping for DRV2285. which just is ridiculous because X has 80 steps/mm. So I wanted to put it at 145 steps/mm at 1/8 microstepping. But if I change that in eeprom the movement also stops at a quarter of what it should be.
A lot of text. and maybe not too helpful, just wanted to keep you guys updated.
I'll keep updating my files here for reference: Google drive link
@niocio01 I'm very eager to know how far you've come with your setup. I hope the trinamics have some sort of overcurrent protection...
I made the mistake to move the axis, which turned the motors, which induced a current, and fried my steppers ;(
But I found a solution to this: http://www.watterott.com/de/SilentStepStick-Protector
I have not had any problems, (regarding destroying hardware) since then.
when I blew mine, I couldn't get them to do anyting at all.
Maybe, try to flash marlin, to check wether they are truly broken, or if it is just a settings issue.
btw. I had to fully power off the Printer, and wait a bit until i powered it on again, in order to set the configured settings...
I have not worked on my printer, since my last post.