Trouble printing calibration object (others print fine)

[Ulterior_Motif]

Hi there, I'm new and just playing around right now. I've calibrated my printer per the instructions provided (using the scribe to confirm even height at towers and center). The script seems to work perfectly (looks straight to me)!

When I attempt to print http://www.thingiverse.com/thing:761799/#files the print head starts trying to print a few inches above the bed and then moves in a curved manner, slowly, until it hits the Z tower and presses against it (scary ratcheting sound happens).

When I print http://www.thingiverse.com/thing:763622/#files things seem to go ok.

Does anyone have a hunch as to whats going on?

[mhackney]

Please clarify...

You can print the tugboat fine and then immediately load the calibration thing and print it - without making any other changes - and it attempts to print above the bed?

How did you slice these two models?

[Ulterior_Motif]

I attempted an almost identical calibration model a couple of days ago and had the result described above. I then printed http://www.thingiverse.com/thing:1134277 without problem.

Today I figured there might be a bug in the other model so I attempted http://www.thingiverse.com/thing:761799/#files and again had the results described.

Immediately after I began to print the boat. I just came back down only to notice that I just ran out of filament. However, the print had done a few layers, all of which were looking good.

[mhackney]

Again, please be very clear - have you printed these two models literally back to back with a few minutes of each other and seen these results? If so, can you then IMMEDIATELY print the tugboat and have it print properly?

[mhackney]

Please post the gcode file for the calibration model. I suspect its larger diameter is exceeding the printer's printable area and causing problems.

[Ulterior_Motif]

Thank you for the swift replies. I'll set up a new spool tomorrow (first time ever) and then see what I can do about providing more information.

[Doug68]

Basically I'm having the exact same issue, but with a different file.
I've just printed the 20mm calibration box with a very acceptable result, but when i go to print the next part from my stl file, it starts off about 2" above the plate and then curves off wanting to hit the Z tower.
Attached is the STL file with issues, I've seen the same thing happen with another STL file and I'm wondering if I'm doing anything to stuff the file up along the way?
In matter control the part looks centered and flat on the build plane, so I'm a bit confused. I've been able to print other files of mine in the past.

To me this thread is describing the same symptoms:

http://forum.seemecnc.com/viewtopic.php ... int#p81182

Currently I'm printing out the 3DBenchy tug boat which has started off very well by the look of it.

[Xenocrates]

Try looking at the layer view and see how that looks. Also, Netfabb can help with weird models, and if you hit Arrange under edit in MC, it helps resolve a lot of the odd things, like getting an annular raft for a dome object. I suspect it's not so much a printer error as a slicer bug. Which slicer are you using, and is it standalone or no? What is the lowest Z value you have in the G code?

[mhackney]

Is your (both Ulterior_ and Doug68) printer HOMING before starting the print? Also, you do not print an STL file, you must be automatically slicing the STL file behind the scenes. The slicer creates a gcode file that is the program that runs the printer. So either your printer is not homing at the start of a print "so it knows where it is" or your slicer is either not configured properly or doing something odd. Which slicer are you using?

[Ulterior_Motif]

I don't have the details that I promised earlier (I'll play around after work) but I'm using MatterControl with the default slicer (which is labeled as "mattercontrol"). The printer is homing as far as I can tell (it drops to the print bed then goes to work but I can't recall how low it homes on the faulty print. I'll report back).

[mhackney]

Ok. Thanks. Homing would go all the way to the top. Then come down to the bed to print.

[Ulterior_Motif]

Just to clarify, to provide the "Gcode" I should copy and paste from the "Gcode Terminal"?

[Xenocrates]

Export the G-code to a folder or SD card, then post it for us.

[Doug68]

So I believe I've solved my issue as follows...

I exported the G code for the problem part, then did this for a known good part to compare the two.
The first 24 lines down to the first move looked pretty much the same, there was a G28 to home etc. until the first real move which was:

G0 F18000 X2.128 Y-93.569 Z0.3

As you can see Z is 0.3 so should go close the print surface and not 2" above it.
From the console ran a G28 then the above, and wow that's a fast move! But it went to the right place.
So I repeated this a few times and approx. half the time the move went wrong, essentially I think the Y tower could not keep up.
I then repeated the test but with an F of 9000 and got 100% success on repeated attempts.

In MatterControl I changed the "Speed for non print moves" from 300mm/s to 150mm/s for the same effect.

The problem print has started properly at the first attempt after this change.

[Xenocrates]

That's good. Glad you found your issue. Interesting that the standard speed is causing issues for you though.

[mhackney]

Ok, that's a 3rd option I didn't consider - it seems that your printer has slightly restricted travels that are causing the stepper (Y from your description) to loose steps. Check the belt tension on that one and move it up/down manually and feel for tightness or "catches".

Good debugging/detective work by the way.

The short term solution is to lower the max travel feed rates in either EEPROM (safest) or the slicer to lower the F18000. Now that you have a single line of gcode to test in the console, lower the 18000 and test incrementally until you get smooth movement to the proper position.

[NeuroJoe]

I'll second the call to check your belt tensions. I was having the exact same problem as the OP, after spending a few hours trying to research slicer/gcode issues, I saw this post and another about the belt tension suggestion. I checked mine and 2 of the 3 were much too loose (~1 inch of travel at mid-belt with not much force). Tightened them all up to about 1/4-1/2 inch and voila!

Joe

[mhackney]

The other thing I learned in the last week related to this...

If you use Astrosyn sound dampers, they attach to the motor with 2 screws and to the Rostock with 2 screws - unlike stock steppers which attach with 4 screws. If one of those 4 screws loosens or falls out, 3 others secure the stepper. With the Astrosyns, if 1 falls out you have a pivot point that the stepper can rotate around! I literally had this problem last week (posted in another thread here) that caused prints to shift in the X-Y plane unexpectedly. It's a new one to add to the list of print shift issues.

[Eaglezsoar]

It's a bummer to get screwed!

[barry99705]

The other thing I learned in the last week related to this...

If you use Astrosyn sound dampers, they attach to the motor with 2 screws and to the Rostock with 2 screws - unlike stock steppers which attach with 4 screws. If one of those 4 screws loosens or falls out, 3 others secure the stepper. With the Astrosyns, if 1 falls out you have a pivot point that the stepper can rotate around! I literally had this problem last week (posted in another thread here) that caused prints to shift in the X-Y plane unexpectedly. It's a new one to add to the list of print shift issues.

Hmm, wonder if we should use some locktite on these screws? I just put the dampers on my printer Monday, what a difference!

[mhackney]

I did use loctite but after several years this side loosened up.