Dim3nsioneer

@Illuminarti: 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...

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...

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. 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.

You could have printed the fireworks... :smile: The same to you!

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...

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...

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. 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...

Yes, exactly. Thanks!

Here is some update. In order to check / rule out the electronics, I swaped the x and the y axis, i.e. the x motor was driven by the y stage and vice versa. The original deplacement along the long edge is significantly smaller (green arrow). However I got a new displacement in x-direction (red arrow). Thus, it's rather not the electronics as the major displacement is still in physical x direction (actually in direction of the fan). I also measured the temperatures of both x and y motor with an infrared thermometer. While the x motor was something like 48°C warm, the value for the y motor was 55°C or even a bit higher. A quick look at the stepper drivers showed that they have indeed a different setting. Wasn't there once a page in the Ultimaker wiki showing in which direction you have to turn to increase the current? Can't find it anymore...

Sounds as if the number of steps per mm is wrong in the firmware. I guess, you compiled your own version of Marlin or built it at marlinbuilder.robotfuzz.com? If it's the second, check the number there; it should be 8/3*200=533.33333 (as long as you use the standard z thread and motor). If you have an Ulticontroller, you can check there. EDIT: You can also use the M92 code in your start.gcode (UM1, correct?)

This is the result of the hollow version: The difference is that there is only one step instead of three (one right, one left and another one right). I listened to the z stage again. No real difference audible. That one was false alarm. @znib: I use Cura 13.12. And I have a Marlin version compiled on marlinbuilder.robotfuzz.com. Therefore I also did a quick check with the standard firmware uploaded by Cura today: same result.

:angry: This is not fair... After having installed belt tensioners for both (x and y) short belts, I get wonderful prints in really high resolution - with the same crappy step!!! As I had to remove some cables I even decided to separate the x motor cable from the extruder cables in order to eliminate the extremly unlikely possibility of cross-talk between the two... as you can see, I'm slowly running out of ideas... While this print was running I listened to the printer. I had the impression (very biased!) that the z step sounded differently at exactly the height where the troubles begin. It was kind of smeared, longer than the usual 'zac'... Letting the z stage make 0.1mm steps brought no real news. The steps do not sound the same for one rotation. But none of them really sounded as strange as during the print. Any other ideas?

This is a quite nice overview of some patents expiring within the next few months: http://3dprintingindustry.com/2013/12/29/many-3d-printing-patents-expiring-soon-heres-round-overview/?utm_source=3D+Printing+Industry+Update&utm_medium=email&utm_campaign=521adf4ddf-RSS_EMAIL_CAMPAIGN&utm_term=0_695d5c73dc-521adf4ddf-64418853

Although I can only 'see' the non-roundness of the holes with calipers it's certainly worth a try. And it will feel good to print something else again than just the same puzzle piece over and over again... :roll: Thanks for the moment! I'll give you feedback as soon as the belt tensioners are in place... Maybe Ultimaker gets rid of the short belts for the third generation printer...? Does the UM2 have short belt tensioners included?

I thought of that too. Indeed I had some non-round holes in the past and still got sometimes small spaces between shell and infill (only at some spots, not everywhere). However I would expect backlash to show up as well when rotating the print by 90°... I have belt tensioners for the long belts. They are really tight and make exactly the sound the should when picked (as shown in the Ultimaker video). So far I haven't seen a good solution for the short belts and in the middle to long term I plan to implement a direct drive. I think the short belts are not an ideal design.

Yes to the first and no to the second (actually not yet, the parts are waiting to be assembled and some of them to be manufactured)...

Some additional information: - The print with solid infill every 5 layers looks the same as all the others: deplacement begins a the height where part of the model gets a solid infill - The print with 100% solid infill also has a deplacement. But it begins where the model gets narrower.

Thank you for confirming the general existance of this effect! I guess this model shows it much better than other models such as figurines or similar... If it's possible it would be interested to know if in your prints the effects is stronger on the fan side (assuming you only had one from one side...) I have the impression it is strongest on that side... Uuh...you're going through a very hard time then... without any printer... :smile: No, seriously... as I understand, you have both Ultimaker models, correct? If your original Ultimaker model still has one fan it would be a very interesting comparison between the two... I'm right now doing some more tests. Just for really, really, really making sure Cura is not responsible, I sliced the part with Slic3r and got the very same result. Doing the infill before the shell (possible in Slic3r, not in Cura) didn't change anything either. The same goes for adding 0.06mm filament after each retraction (equal to about 10mm printed filament at 0.1mm layer height). It just gives more stringing and over-extrusion. Right now, I'm trying the print with a solid infill every 5 layers in Slicer. After that I think I'll do a 100% infill print. BTW: There is no difference between 0.8mm and 1.2mm shell thickness...

