Support for new TMC2130 SSS (SilentStepStick) via SPI

futzicomp

Do you know this driver?
http://www.trinamic.com/products/integrated-circuits/stepper-power-driver/tmc2130</span></span></h6><h6><span style="font-family: Arial; font-size: medium; font-weight: normal; line-height: normal;">https://github.com/watterott/SilentStepStick</span><br/></h6><h6 style="font-style: normal; font-variant: normal; font-weight: normal; line-height: normal;">The driver is Pololu compatible. BUT(!) you can also drive with SPI. Then you get a lot of new features. https://ultimaker.com/en/community/17498-new-sss-driver-tmc2130<br/></span>https://www.youtube.com/watch?v=Prw7wNa20Gk<br/><span style="line-height: normal;">example:
1) Auto Bed Leveling / Ebdstopf (Load detection)
2) Emergency ShutDown
3) Lost Step/Load Indicator (Extruder)
4) no filament detection (zero load)Is it possible to integgrate this Driver (SPI-register) to Repetier firmware?

futzicomp

<font face="Arial, Verdana">...found an implementation in Marlin with a similar driver (TMC5130)</font>

<font face="Arial, Verdana">https://github.com/trinamic/TRAMS/tree/master/Firmware</span></font><br/></div><div><font face="Arial, Verdana">
</font>

Repetier

In theory this is surely possible. You need a software spi implementation for each driver and override the step/unstep/direction/enable function with the appropriate code.

Main problems I see:

1. Setting steps with SPI is much slower. Instead of toggling one bit you have to send 8-16 bit with software spi. So it will be 1/30 or slower of normal speed. So that is not a real option for driving the steps.

2. I'm not familiar with this chipset but I tried writing load detection with TI chips and failed miserably. This requires quite some conditions to work and the right timing and speed. And you would need a very fast fault implementation which only is possible using the external fault pin for which boards have no connection. Without you would again need to query with spi which is too slow.

And if you get fault detection working the next problem is to rewrite the code for this. As it was not possible before, there is no handling to do it.

The only advantage I might see is, if it is possible to set some parameter like current/microstepping in spi mode and then switch back to pin mode. Not sure though if that is possible here or if it is overridden by external ms-pins and poti.

futzicomp

<font face="Arial, Verdana">Thanks for your answer! - But i dont give up ;-)</font>

Fault pin is imho no problem: In the ultimaker link above he wrote:

[/quote]

<blockquote style="font-family: Arial, Verdana; font-size: 10pt; font-style: normal; font-variant: normal; font-weight: normal; line-height: normal; margin: 0px 0px 0px 40px; border: none; border-image-source: initial; border-image-slice: initial; border-image-width: initial; border-image-outset: initial; border-image-repeat: initial; padding: 0px;"><p style="clear: left; margin-top: 0px; color: rgb(24, 41, 77); font-family: 'Proxima Nova W01', helvetica, arial, sans-serif; font-size: 16px; line-height: 22.4px; background-color: rgb(255, 255, 255);">The TMC2130 offers two DIAG output (DIAG0 and DIAG1). You can set those two Outputs to signal errors in realtime to the microcontroller.</p><figure class="thumbnail r-tablet-50 r-mobile-100" style="margin: 0px 0px 0.3em; float: left; box-sizing: border-box; position: relative; padding: 0px 0.6em 0.3em 0px; color: rgb(24, 41, 77); font-family: 'Proxima Nova W01', helvetica, arial, sans-serif; font-size: 16px; line-height: 22.4px; background-color: rgb(255, 255, 255);"></figure><p style="clear: left; color: rgb(24, 41, 77); font-family: 'Proxima Nova W01', helvetica, arial, sans-serif; font-size: 16px; line-height: 22.4px; background-color: rgb(255, 255, 255);">On the stepstick, you can access them via the pins/holes on the middle of the drivers:</p><figure class="thumbnail r-tablet-50 r-mobile-100" style="margin: 0px 0px 0.3em; float: left; box-sizing: border-box; position: relative; padding: 0px 0.6em 0.3em 0px; color: rgb(24, 41, 77); font-family: 'Proxima Nova W01', helvetica, arial, sans-serif; font-size: 16px; line-height: 22.4px; background-color: rgb(255, 255, 255);"></figure><br style="color: rgb(24, 41, 77); font-family: 'Proxima Nova W01', helvetica, arial, sans-serif; font-size: 16px; line-height: 22.4px; background-color: rgb(255, 255, 255);"><figure class="thumbnail r-tablet-50 r-mobile-100" style="margin: 0px 0px 0.3em; float: left; box-sizing: border-box; position: relative; padding: 0px 0.6em 0.3em 0px; color: rgb(24, 41, 77); font-family: 'Proxima Nova W01', helvetica, arial, sans-serif; font-size: 16px; line-height: 22.4px; background-color: rgb(255, 255, 255);"></figure><p style="clear: left; color: rgb(24, 41, 77); font-family: 'Proxima Nova W01', helvetica, arial, sans-serif; font-size: 16px; line-height: 22.4px; background-color: rgb(255, 255, 255);">Today I tested some of the DIAG settings, especially the one for stallguard2. The Diag-Ouputs are interesting because it is easy to make the Ultimaker stop or pause or whatsoever if an external signal (e.g. the DIAG1 signal) comes HIGH/LOW.</p><p style="clear: left; color: rgb(24, 41, 77); font-family: 'Proxima Nova W01', helvetica, arial, sans-serif; font-size: 16px; line-height: 22.4px; background-color: rgb(255, 255, 255);">That means, using the Diag-outputs, the Ultimaker is able to stop/pause if the driver overheats, the extruder loses steps, the printhead crashes agains the frame, ...</p><p style="clear: left; color: rgb(24, 41, 77); font-family: 'Proxima Nova W01', helvetica, arial, sans-serif; font-size: 16px; line-height: 22.4px; background-color: rgb(255, 255, 255);">[quote]</p>

