Improvements by using TMC2130 driver.

Topics around mechanical design, controller and electronics. Mods & hacks welcome.
ABH
Posts: 112
Joined: Sun Aug 14, 2016 7:31 pm

Improvements by using TMC2130 driver.

Postby ABH » Fri Jan 12, 2018 10:42 pm

I decided to post some findings and theories here, that technically inclined persons might find interesting.
Raise3D printers are using Trinamic TMC2100 based stepper motor driver modules, configured to use the smooth and nearly silent StealthChop mode.
An associated "feature" of the StealtChop drive mode is the so-called "microPlyer", which is marketed as microstep "interpolation" that gives a smooth motor operation. In reality, this is not an interpolation feature but rather an extrapolation feature, that tries to predict the time for a future step by assuming that all steps are equally spaced in time and of course unidirectional.
This has some severe consequences for the use in 3D printing, as described below.
I have been wanting to disable the microPlyer feature for a long time in the TMC2100, but unfortunately this is not possible unless you abandon StealtChop drive mode and configure the driver for SpreadCycle mode.
StealthChop provides higher torque than SpreadCycle for the speed range used in 3D printing. Many "3D printing experts" all over the Internet claims that there is a torque penalty by using StealtChop over SpreadCycle, but this is incorrect according to information from the manufacturer. In various Trinamic application notes it is shown that for the NEMA17 type of stepper motors StealtChop will give you the highest torque for speeds below 150 rpm, corresponding to below 100 mm/s X/Y axis velocity in Raise3D printers.
On the other hand, I have experienced myself, that a TMC2100 in StealtChop mode in certain situations can skip steps. I blame the microPlyer feature for this. In the datasheet for TMC2100 it is stated: "Attention: microPlyer only works perfectly with a stable STEP frequency". Well, a 3D printer has nothing but an unstable step frequency! It accelerates and brakes and changes motor direction all the time, just think of a rectilinear infill pattern, usually created at quite high speed.
So, I always had the suspicion, that the use of microPlyer in 3D printing is a big mistake. Remember that Trinamic IC's are not really targeting 3D printing. There are many other (high volume) applications, where these IC's can be used. 3D-printers are not even mentioned in the datasheet's listing of applications for this driver IC :-)
A problem with the use of microPlyer in 3D printing is illustrated in the figure below.
Figure1.png
Figure1.png (5.45 KiB) Viewed 119 times

The figure illustrates stepping forward from X pos. 0 to X pos. 3 and stepping back to X pos. -1. The velocity used here will be the so called "jerk speed", i.e. the velocity ending a brake phase (with constant negative acceleration) or starting an acceleration phase (with constant positive acceleration). The red curve is the electrical step trajectory following the native 1/16 microstep pulses as supplied to the TMC2100. The dotted blue curve is the "interpolated" trajectory, as supplied to the motor phases. The dotted blue curve is composed of 16 smaller steps, in-between the 1/16 steps, giving a resulting 1/256 microstepping smoothness. When reaching pos. 3, the driver expects a further move with the same speed in the same direction, but in reality the direction is changed! The result is an electrical "overshoot" corresponding to one 1/16 microstep distance (12.5 µm). At time=4.8 the driver realizes that it made a wrong prediction and it will now have to change the phase-currents back in a step that corresponds to twice the normal 1/16 microstep change. This "double step" in the opposite direction, which is necessary to mitigate the drivers wrong prediction, might come while the stepper motor is in a critical state. On top of the electrical overshoot, generated by the microPlyer feature, there will also be a mechanical overshoot caused by the abrupt velocity change and the systems moment of inertia. The electrical overshoot plus the mechanical overshoot might furthermore be combined with a critical physical rotor position. The motors torque will not be constant when the rotor moves between the stator poles. If the rotor happens to be in a "weak" torque phase, then the rotor might tip over and a shift of 4 full-steps (= 0.8 mm in the Raise3D printers) will be the consequence.
My conclusion is: microPlyer "interpolation" is not intended for 3D printing, as you have these direction changes all the time.

