tinkergnome

Es steht bei Beiden leider nicht dabei, aber ich gehe mal davon aus, das von SD-Karte gedruckt wird? Hast Du für die Problemfälle mal kontrolliert, ob die gcode-Datei auf der SD-Karte überhaupt vollständig ist?

I bet the gaps are also visible in the layer view of Cura, aren't they? Have you tried to (re-)set the shell thickness back to 1.0? How looks the layer view then?

Simple explanation - UltiGCode-flavor is not supported during autostart. The reason for your observation is probably the lack of proper start-gcodes. RepRap-flavor should work better...

Both is correct AFAIK. There are nice instructions and pictures in this thread.

Don't worry. I've double checked it. The sdcard that came with my printer (11/2014) does not show the "I". It's exactly the same model (from the link). So i'm pretty sure that UHS-I is not necessary.

I'm pretty sure that mine printer was delivered with this one. It should do the job and is quite cheap now.

Some important facts are still lacking... - which printer? - printing speed? - fan? - layer height? - nozzle diameter? General advices are: - try to print a bit cooler (nozzle 245°C) - bed temperature is little bit low for XT, try 75°C - try to print slower - use more fan - try to vary the layer height

Das mit dem Abluftschlauch solltest Du auf jeden Fall in Erwägung ziehen. Der Geruch ist ja nur ein "Nebeneffekt". Soweit ich weiß, sind ABS Aerosole als gesundheitsschädlich bekannt und das Einatmen sollte vermieden werden. In den Abluftschlauch gehört auch noch ein spezieller Filter, ich hab mich aber nicht wirklich intensiv damit beschäftigt, weil ich ABS für mich recht schnell ausgeschlossen habe... Auf deinem Bild vom Druck sieht es einfach nach mittelschwerer "Underextrusion" aus... Also ist möglicherweise die Druckdüse (teilweise) verstopft, oder es wurde zu schnell oder zu kalt gedruckt. Außerdem ist für ABS zu viel "Lüfter" nicht gut. Das wird, wenn es geht, ganz ohne Lüfter gedruckt - oder zumindest so weit wie möglich reduziert. Was hast Du für einen Minimalwert eingestellt - und ab welcher Höhe - passt das zum Fehlerbild? Dieses Modell hat ja viele "eklige" Überhänge, da wirst Du ganz ohne Lüfter nicht auskommen - ich fürchte, das geht nur mit "rantasten" um den besten Kompromiss zu finden...

Perhaps this one...? 9,50 EUR per meter and 7,00 EUR for DHL is still reasonable, isn't it?

The name of the macro has changed in recent versions of avr. Look for "ISR(TWI_vect)" instead. The location of the file is also different, for V1.6.0: ..\hardware\arduino\avr\libraries\Wire\utility\twi.c BTW: i had no success with the V1.6.0, and had no time to find the reason until now. Consider to downgrade your compiler to V1.0.6 if you run into other problems.

1. The primary reason for underextrusion is too much (back-) pressure in the nozzle. The possible extruded volume per second is limited by the nozzle diameter. The feeder will skip back, if the pressure becomes too high. Increasing the flow rate would increase the pressure any further... That's why the general advise is to increase the temperature instead. Higher temperature leads to a better flow and reduced pressure (and automatically: increased extrusion volume). Only if the diameter of the material is much less than expected, increasing the flow rate would help to avoid underextrusion. But this circumstance is very rare compared to the former. 2. Of course the amount of extruded material is higher for thicker layers. This is a part of the calculations of the slicer software. But - as stated above - the volume is limited, that's why you can't reach the same printing speed as with thinner layers. Don't worry too much. Most of this stuff is very logical...

