jeremie
-
Posts
61 -
Joined
-
Last visited
Content Type
Forums
Events
3D Prints
Posts posted by jeremie
-
-
Isn't this how the lastest makerbot works? The filament pushes the head down. On retraction the force drops and it moves back upwards. See this gif here: http://intentional3d.com/teardown-of-the-makerbot-5th-gen-replicator-smart-extruder/
It introduces a bit of sloppiness though (at least on the MKI head), may be this one is better.
I definitely see it as a benefit for dual head setups, but it may be worth just for retraction (much faster than a Z-hop!)
-
Someone in here said the motor on the UM1 wouldn't be able to keep up without the gear reduction.
Well, you always can use a reductor, like this 5:1 with stepper at $32
-
Another well-suited use of bronze... I ran out of mine but I was given a small 1-2 meters only, too bad
I also think this filament is very tolerant and quite easy to print, one good point!
-
I fail to get the same polish as foehnsturm... it was a quick attempt to show it at my fablab tomorrow
The best I got was with steel wool, with the ring placed on a rod in a drill at slow speed (I am lazy).
Re-heating with hot air gives more reflection on the bronze particles, but I do not get the varnish aspect.
Also I confirm, how shiny it is vastly depends on the light and direction.
-
Yep but you won't get past the bonding agent temperature... When polished (low temp only then), the thing really shines like it was metal (too bad someone stole their polished ring). Amazingly heavy filament!
so a lot of bronze means heat conductivity.... I hope...
-
I like your title: comparison or compassion?
Sure, I tend to favor the small one, and especially when it achieves as good results as the big one in my opinion.
I do not say the UM are perfect (be it v1 or v2), but the big one really has a few major drawbacks.
-
Power requirements might be a problem.
Also, I think most of these cards transfer from the card to somewhere, not to the card from somewhere. So communication is the wrong way around.
Actually, both transcend and eyefi can be hacked (telnet access + homemade executable files -- I played with this). So I feel confident that they can be made to listen by themselves if it is needed (linux rules!). Eg. they could silently grab and sync the g files from a given folder on my PC. Hey, they could even slice the files for me (joking... there is plenty of hard drive space but the RAM is pretty small).
Back to the card size, I find it hard to accept there would be no real answer to the compatible SD cards for an Arduino, amazing!
-
Aha, that can be a problem.. mine is a 32GB Transcend..
I bought it for my camera but there it consums to much power..
But whats up with the UM2 can it handle larger SD-cards?
Anybody knows?
Oh my double bad: first, I initially meant "the arduino does *NOT* handle SD cards larger than 2GB".
And second, this is just FALSE
Check, i.e. http://arduino.cc/en/Reference/SD#.UyAixHVdXggActually I just double checked and the controller did read a 8GB SD card (not wifi).
Now, back to the transcend 16GB wifi card of mine: it was formatted as W95 FAT32 *LBA* (type "c" on linux) and was not recognized. So I tried re-formatting it to the same plain FAT32 as my 8GB cards (type "b"), but it is still not recognized by the firmware this is weird...
I cannot spend too much time on it right now. Some ppl may be more knowledgeable here in the short term!
-
I think the real issue is that the Arduino does handle SD cards that are larger than 2GB (at least on the UM1)
So my 16BG Wifi Transcend is no use, too bad... :(
-
I posted lots of details if you like: http://www.tridimake.com/2014/01/how-to-3d-print-nylon-and-trimmer-line.html
I am so-so with Taulman. It is not cheap and yesterday I got yet another blockage in my nozzle due to the varying diameter (increased friction in the nozzle barrel until I could even barely move it manually!). Switched back to my much cheaper trimmer line
Hi has anyone had decent results with either of these products? Wondering about settings, especially bed temperature and material.
I normally use hairspray on glass but suspect I might need to switch to blue tape for this. I failed miserably with their T-glass recently
-
Good idea, even though I am not a UM2 user (but a long time hacker of UM1 with hundreds of hours experimenting with filament feeders as many others).
There may be a few ideas to grab from the extremely reliable one I have been extensively using for the last year, and which I published in details here: http://www.tridimake.com/2013/04/rollerstruder-filament-feeder-driver.html
Actually I switched last weeks to a new and major revision that addresses a few things (mostly feature requests I got). I am not sure it is more reliable though, I will post about it as soon as I have analysed it enough.
Check also the hobbed bolt may be, I just don't think that the default "grinders" that comes with the printer are that good. I talked about it here: http://www.tridimake.com/2013/03/which-hobbed-bolt-for-filament-feeder.html
Now I cannot agree more with the idea that it should better be the stepper that stalls before the filament is damaged. Too harsh a grip is just useless or even counter productive: better tune the flow correctly! See eg, http://www.tridimake.com/2013/05/no-slipping-no-grinding-not-always-good.html
Finally I just like the big gear, simply because I can tweak and FEEL the tension by hand, or even fix a hiccup in real time. I do not think it is possible with a direct drive. Sure, it makes the thing bigger overall, but this is a price I gladly pay compared to a "self contained hidden" mechanism... Which is also why I favor "open" designs, where the filament can be changed and swapped in no time. Finally, I no more trust the push fit, and I better like blind rivets on the bowden tuben with a printed plug that slides in place.
-
OK, Slicing works.
It also made version 14.01 which is great
But now Printing still doesn't work.
Any sugestions on that, by any chance :???::
Well, I am always printing from the SD card, so I did not check. You probably can start Cura in a terminal and check what it tells you.
I think there were issues with Linux + Python and 250K bauds speeds (a near but non-standard speed b/c of the limitations of the Arduino that powers the printer). A year ago it had to be 115.2 and I think Marlin had to be re-compiled appropriately(!). I cannot state about it right now, I would hope the bug is fixed by the time!
-
In fact, the package is broken. It happens regularly with Linux because the author better implements features than packages (which is a good thing!)
I fixed the last issues by installing the *deb like you did, and then compiled the source code of the slicer (downloaded from github). Then I overwrote the existing slicer executabl (was either absent or made for 64 bits).
I just wrote step-by-step instructions it in my blog if you need: http://www.tridimake.com/2014/01/fixing-cura-broken-linux-packages.html
-
FYI on my system I run fine with version 2.8.12
sudo apt-show-versions |grep -i python|grep wx
python-wxgtk2.8/precise uptodate 2.8.12.1-6ubuntu2
python-wxtools/precise uptodate 2.8.12.1-6ubuntu2
python-wxversion/precise uptodate 2.8.12.1-6ubuntu2
Check http://stackoverflow.com/questions/9212234/no-module-named-agw-aui
-
I would definitely suggest finding a bowden with a better fit to the filament. This is a crucial element to having a direct relationship between drive movement and extrusion, and minimizing the sacrifices compared to a drive-on-print-head setup. Think of it as being similar to having very loose belts which introduce lag and inaccuracy between the stepper and print head.
Actually, getting back to a "tight" bowden would be problematic given the weird stuff I extrude (laywoo, trimming lines, etc...). But I agree I could switch to the appropriate one each time -- now, I never had clogging issues so far with my big bowden so this is a separate issue imho
Also, I think this actively cooled, stainless setup is sensitive to wall finish. If you have gouges/scratches throughout the stainless tube, it increases the potential to jam quite a bit. Use a Dremel or drill, glue some fine grit sandpaper to a cylindrical shaft and polish the tube.
You confirm my fears and I need to try your hint - though I did not expect a lot of success on a stainless steel tube (are many tiny scratches better than one helicoidal one?).
Also I finally received my brand shiny E3D hot end I initially expected sooner (hence my own attempt that I now want to finalize!)... It was machined to a much higher level, so I will probably try their tube on my design first.
Once the pulley pairs are indexed and locked down, there wouldn't be any real change of direction in the spherical bearings. They would just allow the small angular misalignment present when you adjust the rods to be perpendicular. I have made some nice little clip-on alignment tools, and still think it's tough to achieve alignment perfect enough to prevent all bushing bind. There is likely misalignment even in the 8mm perimeter rods (don't form a perfect square). The bearings would allow for the bushings to always be free from a bending moment against their shaft. This would definitely reduce wear and friction throughout.Actually, my xy blocks could also clamp the rods with a conic shape instead of a cylindrical one as now... It would give the rod a slight rotational play without the need for spherical bearings. Not sure it would clamp it tightly but it is worth a try.
I also got the thing the wrong way in the first place, eg. "When the head changes direction, I suspect it could drag and lead to my (short!) bushing to rotate a bit on the Z axis, hitting the sliding rods each time" --> not so true since the head is dragged by the XY blocks and not the opposite. Well, I usually drag and move the head directly with the hand and I should better grab the sliding blocks instead!
-
Hi Ian
You can open a gnome-terminal then just type the following
/usr/bin/cura
If ever it is another path, type which cura should tell you.
As a naive guess, try to upgrade with apt-get update followed by apt-get upgrade.
Sometime ago I ran into trouble due to the python or pypy version (see mine below).
But it currently runs fine on my Ubuntu 12.04. Only the splash screen seems empty -- when it stays long enough so I can see it. Really not an issue for me, don't make it slower!
BTW a few more useful console commands to provide more information.
Daid, I saw no "--verbose" nor "--help" option to Cura, they could prove useful maybe.
I also don't know if python/pypy is still in use (I guess so for the GUI).
lsb_release -a
LSB Version: core-2.0-ia32:core-2.0-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch:core-4.0-ia32:core-4.0-noarch
Distributor ID: Ubuntu
Description: Ubuntu 12.04.2 LTS
Release: 12.04
Codename: precise
pypy --version
Python 2.7.2 (1.8+dfsg-2, Feb 19 2012, 19:16:05)
[PyPy 1.8.0 with GCC 4.6.2]
python --version
Python 2.7.3
cura && lsof | grep cura | awk '{print $9}' | grep -v /dev/
/volatile
/
/bin/dash
/lib/i386-linux-gnu/libc-2.15.so
/lib/i386-linux-gnu/ld-2.15.so
/usr/bin/cura
cheers,
Jeremie
-
Also, not to hijack the thread, but I'd be interested to hear your experiences (and anyone else's) experience with Jeremie's blocks, as I'm considering installing those when I take everything apart to install the new pulleys.
Not exactly the answer you expect since I may have a skewed opinion on the banana blocks
Now I hear the danger of over-tightening the bushings... May be the parts printed very nicely on my printer but I really had no issue. Now, my bushings are quite shorter than the "real" ones (only 16mm long, and same 11mm dia).
Still, I have really no trace of wear and the thing moves better than before (partly due to a better alignment may be), so I don't feel I would even buy harder-to-find longer ones if they get damaged in a few years...
What would be nasty is if ever some blob is left on the printed parts, that dis-align the bushing on the X/Y rods indeed. Careful inspection and cleanup is required I guess indeed.
I also initially had lips around the bushing (you'll see the "shoulder" variable in the openscad source), but it did not prove useful in my case -- I can't remember why but I thing it was conflicting with the stop switches, eg. Actually when I finally printed and used the block near the Z screw, I just left the standalone screw lose, as it looks like there is really no reason to tighten the bushing at all. IMHO I really should make a new revision without it at all.
Now I don't like much the idea of a spherical bearing, just because I would need to buy some
Seriously and for sure, it would add more freedom... but there is no reason if the rods are properly tuned and squared... I don't like the idea that my (short) bushing is allowed too much rotational freeplay on the rod, as I suspect it could really induce *more* wear on the rod each time the direction is changed... It still would be worth a try though because this analysis may be plain wrong -- I am fully self-made in mechanics -- -
Looks pretty good. But, how is the retraction working? So far all "all-metal" hotends have failed our retraction-hell test, and blocking up after a few hours.
Hi there -- was on holiday so was quiet about this thread
I also experience clogs with my own all-metal hot end. I think it boils down to a TOO drastic thermal break in my case (something like 40° to 230 in 3mm?). When the filament is pulled back, I guess it "freezes" immediately.
It then probably adapts and sticks so well to the inner metal tube tiny scratches that it will not resume even when I push it back by hand... I have to stop the dedicated cooling fan to let a longer part of the hot end get hot enough to resume...
I though that the filament would contract when cooling down, but if it does it is not enough... It just fits perfectly and seals the colder upper tube on a few mm. It works with a very short retraction like what does Lars but I'm left with some stringing on long hops though on my side (esp. as my bowden tube is 4mm wide inside)... :(
I still need to figure this out... My best idea so far is to make the thermal transition longer (what a pity!), so the filament will not freeze so quickly!
I am sure that we can get rid of this damned expensive PEEK
-
Damn, it looks like linux lacks an official 12.11 release
On
http://software.ultimaker.com/index_.php/
So I switched to the source... but sorry for this highly off-topic newbie question: how shall I launch it once downloaded from git? I keep on getting this error?
Traceback (most recent call last): File "cura.py", line 17, in from Cura.util import profileImportError: No module named Cura.util
No such file, even on the older cura release? I also quickly tried to package.sh it for myself but kubuntu's quantal cx-Freeze got in the way (too old a version...)
-
The wood grains can be used with the Wood plugin
Great! Now I can upgrade... and start writing more plugins
Thanks for all the good work, Daid
-
Many thanks
There may be no libraries yet, but it is way more readable.
The main drawback would be not to benefit from third-party additional skeinforge plugins, and not to bring ours to others sk users. While Cura rules, it does no laser cutting yet... Also, complex plugins may require access to the guts of gcode generation (eg inset, etc)
Now, post-processing calls for pre-processing...! Hacking in perlin noise makes me think I should have a look at disturbing the vertices to give an object a hand-made look... I always promised myself NOT to start coding in there, but I could not resist...
-
LOL, too late man! Why on earth didn't I get an email notification of your reply? :?
I agree, it's a confusing mess
It will be funny to try to localize as it relies on labels to find a variable back, had a hard time figuring this out properly to get my parameters forwarded from cura to my sk plugin (and not much b/c it's the first time I'm programming python, that was a nice reason to try)But it's done now. I also added its config in cura expert settings (along the soon-to-go dwindle). I will post it after I give it some real-life testing.
Anyhow, what would have been the best way to add post-processing to cura WHITHOUT skeinforge then?
Actually: I'm currently adding perlin noise to get better z-wood grain. Would be cool to apply in each each dimension of the object skin (so as to spare exec time and reduce the g-code). I do not have much time though but may be you can help: is there an obvious existing plugin I could recycle to get the x,y,z "surface" coordinates (only) and know how to split a segment to insert M104 ?
I just checked it quickly in skeinforge standalone.
-
I was looking for info on the commands related to temperature and tumbled upon this (how did I miss it?). That's also to upgrade my review at
http://betterprinter.blogspot.fr/2012/1 ... ament.html
I am looking into adding python scripts in the Start/End gcode tab instead of static search/replace
With a script, it would be easy to change temperature at each layer in a pseudo-random but continuous way, with no need for an annoying manual intervention.
Also, such dynamic plugins would open lots of possibilities (with some security breaches, but hey, plugins are plugins)
Update: I may better start with looking at skeinforge plugins, shall I? In cura_sf/skeinforge_application/skeinforge_plugins/craft_plugins
Re-Update: I'm currently testing as a new plugin, I let you know
-
FYI the discussion moved a bit forward on
https://groups.google.com/forum/?hl=en& ... fAFPqLYEHo
(sorry for the dual posts)
Check, i.e. 
It will be funny to try to localize as it relies on labels to find a variable back, had a hard time figuring this out properly to get my parameters forwarded from cura to my sk plugin (and not much b/c it's the first time I'm programming python, that was a nice reason to try)
"Autolift" Kickstarter campaign
in Third party products & modifications
Posted
Oh don't ask me -- I am certainly not the one to say it cannot be hacked for the UM1 !
Now you get my head running again and I have work to do
I need to add "dual head with autoraise" to my wishlist http://www.tridimake.com/2014/01/features-and-improvements-for-a-homemade-ultimaker.html