I mean I'm looking at the red and green arrows on your most recent photo and it looks to me like it goes inwards temporarily and then recovers. If you look at the part in real life is this true? This could be caused by underextrusion for a few layers.
Well I tried to print your puzzle piece and it came out fine. FINE. What the hell. Something strange going on here. I printed it on a cold bed (30C) because I didn't want a hot bed to help out. I printed in green transparent first and that came out fine so I printed it in a solid light blue color and that was fine too. The sides are perfectly vertical except for the "foot" at the bottom. Here's a picture:
I 'feared' it would come out fine... at least we know now what it should look like... :wink:
I'll also test the 50mm/s and 225°C settings. And I just switched back to yellow PLA as the green one has the displacement too but it's less visible on the pictures.
To the term 'displacement': Maybe it's the wrong name. As the geometry changes at half height, it is quite difficult to say if it's a shift or if it becomes narrower.
I mean I'm looking at the red and green arrows on your most recent photo and it looks to me like it goes inwards temporarily and then recovers. If you look at the part in real life is this true? This could be caused by underextrusion for a few layers.
Yes, it's exactly that way. First, the print narrows suddenly for maybe three or so layers and then recovers for something like two layers and then narrows again. Then it comes very slowly back nearly to the original position until the print is finished (this is not visible in the images). However, I would expect a classic underextrusion to show up all around the print. But it's only on one side...
Would it make sense if gr5 sends you the gcode of his successful print to rule out a software problem?
Would it make sense if gr5 sends you the gcode of his successful print to rule out a software problem?
This would only work if he works with Reprap-GCODE and not Ultigcode.
I had some very thorough looks at the code. I checked the x position of the outer shell line for both shifted and non-shifted layers. There absolutely (means up to two decimals after point) the same. I imported the gcode file into excel and calculated the material density (i.e. amount of material divided by travel distance) FOR EACH G1 command (about 12000 lines). All of them are around the same value; they maybe differ by a percent...
I cross-checked the gcode on gcode.ws, which is a very good tool to find positioning or slicing errors. It even has a line thickness estimation which shows the same result for any layer...
In the meantime I also ruled out the stepper driver. Exchanging the drivers of the x motor and the (currently unused) extruder 2 motor led to the same result...
However, I would expect a classic underextrusion to show up all around the print. But it's only on one side...
It depends what is causing the underextrusion. If you are printing too fast and cold the PLA can't get out of the nozzle fast enough and there is a longer than usual delay when asking for "more pla!". So if it is printing slowly for a bit on one side and then speeds up on a longer side, the extursion can't catch up with the faster/longer print line. That's why printing slower fixes many many issues.
Actually this makes a lot of sense in the picture with the green and red arrow. Maybe the green arrow is pointing at an underextruded "slot" and the head was travelling in the direction of the red arrow as it made that slot and in the second half (as it is decelerating) the extrusion finally catches up with demand and the slot gets gradually less prominent and recovers at the corner.
Really Marlin should be smarter and anticipate this and overextrude a bit on the acceleration and underextrude on the deceleration to compensate but in practice this gets complicated as every PLA has different viscosity and every nozzle hole has a slightly different size and I'm sure there are other affects (like the formula would be totally different at different temperatures).
Ok, I'm getting closer...
First, as suggested by gr5, I printed the model with 225°C and at 50mm/s. This is the result:
It looks more or less the same as printed at 210°C. There is no sign of underextrusion during the print. the infill is very solid, no part of it missing (I can post a picture, if someone doesn't believe).
The interesting thing is, that having a closer look at the deplacement indicated by the orange arrows, I found I could stick some very thin foil in behind the lines...
If I look at this print, I have to say, it looks otherwise fantastic. It's an excellent print quality I've not seen so far (the belt tensioners were a quite good investment...) So the overall impression is not the one of a low-quality print, but of a very high quality with one crucial mistake: the displacement. BTW: I began to skip the lower 6mm in Cura as they show no real news...
Having a closer look while printing the next example, I found something very interesting. While on the upper layer (the narrower ones) the printed layer looks ok, on the lower layers (the broader ones) there is a serious gap between the outermost shell lines (of three) and the other two:
So, if my Ultimaker would be a person and not a machine I probably might accuse it to do this intentionally... :wink:
No, seriously: What kind of defect (I start to call it a defect as I think most common-mistakes were exluded already...) could cause this? The belts are tight (the short x belt is so tight that the x motor began to skip when I reduced the current). The gcode seems fine (checked with gcode.ws). I already switched some stepper drivers. This leaves something in the software/firmware (unlikely, as everybody would have the problem), the Arduino, the Ultimaker board, the motor itself and something a haven't thought of...
I guess, my first issue of 2014 will be the last issue of 2013, but with a little bit of luck and help from this great forum, I might be able to solve it.
So, I wish you all a nice 2014! :smile:
And to myself, I wish for a solution of that issue...
Are you sure the gcode doesn't have that gap in it? Can you http://mailto:gcode@fbrc8.com the file to take a look at?
That gap - it looks like play. Usually play comes from the belts but it sounds like your belts are too tight if anything. Play/backlash can come from other things. With power off, place the head near the center of the machine. Then push the nozzle back and forth in X and Y. Does the nozzle move without the belts moving? You might have to hold a belt still to see if there is any play that needs quite a bit of force for it to take affect. If the nozzle moves a distance similar to that gap width in your photo - then that could be the problem. It could come from the bearings in the head. It could come from loose X,Y rods (the two that go through the head). It could come from the blocks that those 2 rods go through. It could be in the print head itself.
I printed it this evening on my UM1, trying to recreate the settings as best I could, and it came out fine also. Looking at the gcodes I generated, You do get some long diagonal moves on those lower layers; I wonder if that's allowing the head to get up to greater speed, and so making it more likely to overshoot?
You might try reducing your travel speed, and also reducing your head acceleration, if you haven't already tried that, and see if it helps eliminate the size differences.
That gap - it looks like play. Usually play comes from the belts but it sounds like your belts are too tight if anything. Play/backlash can come from other things. With power off, place the head near the center of the machine. Then push the nozzle back and forth in X and Y. Does the nozzle move without the belts moving? You might have to hold a belt still to see if there is any play that needs quite a bit of force for it to take affect. If the nozzle moves a distance similar to that gap width in your photo - then that could be the problem. It could come from the bearings in the head. It could come from loose X,Y rods (the two that go through the head). It could come from the blocks that those 2 rods go through. It could be in the print head itself.
I agree, it looks like play. But a very strange kind of play as it cancels out 'on the way back'...
However, I checked a few things:
- I moved the print head to the center (UM off) and checked for play. There is no play. I mean, I can push the nozzle in a way that the flexible parts of the print head begin to deform, but no real play (I've added some spring elements to the design of the dual head in order to make it more sturdy).
- I can move the x and y rod through the print head by 1.5mm with quite some force, but only in longitudinal direction, no way to move it in lateral direction (which is defining the head position). Anyway it might not be a disadvantage to fix that (how? adding some printed spacer at one end?)
- Some time ago (right when this issue started) I also fixed the longitudinal play of the 8mm rods where the pulleys of the long belts are mounted on. I use this nice endcap and adjusted it in such a way that there is only a very tiny play (maybe around 1/100mm) in order not to have friction between the adjustment screw and the rod.
I printed it this evening on my UM1, trying to recreate the settings as best I could, and it came out fine also. Looking at the gcodes I generated, You do get some long diagonal moves on those lower layers; I wonder if that's allowing the head to get up to greater speed, and so making it more likely to overshoot?
You might try reducing your travel speed, and also reducing your head acceleration, if you haven't already tried that, and see if it helps eliminate the size differences.
First, thank you for printing it on your UM1.
I did some tests with different velocities but into the other direction as sometimes it is easier to find the source of an effect by making it worse. I moved travel speed up to 300mm/s. The result was the very same. But I will run a test with travel speed down to 50mm/s.
Consider also cutting the X and Y acceleration and max-jerk settings in half. If you don't save these it will go back to defaults when you power cycle the machine.
I don't see anything odd with the gcode you sent. I see that you're setting your acceleration in the gcode to 5000 for each axis; I'd definitely try reducing that to 3000 (which used to be the default for UM's until fairly recently), and even down to 1500, and see if that helps any.
Things are getting clearer.
First, I tried to print it more slowly. This is the result of the 50mm/s-print (@210°C, 1000mm/s^2 x/y-acceleration, travel-speed 50mm/s as well):
Next try was to print it at even lower speed (25mm/s, both printing and traveling speed):
As you can see, no change. The effect is a bit less visible on the 25mm/s-print as 210°C are quite high for that speed.
After checking everthing again for the slightest play (there is none, really (except the one mentioned above)), I decided to use a special model for further testing. It's a symmetric model (i.e. the same geometry for x and y direction). You can find a description on the first page of this https://dl.dropboxusercontent.com/u/15273556/Ultimaker/Pictures/Displacement%20axes%20analysis.pdf. I will refer in the following to this document. The idea of the model is to simulate a first solid layer zone, a second zone with a reduction, a third zone where the printer has to retract and to travel along more or less just one axis and a fourth zone where the travel distance is about equally distributed on x and y.
First configuration (see page 2) is the standard configuration as any Ultimaker is usually set up. As you can see, the model showed displacements at several spots.
For the second configuration (page 3) I exchanged the plugs of the x and the y motor on the Ultimaker 1.5.7 board (and also the x and y end switches). This is, I guess, the most important result: Within some uncertainties, the effects swaped the physical, i.e. they stayed with the logical axis of the electronics. My conclusion: Whatever it is that causes these displacements, the reason has to be somewhere in between the SD card and the plugs of the motors on the Ultimaker board. It's an issue of the electronics!
In order to narrow it down, I swaped the motor drivers in configuration three in addition to the motors (i.e. each motors is driven again by the driver which drove it in the original configuration). As you can see, it's the same as in configuration two.
After that test, I reversed the changes and printed the model directly via USB instead of using the SD card. It's identical to the original configuration result again.
Unfortunately I cannot exactly determine what the problem is. It may be an issue of the Arduino, of the Ultimaker board or of the connection in between them.
What may also be ruled out is an issue of the firmware. I used two types of firmware. Normally my Ultimaker runs with a firmware compiled by Ginge's Marlin Builder but I cross-checked with the firmware Cura 13.12 installs as the official one.
If you know something to track the error further down, please let me know. Otherwise I think it's time to contact Ultimaker by a trouble ticket...
Excellent work!! It seems to be something about the electronics or firmware - or at least it's not something that is particular to one physical axis or the other. Do you think it's fair to say that it seems to be triggered by longer travel moves?
In that case, have you tried adjusting the X-Y jerk speed, to see if that makes a difference? I don't remember from all the stuff you tried earlier. But irrespective of the speed and or acceleration, the jerk speed would perhaps be the one thing that would remain constant through those tests, and might cause displacement when the head slams to a stop at a corner.
It's more than fair, it's quite accurate... :wink:
To be honest, I haven't tried the xy-jerk yet. At least not with the new model (where I finally can see if something is changing or not). Is that not one of these quite conservative settings (http://umforum.ultimaker.com/index.php?/topic/3695-acceleration-in-marlin/)? Well, I'll check and change that tomorrow...
It defaults to 25mm/s, iirc. You could probably dial it down to about 10 or even 5mm/s. That will reduce the energy that gets dissipated as the head comes to an abrupt halt at the end of those moves. You can change it from the ulticontroller, or via gcode - M205 X10 for 10mm/s etc.
I'd love to see a video when it is printing the "bad" portion. I want to see where it is approaching from an instant before.
[...] Do you think it's fair to say that it seems to be triggered by longer travel moves?
[...]
More precisely: it's related to longer travel moves. At some layers the travel move ends at the place where it shows the shift, at some layers it begins there (alternately).
I'd love to see a video when it is printing the "bad" portion. I want to see where it is approaching from an instant before.
GCODE analysator says it's approaching from opposite of the direction the displacement goes to for the strongest ones.
To make a video of that in which you actually see the printer producing the displacment one would need something like a super-macro-high-speed-high-res-camera which I do not have. I can't see it by eye, I only see the result after some layers.
Update:
Reducing XY-Jerk to 5 doesn't change anything.
A smaller version of the test model (20mm x and y size instead of 40mm) shows the very same effect. Thus it's independent of the travel distance.
Visual check of both Arduino and Ultimaker board showed no visible defect. All contacts between the boards are fine (checked with multi-meter).
I could also exclude pickup from radio devices. I switched off everything except the printer (e.g. WiFi etc.) and it was the same.
weird !....
the only thing that pops to mind is.. that the heater cartridge in the hotend is moving and changing the temp... but then of course that would be not always the same location..... weird....
not really helping... just your problem is starting to annoy me as well... ;-) LOL
Ian
not really helping... just your problem is starting to annoy me as well..
Yes. This is strange as hell. It sounds like play/backlash where the head keeps going. But it is happening on both axes. Could the nozzle just be loose? You tested that already, right? Or did you only check the entire head?
Can you send me your gcode file? I want to just print it exactly as it is - the gcode file. Make sure this isn't some slicing issue. I might have used a different version of Cura or a different setting. Maybe post the file somewhere and then post the link or I can email you directly if you want and you can reply with the file.
I'll print it on my UM Original.
ArunC posted a topic in UltiMaker Cura,
.thumb.jpeg.0b7a05eafc09add17b8338efde5852e9.jpeg)
Dustin posted a topic in Firmware,
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
gr5 2,167
So I'm going back over all your prints again. They look much better starting when you tightened the belts but you seem to have this horizontal line where there is underextrustion and then it recovers. The "displacement" in X and Y seems to be fixed, right? now you get a skinnier couple of layers. I think you are just printing too fast. Lower your print speed to 50mm/sec. My above print was at 50mm/sec, 225C (both green and blue prints).
Link to post
Share on other sites