issues with hot end dragging on print

[mfswords]

Hey guys,
I have a pimped out printrbot simple metal. It has the Z, X, upgrades, the Ubis 13s hotend, and a G2 printboard. I currently call it my 1K paperweight- either that or the 3D printing money pit. I have had it a little over a year. I hope you guys can help me out.

Current problem:
I have an issue with my hot end dragging along the print after the first few layers. I attached several photos to this thread to explain further. Basically after the raft and a few layers in (usually when the infill starts) the hotend seems to not be rising as much as it should, or it is extruding too much. As a result, the hotend is smudging or remelting other layers of PLA, and spreading them outward. After a few layers into the infill, you begin to see the hot end bouncing over my contoured 3D print as it spreads the next layer on a now uneven or cratering surface.

I have tried recalibrating the Z axis to the bed, but the problem is not the first layer. Is it extruding too much? Is the layer height an issue?
Here is a link to the pictures ( this includes prints to show smudging, settings on cura) - https://goo.gl/b1qTgV

I have spent many hours of my life I will never get back working on this issue. If you can steer me in the right direction I would be a happy camper

Here are my current settings:

G-Code settings:
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
M107 ;start with the fan off
G28 X0 Y0 ;move X/Y to min endstops
G28 Z0 ;move Z to min endstops
G29 ;Run the auto bed leveling
G1 Z15.0 F{travel_speed} ;move the platform down 15mm
G92 E0 ;zero the extruded length
G1 F200 E3 ;extrude 3mm of feed stock
G92 E0 ;zero the extruded length again
G1 F{travel_speed}
;Put printing message on LCD screen
M117 Printing...
;G21; Set units to milimeters
;G90; Set absolute coordinates
;G92 E0; Reset extruder

> M501 settings in Pronterface UI

< echo:Stored settings retrieved
< echo:Steps per unit:
< echo: M92 X80.00 Y80.00 Z400.00 E96.00
< echo:Maximum feedrates (mm/s):
< echo: M203 X125.00 Y125.00 Z5.00 E14.00
< echo:Maximum Acceleration (mm/s2):
< echo: M201 X2000 Y2000 Z30 E10000
< echo:Acceleration: S=acceleration, T=retract acceleration
< echo: M204 S3000.00 T3000.00
< echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s), Z=maximum Z jerk (mm/s), E=maximum E jerk (mm/s)
< echo: M205 S0.00 T0.00 B20000 X20.00 Z0.40 E5.00
< echo:Home offset (mm):
< echo: M206 X0.00 Y0.00 Z0.00
< echo:PID settings:
< echo: M301 P22.20 I1.08 D114.00
< echo:Min position (mm):
< echo: M210 X0.00 Y0.00 Z0.00
< echo:Max position (mm):
< echo: M211 X250.00 Y152.00 Z250.00
< echo:Bed probe offset (mm):
< echo: M212 X30.00 Y0.00 Z-0.40

[AZBotr]

My guess is over-extrusion - have you tried to bump down the flow from 100% to 90% just to see if it improves at all?

[RetireeJay]

What kind of thread do you have on your Z rod? The Z calibration value of 400 looks awfully low to me.

[mfswords]

Ill check the thread. It is whatever came with the Z-rod upgrade originally.

[mfswords]

