Im very interested in your progres. I have a corexy based printer on radds+due+extension board..would like to replace the raps128 drivers with tmc2130 module... would it be possible to use the stallguard function to level the bed with the 3 z axis motors?
I'm betting on StallGuard working for end-stops because I have no end-stops in my printer other than a BLTouch z-probe. In fact, with RADDS, two of the SPI CS signals for the drivers are routed to the X and Y endstop headers and hog those pins so you can't use endstops AND hardware SPI at the same time.
So it has to be StallGuard homing. But most likely this is only useful for X and Y homing. You'd likely still be homing Z via a Z-probe because it appears (from other people's experiments) that StallGuard is not precise enough for bed-leveling applications (at least not without a lot of printer specific fine-tuning). I'll defer experiments with bed leveling for now.
So yeah, I'm focusing on getting at least X and Y homing via StallGuard. The challenge is to see if this can be done without routing the diag signals (the extra holes on the StepSticks) to interrupts. Avoiding that would simplify board modifications a bit.
It would be really cool if i could use it as z max for my three z axis. As zmin i will use a piezo probe. As well for probing. No clue how i will do it at this point but ok .
I'm developing against a RADDS + Due. I've just ordered a RAMPS clone on AliExpress and I'll try to test against that too once it arrives.
Are you guys using the original Watterott stepsticks or chinese replicas?
I have got 5 FYSETC TMC2130s and 5 genuine Watteroot TMC2208s.
I recently built my first printer (an Ender-4) and I want to have dual extrusion, so I ordered an MKS gen L and the chinese 2130s.
As Repetier is said to have some advantages to Marlin I would rather like to use Repetier, as soon as the board arrives, but I see using the stall detection, missed step detection and possibly the SPI configuration of the 2130s as more important. So it would be great if we could use those features on repetier!
I wonder a bit, why most here don't seem interested in the SPI feature. I think it could be used for automatically adapting the steppers current, if there was a missed step detected for example. Also auto calibration of the current could be implented this way.
Just as a side node since it will not help for now - in firmware 2.0 I plan to add the concept of stepper driver classes, so it would get quite easy then to add things like spi configuration of steppers. The current design makes it not that easy to add special features in a general way.
Just as a side node since it will not help for now - in firmware 2.0 I plan to add the concept of stepper driver classes, so it would get quite easy then to add things like spi configuration of steppers. The current design makes it not that easy to add special features in a general way.
This really good news!
I was struggling with finding a good spot for the initialization code and accommodating all the combinations of some drivers present and others not. I was tempted to do something like the driver classes myself, but then thought I should keep my changes contained to make them easy to review.
Once the driver classes arrive, I’ll be happy to port the TMC code to them. Is there branch place where I can have a peek of what they will look like?
That is definitely the direction I want us to go in. I also want all the Trinamic goodies inside Repetier.
On my working printer I have Marlin right now and even though the core firmware works ok, I like the integration of the Repetier stack much better. Everything just fits: the firmware, the server and the desktop host.
Back to TMC stuff: I’m using Watterot sticks for my own printer and for development. However I also ordered two FYSETC sticks for testing. Waiting for them to arrive. Be aware that some reports say that for Chinese drivers additional resistors need to be soldered to get SPI to work. I’ll see I feel that’s the case when my drivers arrive.
I will start 2.0 when I finish 1.0 to stable. I do not really plan adding new things to 1.0 dev so maybe in my christmas holiday I get some time to finalise 1.0.
2.0 will get some heavy refactoring to make many things hopefully easier which can take a while, so at the beginning there will be frequently changes making configs incompatible. But I think motor control will be one of the first things to adjust.
@Repetier, I love your 1.0 dev firmware, but like a lot of us, we want to use the TMC2130 and TMC2208. TMC2208 for me personally, but I haven't found any support for them at all. Yes you can run them in default mode and they work, but I would like to be able to configure them with the firmware. Do you have any time estimate to when 2.0 will be ready for testing?
When 1.0 gets marken stable I will start 2.0 tree. Maybe I do it the next days. Want to continue with 2.0 as well since I have nice plans for it and want to test if they work. Be prepared that at the beginning there will be no config tool since it will break configuration.
This work is still very much in progress and features supported are not on par with Marlin yet. However, these first changes work to get my printer moving and control current and stealthchop flags. I can do very rough sensorless homing based on Stallguard right now, but more tuning is required to achieve smooth working state.
Testing is highly needed as well as feedback on user experience. If you know your way around the Arduino IDE and have built Repetier from source before, you can pull my changes from GitHub and try to build it and try it out. Go to https://github.com/alexsomesan/Repetier-Firmware.git and click on "Clone or Download" and then "Download" to get a copy.
BEWARE: This is only implemented in the Due version for now, because this is what I can test with right now. I am waiting on additional StepSticks to arrive and I have a RAMPS + Mega available to test for AVR as soon as the drivers arrive.
All feedback is highly appreciated (especially @Repetier). Testers will get free beer wherever we meet.
@niocio01 I’m planning to test on AVR + RAMPS soon. I am missing the drivers - waiting for them to arrive from AliExpress. The Watterott ones I have are “wired” for the RADDS.
As soon as I get them I’ll test on AVR.
I still don’t have a delta though. I have to Check what it takes to add support “blindly” before someone else can test. Or maybe I manage to borrow a delta.
Anyone in Berlin willing to lend me one?
@alexsomesan Oh, ok I dont think you necessarily need to borrow a delta, I would assume if the driver works for a "normal" cartesian printer on Ramps, it should also work for a delta.
@boelle What stepper mode are you running them on? my printer is all 12V and if I enabled SpreadCycle (to get more torque) I got horrible coil winding as well, which seems to be normal behaviour, according to other forums.
@boelle oh, good to know... I was able to get away with only using StealthChop for my Delta. (with 800ma RMS) So I think it should be possible to run your mendel on StealthChop as well.
if i remember correct we can also ask the chip what temp it is right? if its correct i had an idea of automatic select the highest possible current without getting to hot... ie do a series of moves with different speeds and acc
@boelle that's a good idea. And in addition to that, using StallGuard it could be checked, if the stepper-motor is missing steps, which is a big risk with running high acceleration.
@boelle I run both 12V and 24v. 24v does quiet down the motors a bit. You can run most 12V parts (heaters, fans) off 24v if you run them with PWM instead of always-on power. I routinely run hot-beds designed for 12V at 24v by using PID temp control which pulses the supply instead of keeping it on for long. Works like a charm. Heats up in under 20 seconds too.
As for your crazy idea, it's not so crazy actually. Marlin already has such a feature to increase current until the temperature warning shows and then decrease it. But it might actually not be necessary to do so software with 2130s because they have what Trinamic calls coolStep, which when configured correctly will adapt (reduce or increase) current based on the perceived load from the StallGuard system. This is done internally in the driver chip without intervention from the firmware other then setting the right parameters at power-up. I'm planning to explore this area after the basic functionality is done.
@niocio01We might be able to reduce the standstill whining by playing with the PWM frequency of the driver. This again advanced functionality I haven't tried out yet, but I know the chip can control the PWM frequency.
Comments
looks interesting from tom
I already have a prototype running which can configure the basics such as current, microstepping, step interpolation.
I can feed a gcode file and the printer moves correctly (and quietly) with TMC2130s.
The board I‘m using is a RADDS + Arduino Due. I modified the RADDS to route the SPI signals on the back of the board with jumper wires.
As I said, I got them working but I need to clean up the code a bit before I can make a PR.
Should be another week or so.
I‘m working off the current Repetier development branch.
It‘s going a bit slows because I‘m also building the printer at the same time. It‘s based on the HyperCube Evolution.
I’m interested to know what boards are you guys planning on running TMC2130s on?
Archim2 looks very promising TBH.
Cheers,
Alex
I've just ordered a RAMPS clone on AliExpress and I'll try to test against that too once it arrives.
Are you guys using the original Watterott stepsticks or chinese replicas?
I'm betting on StallGuard working for end-stops because I have no end-stops in my printer other than a BLTouch z-probe. In fact, with RADDS, two of the SPI CS signals for the drivers are routed to the X and Y endstop headers and hog those pins so you can't use endstops AND hardware SPI at the same time.
So it has to be StallGuard homing. But most likely this is only useful for X and Y homing. You'd likely still be homing Z via a Z-probe because it appears (from other people's experiments) that StallGuard is not precise enough for bed-leveling applications (at least not without a lot of printer specific fine-tuning). I'll defer experiments with bed leveling for now.
So yeah, I'm focusing on getting at least X and Y homing via StallGuard. The challenge is to see if this can be done without routing the diag signals (the extra holes on the StepSticks) to interrupts.
Avoiding that would simplify board modifications a bit.
Cheers,
Alex
I have got 5 FYSETC TMC2130s and 5 genuine Watteroot TMC2208s.
I recently built my first printer (an Ender-4) and I want to have dual extrusion, so I ordered an MKS gen L and the chinese 2130s.
As Repetier is said to have some advantages to Marlin I would rather like to use Repetier, as soon as the board arrives, but I see using the stall detection, missed step detection and possibly the SPI configuration of the 2130s as more important. So it would be great if we could use those features on repetier!
I wonder a bit, why most here don't seem interested in the SPI feature. I think it could be used for automatically adapting the steppers current, if there was a missed step detected for example.
Also auto calibration of the current could be implented this way.
I was struggling with finding a good spot for the initialization code and accommodating all the combinations of some drivers present and others not.
I was tempted to do something like the driver classes myself, but then thought I should keep my changes contained to make them easy to review.
Once the driver classes arrive, I’ll be happy to port the TMC code to them.
Is there branch place where I can have a peek of what they will look like?
thanks!
That is definitely the direction I want us to go in. I also want all the Trinamic goodies inside Repetier.
On my working printer I have Marlin right now and even though the core firmware works ok, I like the integration of the Repetier stack much better. Everything just fits: the firmware, the server and the desktop host.
Back to TMC stuff: I’m using Watterot sticks for my own printer and for development. However I also ordered two FYSETC sticks for testing. Waiting for them to arrive.
Be aware that some reports say that for Chinese drivers additional resistors need to be soldered to get SPI to work. I’ll see I feel that’s the case when my drivers arrive.
Cheers,
Alex
2.0 will get some heavy refactoring to make many things hopefully easier which can take a while, so at the beginning there will be frequently changes making configs incompatible. But I think motor control will be one of the first things to adjust.
I've got something working to share
I've opened a GitHub pull request with changes to enable basic TMC2130 functionality.
You can see it here: https://github.com/repetier/Repetier-Firmware/pull/724
This work is still very much in progress and features supported are not on par with Marlin yet.
However, these first changes work to get my printer moving and control current and stealthchop flags.
I can do very rough sensorless homing based on Stallguard right now, but more tuning is required to achieve smooth working state.
Testing is highly needed as well as feedback on user experience.
If you know your way around the Arduino IDE and have built Repetier from source before, you can pull my changes from GitHub and try to build it and try it out. Go to https://github.com/alexsomesan/Repetier-Firmware.git and click on "Clone or Download" and then "Download" to get a copy.
BEWARE: This is only implemented in the Due version for now, because this is what I can test with right now. I am waiting on additional StepSticks to arrive and I have a RAMPS + Mega available to test for AVR as soon as the drivers arrive.
All feedback is highly appreciated (especially @Repetier). Testers will get free beer wherever we meet.
Thanks,
Alex
I just ordered most of the frame parts for the Hypercube Evo, and since i'm a long time repetier user i will use the due+radds combo too
I'm runing it on Ramps. (which isn't the best option for deltas, I know...)
Is your Rep. only working on Due, or were you just not able to test it for AVR, due to the lack of hardware?
As soon as I get them I’ll test on AVR.
I still don’t have a delta though. I have to Check what it takes to add support “blindly” before someone else can test. Or maybe I manage to borrow a delta.
Anyone in Berlin willing to lend me one?
i have a mendel90 and i got tmc2100 on that and had to remove the 12v pin on the modules and supply 24V to the stepper modules to get them silent'ish
rest of printer is running 12V
I dont think you necessarily need to borrow a delta, I would assume if the driver works for a "normal" cartesian printer on Ramps, it should also work for a delta.
my printer is all 12V and if I enabled SpreadCycle (to get more torque) I got horrible coil winding as well, which seems to be normal behaviour, according to other forums.
read here... and i also contacted watterott and they said to get them silent 19V was the minimum
https://github.com/watterott/SilentStepStick/blob/master/docs/FAQ.md#the-motor-makes-noise-in-spreadcycle-mode-when-it-is-not-moving
I was able to get away with only using StealthChop for my Delta. (with 800ma RMS)
So I think it should be possible to run your mendel on StealthChop as well.
crazy thought
if i remember correct we can also ask the chip what temp it is right? if its correct i had an idea of automatic select the highest possible current without getting to hot... ie do a series of moves with different speeds and acc
think of it like a pid tune for stepper drivers
that's a good idea.
And in addition to that, using StallGuard it could be checked, if the stepper-motor is missing steps, which is a big risk with running high acceleration.
I routinely run hot-beds designed for 12V at 24v by using PID temp control which pulses the supply instead of keeping it on for long. Works like a charm. Heats up in under 20 seconds too.
As for your crazy idea, it's not so crazy actually. Marlin already has such a feature to increase current until the temperature warning shows and then decrease it. But it might actually not be necessary to do so software with 2130s because they have what Trinamic calls coolStep, which when configured correctly will adapt (reduce or increase) current based on the perceived load from the StallGuard system. This is done internally in the driver chip without intervention from the firmware other then setting the right parameters at power-up. I'm planning to explore this area after the basic functionality is done.
@niocio01We might be able to reduce the standstill whining by playing with the PWM frequency of the driver. This again advanced functionality I haven't tried out yet, but I know the chip can control the PWM frequency.