codemaven

Impossible... I doubt it.... Extreamly difficult and frustrating - certainly. Cheers, Troy.

I'm not overly familliar with the Cura code myself, but in essense I don't think there's any need to sort the list of path segments based on any solid ordering criteria... You have is a 'travelling salesman' problem, which is notoriously difficult to solve optimally. But as far as TSM problems go, this one isn't the most challanging and Cura already does a good job at it and I doubt it really accounts for more than a few milliseconds worth of the overall slicing time. You basically just have a list of unordered discreet line segments, What you are looking to do is link the lines together in such a way as to minimize machine travel and how you go about doing this is open to all sorts of different approaches. I don't think it's particulairly feasible to tackle the sorting algorithm itself in parallel since to find the next nearest point you need to know your current point, thus it's an intrinsically serial process again.. However it could be interesting to explore and evaluate multiple target solutions to the problem in parallel to choose an optimal one. I.e. you could choose different starting points for the printhead and run different algorithms for path finding and compre them at the end to see which path would be the fastest to actually print. Perhaps a CUDA implementation of 'simulated annealing' with running multiple simulations in parallel and comparing the results to find an optimal path. Or, you could also apply genetic programming and use parallel evaluations of fitness and possible branching evolutions. All in all, this could be very interesting work and very educational, but I doubt you'd be able to really improve significantly on what Cura is already doing. With complex path optimization you may be able to reduce actual print time by a few seconds without significantly increasing slicing time... but I doubt in reality that the results would be worth the effort in any economical sense. However, since your goal isn't specifically to improve Cura's speed but only to learn and experiment then I encourage you to proceed and look forward to hearing your results. Cheers, Troy.

For the ultimate in adhesion and warp-free printing I often print with blue painters tape on the heated bed @ 60-70 degrees, It works great. I used to have a custom heated bed but I switched to the kit and so far it has been perfect for me. I'm mostly just printing right on the glass with just a tiny bit of glue stick and I have not yet had any adhesion problems with that. Cheers, Troy.

Actually, I see you are using ClipperLib in the cura code for clipping... I believe clipperlib is basically using something similar to a BSP tree to do the clipping. For my tree building, I build the tree from a stream as I read the stl file.. I found it to be in the range of a couple hundred miliseconds max for the largest models I could find on Thingiverse. I only need to build the tree once for the process. I tested on quite a few models including very large ones and very high resolution ones and none of them exceeded ~500ms for the building of the tree. Holes in the mesh were an issue for me, but I think that can be caught and fixed in a pass over the tree or at slice-time with some intelligence to generate segments to make the later manifold. Because the BSP tree already has no intersections it's easy to find verticies that are not shared by at least 3 polygons, these would be holes. Adding new triangles to an existing BSP tree to 'patch' any holes is fast. I _think_ this is how netfabb does it, though obviously I'm just guessing.

The BSP tree allows for very fast intersection testing. By testing the BSP tree against a plane I get back a sub list of all crossing points on that plane - i.e. the verticies / line segments of all of the triangles that intersect that plane and where they meet. This was my insperation: http://evanw.github.io/csg.js/ I originally started by building an implementation of something similar to OpenSCAD in Java... and while playing with that I realized that the same code for building 3d meshes by intersection of two BSP trees could also be used to return 2d 'slices' of a model very quickly. Also, my calculated BSP information returns back which parts of the plane are inside the model (hence need infill) or outside of the model. The result comes back as a 2D BSP tree which is incredibly fast to walk. I can then use another 2D inersection operation on the generated BSP tree with another pre-generated BSP tree which I've done ahead of time that contains just crosshatched lines, the result of that is a list of line segments only on the solid (interior) parts of the model - which is the infill. It's a matter of walking the tree and generating the G-Code from that. Cheers, Troy. Cheers, Troy.