Here is the link to the installation of the Z upgrade- it said change the M92 Z400 because the rod is a different pitch (1/4 "- 16) acme rod.

https://printrbot.zendesk.com/hc/en-us/ ... 5003821043

[RetireeJay]

OK, if you have that 8mm per turn screw then 400 is the right number.
You might want to print a test piece with a known z height to verify that Z is moving as expected.

If Z calibration is good, then your next things to check are the Extruder calibration (steps/mm in the EEPROM) and the Filament Diameter you have in your slicer.

[mfswords]

Ill look at figuring out the height- the only thing is that I am scared of getting it past the few layers or when the infill starts because that is when the hot end begins smudging and dragging on the layer is putting down, which causes the bumping up and down of the extruder and that smashed layers. I don't think I would get far on a print.The filament diamter is correct. Ill check the extruder calibration and get back to you. Thanks all.

[ktfergus]

Also check the set screws on the z coupler, if you haven't already. If they're loose the printer will think it's going up but the z stepper could just be spinning freely.

-Kelly

[cbxbiker61]

Make sure that the hot-end is clamped securely. I had a case where the hot-end loosened up and dragged across the prints until it finally fell out. It put some serious gouges in the bed when it did so.

You have to be careful when tightening the clamping screw...too much torque and you'll strip the threads in the stepper motor. This is really a weak aspect of the design.

I resorted to shortening the screws that come in from the backside of the stepper with a grinder, and then if I recall, I used a 1mm longer screw at the clamp.

The rule of thumb for proper strength in a screw hole it that screw should go into the thread at least 1.5X the diameter of the thread which means in this case 5mm.

[mfswords]

Well I was able to calibrate the extruder motor and it was about 5 mm more than what it should have. So there is some slight over extrusion, but not bad. I was able to print a calibration shape. It was originally to be 40 mm x 40 x 40. x and Y are fine (40 x 40) the height is the issue. It only printed it to a height of 10 mm. So there is something up with the z rise. see pics. as a result of the lack of rising of the Z, I was seeing the extruder motor click.

[RetireeJay]

OK, that makes the problem quite specific.
Possibilities:

1) Your Z motor is skipping steps. Typically when that happens the sound of the motor is a bit jerky or erratic
1a) Maybe there is too much friction for the Z motor to turn the screw
1b) Maybe the drive current for the Z motor needs to be turned up to provide enough power to raise the carriage against gravity (assuming low or no friction).
(You might try "manually" raising Z by using the User Interface, and then measure to see if it actually moves down by 10mm when you give a command to lower 10mm; if there's a lot of friction it might not move 10mm, but if it does move 10mm then maybe the problem is insufficient drive power)

2) As ktfergus suggested, maybe the coupling between the motor shaft and the Z screw is slipping

3) Maybe the Z motor drives the carriage up correctly, but it's drifting down between Z moves. That will only happen if the Z motor is powered down between moves (and if that's the case, the remedy involves re-flashing the firmware to keep the Z motor on).

[mfswords]

I am on a hangup at the moment because I tried Reflashing the firmware on the new F6 boards and they dont have a boot jumper. I made one and hit reset and it didn't reflash the firmware. Then I found a jumper off of an HDD and tried again and now it still wont reflash the firmware. I can't even use it at this point. Any suggestions?

[RetireeJay]

I tried Reflashing the firmware on the new F6 boards and they dont have a boot jumper.

The F6 board definitely has pins for a "boot" jumper.

You install the jumper (I guess maybe you did find one?) and then hit the reset button. This puts the board in programming mode (as opposed to run mode). If you have it connected to a Windows computer, you'll hear the sound for a USB connection lost followed by the sound for a USB connection gained after hitting the reset button. At that point, you use FLIP to find the board, erase the existing firmware, and upload the new firmware. Instructions for a Mac are different!!

It's not intuitive, but (at least for boards up to Rev F4) the board will power-up in RUN mode regardless of whether the jumper is on the board or not; you MUST hit the reset button to enter programming mode. Actually, you could leave the jumper on all the time!

So does your board work at all in RUN mode?

Did you determine that the board NEEDED to be re-flashed, that there were no mechanical issues? Note that you do NOT need to re-flash simply to increase the drive power to the Z motor.

[mfswords]

Edited... I teach as a K-6 STEM Teacher and use 3D printing in my class for a club. That being said, my career is not technologically robust as it might be if I worked with this stuff all the time. I am very wary when it comes to electronics and machine hardware, but I feel more adequate when it comes to software. I think I misunderstood your post as a test of 3 different things and went straight to flashing, hoping it was a software issue.

