My venerable Taz 6 worked fine for many months, but it suddenly developed a serious problem with x-axis motion. During high speed travel (200 mm/sec) of an inch or so it can lose as much as 0.1". It’s better at low speed (60 mm/sec) but still not good. Sometimes it happens randomly, and sometimes on every layer.
It also seems to be making more noise moving in the X direction than it used to.
Here’s what I’ve tried:
- Verified that the stepper motor gear is secure and the setscrew is on the flat of the shaft.
- With the belt off, verified that the carriage slides ok on the rods. (But I rotated the bushings anyway, and have a new set on order.)
- Changed the belt – which was probably over five years old – and made sure the new one is tight.
None of that helped. I also notice that during 60 mm/sec travel, the new belt experiences some kind of resonance and vibrates like crazy, particularly when moving left. I posted a video of that here: https://youtu.be/1N5Zpr1igP4
What should I try next?
Is the belt slipping on the gear? Put a little mark at the same place on the gear and belt and move it back and forth and see if the mark on the belt and gear still line up after moving it.
Could also be a stepper driver going out. Do you have a motor to swap in and test?
That belt-slipping test is a good idea; I changed the belt because I was worried about that. But I did the test and the marks on the belt and the gear still match up even after it produced a print like this:
Those are supposed to be vertical cylinders separated by 2", here printed using 200 mm/sec travel speed between them. Clearly something is very wrong.
Do you think the stepper motor is suspect? Or is the stepper driver electronics inside the box more likely to be the culprit?
I have some other NEMA 17 1.8degree motors I can try, although the specs are not identical.
- Moon’s MS17HD6P4150 in the Taz 6: 1.5A, 2.2 ohms
- my StepperOnline 17HS19-2004S1: 2A, 1.4 ohms
Should I try that?
I have no idea what kind of driver electronics is inside the enclosure. The Lulzbot website doesn’t seem to show a motor driver as a replacement part.
The stepper drivers are built into the Rambo controller board so if one is bad, then you may have to replace the entire board. See https://ultimachine.com/products/rambo-1-4.
There are other controller board options if you are willing to use custom firmware. See https://github.com/drunken-octopus for some possible solutions (i.e. Archim 2.0).
Definitely try that other motor. You’re not pushing the limits on that machine so 1.8 should be fine.
Steppers are not replaceable.
I’d go with an SKR mini as a replacement. Much cheaper and modern than archim, and also replaceable drivers. I don’t think it’s part of the drunken octopus build 3 though. But, I think there a bigger community if you need help with building marlin or klipper for it.
1 Like
I suggest that you carefully inspect and test all the wires and connectors from the Rambo board to the motor. In the past I have found that this type of random movement was caused by this type of problem. I’m no expert but that is what I have found on my machines.
My 2 cents
I replaced the motor with a StepperOnline 17HE15-1504S (1.5A, 2.3 ohms, 60 oz-in) and it works, but it didn’t fix the problem.
I inspected all the wires and connectors from the motor to the Rambo board, and everything looks fine. I removed and replaced each connector several times to wipe the contacts. No help.
I monitored the power supply while the carriage was printing and moving, and it was a solid 24.2V with no apparent glitches.
I’m reluctant to conclude that it’s the driver on the Rambo board, since (a) it mostly works, and (b) doing something about that is a big deal. Can anyone think of a test or measurement I can make to provide more incriminating evidence?
The only other thing I can think to do is replace the X-axis bushings when the new ones arrive on Thursday. Maybe the old ones are binding at high speed in some way that isn’t apparent when I move the carriage manually. I took some slow-motion video of the carriage while it was printing, but that shows nothing odd.
Is there any chance I accidently made a change to a parameter that is causing the Cura slicing process to generate problematical G-code? I am using the LulzBot TAZ Dual Extruder V3.1 toolhead and the updated firmware that they recommended, but these tests use only the primary extruder.
Ugh. I’d really like to get beyond this and back to the real job: investigating whether we can build the world’s first computer. See https://worldsfirstcomputer.blogspot.com/.
Almost certainly a bad driver.
But, there is some hope.
If you don’t use dual extrusion, there’s that second extruder driver that can be used by reconfiguring marlin to use it instead of the one you have been using.
Ok, I’ll go with the assumption that it’s a bad stepper driver and will replace the controller board. I do use the second extruder for support structures sometimes.
I don’t have time now to learn about building and configuring Marlin or Clipper firmware, so I just ordered a (very expensive) Rambo 1.4 board from Lulzbot, which they say works for the Taz 6. Hopefully that will be a drop-in replacement for my version 1.3L.
It’ll be drop-in, but you’ll have to flash the firmware. There were some earlier rambo boards with the LCD controller wires flipped, so if you get nothing on the display when connecting it, it’s a pretty easy fix.
Aha - that may explain why it comes with “two Graphical LCD controller harnesses” and none of the other cables.
Flashing the firmware shouldn’t be a problem, since I did that when I installed the dual extruder head. Will report back after the board arrives.
You were right and I was wrong – I installed the new Rambo 1.4 board and the problem disappeared!
Not the failure mode I expect from a digital IC, but then stepper drivers like the A4982 are half analog.
Thanks, all, for your help and advice!
1 Like
Good job, I’m sure that board replacement wasn’t super fun to do - but nice to see the old printer is back up and working.
