Jump to content
Ultimaker Community of 3D Printing Experts
  • Sign Up


  • Content Count

  • Joined

  • Last visited


Community Reputation

0 Neutral
  1. Impossible... I doubt it.... Extreamly difficult and frustrating - certainly. Cheers, Troy.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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...
  13. 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.
  14. Cool! I assume that is planned for release with PinkUnicorn too?
  15. 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.
  • Create New...