I do see that there are pins, but mine with the USB - B just did not have a boot jumper or a place where the boot jumper would have been located if it were a micros usb version of the F6 board. Either that or its plugged in and I dont see it. I have looked for it on pictures online and cant see it. I had to get one from a HDD. I tried to reflash it with mac and I keep getting a popup saying that it failed to load firmware. It might be because our district limits the downloads to apple trusted products. I was able to download the updater after multiple tries but I wonder if I am getting the same filter from when it is trying to install. I have done it before with other printerbots and did not have this problem.
The reason it does not work ATM in Cura is that I hit the reset button, as the directions said before importing the firmware updater, so my guess is that it is in "Program" mode at this point rather than "run" mode as you put it. Or is that not how it works? To my understanding, I reset the printrboard, but the new firmware was unable to install, so my guess is that it is either in program mode, or erased. Maybe that is not how the program works though.

I will try to upload the firmware using a PC and send an update.

Thank you all so much for your prompt replies and help in this matter. You are all very patient and extremely helpful and informative. I truly appreciate your help.

[RetireeJay]

As far as any setting on the board that you might have changed via commands from Cura - they are stored in a separate section of memory called EEPROM and you can restore the "factory defaults" very easily. See viewtopic.php?f=18&t=2763

When you turn off power to the board and turn power back on, it forgets all about whether it was in Programming mode, and reverts to Run mode. The only way to get into Programming mode is to hit the reset button when you have power already on, and a jumper on the boot pins. The board is not shipped with a jumper, but the pins are there.

Printrboard F6 Boot pins.jpg

However, checking for mechanical slipping at the coupling between the motor and the Z screw is not electronic and not high-tech. It should be a prerequisite before you resort to flashing new firmware.

[mfswords]

yes- I reread your email after I wrote that gobly goog there and I understood what you were saying after I read it a few times.

[RetireeJay]

If you determine that you need to increase the drive power to your Z motor, note that the "digipots" on the Rev F boards live in their own little world. They do have on-board EEPROM, but it's not part of the Atmel EEPROM, and it's completely divorced from the M500 commands. Each digipot chip has its own little on-board memory.

You can use these commands:
M909 reads the current digipot values (X, Y, Z, and E).
M907 sets (changes) the current operating value, in percent. Once you are satisfied that you have the right operating value,
M910 saves the current value to the digipot's EEPROM so it will be used the next time you turn on the power.

[mfswords]

I tried moving it and it indeed does NOT move up 10 mm when I raise it up OR lower it. It is usually between 2-3 mm raised, which is consistent with the ratio of how tall my print was.

[mfswords]

I keep adding to the Z motor and the power does little to change- still 2-3 mm difference when I move it up 10 or down 10 mm when using the settins you suggested (M907, M910, etc.) I also retightened the Z axis rod coupler so that it wasnt sitting directly on the base of the printer when connected to the Z motor- no change.

[RetireeJay]

That's good progress; now we getting closer to understanding exactly what needs fixing. The symmetry of up and down indicates that probably the problem is not lack of power to the motor.

As you add power to the motor, be careful to check the temperature of the motor after it's been on for 5 or 10 minutes. If it gets too hot to touch for more than 1 second, you've gone plenty far enough and should be able to back off. The Printrbot simply should not need that much power going to the motor. (BTW, the way these stepper motors work, they generate just about the same amount of heat whether they're moving or not as long as they are actually powered up. You can tell if it's powered up by trying to turn the rod by hand; if it resists turning firmly, the motor is on.)

Can you post a picture of your threaded Z rod? With your 400 steps/mm, the slope of the thread has to be pretty steep, and if you actually have a different threaded rod for some reason (not the one that matches up with 400), that could explain everything. When you take the picture, it would be great if you can get a ruler with mm calibrations near the rod. Also, if you're capable of taking video - or really just audio - it might be helpful to listen to what the motor sounds like when you tell it to go up or down by 10mm. It should sound pretty much like the X or Y motors.

[mfswords]

Here is a picture with a ruler in MM and a video link to the sound. I sounds no different when it is rising than when it does with the motors X and Y. https://youtu.be/E2nI0EWWk3Y

[RetireeJay]

It looks to me like you have 5 threads every 8mm.
That's 0.625 turns per mm. At 3200 steps per turn, that's 2000 steps per mm.
So try using
M92 Z2000
M500
and see if things don't improve dramatically.
This is a setting in EEPROM, no need to re-flash the firmware.

[mfswords]