I will try to get contact in german reprap forum with similar request, to ask if it is possible to change drivemode "on the fly"

<font face="Arial, Verdana">http://forums.reprap.org/read.php?336,644397,650561#msg-650561</span></font><br/></div><div><font face="Arial, Verdana">
</font>

Repetier

Ok, with the 2 extra pins you have at least the chance to request for errors. For playing around I'd suggest extending the endstop handler with a extra variable for faults. You could then set pins high when a fault is detected. endstop detection is called every step if always check endstops is enabled. Or write a similar class that is independently called. As a start maybe just write out faults detected (watch out if done in interrupt it can hang firmware on many faults) so you can test how reliable it is with these chips and your motors.

kubi23

<blockquote rel="Repetier">In theory this is surely possible. You need a software spi implementation for each driver and override the step/unstep/direction/enable function with the appropriate code.

Main problems I see:

And if you get fault detection working the next problem is to rewrite the code for this. As it was not possible before, there is no handling to do it.

Hi All - I would like to clarify some things with this nice chip set from TRINAMIC. The TMC2130 and its bigger brother TMC5130 are extremely versatile stepper drivers. Futzicomp mentioned some possible benefits. One major advantage is the silent mode operation called stealthChop. You need to here this mode...actually you do not here the motors any more. Only your (bad) mechanics.

The TMC2130 is a typical step/direction driver! It has an SPI interface, but this is only used for configuration (current, micro stepping, chopper....) and for read back of high level and detailed diagnosis information. So from software point of view you still use your typical Step/direction generation routines. With respect to stall detection or load detection the integrated feature (think they call it stallguard) works really nice for homing for example. you can eliminate your end switches completely. The driver is doing an automatic stop. you do not need to monitor and react in firmware.

The TMC5130 is even better. Allows for a bit more current. It can be operated as a step/direction driver as well. But the most interesting feature is its integrated ramp controller/motion controller. Using it you do not need to generate step pulses in software any more. You also do not need to send step pulses as SPI datagrams as posted in the quote above. You only need to command your target position and if desired updated ramp parameters for acceleration and max velocity. All the time critical computation is done in the chip. I think it is real dedicated hardware. No DSP, software. You just command positions on the fly and it is automatically going there. This really offloads the software load.

boelle

could be nice with a "for dummies" example on how to setup the driver to set an output high when the driver stalls

what i had in mind was to use this as a touch probe... no more extra wires for a servo etc

boelle

mostly interested in how to program it

can i use an uno and a few test wires to program them?

any sample sketch out there to use?

boelle

maybe this one is a good example: https://github.com/makertum/Trinamic_TMC2130/blob/master/Trinamic_TMC2130/examples/configuration_tool/configuration_tool.ino<div><br/></div><div>will have a closer look in a bit</div>

Jared

Hi Guys,

I'm just joining this thread, and am seeing a bit of information where some people are testing these with luck: https://ultimaker.com/en/community/17498-new-sss-driver-tmc2130 ...and it seems Marlin has a fork: https://github.com/makertum/Marlin</div><div>I'm happy to test these with RAMPS1.4/repetier firmware machines if you'd like, if needed. Am I correct that this is unsupported in Repetier?

