Jump to content

derbroti

Dormant
  • Posts

    45
  • Joined

  • Last visited

Posts posted by derbroti

  1. Thank you for your post. I would like to ask if you care to open up a new topic about this, so we can help you troubleshoot your issues.

     

    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

     

    Your feeder shouldn't really be scratching the filament. Perhaps when you took it apart to check the internals something got misplaced?

     

    Sorry if I was unclear: I first noticed the scratching and then took it apart :)

     

    Are you releasing the tension to the fullest with the lever?

     

    Yes, I even losend the tension screw to the top position to have the level easily pulled.

     

    It is always recommended to straighten the filament a little bit by hand before you feed it in the feeder.

     

    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.

     

    Could you elaborate a little bit about the error you are having?

     

    Thankfully that one is solved :)

  2. There is no need to make complicated changes the tinker firmware is readily available for the um2+

     

    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.

    • Like 1
  3. 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.

    IMG_2569.thumb.jpg.7f4494b926b49b240253bc40e79d419e.jpg

    IMG_2569.thumb.jpg.7f4494b926b49b240253bc40e79d419e.jpg

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

    5a331da817b1a_ScreenShot2016-05-28at14_27_38.thumb.png.90df973a2a6eb2a358f67001e948a9a9.png

    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:

    scratch.thumb.png.31aa73799de33a15e3a8f61acc6e2afc.png

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

    5a331da817b1a_ScreenShot2016-05-28at14_27_38.thumb.png.90df973a2a6eb2a358f67001e948a9a9.png

    scratch.thumb.png.31aa73799de33a15e3a8f61acc6e2afc.png

  5. 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 ;)

  6. 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 :)

  7. "/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 ;) )

     

    (I'll ignore it since it occurs in "electronics_test" and hope it is just a test that fails):

     

    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 ;)

  8. as the firmware goes over 128k in size (not the size of the hex file, actual binary flash size)

     

    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?

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

    • Like 1
  10. 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.

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

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

  13. 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 :)

×
×
  • Create New...