codemaven

Hi all, I'm sure this has come up before.... But I can't seem to find anything. My question for you folks with heated beds is how do you attach them to your UM? I'm planning to use the existing method of springs and screws into the delrin nuts, but I'm worried about the durability of the delrin parts with a heated bed. I'm using teflon washers and bushing sleeves on the bed to avoid heat migrating down the screws as much as possible, but I still expect that during long prints the screws going into the delrin will heat up. The listed melting point for Delrin is 175 degrees C. I don't expect to ever go that high on my bed and consequently the screws should keep much cooler... but will they potentially soften the delrin to the point that the springs can push them out? I've been planning to put together a heated bed for some time... but I just got around to ordering parts. I'm going to go the route of a 220v mains heater on an aluminium bed. I'm experienced enough with mains electronics to handle it, but I still recommend others to take the low voltage approach. Instead of a silicone heating pad though I've opted for a 400W mica heater plate. It will be controlled by a 5A ssr driven from the UM hot bed mosfet. I'm planning to have a 200 degree NC bi-metallic cutoff switch in series with the heating element as a safety feature. I'm also going to connect an LED to a NO 50 degree bi-metallic switch so that the the LED is lit whenever the bed is over 50 degrees C. My plan is to power it from a 3F ultracaps (memory backup cap) that is kept charged from the +5v on the thermocouple output. The idea then is that the HOT BED warning LED will still work if the power is turned off. If the ultra-caps and +5v thermocouple supply don't work out as planned I'll fall back on a battery backup for the LED. Cheers, Troy.

The Register ran a feature on 3d printers this morning. http://www.theregister.co.uk/2013/02/04/ten_3d_printers/ It's a shame that the Ultimaker is not on the list... But it may be an interesting read for some. Cheers, Troy.

Hi Smorloc, At the time that original comment was written they did not have a working hot-end or extruder... There were serious design flaws in the original releases that were causing failed prints for lots of people and many were not able to print at all... Not everyone needs or wants a heated build platform, but everyone does want a reliable hot-end and extruder.. They have since released a v2 hot-end and extruder upgrade that solves the prior issues. I imagine that UM is now working on a HBP, but whether or not we will ever see a retrofit kit for one is unsure. Personally I think that the changes required for an official HPB are too great, so my opinion is that we're more likely to see a whole new Ultimaker-2 printer with a HBP option than an official upgrade kit for the current model. Cheers, Troy

I've only printed a couple of things since NetFabb's retraction update came out, but so far I've been seeing a significant improvement with regard to stringing. It is very violent though as mentioned. I've not used Cura's retraction so I don't have anything to compare to, but it sure makes a racket and lots of shaking when you have a model with a lot of retraction... results are good though. Except... I was printing a model on the weekend that had a lot of retraction and I had a filament jamming issue of some sort. I haven't had time to investigate yet, I just turned the machine off when I noticed that the print head was above the model with nothing coming out. It looked like a plug.... which Is something I havn't had since upgrading to the 2.0 nozzle. I will see tonight if there is a plug, grinding, or anything indicating why no plastic was coming out. By the way, retraction came with 4.9.4 a couple of weeks back. A few days ago a 4.9.5 update was released. The release notes for 4.9.4 are available, but I have not seen any release notes for the 4.9.5 release. I suspect it may simply be a fix for issues that some people had with their settings being wrong in 4.9.4. Regards, Troy.

Alaris > The Z shells are easier. I'm assuming you are talking about upskin / downskin (at least that's what it's called in NetFabb). Basically, for each layer I'm doing a BSP tree 'Diff' with the previous layer. Any zones that are solid in the current layer, but were not solid in the last layer get a filled skin. It's done going bottom up for downskins and then in another pass going top down for upskins. In order to get more than one layer of course we need to define multiple skin zones... I.e. for each zone if there is no solid below it then this region is solid infill-1, then on the next pass we do the diff and we see that a solid region is above an infill-1 area so we make this new layer an infill-2 layer (perhaps a different direction of infilling if we're doing croshatch). Just keep going for the appropriate number of skins. This is configured seperately from the shells, but for consistency should be determined by shell thickness... If you have 3 shells at 0.4mm then that total thickness is 1.2mm, so at 0.08mm height you would need 15 layers if infill to match the same thickness. Cheers, Troy.

