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.
Fault pin is imho no problem: In the ultimaker link above he wrote:
[/quote]
The TMC2130 offers two DIAG output (DIAG0 and DIAG1). You can set those two Outputs to signal errors in realtime to the microcontroller.
On the stepstick, you can access them via the pins/holes on the middle of the drivers: 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.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, ...[quote]
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"
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.
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.
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.
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!
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.
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.
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.
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.
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.
...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.
1. 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.
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.
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:-)
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.
1.7us is for high signal, we also have overhead per interrupt which is much higher. On AVR 30-40 khz with quad stepping per interrupt is possible. On a Arduino Due 100KHz singlestepping is possible.
With lost step detection it often depends on the motor used and also the speed. Not for all speeds it detects a lost step. Has to do with how they detect it from current changes.
This corresponds to what I read from the datasheet. In a nutshell, speeds under 1rpm and when the motor voltage is close to PS voltage. Fortunately, I don't think those circumstances occur often. Most print speeds are around 70mm/s.
I'm studying the datasheet and arduino config tool now for a few hours. Yeh, there's a real good reason why noone uses these...the config makes your head want to explode. So many great options, but getting them to work reliably might require weeks of work. I want to get these moving in the simplest manner possible, at first, but even in doing so I might be looking at this being more work to get this moving than designing my own closed-loop detection system. I think for now the TMC2130's deserve a day to get moving and observe a few things I'm not too clear about (mainly if Repetier needs SPI interface to 2130 during operation, which I'd like to avoid).
The point is to reduce error occurrences, and errors will still happen. I think this has a chance of making 3 of 4 prints due to skipped steps recoverable, just to put a guesstimate on it. Historically, measuring back EMF is not the best way to ensure positional accuracy, but it seems new designs are getting better.
Properly implementing the dcStep function of TMC2130 could potentially make prints not have all those fine stepping errors and enable the motors to accel and move closer to their full potential. Mr. Wattercott confirmed not all dcStep pins are available for the breakout boards, but might be in the future. The D1 pin can output dcStep skipped steps...perhaps to slow Repetier's motor pulse generation adequately, while taking care of all the other functions. This function of the TMC2130 basically re-applies pulses when a motor skips and waits until the motor catches up, effectively slowing motor speed to prevent skipped steps. I'm thinking a function that adds a loop inside the interrupt step routine to slow the pulse generation by a rate no more than the maximum motor deceleration speed. The number of times the loop runs would be proportional to the number of skipped steps read, thereby hopefully properly delaying pulse generation for other motors. When a max number of skipped steps is read or the loop repeats a max number of times (timeout), a flag is set, then the print pauses and re-homes.
There might be a way to program the D1 skipped steps to be compatible with the limit switch operation. This would prevent configuration hell, but might not be possible. Just programming dcStep to function proper will be a feat I bet, but it's something likely worth the extra work. The future of 3d printers will include position monitoring, I would bet my house on it. The best way right now is by using encoders, so if the TMC2130 becomes tougher than integrating encoders I will make the move to real closed loop control.
I could see accomplishing real closed loop control using encoders like this. Using encoders would be a different discussion topic I presume, but might be the same level of difficulty and similarly priced as the TMC2130 driver.
Is there a reason why Repetier wouldn't consider X and Y axis AB encoder input, or perhaps this has already been programmed? I might opt to try just one phase from the encoders into a limit switch plug (3-pin) and correct positional errors by slowing other motors when a motor position is lagging, similar to the proposed operation of dcStep of the TMC2130. If done properly, I think positioning with encoders would be preferred for reliability.
There is a project Mechanduino making cheap closed loop solutions. Not comparable with the 300 Euro professional solutions, but functional I guess.
I do not really think a firmware could handle all the special cases and exceptions in closed loop. That would require extra interrupts to control position and catch up with wanted position. Here a cheap AVR chip or even ARM for monitoring one extruder on it's own would be the more efficient solution. That chip could put interrupts in step/dir signals so it does not need to poll changes and can use it's interrupt solely for keeping up to wanted position constantly monitoring for lost steps.
I remember seeing the Mechanduino project a while ago...I like it, but I don't think it communicates positional errors to the microcontroller so it doesn't know to slow the other motors...I don't know that I'd call it good for a 3d printer...maybe just for single motor systems. As we can imagine, a print will be pretty screwy still if one motor slows but the others do not. Steppers with skipped steps are not to apt to "catch up" via acceleration either, so I don't know how it could be done unless the single-motor processor communicated to the main controller to allow it's motor to catch-up. You could have buffers in all single motor processors but they still need to request the main controller slow down. The X and Y motor step pulses I think is easiest dictated by the printer controller, as that is it's primary function, even tho many controllers now interface all kinds of hardware.
TMC2130:
Firmware would need to count pulses from the DIAG1 pin with pulse widths down to 2.5us (thinking interrupts), plus TMC2130 needs to be calibrated for each motor and has so many settings, which makes it unattractive to most RepRappers I think. I'm not too confident it will catch all positional errors, but maybe I'm wrong, and maybe the setup for this chip is not as bad as I dred.
For encoder:
Firmware would need to read a 100p/r encoder on X and Y, and compare the actual pulse to the theoretical position to determine number of steps a motor is off, then adjust the following pulse stream slower until the retarded motor is back to the correct position. No need to ever re-home, just compensate on-the-fly. Initiate a pause if motors cannot get to correct position. Might be tough to program, but doable I think.
I believe I will move to trying the real encoders first, and using the firmware to interpret the pulses via change-state pin interrupts to slow the pulse rate for all motors not lagging by the decel rate. If encoders can be read without interrupts I will do that, as I understand the interrupts can cause disturbances in the output pulse timing. Using a lesser count encoder than the 600p/r I mentioned in my previous post should help drastically, and shouldn't hurt accuracy noticeably. If needed I'll free processing time by moving to 1/4 stepping and removing lcd interface for my printers. I don't expect all Repetier users be able to use these settings, but the added benefit of cleaner and less ruined prints is worth it IMO. If this works well I expect eventually I will need to incorporate a better shield than RAMPS1.4 for my printers and will break out the encoder pins better then. I am happy to write this in Repetier, but as I understand, since this may not be very universal you might not want to consider this, or perhaps this becomes a new board config? If you don't mind this being a new board or option, I will write this so anything not included in the settings for this board will not significantly slow the rest of the firmware.
Page 75 of the TMC2130 datasheet shows a nice graph of what their dcStep function does, and how skipped microsteps look before the full step skips. It shows the drive slowing the motor to prevent major skippage and give the motor time to (hopefully) catch up, and steppers have more torque at lower speed.
I wish we could just add extra steps to the motor that's behind, but this would exacerbate a overload issue and cause a full step jump. Decelerating alleviates the overloaded motor.
I see closed loop helping 3D printers in separate 3 ways:
1. Pausing for later recovery from a print on a major blockage, jam, or misbehaving motor. This to me is most important, and even a single pulse per revolution non-contact switch could serve this purpose.
2. Correcting "ugly" prints caused by smaller errors. Motor drives and controllers often make small "misteps" caused by timing or electrical issues...sometimes belts slip just a few tenths of a mm on pulleys too...then there's momentum and everything flexing...vibrations...earthquakes even! Closed loop with an accurate encoder can fix most of these issues on the fly. I think the end result is a cleaner part.
3. Speeding print time. If acceleration is limited by positional accuracy instead of a pre-programmed value we have potential to work our motors to their fullest potential. This should effectively reduce print time.
There are plenty-a master's thesis' on closed loop control, and if this were easy it would have already been done with large success for 3d printers:/ I think getting feature 1. (from above) is a good starting point, but I'd like to one day get features 2. and 3. working.
I’ve gotten the basic configuration of TMC2130 via SPI working on a RADDS + Due board. I wired the SPI up with jumper wires on the back of the RADDS.
The motors are moving and I can set coil current and microsteps as well as toggle stealthchop and interpolation. I’m using https://github.com/teemuatlut/TMC2130Stepper as a driver library.
Next I will be tackling endstops through the StallGuard feature of Trinamic.
I would eventually like to merge this into Firmware master when it’s in good enough shape. For that I need some input from Repetier developers about the conventions to follow, where to put certain code and where not to. Is there a developer’s Getting Started Guide somewhere for Repetier?
Or I can just put up a work-in-progress pull request and we can discuss the details there.
Really looking forward to using my TMC2130 in my new HEVO variant which I’m now building.
We have no guide but if you look into our sources you see how we like it. camel case names, astyle formatted.
Important note so we can merge it is to use latest dev version from us, so pull request shows clearly the added code parts. And also to include our configuration.h when submitting.
And be aware that most files are identical in avr and due tree, only hal/fastio differ depending on architecture.
Comments
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.
I wired the SPI up with jumper wires on the back of the RADDS.
The motors are moving and I can set coil current and microsteps as well as toggle stealthchop and interpolation. I’m using https://github.com/teemuatlut/TMC2130Stepper as a driver library.
Next I will be tackling endstops through the StallGuard feature of Trinamic.
I would eventually like to merge this into Firmware master when it’s in good enough shape.
For that I need some input from Repetier developers about the conventions to follow, where to put certain code and where not to. Is there a developer’s Getting Started Guide somewhere for Repetier?
Or I can just put up a work-in-progress pull request and we can discuss the details there.
Really looking forward to using my TMC2130 in my new HEVO variant which I’m now building.
Alex
Wiring th SPI on a RADDS board:
Important note so we can merge it is to use latest dev version from us, so pull request shows clearly the added code parts. And also to include our configuration.h when submitting.
And be aware that most files are identical in avr and due tree, only hal/fastio differ depending on architecture.