derbroti

Right, just a heads up here and I continue in another thread (here: 21259-um-feeder-scratches-filament. For my second problem I did, and the solution was as weird as the problem: my SD card was half broken 21252-weird-axis-movement-mid-print Sorry if I was unclear: I first noticed the scratching and then took it apart Yes, I even losend the tension screw to the top position to have the level easily pulled. Straight filament works fine I am just worried if I use the automatic filament change that if I do not bend it straight enough it will jam and grind but this is no problem, I change filament rarely and can do the manual insertion. Thankfully that one is solved

I know, but I wanted to keep my settings as the + version increments the eeprom data version and you have to go through the bed levelling again and I wanted to avoid that. "Change a running system as little as possible." But I fixed it... ...tuns out my SD card failed a bit. Only a bit because it works as normal but sometimes when reading it reads just garbage -> so some gcodes were read wrong which resulted in weird movements.

Hi, i just upgraded my feeder+motor to the one used in the plus model. Everything went fine and it prints... for a few layers then then one axis moves to the limit and goes back to the intended position. (In one attempt this resulted in a huge... retraction motion). Any idea what the problem is? Before the upgrade the printer worked fine with tinkergnomes firmware. After the upgrade I modified the firmware by changing the e-steps, extruder directions and some default retract values because firmware wise those are the only differences between plus and non plus (standard height) machines. Worrying that something went wrong I now used the original plus firmware but the result is the same. In the picture I tried to print the speed-test cylinder. The diagonal line is movement from priming to skirt and skirt to print which is fine but the vertical line is where after a few layers the printer moved the Y axis to the front instead of continuing the circular motion (i switched the printer off at that point). I also tried different gcodes with the same result.

I have yet to test the whole thing but so far I noticed a few oddities: first (sorry if this is a repeat): The youtube installation guide tells me to use the washers from the old feeder but neither the video uses them, nor is it possible to use them (the white plastic case collides with the washers if I use them) But that is just a minor thing, my main problem is the feeder itself: First: it scratches the filament quiet deep when I insert it manually using the lever: I know why: the knurled wheel is slightly in the path of the filament, even when the idler is fully out of the way, and I think I get why but it is quite unpleasant when I fill the feeder with filament shavings when changing material. Another thing: When I insert the material manually and it comes from the roll curved: it is impossible to get it to line up so it passes the top guide hole. I have to bend it by hand and force it in. Is there a trick to avoid this? I have yet to try to let the feeder push it up by itself but i am worried that it would also not "hit the hole" and jam. Lastly: The outer bearing of the knurled wheel sadly is a bad one... (I disassembled the feeder to check) and it binds at one position. It feels like a "snap to grid" - it spins freely enough that I think it should be no problem but I was a little disappointed. Update: After an initial test: Besides my complaints: really nice - I started a small test-print with (what I consider) fast settings and cranked the speed up to 140% and it kept going like nothing. With the old extruder I never dared to go above 100mm/s now It feels like a piece of cake. Update2: Well... i jinxed it?! Now I have a weird error where in the middle of the print the machine just moves Y to the front for no reason. :( Fixed: broken SD card (see my other thread).

Go and extended(+) have different branches; std/std(+) are in master. That's why the Cura package.sh checks out different branches. UM2.1 should be the new firmware that will ship with the new Cura 2.1

Are you sure you did nothing else in 3.? I just re-downloaded 1.6.9 and tinkergnomes master and with just editing the three lines mentioned (the detection if clause and the two assignment lines below that) and it works fine. For example in your 1. you had a wrong mainboard define "HARDWARE_MOTHERBOARD=7" instead of 72. Try a clean restart: elif [ -d "/Applications/Arduino.app/Contents/Java" ]; then <- edit here to match the line below ARDUINO_PATH=/Applications/Arduino.app/Contents/Java <- make sure same path as the if and a valid one ARDUINO_VERSION=169 <- version works fine and then the package.sh will work fine with 1.6.9

"/Applications/Arduino106.app" You should use your more recent version 1.6.9 of the Arduino IDE. (tinkergnome, at least for the last release, is using Arduino 1.6.5, and his builds are good - at least no one is complaining ) Please don't, it is bad practice to ignore warnings - often there are harmless but there is a reason that gcc has a switch to treat all warnings as errors

Shouldn't the avr-gcc linker create jumptable workarounds on his own when reaching the 128k limit for the pointers? (trampoline section) Or is there linker-breaking pointer magic in the lcd code?

Some remarks: first of all the plus firmware is merged with the std one (just different options while compiling) - so use https://github.com/TinkerGnome/Ultimaker2Marlin for everything. Well "toolchain"... As tinkergnome mentioned in his repo there is a package.sh script which will build the firmware for UM std, +, etc... On a mac you need to install the Arduino IDE and change the package.sh lines from 43: elif [ -d "/Applications/Arduino.app/Contents/Java" ]; thenARDUINO_PATH=/Applications/Arduino.app/Contents/JavaARDUINO_VERSION=169 Adjust the Arduino to the one you are using You probably need to make package.sh executable (chmod +x package.sh) and you need to create the folders: "resources/firmware/" inside the Marlin folder (mkdir -p resources/firmware). In the package script you can see the only difference in building the firmware for the different types of Ultimaker2s are the environment variables passed to the make command. When it is done it produced *.hex files for UM2, UM2+ and UM2dual.

Sorry, to be pedantic (the german in me you know...) in two threads but: 99 excluding taxes.

99,- (tax excl.)

Wait wait... so you are also selling an extruder upgrade only? http://www.shop.creatr.it/en/um2-spare-parts-and-upgrades/201-feeder-upgrade-ultimaker-2.html Is that the "official" one? On and when I am in your shop, I can only choose between Italy and UK as my country - neither is which I life in ^^

I ran into the same problem (ultimaker 2 but should use the same arduino bootloader...). avrdude -c arduino ... quits with: avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xe1 avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x6e ... avrdude done. Thank you. avrdude -c stk500v2 ... loops with: avrdude: stk500v2_ReceiveMessage(): timeout Finally: avrdude -c wiring ... works fine. Source: http://www.avrfreaks.net/comment/1523081#comment-1523081 "-c wiring is just stk500v2 with DTR wiggle." Edit: Oops... the Makefile includes an avrdude section with he correct wiring programmer argument... I know the topic is super old but I want to give a solution so google can index it and hopefully help others.

Did you update the firmware?

What is on the other end of that cable?! I mean on newer boards jp3 is supposed to be a jumper... shorting 5v and the MS3 input, which has a pull down but is not really capable of being a supply for anything...

Ok, I read through the marlin firmware and the result (if I got it right) is okay. The main loop first reads from serial in a loop until the buffer (8 commands) is full or no more serial communication happens and then from SD again in a loop until card EOF or buffer full. So, if I send too many commands fast enough, I could fill the buffer with serial commands (as they will be read first) and starve the SD communication and make my print fail... ...this should be unlikely because generally, when just occasionally sneak in a command it should work fine as the serial loop would stop and it can happily fill up the buffer with SD commands.

Hi, the topic basically says all: Is it possible (honestly not tried yet...) or better asked can it lead to problems (too much traffic for the little atmega to handle?) when I try to send gcode commands via USB during a print from the SD card? (Of course no movement commands just status requests) Cheers, derbroti

igo3d, the german distributor, removed the upgrade kit from their shop - or am I simply unable to find it?!

Okay... ich weiß das Datum zwar immer noch nicht, aber die Feder ist eher keine zu starke: hab das Filament gewechselt und auf der obersten Einstellung ging da nix (Verbatim).

Hi, ich habe mir Anfang des Monats einen UM2 gekauft und würde gern wissen wann er gebaut wurde. Kann man das selbst anhand der Seriennummer herausfinden? oder den Support fragen? - Im Forum/per Mail? Hintergrund: Ich nahm an, dass er irgendwann ende 2015 gebaut wurde, weil ein Olsson Block dabei war. Aber beim Forum durchstöbern hab ich die Sache mit der zu starken Feeder Feder gesehen und meine ist auch auf die minimalste Stärke eingestellt (Indikator ganz oben) - zum testen hab ich dann mal auf die Mittelstellung gewechselt aber da grindete er fröhlich das beiliegende graue Start-Filament. Hab ich also auch eine von den zu starken Federn? Oder ist das UM Filament einfach sehr weich? Danke für Aufklärung