Jump to content
Ultimaker Community of 3D Printing Experts

z-axis-3d

Member
  • Content Count

    63
  • Joined

  • Last visited

  • Days Won

    1

z-axis-3d last won the day on December 6 2017

z-axis-3d had the most liked content!

Community Reputation

4 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks again. Yesterday I ordered some "Flexfil" TPU from 3D filaprint, which is 92A; I also ordered a sample of Ninjatek Cheetah, which is 95A (and a LOT more expensive) - will be interesting to see the difference, but at least it looks like it was the right decision
  2. You star!! thank you, that is exactly what I needed.
  3. I had some of this material from a while back and I did a print for someone recently and they said it was perfect. Now they want more and I can't get this anymore. I will need an alternative of similar hardness. It is quite a lot harder than the 82A filaflex and ninjaflex that I use. Can anyone tell me a number for this? FYI Soft PLA from filament2print is 92A https://filament2print.com/gb/flexible-tpe-tpu/660-soft-pla-flex.html Flexible PLA from rigid ink (when they were still around) was 55D which seems closer to the high 90s in A ht
  4. Also still getting the error when starting up in 4.4.1. I submitted via "send report". I seem to get 4 instances of the crash report dialog Starts fine on my laptop, this only occurs on my desktop PC Added DXDiag screenshots with system info
  5. Update on this. I replaced the bearings nearest the stepper pulleys and it made no difference. I am now convinced that it's the belt on the pulley itself that is making the noise. I tried moving the pulley laterally to make sure the belt was not riding up the side of the pulley- that seemed to make no difference either, but applying a little pressure to the belt while it's turning and you can feel and hear the noise worsen- in fact you can feel the vibration of the belt running onto the teeth I can only imagine that the belt has stretched so the teeth are not meshing pe
  6. yeah I think what you are referring to here is that it's very difficult to get it apart without breaking the clips. I have a couple of broken clips now. My blocks are mostly holding together but I will get a couple of replacements. Tools I had were 2 small flat screwdrivers and an engineers scribe. You need to ease the clips up gently with one screwdriver while levering the halves apart with another -(after you have managed to create a gap- that's where the scribe come in) What you might expect from clips like this (what I expected) is that when you ease the clip apart the block w
  7. It's very hard to tell where it's coming from in there, the sound bounces around. In fact this is my oldest UM2 (march 2014 !!) and I have just been giving it some love. I have just replaced the bushes in those blocks too. It didn't make any difference to the sound or performance, but I had black residue building on the shafts, I think the bushes were starting to break down. However try loosening the 4 screws securing the stepper motor, and then tension the belt (or loosen it) - if you have the same issue as me you will be able to tell straight away. If I loosen the belt the noise
  8. I have the identical sound. Also has no effect on print quality so I have been putting up with it for ages, but very annoying. Looks like it's the the bearings closest to the stepper which go first - they have more force on them from the belt. I know it's a few months late for you, but for anyone reading this here is the spec for the 8 shaft end bearings https://github.com/Ultimaker/Ultimaker2/blob/master/1220_Ball_Bearing_F688-2RS_(x8)/catalogus Specsheet 1220 Ball Bearing F688.pdf
  9. ust to follow up on this : I don't think I was running the right version from GitHub; so between the marlin code version and the arduino version I was running into different issues. I took a step back and -got the latest version of @tinkergnome 's geek_mode branch (17.10.1) -changed a couple of paths: --makefile : ARDUINO_INSTALL_DIR ?= /c/Arduino --package.sh : ARDUINO_PATH=C:/Arduino and now with Arduino 1.8.5 restored to that location (and all the previous configuration as per @gr5 's post I got a successful build of the hex files Thanks again Greg
  10. Final follow-up: I chqnged the pins as follows: #define Y_STEP_PIN 49 //was 32 // PC5 #define Y_DIR_PIN 47 //was 33 // PC4 #define Y_STOP_PIN 26 // PA4 #define Y_ENABLE_PIN 48 //was 31 // PC6 And it is working perfectly. Thanks so much. Cheers, Greg
  11. Thanks again, I don't think I was running the right version from GitHub; so between the marlin code version and the arduino version I was running into different issues. Editing UltiLCD2_hi_lib.cpp as you suggested above did work, but in the meantime I took a step back and -got the latest version of geek_mode branch (17.10.1) -changed a couple of paths: --makefile : ARDUINO_INSTALL_DIR ?= /c/Arduino --package.sh : ARDUINO_PATH=C:/Arduino and now with Arduino 1.8.5 restored to that location (and all the previous configuration as per @gr5 's post I got a successful build of the hex
  12. "eeprom_read_float" was not defined in earlier compiler versions, so it may actually help to use an older compiler. On the other hand: i used version 1.8.1 last time, the difference should not be that big... and the used "weak" pragma is intended as a hint to the linker how to handle this. For newer compiler versions it should be safe to remove the definitions of both functions from UltiLCD2_hi_lib.cpp ("eeprom_read_float" and "eeprom_write_float"). Thanks I will try this. FYI in the meantime I used older compiler(s) and got a different error, but had to stop before I had explored al
  13. I downloaded that from sourceforge and it looks like the shell (called "terminal window") that is put in the start menu is just a shortcut to a BAT file which has : set PATH=C:\Program Files\mingw-w64\x86_64-7.2.0-posix-seh-rt_v5-rev1\mingw64\bin;%PATH% So I just put a path environment variable to c:/MinGW/bin/ and then launch the command prompt window as normal. So I am not sure that mingw64 is needed. However in the end I got the same error as I got when trying to build in the IDE c:/arduino/hardware/tools/avr/bin/../lib/gcc/avr/4.9.2/../../../../avr/lib/avr6\libatmega2560.a(e
  14. Awesome. I just wrote a long response to this with lots of details about how I got on and it's all lost for some reason. The browser, our new operating system. faaaaaantastic. I will try to respond again sometime. Thanks @gr5 and @tinkergnome for taking the time to do this. it helped a lot.
×
×
  • Create New...