Jump to content
Ultimaker Community of 3D Printing Experts


  • Content Count

  • Joined

  • Last visited

Everything posted by umagi

  1. Hi, On the Ultimaker 2 main board is a jumper JP3 "8/16 step". What does this do? If this sets the microstepping mode, why is there only 1 jumper and not one for each stepper motor? If it is used, does the open state (no jumper installed) mean 8 or 16? Thanks!
  2. Hi Lars. Thanks. Yes, I finished it! It works fine, but the whole 3D printing process is too slow for my liking (and I get bored quickly). So, for the moment, I am focusing on other stuff.
  3. Hi, My Ulticontroller v2.1 blew up due to what I thought was an ESD discharge when touching the knob. This fried the U3 chip on the PCB (the PCA9306 chip: Dual Bidirectional I2C Bus and SMBus Voltage-Level Translator) which I replaced myself. With the repair, things appeared to go well for a moment, but then the U3 chip started smoking... again. I start tot suspect that there must be another underlying problem to this and that the ESD I first got was just a symptom and not a cause. Does anyone know where I can can PCB debugging support for my self-built Ultimaker 2 ? What can cause this U3 chip to get smoked like that? Many thanks...
  4. Hi, I have built my own UM2 with aluminum extrusion profiles as frame and some minor modifications to make it slightly taller than the UM2 extended. The aluminum extrusion frame is covered with composite aluminum panels ("dibond-like"). The control knob is a solid one made of anodized aluminum (see image below). I used a switched power supply 24V/10A with AC ground connected to the aluminum frame. For the testing however, I used the output of a stabilized lab power supply (so that I could also see the actual current drawn) but I did not connect the ground of that supply to my UM2 frame during the test. When touching the control knob on the Ulticontroller v2.1, an electrostatic discharge (ESD) occured which took out the controller: the display and knob leds went out and I could smell that something had fried. Inspection of the PCB showed that chip U3 on the PCB (the PCA9306 chip: Dual Bidirectional I2C Bus and SMBus Voltage-Level Translator) was fried: the package shows a hump on the top (see image below) I will try to replace that component, hoping that the damage was limited to that one alone and did not propagate to other parts of the circuitry, especially the main board. But how can I effectively protect my UM2 against such ESD damage in the future? Was the choice of using an aluminum knob a bad one since it provided a discharge path into the circuitry? Thanks for sharing your insights on this!
  5. Hi I don't know if this may be a problem or not, but I use an external SPST (single pole, single throw) switch at the AC side and I leave the switch on the PCB (i.e. DC side) always ON (I did this due to mounting and accessiblity problems in my build). The AC switch turns the Switched power supply on and off, of course. I am really at the end of my wits here, trying to figure out why my Ulticontroller keeps blowing up (chip U3). If the above is not a problem, may my problems be due to bad power supplies? If so, how can I check that? Any help is welcome as these problems are getting very frustrating... Thanks!
  6. EDIT: This post first started out of my initial frustration of not succeeding in building Cura's developer's version in Windows using MingGW-w64 and MSYS2, and trying to get some help. It evolved into a rather long monologue that documents my step-by-step build of the Cura package, the problems I encountered and the sometimes uggly workarounds I used. The final lesson from all this is that building Cura in Windows 7 with MinGW-w64 and MSYS2 works! Hopefully, my post will be of some help to others... EDIT2: After installing the freshly built installer package on a Windows 7 Virtual machine... I get an error. So not all is well yet... For the error see my latest entries in this thread below. EDIT3: Although the Cura package and installer build to completion, launching the Cura (developer's version) program fails with the error at the end of this thread. EDIT4: To have a working Cura build, I just used the daid script (the one that creates the official Cura releases, it seems) from: https://github.com/daid/Cura After a few tweaks, the Daid script worked for my installation using the latests MinGW-w64+MSYS2 and the installer package builder NSIS3 except for the build of CuraEngine.exe, which must be compiled from scratch. But I already built it using the cura-build (developer's version) script. Just copying that one and using the rest of the Daid script seems to work. Cura installs and runs correctly as far as I can see. I still need to figure out why the dev version of Cura crashes after launch though. Hi I have been utterly wasting my time trying to build Cura in Windows 7 (64bit) using the instructions from https://github.com/Ultimaker/cura-build and also from: https://github.com/daid/Cura Both to no avail. I have installed: CMake 3.4.3 MinGW-w64 from https://sourceforge.net/projects/mingw-w64/ msys2 from https://sourceforge.net/projects/msys2/files/latest/download' PyQt5-5.5.1: PyQt5-5.5.1-gpl-Py3.4-Qt5.5.1-x64.exe Python 3.4.4 numpy-1.10.2-win32-superpack-python3.4.exe I did the following in MSYS2 (and also tried in Git Bash): git clone git@github.com:Ultimaker/cura-build.gitmkdir buildcd build../env_win64.batcmake -G "MinGW Makefiles" ..mingw32-make I also tried with env_win32.bat, and also once tried with cmake .. to generate the default generator, which in my case is Visual Studio 14.0 - from VS2015 and tried to build the solution in VS2015. All these trials did not work either... The build of the Protobuf target succeeds, but then I hit a snag witth the following error: [ 5%] Completed 'Protobuf'[ 7%] Built target Protobuf[ 7%] Built target Python[ 7%] Performing update step for 'Protobuf-python'Current branch master is up to date.[ 8%] Performing copy-libproto step for 'Protobuf-python'[ 9%] No configure step for 'Protobuf-python'[ 10%] Performing build step for 'Protobuf-python'running buildrunning build_pyrunning build_extbuilding 'google.protobuf.pyext._message' extensionE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\descriptor.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\descriptor_containers.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor_containers.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\descriptor_database.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor_database.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\descriptor_pool.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor_pool.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\extension_dict.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\extension_dict.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\map_container.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\map_container.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\message.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\message.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\repeated_composite_container.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\repeated_composite_container.o -Wno-write-strings -Wno-invalid-offsetofE:\DevTools\MinGW\bin\gcc.exe -mdll -O -Wall -I. -I../src -IE:\DevTools\Python34\include -IE:\DevTools\Python34\include -c google/protobuf/pyext\repeated_scalar_container.cc -o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\repeated_scalar_container.o -Wno-write-strings -Wno-invalid-offsetofwriting build\temp.win-amd64-3.4\Release\google\protobuf\pyext\_message.defE:\DevTools\MinGW\bin\g++.exe -shared -s build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor_containers.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor_database.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\descriptor_pool.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\extension_dict.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\map_container.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\message.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\repeated_composite_container.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\repeated_scalar_container.o build\temp.win-amd64-3.4\Release\google\protobuf\pyext\_message.def -L../src/.libs -LE:\DevTools\Python34\libs -LE:\DevTools\Python34\PCbuild\amd64 -lprotobuf -lpython34 -lmsvcr100 -o build\lib.win-amd64-3.4\google\protobuf\pyext\_message.pydE:/DevTools/MinGW/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/bin/ld.exe: E:\DevTools\Python34\libs/python34.lib(python34.dll): Recognised but unhandled machine type (0x8664) in Import Library Format archiveE:\DevTools\Python34\libs/python34.lib: error adding symbols: File format not recognizedcollect2.exe: error: ld returned 1 exit statuserror: command 'E:\\DevTools\\MinGW\\bin\\g++.exe' failed with exit status 1CMakeFiles\Protobuf-python.dir\build.make:112: recipe for target 'Protobuf-python-prefix/src/Protobuf-python-stamp/Protobuf-python-build' failedmingw32-make[2]: *** [Protobuf-python-prefix/src/Protobuf-python-stamp/Protobuf-python-build] Error 1CMakeFiles\Makefile2:292: recipe for target 'CMakeFiles/Protobuf-python.dir/all' failedmingw32-make[1]: *** [CMakeFiles/Protobuf-python.dir/all] Error 2Makefile:148: recipe for target 'all' failedmingw32-make: *** [all] Error 2umagi@HOME-PC MSYS /G/dev/cura-build/build The error is thus: E:/DevTools/MinGW/bin/../lib/gcc/i686-w64-mingw32/5.3.0/../../../../i686-w64-mingw32/bin/ld.exe: E:\DevTools\Python34\libs/python34.lib(python34.dll): Recognised but unhandled machine type (0x8664) in Import Library Format archiveE:\DevTools\Python34\libs/python34.lib: error adding symbols: File format not recognizedcollect2.exe: error: ld returned 1 exit statuserror: command 'E:\\DevTools\\MinGW\\bin\\g++.exe' failed with exit status 1CMakeFiles\Protobuf-python.dir\build.make:112: recipe for target 'Protobuf-python-prefix/src/Protobuf-python-stamp/Protobuf-python-build' failedmingw32-make[2]: *** [Protobuf-python-prefix/src/Protobuf-python-stamp/Protobuf-python-build] Error 1CMakeFiles\Makefile2:292: recipe for target 'CMakeFiles/Protobuf-python.dir/all' failedmingw32-make[1]: *** [CMakeFiles/Protobuf-python.dir/all] Error 2Makefile:148: recipe for target 'all' failedmingw32-make: *** [all] Error 2 Does anyone have an idea about this error or more detailed info about a working build procedure with detailed configuration info and correct (i.e. compatible) versions for the various dependencies to use? Thanks from a very frustrated Cura beginner...
  7. Version 1.0


    In order to check the quality of my bed leveling (seem to have trouble when printing close to one edge of the bed), I made this mount for my digital dial indicator. Initial measurements seem to indicate that my 6mm shafts may be bent somewhat. Since my dial's shaft is too short, I used an extension shaft salvaged from an old CD-ROM player, together with one of its slide bearings. First, I was hoping to be able to use the unused nozzle opening to pass the dial shaft (or its extension part), but unfortunately, I couldn't find an easy way to secure the slide bearing to firmly hold the extension shaft in place. I therefore mounted it on the outside of the printhead. The whole thing works well, although I should have made the upper support part a little bit sturdier. My next step is to build a data interface for the dial gauge so that I can send the measurement data directly to my computer, e.g. to make a 3D map of my bed leveling, e.g. as in: https://hackaday.io/project/511/logs Overkill, but just for my personal experimentation... PS. The picture also shows my uggly Bowden tube clamp. Uglly, but seems to work in holding my bowden tube in.
  8. What a nasty surprise I got when by accident, I checked my filament after my extrusion halted to a stop, with the filament ground (grinded?) into the profile of my drive nut... Somewhere along the roll, I discovered something that looks like a section that was fused together, or more probably it is just an extrusion fabrication error. In any case, that section has a diameter of 2.83mm, more than 1mm off the size it should be! Quality control please? For the remainder, this filament produced by Esun is rated to be 1.75mm is actually closer to 1.65mm. What else am I to expect of this spool? That they would sell such is thing is really scandalous.
  9. That's what I did, and the supplier sent me a new one, from another batch. They indeed asked me for a picture of the fabrication label (including the batch ID) to send to the manufacturer probably. Nevertheless, any good manufacturer (the package in which this spool comes states "premium quality material") would have caught such gross fabrication error immediately, since this can be easily automated.
  10. Found a 2.83mm section somewhere along my 1.75mm diameter filament spool... Doctor, would that be a problem? https://ultimaker.com/en/community/20351-damn-filament-vendor-175mm-filament-roll-has-283mm-fused-section-in-it It would be nice to have a setup that checks every new spool by automatically unwinding it and onto a second, empty spool while having the diameter checked somehow, since apparently this particular manufacturer does not seem to bother.
  11. As maybe Einstein would have said: try to buy as cheap as possible, but no cheaper. I recently got this cheap crappy one: https://ultimaker.com/en/community/20351-damn-filament-vendor-175mm-filament-roll-has-283mm-fused-section-in-it
  12. umagi

    why is ultimaker filament crazy expensive?

    Maybe to avoid problems such as this one: https://ultimaker.com/en/community/20351-damn-filament-vendor-175mm-filament-roll-has-283mm-fused-section-in-it
  13. Version 1.0


    I made this to prevent the bowden tube from popping out of the feeder. For some reason on my self-built printer, this usually happens during the print of the first layer (starting with the brim). Since the tube is pushed out with quite some force, I resorted to this design, which combines the function of the shoehorse clip (to lift the ring fitting) and of a 25mm clamp, which squeezes the bowden tube to hold it firmly in place. The design is for a 4mm external diameter bowden tube (1.75mm diameter filament).
  14. Hi. I'm using 1.75mm filaments with 4mm outer diameter bowden tube and noticed that the PTFE isolator in the printhead has an input diameter of 8mm! The exit diameter is 2mm, which is OK. Looking at the drawings of the vendors of such isolators, they all seem to be the same 8mm input diameter for the 1.75mm filament version, while the 3mm filament version has an input diameter of about 6mm, which is about right for a 6mm outer diameter, 4mm inner diameter bowden tube that is usually used for 3mm filaments. Since the bowden tube usually used for 1.75 mm filaments has a 4mm outer diameter (2mm inner), I really don't understand why the 1.75mm version of the PTFE isolator has an input diameter of 8mm!?? Since I use a 4mm OD bowden tube, I have initially fitted the end of it with a 6mm OD section which I happened to also have. However, this is still does not match the 8mm input diameter of the PTFE isolator, and therefore results in problems, e.g. when inserting new material, since the hole of the bowden tube and the 2mm hole of the PTFE isolator do not normally align even when I use the 6mm OD section. I cannot imagine that I must use an 8mm OD, 6mm ID bowden tube for my 1.75mm filament... Or that I must fit a section of 8mm tube to my 6mm tube end for my 4mm tube (like russian dolls). Any ideas as to why such a travesty in the PTFE isolator design for 1.75mm filaments?
  15. Hi swordriff, It is obvious that I am a beginner isn't it? ^^. Well the difference is that we are talking about raw materials here, the result of a simple (but what do I know, I always hated my chemistry classes) polymerization process to give a single, base material (well, if you don't count the carbon and fluor of course). What you are talking about are complex finished products. I agree that dimensional tolerances etc... can be different for a worked piece of PTFE, but I don't see how much different the raw material can be, which is the result of an automatic chaining process of the C2F4 monomers. Impurities maybe? Small impurities can have a great effect on material properties of course, cfr. semiconductor doping for instance. In any case, I was just wondering. As you suggested, I'll have to indeed experiment! Thanks for your valuable info.
  16. Hmm... PTFE is just a polymer of fluor and carbon ... not sure any difference in polymerization process justifies a 5 to 10 times increase in price... As for TFT, I can't seem to find any info on that? What does it stand for?
  17. Hi Dim3nsioneer, You're right. I was looking at a well-known Chinese site... Yes, but have you seen the price ? 16 Euros for this thing? They must be kidding? Apparently, they are out of stock, "waiting from material from the US", so are they making these parts themselves? If so, I could try to make my own part, since I can have access to a lathe. However, I'm not sure how well PTFE is worked on like that. Update: I found this Youtube link that shows some (big) PTFE seal being made from a lathe, so I may give it a try myself, if I can find some PTFE rod somewhere...
  18. Probably yes. I was looking on some well-known Chinese site for 1.75mm PTFE couplers for UM2, and they all seem to have that input diameter of 8mm, which makes no sense to me. I will have a look at the TFT coupler from 3dSolex as Dim3nsioneer suggested.
  19. Hi, Wondering if I can turn off the heated bed of a PLA print after a sufficient number of layers have been printed? For long prints, it seems a waste of energy to have the heated bed on until the end of the print. Thanks for sharing your experience on this!
  20. Labern, tommyph1208, thanks for sharing! Chose the first answer as the "best" one, because, well it was first...
  21. Hi. I finally started printing with my self-built UM2! Many thanks to Coen for helping me out with my Ulticontroller board problem. I reverted to using a power supply setup closer to the original UM2 setup. I no longer have voltage peaks on my Ulticontroller board that used to damage the U3 voltage level translator chip thereon. This being the first time ever for me to 3D print anything (I haven't tried printing on other printers before setting out to build my own...) the first prints did not go smoothly. I'm using a 1.75mm PLA silver filament rated for 190C to 220C with a 0.4mm nozzle and Cura 15.04.4 as slicer. My first print was a simple test object, a hollow square vertical column 25mm x 100mm. I changed the nozzle setting in Cura to 0.375mm, after my first attempt did not have fused shell walls. My latest print of that object seems to go the right direction (Temperature was set to 214C, no overrides of the settings on the machine - all 100%, except for the filament diameter set to 1.75mm): The settings for this print were as follows: However, I am faced with one constantly recurring problem: my bowden tube keeps popping out at both sides.This seems to happen mainly when printing the first layer(s). I try to keep the tube in place, but actually quite a lot of force is required, even when printing at these low speeds of 20mm/s. In order to somewhat remediate the problem at the print head side, I printed a simple clip that I mounted on the knurled screw on the printhead. The teeth on the screw head and a tight hole diameter help maintain the tube and its fitting ring in place. This solution is effective in most cases so far, but sometimes, even that is not enough to prevent the tube being lifted out of the head. At the feeder side, the tube keeps popping out however. This seems to start at the pruning stage before the printing starts. I can push it back in, but I must maintain it (and sometimes also the other end at the printing head) with quite some force for the few first layers of my print, after which things seem to go better and I can release the tube. Even though I am not using the shoehorse clip that seems to be standard in the official UM2 build, I doubt that using such a clip would help, given the amount of force I need to apply to keep the tube in. How come things seems to go better after the first layer(s)? As shown in my settings above, I set all speed fields in Cura to the low value of 20mm/s, and even then, I have this problem. I tested my extruder operation using Pronterface to extrude 100mm with the bowden tube removed from the printhead, and almost exactly 100mm was extruded by the E motor. I use the following extruder driver nut: I noticed that PTFE isolator in the printhead has an input hole diameter that is too wide for my bowden tube, which is for a 1.75mm filament, and I therefore fitted a short section of a wider bowden tube on it at that end. However, the fit is still not perfect as the PTFE isolator hole is still somewhat wider than even that thicker tube section. I don't know however if that is an issue? Any ideas? Thanks!!!
  22. On the TI site, I found that someone named Patrick Olma (someone from Ultimaker, I presume?) posted the following question: https://e2e.ti.com/...rface/f/390/t/495210 Looking at the date, I also assume that his question was posted after I flagged it in this forum. This was the message: The response from the TI employee is rather interesting: I guess I will try to jumper EN to VREF1 then, if possible at all. I am expecting some clarification from Ultimaker though...
  23. Hi... I did some measurement with the scope, and found some problems indeed with my setup. As stated above, I use a self-sourced switched power supply and an external AC switch whilst leaving the PCB switch permanently ON. This may be the cause of my problem. When using this setup, the VREF1 and VREF2 measurements look as follows: CH1 (blue) is VREF1, CH2 (yellow) is VREF2. CH3 (green) is measured directly at the DC output of the supply. Thus, a spike of almost 1V appears on VREF1 and VREF2, and the timing seems to correspond with the time when the 24V rail becomes live (i.e. the relay K1 closes), one of the figures below. When I use the PCB switch instead, the spikes do not occur: The 24V rail comes live as follows: The 24V rail activation timing seem to correspond to the time when the spikes appear when I use the AC switch instead of the PCB switch. I'm not quite sure why this is happening (is power supply coming up too slowly?), but I will immediately change my configuration and eliminate this AC switch and only use the PCB switch (or use an external switch, but at the DC side this time). I will also try to source a power adapter closer to the "official" one.
  24. Hi, Trying to figure out why the PCA9306 chip on my Ulticontroller keeps blowing up, I checked the datasheet from Texas Instruments for it. I found the following: However, the Ultimaker schematic shows this: So in the UM2 schematic, VREF1 is at 5V whereas the range for VREF1 as per the datasheet is only between 1.2V and 3.3V... What the ... ?? Can any of the Ultimaker design engineers please help me out here?
  25. Cohen from the Ultimaker team has confirmed the chip is not connected as suggested by the datasheet, and that he will correct this in the new revision he is working on. Although the chip does bidirectional level translation, it apparently matters what you define as VREF1 and VREF2, since it matters what you connect the EN pin to. Texas Instruments' reply clearly states that the EN pin should be connected (via the 200kOhm resistor) to the HIGHER voltage reference. In the case of the Ulticontroller v2.1, this is the 5V pin, while now it is connected to the 3.3V pin. And although indeed this would not normally cause problems, the fact is that the U3 chip on the Ulticontroller should be wired differently. When I posted this message, I was just wondering if Patrick Olma may have been from Ultimaker, partly because of the timing of his inquiry and the timing of my first post on this forum about the schematic discrepancy for U3 with the datasheet, the similarity of his problem with mine, and partly because of his Dutch sounding name... Looking more closely at his post however, I should have realized that his design did not correspond to the Ulticontroller design... So, my assumption was wrong, and I apologize for this.

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!