Thanks for the idea for the Z steps per mm! That did the trick. The only issue I have currently is that some places on my bed are easier to adhere to than others, but Ill check that out on my own. Thanks for the walkthrough and troubleshooting guys! At the moment- Case dismissed. Ill do a more complex print and post the results. Very pleased. Now I don't have the most expensive paper weight known to man! And I didnt even need to flash the firmware!

[Buchnerb]

I am also having a hot end dragging problem but I think the cause is different. On Saturday I received the new Printrbot 4 start threaded Z axis rod. In his video's Brook touts as a feature how you can manually move the Z up and down by pushing on it. My problem is it drifts down as I'm printing. I used the Z400 setting they gave and it seems to move 10 mm up when I tell it to. It seems like the motor is releasing after it moves it up for each layer and the vibration causes it to settle downward. Z coupler is tight. I have a rev D board and use Simplify3D for control.

Thanks
Bruce

[RetireeJay]

In your case, you probably need to re-flash your firmware. The firmware that was provided with the old Rev D boards generally turned off the power to the Z motor within a second or two after a move. In more recent days, the bed-compensation activity tends to keep the Z motor powered up. But that's a parameter you can change in the source code. With that very steep thread, if the motor is off then friction is not quite adequate to hold the position in place; you need to keep the motor on.

It may be difficult for you to find a pre-compiled hex file for the Rev D board that keeps the Z motor turned on. Firmware for Rev D is not compatible with Rev F and vice versa; you need a firmware specific for Rev D.

If your software skills are just slightly above beginner level, it's not too hard to create your own version of the firmware (e.g. viewtopic.php?f=22&t=10160, which is long, rambling, and not well-organized but contains a wealth of information) . You don't have to write a single line of code; you just set up the parameters in "header" files. There are several posts in this forum about doing this, as well as some general discussion of the foundational concepts in the Wiki (click the red-beige-white box next to the "Search..." text box).

[Buchnerb]

Thank you Jay.

That delay explains why my very small test piece worked perfectly. It moved up to the next level before the motors cut out but on bigger prints it started dragging the head. Increasing the motor power would not have helped

I think the changing of code is beyond me. I still have the old acme rod. I'll reinstall it and see if PB will accept a return. Too bad because it did move better.

Bruce

[ktfergus]

Hi Jay,

I hope to raise the current for the X axis stepper on my Play & I'm hoping to get clarification on the digipot current commands (there's a sentence I never thought I'd ever write). Per the M909 command, the current current value for X is 2464. I'm increasing 10% at a time so for the x axis I'd type in "M907 x2710" correct?

I also have a question regarding the M910 command. On the RepRap wiki they list the following info for that command:


"M910: Set decay mode
Support FiveD Teacup Sprinter Marlin Repetier Smoothie RepRapFirmware Machinekit MakerBot grbl Redeem MK4duo
No No No No No No No No ??? ??? Yes No
Example
M910 X3 Y5 Z2 E3
Set the decay mode for each stepper controller The decay mode controls how the current is reduced and recycled by the H-bridge in the stepper motor controller. It varies how the implementations are done in silicone between controllers. Typically you have an on phase where the current flows in the target current, then an off phase where the current is reversed and then a slow decay phase where the current is recycled."

If I type in just "M910" without a value will that affect the decay settings?

-Kelly

[RetireeJay]

Here's what I see when I type in M909

Code: Select all

12:20:43.928 : N18 M909*26
12:20:43.934 : echo:Stepper current values in % (Amps):
12:20:43.934 : echo: X:60.00 (16581.82) Y:65.00 (36581.82) Z:60.00 (16581.82) E:55.00 (71054.55)


So if I want to change the current to the X stepper to 5% more, I would type in M907 X65.00
The value in parenthesis should be ignored.

I don't know about that decay mode thing. In Marlin 1.1 which I am using, M910 is simply used to put the desired value into the digipot's own special tiny EEPROM. Here's a line from Marlin.cpp:

Code: Select all

Line 198:  * M910 - Commit digipot/DAC value to external EEPROM via I2C. (Requires DAC_STEPPER_CURRENT)

This assumes you are working with a Printrboard.

[ktfergus]

That did the trick. I used M910 & it stored the new value.

Thanks Jay!

-Kelly