Closed adriaanb closed 6 years ago
I had the same issue i finally found that my set up doesn't like low values of k like 0.05
I tried finally decreasing k from 1 to 0.1 and found a sweet spot at 0.12
tmc2208 (no UART) and ramps 1.4
I created test files for testing all K factors between 0 and 2, in .01 increments (using lin advance 1.5) - it makes no difference, the extruder stops working almost immediately.
If testing with gcode generated for the K factor calibration pattern, it always prints the first slow line segment followed by the fast line segment, but no matter the K factor then fails when it comes to printing the second slow line segment at the end.
But out of curiosity - how did you tweak the behavior of your extruder to match a k factor of 0.12 as opposed to the one you determined for your settings & filament using the calibration pattern? All filaments I use require K factors between 0.06 and 0.08 depending on filament (I calibrated while my A4988 drivers were still in place), so printing with twice the K factor would result in rather distorted prints, no?
I had the problem using the K patern becaause it starts with low values of K
so I abandonned the use of K pattern and printed calibration cube adjusting K directly before printing starting from "high " values intentionnaly I know it is a lot longer than k pattern but closer to real prints as I was focused on angles orthogonality
here are some examples at 40 mm/s no retraction from left to right : 0.3 - 0.15 - 0.1 - 0 (vase gcode for 0, old try for comparison) I only note angle aspect and start of layer aspect
0.3 has no matter on angles, 0.15 has a little round corners, 0.1 the swelling starts to appear then I did 0.12, but it depends on print speed, at 60 mm/s, 0.12 seems a little too high, 0.1 should be ok K is dependant of your setup extruder hotend nozzle... 0.12 for me, 0.08 for you sounds normal to me
I tried to print several benchies within reasonable parameters for my printer in terms of K factors. All failed after priming the nozzle.
Do you run a bowden setup or how are you using K factors above 0.1? As stated in my initial post I am running a direct drive setup (with and e3d v6 hotend).
I also modified the g-code of the test pattern by hand, allowing me to reduce the K factor instead of increasing it with each incremental line to print - testing that way yielded the same results sadly :(
For now I will just have to disable linear advance it seems - possibly I'll order some TMC2130 drivers and see if the issue persists with those drivers. Would be interesting to find out if TMC2208 on X Y and Z and TMC2130 on E0 and E1 mix well...
In case others come along looking for a solution to this issue - as a solution for now I ended up using the drivers in legacy mode and setting them to SpreadCycle using the OTP (One Time Programmer). Unfortunately trying to set individual drivers to SpreadCycle via UART by endabling HybridThreshhold and setting the threshhold to 0 for the respective axes did not work.
Since setting this up viat the OTP may not be super straigtforward for some, this video may be of help.
Also, don't forget to solder in the pin headers for MS1 and MS2 to configure the microsteping mode in case only the pins necessary for running the drivers via UART were previously soldered in, heh.
I am still hoping there will be a better solution to this at some point, as it is quite nice to be able to monitor and tweak the drivers via gcode, but for now I hope this will help others :)
As long as we don't know the reason for this problem, it's hard to fix it. My personal feeling is that there is quite a big amount of issues related to TMC drivers, which raises the question if this drivers are much more picky to settings than "normal" drivers. So, is it a LA problem or a driver problem?
When LA works at some K value but stops suddenly at some lower value, all that will be changed is the pulse frequency. But all frequencies could also happen during printing without LA and even if there would be an issue with odd timings (short double pulses for example), it should "only" lose a step and not stopping extrusion completely.
@Sebastianv650 based on my limited understanding of this post I referenced earlier, it seems plausible to me that it is a hardware/firmware issue with the chip. I am not sure to what extent changes in the Marlin firmware can compensate for this, but I would happily help in trying to identify which settings interfere with it/narrowing down the source of the error. For me, it does not work at all no matter the K value, for others it apparently does up until a certain point. I will start playing around with settings and seeing if I can get the printer to react (disabling various features, playing around axis steps per unit,... not sure what else would be worth a shot) as soon as I have the time to do so.
@thinkyhead I carried over the Linear Advance settings I used prior to installing the TMC2208s, it has all the fancy extrusion features disabled except for retraction itself. Once I get back home I will try to disable that and report back, thanks for the tip.
@adriaanb your linked post might be the root cause indeed. LA can only work when it has some jerk speed to play with. That's an amount of speed where the extruder doesn't need an acceleration part. To prove that, try using the spreadCycle mode because as I understand it this problem should only exist in stealthChop mode. Using this on the extruder stepper only should be OK if thats possible.
@Sebastianv650 that is exactly the solution I have resorted to, so far it works well. I switched the drivers on my extruders to SpreadCycle using the One Time Programmable memory, as I could not find a solution to switch only individual drivers to SpreadCycle in Marlin. Enabling HybridThreshold and setting it to 0 for the extruders did not have the desired effect.
As the OTP is not that intuitive and requires users to make irreversible, potentially destructive changes to their drivers, a better solution might be a way to put individual drivers in different modes using the Marlin firmware without having to rely on the HybridThreshold mechanism. On the extruders SpreadCycle does not cause any noticeable increase in noise anyways and generally seems to be a more robust, less error-prone mode.
Good to know, one important thing to keep in mind if we see issues with shifted layers and so on when there is a TMC in the system. As all movements can see jerk, a jerk-sensitive driver mode is realy not a good thing at all.
I could not find a solution to switch only individual drivers to SpreadCycle in Marlin. Enabling HybridThreshold and setting it to 0 for the extruders did not have the desired effect.
@teemuatlut — Do we have a standard and supported method to switch one driver to SpreadCycle?
Not yet but you can do with TMC_ADV
.
stepperE0.en_spreadCycle(true)
@adriaanb — Looks like TMC_ADV
can do what you want.
#define TMC_ADV() { stepperE0.en_spreadCycle(true); }
That is great news, thank you! I will reconnect the drivers and give this a whirl as soon as I get the chance!
I am going to change my driver to spreadcycle using the One Time Programmable memory. Does anyone have a reliable video of hot to handle the software to make the change.
@Thesecky I linked a comprehensive video description on how to do this in this post.
However, you might want to first give the method teemuatlut and thinkyhead mentionned above a try, as this will allow you to avoid making permanent, potentially destructive changes to your driver as well as monitor the drivers from Marlin.
I hope it helps.
I am using cliper so this unfortunatly isnt posible. Thanks for the video, will take a chance and use otp.
Using Klipper you can program them using UART so it isn't permenant.
Ok so I disabled Stealtchop on my TMC2224 extruder driver by installing a jumper on MS3. Not sure if this would work for everybody in stand alone mode, this was the procedure for my Azteeg X5 Mini Wifi.
I immediately heard a swish swish noise when I actuated the extruder, but it still refused to budge.
I then set:
#define MINIMUM_STEPPER_PULSE 2
and it prints. The weird swish swish noise is a little disconcerting but it's not stalling so looks good so far.
@teemuatlut — What's the closest thing we have to TMC2224 in our stepper selections? Should we add TMC2224 as another option?
@thinkyhead The TMC2208 "seems" identical save for the pinout.
https://www.trinamic.com/fileadmin/assets/Products/ICs_Documents/TMC220x_TMC222x_Datasheet.pdf
TMC2208.
You could make a new specialized template for it in tmc_util.h
that just inherits the TMC2208 specialization and passes on every parameter given. Then add it as a supported option.
So here is the conundrum:
I have 4X TMC2224 but turned off stealth chop on the extruder driver by installing a jumper on MS3. In order to get it working, I had to #define MINIMUM_STEPPER_PULSE 2.
If I understand correctly this will apply to all axis, will this cause any issues?
FYI: I just found 1 difference between TMC2208 & TMC2224. On the TMC224 you can disable StealthChop by installing a jumper on MS3.
Just a confirmation that same issue persists in bugfix-2.0 2019-JAN. Also: extruder driver crashes with any value, even if K=0 (but LA enabled). Temporarily installed A4988 for extruder.
I have TMC2208s on my Prusa p3Steel, running 8 bit RAMPS. I'm also using a bowden tube.
If I have default_ejerk set to 5.0, I can get it to print, but the extruder motor makes a horrible noise every time the print turns a corner. I know this has been reported elsewhere.
If I change the ejerk to 1.0, the extruder stops and the print never gets off the ground.
I have not been able to find any satisfactory setting using the TMC2208 with lin_advance in stealthchop mode, unfortunately. I think the TMC guy said that the noise comes from an abrupt voltage change?
Anyway, it's too bad that this problem exists. Hopefully someday there will be a solution.
If I have to be honest, after finding myself helpless trying to use a 2208 on the extruder motor, I switched back to an Alegro 4489 and I haven't regretted it ever since. The extruder driver is, by far, the least problematic one. Once you tune in the current delivered to the motor and have a consistent extrusion without overheating or skipping steps, it isn't really noisy at all. So I have a couple of printers with 2130s on X and Y, 2208 on Z and 4489 on E... very happy with the setup.
If I want to use lin_advance, I will have to go back to an 8825 driver. I will be going 32bit soon, so maybe then, if I'm using Marlin 2.0, I can use the 2208 in spread cycle mode.
Otherwise, without lin_advance, I'm quite happy with the 2208 on the extruder.
Just a confirmation that same issue persists in bugfix-2.0 2019-JAN. Also: extruder driver crashes with any value, even if K=0 (but LA enabled). Temporarily installed A4988 for extruder.
Replaced the extruder driver "unfliping" its connectors only? Thanks!
That is great news, thank you! I will reconnect the drivers and give this a whirl as soon as I get the chance!
So, did it work? I'm waiting for my tmc2208s and thinking about applying this to enable LA. Thanks!
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Description
Enabling Linear Advance while using Trinamic TMC2208 stepper drivers on the extruders almost immediately causes the extruder to stop extruding - any K factor larger than 0 has some files failing immediately after priming the nozzle or somewhere in the first layer of the print due to the extruder motor shutting off.
My printer is a cartesian design based off of the Prusa i3 with dual extruders, both with a direct drive. Due to the ertruder assembly's significant mass, I have low Acceleration (600 mm/s²) and Jerk (10 mm/s) settings.
The error occurs both with the 1.1.x and the bugfix-1.1.x bugfix branches. I tried setting the hybrid threshhold for E0 and E1 to 0 as to see wether the problem would also occur in SpreadCycle mode as opposed to StealthChop, but doing so made no difference.
The slicer used is Cura 3.4.1
Steps to Reproduce
Additional Information
I found bug reports for other firmwares while searching the web for a solution to the problem that suggested increasing jerk and/or decreasing the k factor as well as decreasing the motor current as a remedy, which did not affect my printer in a positive way. The most interesting one was the following:
https://github.com/KevinOConnor/klipper/issues/196 (or this post in particular)
My Configuration.h and Configuration_adv.h files