I printed the puzzle pieces and had exactly the same problem, of everything I have printed this is the first time it has showed up. Tried several settings including reduced speed and had the same problem. Will try further tests over the weekend. Hopefully an answer can be found.
Have you looked into the wall thickness ?
I like to print most of my objects with a thick wall 1.5mm or more, this gives it more rigidity when sanding the part,
and I noticed when I forgot to add the thick wall, there was also a step in the outer wall, when the layer went from a more solid infill to a more hollow print.
thanks zeno... ill give that a try tomorrow... have a nice model i can test it on !
Ian :-)
Wow! I used your gcode exactly and... I got the same problem as you! My previous test was on the UM2 but I'm thinking it might be a slicing issue.
I added arrows. The blue arrow shows the path before the displacement and the green arrow shows it after. I really don't think this is a temperature issue because it's shrinking on the short length, not the long. I think it's play/blackslash due to change in approach side of the wall. I'm wondering if my slicing settings swapped directions here - potentially because I had 1 more or fewer shell layers it may have reversed direction? That doesn't make sense. Or 20% versus 24% fill may have ended up at a different spot. Anyway I never delete anything so I can try:
1) Use my settings and slice up your stl (I don't have your short stl though - please post somewhere)
2) Look at the gcode for the print I printed (using repetier host - wonderful visual viewer for gcode) on the UM2 that came out fine
I might not have time to do any of this until tonight.
Dim3nsioneer 557
First of all, having a look at the last few posts is quite impressive. Within last 24 hours this has changed from being an issue of just one machine to something more general.
Have you looked into the wall thickness ?
I like to print most of my objects with a thick wall 1.5mm or more, this gives it more rigidity when sanding the part,
and I noticed when I forgot to add the thick wall, there was also a step in the outer wall, when the layer went from a more solid infill to a more hollow print.
I made it again with shell thickness 1.6mm. It worked for the model of which gr5 just posted a picture! I then tried it for the original troublemaker: The displacement might be a bit smaller, but is still there. The same with shell thickness 2.0mm.
Wow! I used your gcode exactly and... I got the same problem as you! My previous test was on the UM2 but I'm thinking it might be a slicing issue.
I added arrows. The blue arrow shows the path before the displacement and the green arrow shows it after. I really don't think this is a temperature issue because it's shrinking on the short length, not the long. I think it's play/blackslash due to change in approach side of the wall. I'm wondering if my slicing settings swapped directions here - potentially because I had 1 more or fewer shell layers it may have reversed direction? That doesn't make sense. Or 20% versus 24% fill may have ended up at a different spot. Anyway I never delete anything so I can try:
1) Use my settings and slice up your stl (I don't have your short stl though - please post somewhere)
2) Look at the gcode for the print I printed (using repetier host - wonderful visual viewer for gcode) on the UM2 that came out fine
I might not have time to do any of this until tonight.
Thanks for testing the file. I think it's important to know it is nothing mechanical or an issue of the electronics hardware.
If you want to slice it yourself and test it: here is the stl. I'll be happy to see the result when you slice it yourself with your settings.
I also had the idea it might have something to do with the number of travels on the x axis. I had the impression it's printing it differently on layers with an odd number of travels compared to layers with an even number of travels. But this is much more guessing than knowing.
At the moment it looks to me as if there is something in Marlin causing this. I wouldn't call it a bug; maybe it's a feature which makes absolutely sense for something completely different. If it would be really a slicing error or similar, the probability it comes out exactly the same for Cura 13.12 and Slic3r is relatively small (but not zero of course). But with a nice gcode viewer such as gcode.ws or repetier host or whatever you prefer, one should see a difference between the layers if it is a slicing error.
So we may need a volunteer who has a look into Marlin to check if something in there could cause such an issue...
Please send me the gcode that also failed for George, and I'll try that exact version, too. I do have a thought about what might be happening firmware-wise...
What version of Marlin firmware are you using, Stefan?
interesting if we have spotted a sneaky little bug in the firmware...
Dim3nsioneer 557
What version of Marlin firmware are you using, Stefan?
Ginge's Marlin Builder version, dual extruder w/o heatbed
The gcode for the orange print I did with picture above is here:
https://dl.dropboxusercontent.com/u/15273556/ultimaker/gcode/VersatzTest1a_0103_13.gcode
Ok, I tried printing the gcode 6 times now, with some firmware changes... but to be honest, the 'wrong' effect is so subtle on my printer, that I can barely tell whether right/wrong better/worse between prints.
It looks like what happens on the lowest layers is that the little joining piece is thick enough for all of the perimeters around the bottom to print as continuous loops. And on the top part, the islands are totally separate, so again each of the three rectangles gets its three perimeter loops printed one after the other.
In between, the little bar joining the smaller block to the other two becomes so narrow (because is slopes to a point) that the two inner loops can be printed continuously, but there isn't room for three loops in that bar. So the outer perimeter gets drawn around the smaller block, and then it travels over to the larger side, and draws the outer perimeter there.
So only on those few layers where the joining bar still exists, but is less than 3 lines wide, does the outer perimeter on the bigger side get drawn after a long travel move from a different part of the print, rather than after a tiny move from an adjacent loop of plastic.
I think that is experiencing some backlash, and so there is an outward displacement of the line... but I'm still looking at it.
There are 2 issues:
1) You have some play (and so do I - in the long belts on my UM1).
2) The outer surface of the rectangle on the right is always drawn starting at the left corner in this picture and proceeds to the right. But sometimes the edge before is an inner skin on the same rectangle and sometimes it is the yellow square to the left that is drawn just before the outer edge of the right rectangle.
When you sliced you did skin 1.2 and it somewhat randomly ended up with this horizontal "groove". When I sliced it I did 0.8 so there were 2 skin passes (instead of 3) and this changed the order of these 2 yellow rectangles so that for my print they were always perfect.
So one fix (for this part only) is to do walls/skin 0.8mm thick.
A better fix is to tighten your belts. You have to tighten both short and long belts. You said your belts were extremely tight but did you mean short or long?
edit: fixed who did 1.2mm and who did 0.8mm.
oops - I had it backwards. I did 0.8mm walls - you did 1.2mm walls. But that is one of the main differences that affected this print. This is fixed now in above post.
When you reversed the 2 axes you got a mirror image because the problem is a combination of 2 issues - not one. Both of your axes have play. But only one tiny area of this part/gcode shows a "nasty displacement" because of the slicing and the order of how it approaches one small area of the part.
Dim3nsioneer 557
Case solved!
(sorry for shouting... :eek: )
First I would really like to thank all of you who helped me finding the way to this extremely satisfying moment for the last two weeks!
This is the solution:
gr5 was actually right, but he was wrong... :wink:
As I wrote earlier, sometimes you first have to make a situation worse to make it better in the end. This is exactly what I did today. After finishing four times two Ultimaker Wiki Calibrate page.
The print I made after this was the one with the absolutely worst displacement I got for the last few weeks! The shift was nearly 1mm! I didn't had to think very thoroughly what was wrong as I had realised the print head needed a tremendous force to be moved.
So the next step was to make the long belts rather sloppy. I just tensioned them enough that they will not slip on the pulleys. The result you see above.
So my problem never was too much play. I actually have some now which results in an increased wobble from layer to layer. However, this wobble is magnitudes smaller than the displacement I had before. I didn't have enough play with the belts tensioned too much. Thus, the video on the Ultimaker page is absolut nonsense in my opinion! If you put that kind of tension onto your long belts, you'll get exactly the troubles I had...
I have to add that the tension on the short belts is still quite high. I will not lower it as I know I'll get troubles doing so.
Great to see that you finally got it working. I've felt bad about not contributing to the solution but I have to admit I felt a bit lost on this one, I have followed every single post though
Wow. I added "solved" to the topic title. I'm very musical so I listened carefully to the video and the belts are quite loose in that video. They are *barely* tight enough to make an audible note. Mine are pretty loose also. The UM2 however has quite tight belts.
Anyway - I really don't see how having "too tight" belts caused this exactly. I guess there was so much friction that the motor would move an additional .3mm but the pulleys (and head) would stop before moving that last little bit? That must be it.
OH WAIT - there's a new video. I was talking about this older video that ERIK HIMSELF made. The newer video shot vertically with a smart phone doesn't tell me *anything*. It could be amazingly loose and the person is just barely lifting.
Dim3nsioneer 557
Exactly. The old video was ok. The new one is - uhm - suboptimal...
You're right. And the additional friction was a result of the high tension. Anyway, these kind of belts are form-locked. There should actually be no need for a high tension in contrast to a V-belt.
As I wrote earlier, sometimes you first have to make a situation worse to make it better in the end. This is exactly what I did today. After finishing four times two Ultimaker Wiki Calibrate page.
Glad everybody is happy with the result!! :-P
But I like to make an off topic comment on the above mentioned and printed banana tensioners.
I use them myself, but at night when I can't get to sleep, I dream about a better tensioner.
These tensioners have the bad habit to lift the belt, so its out offline, I mean the beltparts are not parallel anymore.
Therfore while moving, the tension changes.
Perhaps the tension equals itself left and right, but than the corresponding 6mm shaft has to disalign itself.
In my (humble) opinion, you need two parallel parts. so a tensioner almost as the original one, but than with a banana like construction in the centre ( where now that little wooden tensioner is) To be adjusted separate from the 6mm shaft clamp.
Making any sense? what's your opinion?
Dim3nsioneer 557
To be honest, after that adventure I'm rather thinking about a way to get rid of all belts... but you're right about the banana tensioners. However, mines are nearly not used at all right now...
I also don't understand how too much tension can cause this displacement, unless your motors are loosing steps, but this should be audible. Anyway, glad you found a solution. :-)
As for the belt tensioners: I use these http://www.thingiverse.com/thing:17058
They are simple and work perfectly for me. And because they don't have any moving parts, you never have to re-adjust anything.
Dim3nsioneer 557
I also thought that the motor should skip and I would hear it. Obviously not. Or I'm deaf... :wacko:
Recommended Posts
Top Posters In This Topic
28
23
11
6
Popular Days
Dec 28
12
Dec 31
11
Jan 3
10
Jan 6
10
Top Posters In This Topic
Dim3nsioneer 28 posts
gr5 23 posts
illuminarti 11 posts
znib 6 posts
Popular Days
Dec 28 2013
12 posts
Dec 31 2013
11 posts
Jan 3 2014
10 posts
Jan 6 2014
10 posts
Dim3nsioneer 557
Although illuminarti already had a look onto one of the gcode files (and didn't find anything suspect), I'll send you a link in a PM. As physicist, I believe in statistics... (well, mainly the statistics I faked myself... :grin: )
@Ian: I've a similar problem. I actually want to use my Ultimaker to produce prints for other people (let's call them customers) in a not to distant future... so I'm running out of time. Timeline says, the case has to be solved a.s.a.p. I know, reality sometimes says something else... :(
But as I see it, you have a slightly different problem. It looks as if the print gets larger all around it and is not shifted in one direction. However, it looks as ugly as my displacements... :wacko:
Link to post
Share on other sites