Cura is already the fastest slicer out there. Compared to the older generation it's really quite impressive. I wrote a slicer myself a while back... It was around the time that Daid first started on the slicing engine for Cura (before he was hired by UM). My slicer was written in Java and was of comperable speed to Cura. I did have a threaded pipeline in it, but only in a couple of spots. Some areas that I had hoped to multthread turned out to not be possible - for example, I wanted to read the file in triangle by triangle and pass each triangle to the slicer immediatly running in another thread. But I discovered that .stl files are not cleanly ordered... Triangles are all over the place in the files and not neatly in order. To get around this I would have needed a much, much more compllicated and memory intensive way of building the BSP tree. Whereas by loading the file in first and then building the tree from it I got a much more ordered and optimized tree that was hundreds of times faster to walk. Some day I would like to get back to my slicer... I got it working in a basic sense, but it's far from complete. My priority is on other projects at the moment. Cheers, Troy.

There are bits that can be multithreaded... But multithreading is not the solution to every problem. It can seriously reduce performance in many cases. Some tasks are inherently threadable and others are not. You could slice different models on the build plate in parallel... The easiset way to do this is just to spawn a new instance of the slicer engine thread... But within the slicer it's a poor focus of effort in my opinion. Better to work on making the process more efficient than just throwing around threads at it and hoping that it will go faster. You will run into contention without serious tuning and simple problems. Because you need to identify top surface skins vs infill you cannot slice it in chunks, you need to slice it either top-down or bottom-up, layer-by-layer. As pointed out, there are other slicers out there that claim to be multithreded... to the degree that they actually are? not sure... but they are slower than Cura is already. I work as a software developer on stock market trading applications for one of the world's largest banks. The sofware I deal with is highly threaded and highly distributed across many cores and servers because we have to process hundreds to thousands of trades per second. I can tell you from experience that threading is not always the answer to every problem. Cheers, Troy.

John, Most of slicing is an inherintly linear task. Some small parts can be broken out... but for the most part you can really only process one polygon / line segment at a time because each segment is dependant on the last... You need to do one layer before you can do the next one because you need to determine overhangs, etc. Not all tasks lend themselves to multi-threading... If Step A requires Step B to be complete before it can begin then by multithreading it you are just locking resources and introducing overhead. I've looked at slicing algorithms. There are some places where it can be threaded... but the benefits would probably be small compared to the complexity... And the majority of the tasks involved simply cannot be done in parallel because of circular dependancies. It's like trying to construct a sky-scraper by using a crane to lift beams up to the top and letting them go... unless you build the base first they're not going to stay where you put them.... Cheers, Troy.

Great to see some practical tests being done. I've always been skeptical of the carbon fibre filament myself because by the way it's described I just can't see how it could possibly be stronger than regular PLA. It's just PLA filled with short chopped carbon fibres... That is really no different than Bronzefill or anything like that. What gives carbon fibre products their strength is that the fibres are long and interwoven or intertangled with eachother, which just isn't the case in the PLA. I actually wouldn't be surprised if they weakened it overall because I don't think the PLA will bond 100% to the fibre as it would if it were just homogenous PLA. Cheers, Troy.

Hi Drayson, The temp sensor ports on the Ultimaker are all designed to work with thermocouples, which require a thermocouple amplifier to work. That's the little board with the blue light on it on the top of the print head (on the UM1 at least...). I just used a thermistor for the temperture sensor instead, but I took advantage of the +5v power supply for the TC amp on the connector to charge a small 1F SuperCapacitor on a little board under my heated bed. I ran this through a resistor and a 35 degree bimetal thermal switch to an LED. Thus when the bed is above 35 degrees the switch closes, causing the LED to light. When the machine is powered off the supercapacitor holds enough charge to keep the LED lit for nearly an hour, but of course the bed cool off much faster than that. My bed itself is heated by 2 x 150 watt AC heating elements powered direct from the wall and swtiched through a solid state relay. The Heating elements are in series so if either of them fail they both will stop. There are two normally closed thermal 110 degree thermal switches positioned on each side of heated bed that are in series with the elements so that if either of them get above 110 degrees the power is cut. Cheers, Troy.

Hmm.. 5 mins isn't too bad for a heat up time I suppose. My current home-built solution is 300watts so it heats up to 70 degrees in just ove a minute... However I've bought the upgrade kit (and have it sitting under my desk awaiting install on the weekend) mostly for the 3-point levelling and improved z-stage. There are some features of my solution that I'm going to miss like the redundant over-heat cut-off sensors and the led light that indicates when the bed is hot (even with power off)... but I'm looking forward to trying the 'official' implementation. My current heated bed is aluminium with kapton tape... which is actually quite a pain in the but. The glass surface seems to be a better option. Cheers, Troy.