While TMC2100 doesn't allow the microPlyer to be disabled in StealtChop mode, this can be done in the TMC2130 driver IC. There are Watterott driver modules available, that can be used in the Raise3D motion controller board. As the TMC2130 is configurable via an SPI interface, you need to connect some wires from connector pins on the motion controller board (Rumba board) to the SPI pins on the Watterott driver modules, in order to "talk" to the chip.
There has recently been added support for TMC2130 in the Marlin firmware. Not in the Raise3D version of Marlin (Raise3D firmware "1.1.6-rev1" is one year old and based upon a three year old Marlin SW!), but in the real Marlin open source project, where the latest release is called 1.1.8, and is from December 2017. There are a few modifications necessary to make the std. Marlin firmware work in Raise3D printers. I made these modifications to the 1.1.8 release in a repository that can be found here:
https://github.com/ABH10/Marlin-for-Raise3D-N-series/tree/1.1.x_Raise3D_TMC2130
There are pre-compiled ".firm" files for the std. printer configurations (N1, N2, N2PLUS, single, dual, Bondtech), that can be used directly, without the need for setting up Arduino to compile the firmware.
Using TMC2130 with this firmware also allows you to set the stepper motor currents by M-code M906.
"M906 X900 Y900" for example, will set the RMS phase current in both X and Y stepper motors to 900 mA.

I used a specific wiring for the SPI signals on the motion controller board. This wiring is also defined in the firmware. There must be agreement between the HW and SW on this. All SPI connections are taken from the Rumba board "EXP1" connector:
SPI connections.png
SPI connections.png (2.42 KiB) Viewed 119 times

Note:
The EXP1 socket on the Raise3D Rumba board is mounted incorrectly (turned 180 deg.).
This means that the pin numbering doesn't follow normal convention and the marking on an IDC connector.
The pin numbers listed above follows the Rumba board schematic and are thus different to the IDC connector marks.
This picture shows the correct pin marking of the EXP1:
EXP1.png

The 4 pins on a module used for the SPI must not go into the module socket on the Rumba board. This will create unintended shortcuts.
Some people use connectors for the SPI wires to the module, but I chose to solder in the wires.
Connectors will be large and tall and will reduce the air flow for cooling the drivers heatsink.
Wired Modules.jpg


This link might also be interesting:
https://www.youtube.com/watch?v=sPvTB3irCxQ

So, this write-up has so far just been theory, but is it really true?
I saved a g-code file that I never had any success printing, while using the TMC2100 drivers in StealthChop mode. There is a certain layer region in that model that always produced one or more skipped steps. No matter how high stepper motor current was used, I always experienced skipped steps in this particular g-code file. The same STL file printed fine if I moved it to another place on the build plate. This supports my theory, that in this particular g-code file there are abrupt direction changes at critical stepper motor rotor/stator phases. The gantry in my printer was never disassembled from the time when these print failures happened till today. A disassembly might have made printing this g-code file possible, as this would likely move the rotor/stator phase relative to the critical abrupt direction change. I should mention that I printed hundreds of other models without problems with skipped steps, so this is not a common problem for me.
When I started using the TMC2130 driver with the new firmware, that had microPlyer disabled, I was able to print the g-code file for the first time using StealthChop!
I afterwards confirmed that using TMC2130 with microPlyer enabled generated skipped steps.
I also confirmed that using TMC2100 drivers and the same firmware generated skipped steps.
The visual results from using StealthChop with disabled microPlyer are better than ever. I don't see any downside of this modification at all and I would therefore strongly recommend this modification. If you listen carefully you can sometimes hear a very faint tone from the stepper motors now, that was not there before. This is the only very minor "negative" consequence of the modification. I know that some people are using other types of drivers that doesn't have this issue. However, I like the smoothness and silence of the StealthChop mode, so I am happy about this modification. And, my conclusion is clear: Using microPlyer interpolation in 3D printers is a mistake.

firesped
Posts: 788
Joined: Mon Mar 21, 2016 9:23 pm
Location: Tucson, AZ

Re: Improvements by using TMC2130 driver.

Postby firesped » Sat Jan 13, 2018 3:13 am

interesting. I replaced all my steppers with Panucatt SureStepr SD6128 Stepper driver myself. I use them on my trinus as well, which I replaced the controller with the Panucatt Azteeg X5 GT 32bit Motion Controller. I'm not even sure that printer makes any noticeable noise at all with the digipot versions.

do you know which steppers use microPlyer?
RL name: Michael Nolen
printers:
raise3D N2 kickstarter Early Bird
Trinus Deluxe (running smoothieware on Azteeg X5 GT board)
Monoprice Maker Select v2

ABH
Posts: 112
Joined: Sun Aug 14, 2016 7:31 pm

Re: Improvements by using TMC2130 driver.

Postby ABH » Sun Jan 14, 2018 4:34 pm

I think it is only trinamic that has this feature in their TMCxxxx series drivers. Never heard of any other drivers that does interpolation (= extrapolation).


Return to “Hardware”

Who is online

Users browsing this forum: carlosgray and 4 guests