Kind of a fringe case here I’m looking for some input on. I’ll try to bring you guys up to speed briefly.
Background:
I recently changed out the Z threaded rod for a 8 mm lead screw, which made the Z movement much smoother. You can easily spin the screw with your fingertips to move Z up and down when the printer is off.
I also installed a print surface from PrintinZ. Because of how I wanted to mount to the aluminum bed, I needed to turn off auto leveling as it would crash into the mounting hardware. But since my bed was physically leveled with spring washers under the screws anyway, I didn’t think it would be a problem.
As I expected, the prints still came out perfectly since the automatic bed leveling wasn’t really compensating for anything in my case to begin with.
Current Problem:
I’ve noticed that on some prints (usually large ones with a lot of moves) I get messed up layers, and upon close inspection have determined that the Z rod is occasionally spinning backwards! Sometimes it’s so slight I wonder if I’m not imagining it, other times it knocks backwards almost as far as it does forwards on a layer change. The movements are almost always accompanied by a strange “thunk” noise.
My theory is that because the Z action is now so smooth, and that the firmware isn’t constantly working the Z stepper, that enough movement causes the Z arm to slide back down and smash the layer its working on.
As confirmation, if I turn autolevel back on the issue does go away.
Question:
Can anyone think of a solution where I can keep autolevel turned off but not have Z slip back down? I was looking for some kind of software option to keep Z energized even when not actively moving, but my Google-fu seems to be failing me.
What are you using for printer control? I think Repetier keeps a motor powered after it’s been engaged, so the Z motor shouldn’t be disengaging. I did, however, notice that my Printerbot had a tendency for the Z axis motor to slip with default jerk and acceleration settings. Try reducing your jerk and acceleration - it’s not like your Z motor is going to be a rate-determining step anyway.
Any pic on the fail print part?(and video when that slip happen would be nice)
My guess would be that the calibrated data from autolevel isn’t match the bed you level manually.
Agreed, it seems like the Z motor becomes disabled between layer changes. It may also be the printer adjusting the Z level based off your last tram with auto leveling. Did you try resetting those values?
Are you aware of issues that micro-stepping and power saving produce? You may need to adjust your layer height to match the step count and thread pitch combination of your Z axis to prevent microstepping. http://prusaprinters.org/calculator/#optimallayer
@Patrick_Ryan Repetier-Host. I planned on playing with jerk and accel anyway to see if I can improve some of the ringing I see at high speeds. Any suggested values to start with?
@Dont_Miyashita , @Adam_Steinmark Autolevel values are cleared at the begining of my GCode with G28, so no hold-over. Also, observing the Z axis shows it is making no attempt to perform any compensation (when the bed leveling is on and bed is not physically leveled, you can clearly see the Z rod moving back and forth during each layer).
@Alex_Wiebe PB uses 1/16 microstepping so I have set steps per mm to 400 as per the Prusa calculator. This makes common layer heights (.1/.2/.3) even numbers of steps. I could try setting the steps per mm to be 25, which would be full steps and no microstepping. But then the layer heights would need to be changed (I.E. .3 becomes .28).
Seems like that would negate the advantage of moving from an imperial threaded rod to a metric lead screw, as I had to deal with odd layers/steps before. But maybe worth a shot to see if the microstepping has something to do with it.
@Patrick_Ryan Wow, so you have accel at 30 vs the stock 2000? I had seen some people online suggest dropping it down to 1000 for sharper corners, but never that low. I’m assuming you did your own experimentation to come up with that value. Definitely something I will take a look at.
@Alex_Wiebe Doing more searches for this issue with the idea of microstepping involved has uncovered an interesting thread from 2012 (before the auto level had even been introduced in the PBs, and therefore Z was not powered except for layer changes), where the poster theorized that using microstepping and a metric lead screw could cause the bot to knock down to the next detent due to lack of torque. Seems the solution put forward was to make a change in the firmware that keeps Z powered on all the time.
This appears to be the exact issue I have developed, if my observations are correct.
I’m not necessarily against doing this if that will solve the problem, but at some point the juice may not be worth the squeeze. It would be less invasive to come up with a different way to mount the plate than doing a custom firmware compile.
I’m a bit embarrassed to admit that’s a holdover from long, long ago, when I was still using nylon line instead of GT2 belt. Guess I can dial that up a bit…
@Tom_Nardi Since your using repetier firmare you can simply set the z-motor to not turn off, to simply hold its position. This will make it so you don’t have to keep autoleveling on.
Personally I would suggest migrating to Marlin Firmware. Just my two cents. Imho I think Marlin is easier and faster to use.
@Tom_Nardi I thought you had mentioned you were using repetier. My bad. There is Repetier Host, Repetier Server, and Repetier Firmware, all of which sound synonymous.
Anyways, you could leave the auto leveling on, but the proper way to adjust things is to change the firmware. You can download the Printrbot Marlin from Github. I believe that is https://github.com/Printrbot/Marlin.
If you wanted to change speeds and feeds for your printer it is sometimes better to do it in the firmware rather than through repetier host. Repetier host does not modify the firmware on the machine, but merely the EEPROM. You can find the best speeds using Repetier, but I would suggest updating your firmware as well. It would also pay to check if the Marlin on the Printrbot supports EEPROM from the box.