Yes!!! Now... if only I could send back my Fab colours to get them spooled up... I already have between 20 and 100 meters of every single colour that they sell...

Criminals have been doing this for years. This is the first I've heard of 3d printed facades, but a few years ago criminals were doing the same thing in the US and Canada with elaborate injection moulded pieces. Cheers, Troy.

Cool! I assume that is planned for release with PinkUnicorn too?

Nice to hear that Cura is continuing to progress. The feature mentioned in this thread is one of the few big Netfabb features that I miss which are missing in Cura... In fact, now that you have seperate speeds for outer shell vs inner shells I think the different layer heights for infill vs shells is the only significant feature that I find missing in Cura compared to NetFabb... Although the ability to do contour type top/bottom skins would be nice too. Cheers, Troy.

I've tried quite a few filament suppliers now and still find Faberdashery to be the best by far. I've tried 3 or 4 different colourfabb rolls and althought they're OK... My Faberdashery filament is better. I get a much nicer surface, the colours all seem better... the only thing I have issues with is the loose spool... I always run into tangling problems... But aside from that I wholeheartedly reccomend Faberdahsery, I've bought pretty much every colour they produce and have been using them for over 3 years now. Cheers, Troy.

I actually print Faberdashery filament at between 185-190 most of the time. Great quality at that temp, but I also generally keep speed around 40mm/s. Cheers, Troy.

Not that strange really. I found with LayWoo-3d that it worked better if I print fast. Some PLAs too. The problem is that you need to keep constant motion through the nozzle. Some materials can break down or fuse at the temperatures involved and therefore form a clot if they are exposed to the heated zone of the hot-end for too long. The best thing is to keep them constantly moving through the nozzle at a brisk pace. I understand this is a major problem with PVA filament as well. I've not tried Bronzefill yet... I pre-ordered last month, but it has not arrived yet. Cheers, Troy.

Hmm... Guess I will need to drop them an email...

Hope mine comes soon... I pre-ordered on June 6, so far no sign of it. Troy.

NetFabb can do this too, though NetFabb is no longer supported or reccomended... I paid for the comercial NetFabb years ago when it was the reccomended comercial option for UM (and the only alternative at the time was Skeinforge). NetFabb is now way behind in most areas and hasn't received any updates for it's Ultimaker support in well over a year... but although I use Cura for most things I still fall back on NetFabb for high quality prints. Cheers, Troy.

I print T-Glase at 240C on a heated bed at 50C with blue tape... It prints fairly well, but it's best if you print very slow with large (~0.2mm) layers. Cheers, Troy.

I doubt they've tested the wear extensively.... And it's difficult to really know how it will go in the long term... but I would plan on changing your nozzle after a while of using this. I've had my UM1 for over 3 years.. I recently changed the nozzle (had a really hard time getting the old one off...) but it made a huge difference in printing. I had barely noticed the slow degredation of print quality over time until I replaced it. Nozzles are definatly a consumable part. I've done a little bit of printing with woodfill (Laywoo-d3) and stone (laybrick). LayBrick epsecially probably contributes to nozzle wear, but it's not particulairly rapid or problematic. I'm also looking forward to Kai Parthy's new foam/felt like filaments, although I understand they contain some PVA which is a little scary given that it's prone to charring... But since it's only a component mixed with other plastic, and since it's intended to flow continuously and not sit in the nozzle like a support material usually does it may be ok. I'm looking forward to trying anyway. So many great new things! Cheers, Troy.

I've wondered this as well myself, but have never bothered to figure it out other Mathematically. The NetFabb defaults for the Ultimaker use a layer hight of 0.08 for the 'Ultra' quality and multiples thereof for lower resolution prints... And I've played around with this quite a bit trying all sorts of odd and even layer heights but I have always found the best results to be divisible by 0.08 on my machine. I get far better results at 0.08 than I do at 0.06, and similarly I get nicer results at 0.160 than I do at 0.1. Regards, Troy.

Hi, Is there a linux build of Cura 14.01? I don't see it on the download page. I'm currently running 13.06. Perhaps theres a PPA I can add to get a later version? Thanks, Troy.