Hi swordriff, the ordering worked well, i received the "Thank you for your purchase" message. But now i have an automatically created PayPal account (again... :() This is a point i'm definitly not amused about... For the wishlist: Please consider other payment methods. Howsoever...i decided that the Olsson block is more important than the hassle with PayPal...

Referring to this: only initialized variables can be placed into program memory area It seems that these warnings are false alarms (fixed in newer versions of the compiler) - should be fine to ignore them. It's very hard to brick the board by a firmware upload. As long as the bootloader is functional - you can ever install a new one... Of course one can damage other hardware... if you program weird moves for example.... but those things are fairly unlikely. A huge part of changes one can test (and debug) with the simulator. AFAIK the development was made by daid. I found these sources to get it up and running: Marlin Simulation... on your desktop?!? (For developers) Missing note about how to compile and run the simulator But as a conclusion: once you have the hex file: Go! Give it a try - no risk, no fun

You can download the source files from GitHub or use git to clone the repository. There is a "Download zip" button on the GitHub page. This would always be the ... mmmhhhh... let us call it ... "the latest development version"... The sources for a specific release are downloadable from the "releases" page. The simplest way to create a hex-file: just feed the Arduino environment with these sources... I use the Arduino release 1.0.6 (have not tried the recent version) - download page is here. AFAIK daid still uses the version 1.0.3 (so - one of these should be fine...) First step is to "fiddle" with the twi.c as described in the link from your previous post. In V1.0.6 the line starts with "ISR(TWI_vect)" - but the rest is the same (just comment out or delete all lines from there on). Then start the Arduino environment and select the "Arduino Mega 2560" from Tools->Boards. Now an important detail: Select "File->Preferences" and switch on the option "Show verbose output during compilation". From the (downloaded) sources load the file "Marlin/Marlin.ino" and select "Sketch->Verify / Compile". If nothing went wrong the hex file is created in a temporary build folder - you can see the filename near the end of the messages. Copy and rename the hex file for your needs and use Cura to upload it to the printer. Another approach: The descibed method is very inconvenient if you change little things (and compile) often... I borrowed the "package.sh" from the Cura sources and use it together with mingw32-make to generate the hex files. But you would first need mingw and for a Windows OS additionally CygWin, or GitBash, or ... something similar... And centainly you will have to adjust some of the paths in "package.sh" The "package.sh" and the "Makefile" are included in the Marlin subdirecory. More efforts in the beginning - but more convenient after that... Happy coding! (and if you get stucked - just ask)

The sprintf function composes a string from the given arguments (aka: replaces all occurrences of %i with the following parameters - sequential). In this example the last parameter is the Y-coordinate for the G1 gcode command: sprintf_P(buffer, PSTR("G1 F%i X%i Y%i"), int(homing_feedrate[0]), X_MAX_LENGTH/2, 10); and Line 2224...? You are too slow... It's moved down to line 2391 - at least until the next commit.. Just search for "Y10" - there should only be one occurrence in this file: enquecommand_P(PSTR("G1 F12000 X110 Y10"));

The easiest way... depends on the direction of the needed offset... If your new position is inside the (hardcoded) min/max values (0 - 230) you can probably set a homeing offset with a M206 command - and store it with M500. Elsewise you have to change these limits in the Configure.h and compile your own firmware variant first (also negative values are allowed). #define X_MAX_POS 230 #define X_MIN_POS 0 #define Y_MAX_POS 230 #define Y_MIN_POS 0 But wait a minute... i just took a look at your gallery. I guess you just lose a few millimeter of the "reachable" printing area, or do you have modified the position of the endstops too? Wouldn't it be sufficient to change the buildarea in the slicer? I'm afraid, i missed something...? Edit: finally i found the source of your question... nice project The "HEATUP_POSITION" is only 5mm away from the front and the same applies to "BED_RIGHT_ADJUST_X" Setting a homeing offset would solve this problems - but leads to others. You could not use the coordinates between zero and your offset and i see no way to teach the slider this circumstance... As a conclusion - you have to modify these positions in the firmware (yes - i know that you suggested this first...) Here are your directions: HEATUP_POSITION_COMMAND - increase the y-value the same here (front position for material change) BED_RIGHT_ADJUST_X - decrease the x value a little bit further and decrease the X/Y max values in the Configure.h too. That's a piece of cake, trust me..

Sounds good! Just a short status report from my side: Ready to go - only one tiny item missing yet...

No, if it displays 60 it is capped at 60 (IMHO). It seems that "someone" has changed this configuration setting on your printer. It's not very difficult to send a M203 command via pronterface...

Dem Dank würde ich mich gern anschließen. Das mit der Sammelbestellung war eine gute Idee, so hatten alle was davon... ...und apropos rantasten: Ich habe auch festgestell, das ich für Colorfabb XT die Temperatur vom Druckbett auf ca. 90°C "aufstocken" muss, damit der erste Layer hält. Wenn der aber erstmal liegt, kann man wieder auf die üblichen 75°C runterregeln (aber nicht weiter! ). Da löst sich nix mehr ab. Das Beispiel oben ist so entstanden.

Hast Du die Druckgeschwindigkeit angepasst? Fastprint geht beim Infill auf 100mm/s hoch, das sind dann 12mm3/s. Das schafft der UM2 nicht (zumindest nicht mit der 0.4er Düse...) Bei 0.3 Layerhöhe kannst Du mit max. 80mm/s drucken - aber dafür muss zusätzlich die Nozzle-Temperatur nochmal deutlich nach oben geschraubt werden - für PLA z.B. auf 230°C. ...oder reduziere die Druckgeschwindigkeit. bis das "tock tock" aufhört - einfach rantasten.

Hallo zusammen, ich drucke zwar kein ABS, aber ich habe auch festgestellt, dass im Vergleich zur Glasplatte die Temperatur mindestens 10°C höher eingestellt sein muss, sonst haftet da gar nichts... Das ist zwar mit Colorfabb XT kein großes Problem, aber ich hatte irgendwie das Gegenteil erwartet....? Wenn der erste Layer aber erstmal liegt, sieht's gut aus. Ich hab mal ein "Problemteil" ohne Brim ausprobiert - da hat sich bis in die Ecken nix abgelöst. Das ist neu.. Zur Reinigung ist doch in der "mitgelieferten" Anleitung von Spiritus oder Isopropanol die Rede - und nur bei kalter Druckplatte. Ich hatte nur Bioethanol da, das geht offenbar auch.

Das kann gut sein. Es gibt da schon eine gewisse Logik... Mehr speed = mehr flow = höhere Temperatur notwendig Und umgekehrt: wenn man sehr langsam und mit geringer Layerhöhe druckt, reichen oft auch schon 190° für PLA.

In case of an Ultimaker2 - i would say - yes - indeed... It's pretty hard to notice any differences at all - but for sure no drawbacks so far. I would first follow the suggestion in the thread you've linked. Export the used profile settings from both Cura versions and compare the .ini files. Maybe other printers are running earlier into problems with frequently changes of the printing speed/flow rate? Set all the advanced speed settings to zero and give it a try.

Hallo Polle, willkommen in der neuen Welt...! Auch wenn Du es Dir grad noch nicht vorstellen kannst, das funktioniert schon so, wie es auch sinnvoll ist. Für den Drucker ist die Materialzufuhr letzlich auch nur eine Achse, die einen bestimmten Weg zurücklegt. Und selbstverständlich wird beim "Slicen" auch dafür der Weg passend berechnet, damit am Ende das richtige Volumen die Düse verlässt. Abgesehen von "Nozzle size" und "Layerheight" ist dafür übrigens auch der Durchmesser des Materials wichtig - und wird von Cura auch in die Rechnung einbezogen. Mit den Einstellungen am Drucker ist es so ähnlich. "Speed" ist ja eine prozentuale Änderung und gilt für alle Achsen gleichermassen (auch für die Extruder-"Achse"). Die "Flow"-Rate hingegen wirkt sich auschließlich auf den Vorschub der Extruder-Achse aus (damit wird also allein der Materialfluss prozentual verändert). Eine Möglichkeit, die Geschwindigkeit nur für die X/Y-Bewegungen zu ändern, gibt es am Ulticontroller gar nicht (und ist ja auch nicht notwendig).

That's a bit different... AFAIK there are no special "ulticodes". It's more a problem of a lack of gcodes... The firmware distinguishes between UltiGCode and "classic mode" based on the comments on top of the gcode file, ...and only if one prints from the sdcard. If the ";FLAVOR:UltiGCode" is detected on the beginning of the file, the firmware takes care about the start- and end- processing (based on the material settings of the printer). For example: The first gcode command is not even read from the file until the heatup procedure is completed. It's not possible to initiate the UltiGcode behavior via serial connection (USB) (or any other way). If you ("automagically") would add gcodes for moving, heating etc.., than it would just be another approach to add classic (RepRap) gcode. As a conclusion: to achieve the wanted behavior you had to modify the firmware too.