Just to get a little bit back on track here... "...or example, take an U shape, and have the bottom part really thin, thinner then 4 shells. " The issue with thin walls is something I'm familiar with.. I haven't done extensive testing yet, but my BSP tree should be taking care of that. For each line segment on each interior polygon the BSP tree can tell me with a simple call whether my line segment is clipped by another polygon (i.e. if it's scaled down to negative space, meaning that the wall is too thin.). In these cases I can adjust. Exactly how to deal with these situations is another issue... But I've got a few ideas. For the shells, I am producing a configurable number of shells with configurable widths and speeds. Each shell can have it's own width and speed. This is like NetFabb. Thus, the outer shell can have a small width that is done slowly while the inner shells can be printed faster. I've also added the ability to do everything on a 1 or 2 layer basis so you can slice at 0.04mm layers and print the outer shell on every layer, but the inner shells on every second layer. As far as I can tell this is basically what NetFabb is doing with half-layers. Cheers, Troy.

Hmm, sounds like you're both taking much different approaches than i am. My slicing function returns an array of 2d polygons for each continuous loop on each layer with normals on the line segments. I'm just scaling those polygons by multiplying each point. A negative number for polygons with exterior normals (outside facing walls) and a positive scale for interior normals (inside facing surfaces.. i.e. holes). Cheers, Troy.

I've been playing with mine whenever I get a chance... But I still have nothing really worth showing though... I spent a couple of hours last night chasing a red-herring in my algorithm that sorts line segments into continuous paths... I'd really like to spend some more time on it, but unfortunately I spend 8 hours a day writing code at work, and then have an hour commute home to my girlfriend... so I'm lucky to find 30 minutes in a month to devote to my own projects.

I've personally had fantastic results with superglue (cyanoacrylate). I've glued many different PLA models together with it and they're as strong as if it was printed as one piece. I've not had any glue joints with superglue ever come apart on me. I've also had success with standard plastic model glue (used for building polystyrene aeroplane / car models, etc.) such as this: http://www.testors.com/product/136635/3 ... stics_58oz it's very slow to cure and smells horrible though, so I usually stick with regular superglue. Cheers, Troy.

Hi Alexander, On the changelog linked to above it says "released Linux version as Debian Package". How do I get that? I've been hoping for a Linux version of NetFabb forever and have not seen any indication that it is available. I currently run NetFabb inside a virtual machine on Linux and it is a serious pain. I want to remove that VM and run it natively. I cannot find any link to a linux version on either the NetFabb webpage or the Ultimaker webpage. Thanks, Troy.

This is it: http://www.thingiverse.com/thing:14345 I cut it into two parts using NetFabb and printed them in gold and silver and then glued them back together. Cheers, Troy.

For Fun I bought it because I don't like upgrading every year... I could afford it so I decided to buy top-of-the-line everything... Including a custom overclocked CPU and watercooling. I mostly only use it for development and slicing for my printer... and email Cheers, Troy.

I should mention that my computer that I'm running this on is a 12-core 4.5ghz machine with SSD storage and 32gig of ram... That could contribute somewhat to my speed reports...

Haha. We'll see how quick it is when It's fully functional... Besides, I probably won't have time to work on it much for a while. I'd like to see what you come up with independently and then maybe we can compare notes. Cheers, Troy.

My approach is to take the NetFabb style of things and define different settings for different region types. So you can have different speeds for outer walls, inner walls, upskins, downskins, and infill. I also intend to give every option the ability to skip layers so you could slice it at 0.05mm and do infill and inner walls only on every second layer thus making the visible outer wall happen every 0.05 layers (printed nice and slow for good surface), but everything else inside effectively at 0.1mm layers.

I normally print at 0.08mm layer height as that is the default in NetFabb, but when I want really nice quality I go as low as 0.04. Last night I sliced a 147meg STL file (the full fat yoda bust) with my Java slicer at 0.04mm layer height in 24 seconds. That's total time to read the file in and slice it into bsp trees. I'm using 4 worker threads for the time being, but I can change that number. I've started the base code for adding in-fill, but it's not working yet. My design allows for any number of in-fill patterns very easily. I'm thinking of starting with cross-hatching and honeycomb patterns. I'm not sure how to calculate support structures yet. I can only think of one way to do it, and it's not a very attractive approach... Cheers, Troy.

I used to be a hardcore C++ developer who scoffed at Java developers.... But these days professionally I'm working on high performance Java applications at work for stock market trading.... and I've been impressed. The JVM has improved by leaps and bounds in recent years. We're pushing gigabytes of realtime market data through our Java components without breaking a sweat. I'm still not a fan of a lot of aspects of the language itself, but that too is improving. Java 6 is a big improvement over Java 5, and likewise 7 is a big improvement over 6. My experience with the latest versions of the JVM is that they tend to perform as good, if not better than similar C++ programs. This is because there is so much optimization in the JIT compiler, most C++ compilers are just not as up-to-date with the latest techniques for optimizing the generated code on the latest CPUs... It still holds true that Java programs load slower than C++ programs, and well tuned C++ programs have the potential to be faster... but in practice this is often not the case. Cheers, Troy.

I think the speed comes down to a good design in a fast language... Skeinforge is written in Python, which is not known for speed... As a dynamic language it simply cannot keep up with C++ or even Java. It also (from the little bit I've looked at) seems to be a huge mess of rand bits bolted together without a unifying design.... Simple slicing can be fast, but this will slow down as features are added. Depending on how it's done the in-fills and such can be quite expensive. I myself have just started working on a slicer in Java as a pet project. This is one thing I've been thinking about for a while. I'm writing it in generic Java so I should be able to build it for Android as-is without any major changes. That is one of my goals. Also I want to run it on the web too, either as a web service or cross-compiled to javascript in the browser. So far I've been slicing a 1meg stl file with 5100 polygons in about 190 milliseconds. I do not have infill or up/downskins working yet, but I know how to implement it. It's just a matter of finding the time. I'm hoping to have a demonstratable slicer with infill and up/downskins at least (if not g-code generation) soon, however I'm going on holidays next week so I probably won't have time to work on it any more until January. This is only a side project for me, I don't know when / if ever I will release it... If I loose interest I'll happily share the code. Cheers, Troy.

I have a few meters of synchromesh cable that I bought to use on a CoreXY platform... if I ever get around to building it. I can't comment on how it works yet, but the stuff feels more sturdy than belts and I think it will work great. Cheers, Troy.

Though they are more expensive,I wonder if we could gain some improvements with smarter stepper drivers like the L6470? You can't just slot L6470 drivers into the current motherboard unfortunately, but a new design with these drivers could reduce the software requirements significantly. Basically, the L6470 allows you to just specify a speed and distance to travel (RPM and number of steps) and then handle the actual stepping from there. It also supports micro-stepping configurable on the fly from single to 128-step. Though going beyond 16-microsteps would certainly be a waste for us. Cheers, Troy.

Concentric fill is one of the many nice features of Netfabb that are missing in the free slicers. It's a great improvement to the surface finish on many objects. Cheers, Troy.

Nik, I would consider a port to C++. As it is, the algorithm would be difficult to port to straight old C but a C++ port should be fairly straight forward. I used to do all of my personal development projects in C++, but these days I'm working with Java at work... I used to hate Java, but it's actually grown on me... I actually decided to do this in Java because I was considering cross-compiling it to JavaScript (as in Google Web Toolkit) and/or running it as a webservice with a web front-end... And possibly an Android port... Though I haven't done any of that and that was all secondary to running it on a PC anyway. The bulk of my Java code is the language parser itself for my parametric modeller. Ultimately, I am also interested in continuing with that project and seeing what I can evolve it into. The problem is that I just don't have much time these days. I only sped a couple of hours a month on my coding projects... Cheers, Troy

I've been thinking of writing a slicer too... It's a difficult proposition. I already have code that I wrote for a previous project that can take an STL mesh, break it into a BSP tree, and perform CSG operations on it using BSP math operations. Since it supports 2d planes as a primitive the slicing is simply a matter of doing an intersection operation on the BSP tree, which returns a solid 2d triangle mesh of the slice in a BSP tree. But then the devil is in the details... From here I find that it gets hard. I've not put any fingers to keyboard yet, so far I've simply mulled it over in my mind... But once I have a list of 2d cross sections actually generating the toolpath is far more complicated than it seems. At least to my mind. Firstly, I get a triangulated mesh. I need to break that down into parimeters and in-fill. The easiest way I can think of to determine what is upskin / downskin is to run through the whole list of slices twice from bottom-up, and then top down. For each slice do a BSP tree intersection between the current and previous layer. This would give me two regions - the overlap region (which would be regular infill) and the non-intersecting region, which would be downskin or overhang. Doing this from bottom up gives me the downskins and then from top down gives the up skins. My BSP math functions are pretty quick so it shouldn't be too bad to do this stage.. Once I have that, then I need to determine the outermost contiguous polyline... Since I will have mesh triangles going into the mesh infill I need to identify which ones are not adjacent to other polygons, sort these, and then form the shortest path across all of these faces.. The actual algorithm to accomplish this still eludes me. The BSP tree code I have is written in Java... There is still one bug in it somewhere that I havn't found that applies to 3d operations on large meshes over 2000 polygons... It also tends to produce lots of of branches on the tree because there is no optimization in picking the root. Each subsequent BSP operation then causes the triangle count to increase exponentially. I need to add a mesh optimizing function in after every CSG operation or the polygon count quickly gets to the millions for very simple meshes. This was all written for a parametric modelling language I've created similar to OpenSCAD. I'm not sure when (or if) I will ever actually release it. Cheers, Troy.

I have lots of Faberdashery Filament.... A little bit of almost all of their colours. It's great stuff. My favourites are their stone white (which is just a nice shade of white that is perfect for so many things..) and the Robot Silver. I even have some of the Gold and it looks great and quite convincing in the right light, though most of the time it's more of a dark yellow colour. The Glow in the Dark filament is great, I've printed a Yoda and a few other things with it. However, it doesn't glow for very long compared to other glow in the dark things... But is lights up like the sun under UV blacklight! I've also fount it to be slightly more brittle than the other colours. I'm less than impressed with the starry night filament though... Basically, the blue is too opaque so you don't see the sparkles in it very much. The blue should be much more translucent for a good effect. The only negative about Faberdashery is that the filament doesn't come on any sort of spool... it's just loose so it tangles easily. I've lost many good prints because of tangles. I've just finally bought myself a lazy susan to try the filament in a bowl on a lazy-susan trick that others have talked about, hopefully that will improve my success... I had a print fail yesterday 14 hours into a 16 hour print because of a tangle... These days, that's the only cause of failures I have any more. All of my prints here are done with Faberdashery filament, except for the wooden ones.... Maybe they'll carry that too some day. https://picasaweb.google.com/102544598518008997408/3dPrints?authuser=0&feat=directlink Cheers, Troy. Cheers, Troy.

Hi All, I got a response from NetFabb support today on retraction. Apparently they are "Finally in the testing phase of the retraction and we plan to release it with the next 4.9.4 version of netfabb by the end of the year". It sure would be nice if they would release a beta to the community or something.... Troy.