In the meantime this is becoming a case for CSI Ultimaker I guess... Yesterday, I did a few times the same print at different locations on the print bed. It turned out the effect ist strongest on the right side of the print bed and weaker on the left side. It also gets stronger towards the back of the bed. I've scaled the model in z to 2/3 in order to check if the displacement also changes height. It stays relative to the model, i.e. it was happening at 2/3 of the original height. This is actually the only thing that is clear to me so far: it must have something to do with the rectraction. The deplacement starts on the first layer where the first retraction with a significant move in between takes place between the larger and the smaller structure of the print. And it seems only to happen when the retraction goes from the small structure to the larger one (underextrusion-theory). As suggested by Illuminarti, I also deactivated combing and set the minimum travel distance for retraction to 5mm. It looked exactly the same as with coming. Next test was to leave z dimension as it is and to scale x dimension by 2 and y by 0.5. The size of the displacement stayed about the same (no scaling). I then mirrored the print along the y axis. What I got was a (smaller) displacement at the small structure and no displacement at the large structure. Next try was to print the model on the second extruder with the same filament. The result was the very same as for extruder one. Thus, it's nothing related to a single extruder. The final test was exchanging the filament to Colorfabb which is known to have a diamenter between 2.80mm and 2.85mm (i.e. reasonably thin to fit through the Bowden tube). The displacement was even more pronounced in this print. When looking a this very distinct pattern of this last print I decided to check what's really different on the layers with displacement. I found that on these layers Cura, first lets print the shell of the small structure, then the shell of the large structure, then the infill of the small structure and finally the infill of the large structure. Below the height the displacement starts, there is only one shell for both structures. On these few layers above the first displacement zone and below the second displacement zone, it first prints the shell of the larger structure and then the shell of the smaller structure. I'm beginning to wonder if my Ultimaker does something which really no other does (bad airflow?) or if this is an issue that will occur on every Ultimaker. So if someone else would like to print this model, I would appreciate it. Please just print the part no. 2 exactly in the way Cura aligns it.

Make sure you have set the units in Blender to 'metric' instead of 'none'. If it's set to 'none', Blender will use so-called Blender units. I think, one Blender unit is something very tiny like 0.1mm or even less. If you use Blender usually for creating 3D models then it's recommended to change this setting permanently by saving it in the startup-file.

Kann ich leider nicht so genau sagen, da ich einen UM1 habe... Der G-Code lautet M106 Sxx wobei xx eine Zahl zwischen 0 (0%) und 255 (100%) ist. Da gibt's glaub' ich noch kein Plugin, dass das macht. Würde aber gut ins TweakAtZ passen (gute Übung?).

TweakAtZ 3.0.1 verwendet den RepRap-GCODE um seine Infos zu bekommen. Funktioniert beim UM Original, nicht aber beim UM2 mit UltiGCode. Dieser GCODE hat keine Infos zu Temperaturen drin, da der Benutzer dieses Einstellungen direkt am Drucker wählt. Um das Plugin trotzdem auf einem UM2 nutzen zu können, muss in Cura in den Maschineneinstellungen der Flavor von UltiGCode auf RepRap umgestellt werden. Danke für den Hinweis. Da ist wohl eine Version 3.0.2 fällig, die den UltiGCode 'abfängt', d.h. wenigstens nichts dummes anstellt wie Temperatur auf -1 setzen. Generell dürften die meisten Plugins Probleme auf einem UM2 mit UltiGCode machen.

Hi Sander I'm a bit confused... :wacko: Could you please give some more details which printers are affected? UM Original and/or UM2? Direct print via USB or from SD Card? Is the bug actually in Cura or Marlin?

Meistens hilft es (bei neueren Versionen jedenfalls), Cura rasch zu schliessen und wieder zu öffnen. Subjektiv würde ich sagen, man konnte früher einen Hot-Swap (d.h. während der Ausführung von Cura) bei den Plugins machen, was heute nicht mehr geht. Scheinbar wird der Code schon mit Cura zusammen geladen (geht dann beim rechnen wahrscheinlich schneller). Nimm Dir doch einfach mal ein einfacheres Plugin (z.B. das PauseAtZ) vor und schau es Dir an. Speziell ist eigentlich nur der Header, wo die Angaben über die Eingabefelder etc. drin sind. Der Rest ist 'normales' Python-Schreiben. Für den Header-Inhalt findest Du ein paar Angaben http://wiki.ultimaker.com/How_to_write_a_Cura_plugin(falls Du die Seite noch nicht entdeckt hast). Falls Du Dich mit dem GCODE noch nicht so gut auskennst, findest Du eine Übersicht über den 'normalen' RepRap-GCODE http://reprap.org/wiki/G-code. Die Anführungszeichen sind deshalb, weil der Ultimaker2 einen erweiterten Code-Satz (namens UltiGCode) verwendet.

Fast alle in der Ultimaker-Wiki aufgeführten Plugins kranken leider an einer Änderung im generierten GCODE, die mit Cura 13.06 eingeführt wurde. Aber es gibt Abhilfe: http://umforum.ultimaker.com/index.php?/topic/2454-cura-13064-plugins/