Any reason why these can't simply be plugged into RAMPS1.4 and header wires from the diag wires to the XYZ min/max endstops? Is it possible initiate a routine, which when the diag output is read to repetier the controller auto-homes the skipped motor?

Thanks in advance, and I like where you all are going here!

Jared

...oh, now I see my ultimaker link at the top...

Repetier

No one said it is not possible to impelement. It is not a simple modification, so it needs someone having a test printer with such a setup who writes a patch for this. There are simply many places where blind implementation would fail, so it makes no sense to write mods you can not test.

The idea of adding a home when a lost step is detected is great. Also we would have to empty current print queue that would fix the problem so print would finish with a little glitch instead of failed print.

Jared

@Repetier

<font face="Arial, Verdana">Yes, my goal of this implementation is just to sense skipped steps, re-home, and restart...or initiate a pause or some routine similar to the filament runout in Repetier. I agree...blind testing seems difficult. I'm a mech engineer, so I can read code and write some code, and can take care of all things mechanical. I have a printer I can dedicate to this....I'm a bit weak on the code writing part here. Presently my printers use Ramps1.4, but I'm considering moving to MKS gen1.4 or ramps-fd if 32-bit is truly beneficial.</font>

Am I correct to theorize the easiest (and most compatible for most users) place to start here would be to plug the D pins from the 2130 into the limit switch inputs? I think you mentioned those are checked on every move pulse? This seems like a better place for the inputs than where the Marlin guys are doing it on the aux port (but maybe that's ok too). I'd like to utilize a filament runout function if those are checked on every print move also...are they? Once I get a motor skip to trigger a filament runout routine I will work to write a custom routine for skipped steps that works like the out-of-filament. Would that work properly with the buffer, to your understanding?

...I imagine this may not work well for homing, unless Repetier isn't looking at the filament runout during the homing process. I plan (hope) to use the 2130 D pin for homing and pitch the limit switch, but if it ends up complicating things I'll begin by keeping my limit switches in.

Repetier

First, endstops are only tested every step if endstop check is enabled. This is the case for homing and if ALWAYS_CHECK_ENDSTOPS is true. A better position might be a completely seperate routine that tests the D pins and is called from the bresenham function in motion.cpp where all steps get executed. As this is a interrupt routne you can not do longer computations or modification, so you would trigger an event like jam control does and handle the lost steps in main thread which has as much time as needed.

The nedstop pins behave the same as all other digital pins. What makes them special is that they offer 5V/GND pin per endstop so you can connect electronics easily. Since this is not needed here you can use any free pin available.

Homing and end of filament is no problem. Filament is only tested on E moves and homing does not move extruder.

What you need to do on skipped step detect is memory extruder position, call home for x and y (or only axis where steps are lost if it is pure cartesian and no corexy) and add move to original position.

Jared

Cool. So I get the jist of the triggering the jam control event, and thanks for your assistance!

I do see that 4 of the endstop pins are interrupt pins on RAMPS1.4. I guess I kind of like the idea of using the interrupt pins for D0 on the 2130. The lim switches seem like the right place for connections anyway, as these drives should be able to replace the limit switches. If I use an interrupt to simply set a flag to initiate a filament runout routine, wouldn't that work out proper, and even remember extruder position? I understand I shouldn't spend too much time in that interrupt...but if it's initiated that means I need to pause and move to home anyway. I definitely don't want to do anything to add to the length of time the controller has to write steps, as most perceive 8-bit controllers as slow already. I think the D0 pin from 2130 pin goes hi or low for lost steps and overtemp and that's about it...simple for an interrupt. No reason to try to read serial or other things coming from D1 like number of lost steps that I foresee. Unless there is some unforseen reason why I shouldn't use interrupts, that seems pretty easy and would be quick enough to catch anything the 2130 throws at it I think.

I see references that repetier uses an interrupt based sending buffer, and I'm not sure if that could interfere with the reading of additional interrupts.

*the crux of this might just be getting the settings for the drive right...these puppies have a lot of options and need calibration for the positional error checking.

Jared

...well...I guess if I do this I may need to write a special option for different limit switch handling. Or maybe all printers might want to pause and re-home if a limit switch gets hit mid-print?

I've had a printer, either Marlin or Repetier to at least stop when the switches were hit unexpectedly. Rehoming and a menu asking to continue printing would have been better yet.

Repetier

Do not start home etc from inside interrupt. That will crash firmware in many cases. These commands are not allowed to be added outside main thread flow. Think of being in process of adding a line while you call that adding a second line the same time.
2. Using interrupts for detecting switches is on the performance side very clever, but on maintaining side a nightmare. You need to know which pin maps to which interrupt for every supported board and handle that correctly. Interrupts mean having a special signal handler for each signal = pin and then map that back to pin/function. And for users not having them free you still need to implement the trivial method of reading the pin state. We had the same hell for timers until we decided to use no hardware PWM any more so we can use timers like we need them and not work around which timers were in use for pins and which we could use for timing.

Jared

@Repetier

Thanks, very informative! Yes I am amazed how many configurations are supported by both Repetier and Marlin, and Repetier being significantly better organized (and with the web config tool too) makes it much better to work with. I definitely don't want to get into configuration hell.

Right now I can't discern how long the D0 pin goes hi or low on a skipped step...the datasheet for the 2130 is very in depth, but doesn't describe too well the electrical states for this function, or maybe I have not found it in the datasheet. If the 2130 reads skipped steps at the 1/256 microstepping interval I think that will need an interrupt. I will do more reading.

When running a print, do you know how long Repetier's motor pulse (and read D0 pin) routine takes...I'd assume it would be around 20kHz. I guess if that D0 error flashes for less time than that I will need to use interrupts...if not, then should be fine within the function.

Would it be crazy to make this routine (of homing and waiting for user input on limit switch state change midprint) standard for all printers? Maybe I'd make an option to home and continue printing instead of waiting for input. I can't imagine when a user would not want to re-home after a skipped step or a mid-print limit switch trigger, for any printer. Maybe there's printers out there I'm unaware of tho. If it's ok to change behavior for all printers then I suppose this feature could be integrated without additional configuration options. We can plug D0 to the limit switch input for all boards and the user doesn't need to configure Repetier differently to use 2130 vs a normal limit switch.

I have a theory also that plenty of printers skip just a few steps routinely, typically just 1-5 steps per print, resulting in layers which are slightly misaligned. Has anyone ever considered a firmware option to home every layer, or every few layers? I see a lot of pictures of prints that seem to be skipping just a handful of steps...probably is often an electrical or programming issue and not mechanical issue, if I am to guess, but obviously I can't speak for all printers. This is the main reason I use Repetier instead of Marlin. I'm quite sure Marlin on a MEGA 2560 introduces step pulses from time to time that don't agree well with motor dynamics and result in slight stepping errors. Probably related to a processing that's not keeping up with the motor dynamics. I guess this is a different issue.

Repetier

In AVR boards the high signal is 1.7us I think if you do not add extra delay. There is exactly one function that sets all pins to low and that is endXYZSteps() so if that signal is very short lived, you would make your test at the end of that function. I would normally suspect the signal staying high and requiring to got to spi mode to reset it and then go back to step/dir mode.

Loosing steps is always a possibility. Sometimes it is just a part sticking up and when moving over it you loose a step. But you would always loose full steps not microsteps so it is much better visible then you might think. Homing every layer is possible at least with slic3r as you can add layer change code. But homing might be even worse if it does not signal on the same microstep you get a difference from homing. Many home sensors should be good enough to be more precise then full step but from tests with z probe I know that repeatability is not 100% and of course it adds a big penalty.

There is one solution that is really working great, but it expensive. There are stepper motors from I think nanotec and maybe also other vendors, that have lost step detection and autocorrect any lost steps as fast as possible. Only problem are around 300 Euro/motor:-)

Jared

Yeh...I've seen (actually made) motors with integrated drives and position sensing. I'm just trying to make it simple/cheap/effective for my printers and mainstream RepRap.

Yow, 1.7us is much faster than I thought they were moving. These drives need 1/16 microstep pulses, then interpolate their own 1/256...so to read faults at 250mm/s (current travel speeds for my printers) that's in the neighborhood of 25kHz, which sounds like we shouldn't have a problem with. I see documentation and examples which explain that the D0 pin acts just like a limit switch, and I don't believe SPI is necessary to reset...or for anything I'd like to incorporate. I believe the drive may need to move in the opposite direction to take the 2130 out of the stall condition. We will see.

Incorporating the dcStep from their datasheet would be the best option, if it was broken out on the A4988 compatible board. As far as I can comprehend from page 75 of their datasheet, it uses 3 pins which throw flags to tell the controller to reduce speed to prevent skipped steps, and can apply maximum acceleration and top speeds due to intellegent controls. They say it works without skipping steps, but that's tough to believe.