chopmeister

Nice to know Rhino can handle itself nowadays, haha. That wasn't really the case years back when I had some experience with it during college. Back then, it would usually just hang. On any command. But still, that's brute force swapping each small face with a surface, which isn't usually what one would want (and which is exactly what one of those two apps in the first post does). You can't use that STP file to perform basic solid body actions like modifying fillets or chamfers and such, since there are none. And SpaceClaim's Repair feature on that STP still reports 195 tangency errors, 39 extra edges, 8 inexact edges, and completely hangs when trying some other repair functions. :mrgreen: But of course, that is beside the point if all you're looking for is that the object simply loads into your app of choice, to use for reference or something similar. In that case it's more than good enough of a solution.

There is reverse engineering software out there which enables you to use an scanned meshes as a base point for solid modelling. I think even SpaceClaim can maybe do something like that. It doesn't depend that much on polygons (since a flat plane can have 100k polys) but on the features. But you still have to model most of the stuff if you want it to be any good. And reverse engineering is mostly used in... well... engineering! So it's a particular kind of objects which are suited for solid modelling anyway, which makes it all a bit easier. Organic shapes are a different beast entirely. Imagine a rough rock wall. While you can easily model something like that, or 3d scan it, there is no way to do it in solids, since it would require hundreds of thousands of surfaces, which (unlike a polygon which has only 3 vertices to it) have loads of data describing them. In contrast, a face like on your link would require two dozen or so carefully placed surfaces to recreate (which isn't really that bad), and nonetheless somebody must have put some manual labor into it. So in reality the answer is yes and no. Yes, it's "possible" but on a limited number of scenarios, and no, there is no easy way of doing it. I hope that clarifies what I meant in the first post. Or to elaborate: while it is certainly possible to recreate an object in solids based on meshes (which is what your scanning bureaus do), it is virtually impossible to "convert" it in a standard way like converting video or audio formats, which is what I thought you were asking about. And no, I haven't used a scanning bureau myself, but I do 3d modeling for a living, so I usually try to help with 3d related subjects here on the forum. Still, I think my previous question has merit - why do you need that shape in your solid modeler? Maybe we can find an easier and more effective solution if you elaborate your specific situation a bit.

You can't convert STL or OBJ to STEP. STL and OBJ are polygonal mesh formats, while STEP is a solid body format. Because STEP doesn't work in a way polygonal meshes do (it's basically a lot of mathematical functions describing surfaces) you can't scan into STEP. 3d scanners output point cloud data which then gets triangulated into a mesh, thus you get your STL, OBJ, 3DS, or whichever mesh format you choose. You can go from solid to poly, but not from poly to solid. The solutions you mention here are actually "hacks", ie. they work by detecting (with the user's help) features on the model that can be easily described with surfaces and recreate a solid model based on approximations of those features. It works with simple models, and low poly models, but not much else. There is no solution for what you are looking for.. The better question is what do you need to do with organic forms in a solid modeller anyway?

No clue about the Ulticontroller, I was thinking of getting http://www.sainsmart.com/3d-printing/3d-printing-modules/sainsmart-smart-controller-ramps-1-4-lcd-12864-led-turn-on-control-for-3d-print-1.html instead. The heatbed driver works like a charm, no more relays for me. I did a pseudo-review on my blog, IDK if you've seen, but it covers the basics. I'm not sure but I seem to be having some issues lately (I'm not sure if it's related to the board though), so if you are planning to buy such a board I'll PM you about it, to quit the thread hijack.

I'm aware of the ESD issues, but I don't think the thermistor should have been electrically connected with the nozzle. Anyways, just got a bunch of thermistors, so I'll switch and test today, Wish me luck. PS. I don't have UM electronics, I switched it for Megatronics V3.0 with DRV8825 drivers a while ago.

I honestly don't have a clue. First off, I had no idea a thermistor even could explode. Secondly, I don't see how touching the nozzle with tweezers (which are insulated with rubber grips btw, just for the record) could produce that effect. I didn't short anything except the nozzle with, well... the nozzle! If the thermistor was shorted in any way, it wouldn't report temperatures as normal, which it did. Everything was 100% normal until the fatal tweezer touch. I just hope my new electronics didn't get fried in the process. So far it seems ok, I'm getting some new thermistors today and I'll try to replace the broken one. We'll see what happens next...

I gotta share this with you guys... So there I was yesterday happily printing away throughout the day. And in the evening when I started my soon to be final print, I extruded a bit of material to prime the nozzle, and then tried to remove it with tweezers, like I usually do. But, when I touched the brass nozzle of the UBIS with the tweezers, the thermistor EXPLODED. Yes you read that right. There was a flash, and a loud bang, and bye-bye thermistor. How on earth did that happen? o.O

For true displacement to work, you need a poly model, not NURBS. So Rhino is a shoddy choice for messing with displacement, especially since it has no proper mapping tools like it's mesh-based brethren do. Blender on the other hand has all you need, but UV mapping is not all that simple if you are just beginning. Let's say you want to displace a rectangular wall, like Nick did here. You can selectively apply your map to the polygons you want. That way the outer facing wall will have a brick texture, for example, while the other five sides of the wall tile will remain perfectly straight. All 3d apps have various mapping types (planar, box, spherical, UVW unwrap etc.) which determine how your map is "projected" onto your model. Those same controls define what size the map is once projected to the model, and which polygons will be affected by that projection. In order for displacement to do it's job, you need to have a sufficiently segmented surface to begin with - no detail in the map will be visible if it's smaller than your smallest polygon. Also, like Nick said, the maps you use should be pure grayscale. Generally 50% gray is zero displacement, pure black is maximum negative (or indented if you will) and pure white is maximum positive displacement. The application you use will have controls for defining the actual range in real world units between black and white. There are nice apps for generating displacement maps, so you don't have to mess too much with that. Take a look at CrazyBump. Just load a photo and it can output various maps, it's very easy and intuitive. Ideally you will end up with something like this: They look the same, but the left one has around 165000 faces. Which is too much, since more faces mean more slicing time, and possibly many small gcode segments which can mess up your prints. You need a way to optimize the topology, and you can end up with something looking the same but having only 5000 faces, like the right one in the pictures. This was done in 3dsmax, but blender has all the same options I suppose, only I don't have a clue about blender so I can't help you there. For easy stuff like brick textures it's usually better to use procedural maps than bitmaps, but that's too big of an area to cover here. I hope that helps a bit and good luck with your endeavors!

Today I tried to print a Yoda bust. The model I used is optimized, so it has less polygons than the one on Thingiverse. I sliced it with Cura 14.01, 14.03, and 14.05 RC2 (on a Win8.1 machine). Each time I tried to print it the motors were twitching and stuttering on the perimeter lines (but working properly on infill lines). Since I've done a lot of mods to my UM including switching to Megatronics V3.0 at first I thought it could be a hardware/firmware problem. I even tried switching to Repetier firmware, but to no avail. I haven't really seen this thread before, so I didn't know others had issues with the skin quality in recent versions. The stuttering was so severe, that I still thought something was wrong with my machine, so I tried slicing the same model in Kisslicer - and it worked without any problems with both Marlin and Repetier firmware. I found that the problem in Cura seems to appear only on models with very small features. I then inspected the gcode in Repetier host, and here are the comparisons: The gcode from all three versions is basically the same. And you can see there's lots of small, jagged segments, which apparently cause buffer errors on my machine. The Kisslicer output on the other hand is very smooth. Here the difference is very apparent, especially on the area of the mouth, and the right shoulder. I must admit that I haven't had any problems printing regular mechanical parts, which don't have as much polygons or small features, and that my machine may very well be more prone to buffer errors for some reason, but still, there seems to be some sort of weird stuff happening with Cura's gcode. As a side note, the file sizes are completely different: Kisslicer: 4 MB Cura 14.01: 6.7 MB Cura 14.03: 10.3 MB Cura 14.05RC2: 6.9 MB I haven't tried the 14.04 versions but I'm guessing it will be the same. Any idea why Cura produces so much more little segments? EDIT: I forgot to add, I AM printing over USB, so that's a factor, but I've printed dozens of those very same Yodas before, from the same PC, the only difference is that I upgraded to Win 8.1 in the meantime.

That depends on how the original files are made. The laser beam has a given thickness, usually around 0.1 mm, so common practice is to offset certain parts inward/outward to get a tight or loose fit. When working with wood or plywood this is not so critical since it can easily be compressed with a little force if you missed something. You don't have that freedom with acrylic or aluminium so you have to be careful and plan ahead.

The blocks can work with 303 GT2 belts without a problem, I just need to make the appropriate tabs (which I wanted to do yesterday, but couldn't find the time :( ), which have an inverse GT2 tooth profile in them so they keep them in place (like the Reptar blocks have), instead of the raised area which tensions and clamps the belts now. As for the 6mm rods, the blocks were designed to provide 269 mm of space between them for the rods on both axes. At least according to the latest UM drawings. It is possible that some printers print them a bit too thick due to overextrusion, and when that combines with imprecisely cut rods, problems start appearing. A bit more room could be added, but I fear that would compromise the rigidity of the blocks. On the other hand, situations like that are exactly why I uploaded the STEP files. :mrgreen: There's just too many different setups, and while I try hard to cover as many as I can, you can't get them all.

Hey there! I wasn't really looking at the forums for a while now, too busy at work and stuff... But, there should be no problem modifying the TwisterBlocks to work with the GT2 belts. They were originally designed to work with stock belts which generally come a bit loose, especially over a longer period of time, so they provide crimping and tension via the same part. All that is needed here is to change the little tab a bit and the rest of the blocks stay completely the same, so if you already printed them out, all you need is to print out those 4 small parts again. I will do the design right now, I have some GT2 belts laying around somewhere, so expect an updated part sometime today. In the future please don't hesitate to contact me here, or on TV, or YM if you need help with some of my designs, I'm always glad to be of assistance if possible. Sorry for the thread hijack Jonny!

If I remember the yoda STL correctly, the eye problems are a result of messy boolean operations. The best solution (and usually the only one) is to load the stl in a poly-modeler such as 3dsmax and fix it by hand.

What usually works for me in that situation is using the same size torx screwdriver.

I change whole printheads very often for various experiments. That's why I designed https://www.youmagine.com/designs/twisterblocks. Not exactly what you proposed, but a step in that direction. I'm working on an easily replaceable hotend mount since I have the E3D and UBIS now and plan to get a Merlin hotend too.

Can anybody tell me the dimensions of the idler bearing in the UM2 extruder?

I wouldn't be too concerned with that test. The UM2 is still in its young age, a lot of things will be improved upon with time, as it was with the UM Original. Besides it comes with added value makerbot will never have - namely the UM community. Which in my humble opinion is irreplaceable.

The E-steps in the firmware don't really matter if you set them in Cura machine settings. Those will override any value in the firmware, and the firmware from marlinbuilder should work just fine with your machine.

That's an awesome print there! Good work, and congrats on the success.

Here's the original extruder assembled so you don't have to mess with the parts: https://dl.dropboxusercontent.com/u/6806756/UM2%20Extruder%20Assembled.zip

Awesome, I just downloaded the files, I'll go and dig into it a bit now. Thanks Harma!

Well, we're all seriously off topic now, since this is turning into a discussion about 3d modelling. Maybe this warrants a separate thread. That being said, it is not completely true slicers don't care about topology. I've had to fix dozens of models from other people over the years because they wouldn't print, mostly due to liberal usage of booleans. And even if they don't care, you should. It's good practice and solves all the problems in advance. I'll always rather have correct models than hope the slicer, renderer or whatnot won't notice. And good topology facilitates easier subsequent changes. And just to set the record straight, the industry standard practice is to avoid booleans whenever possible, and anybody who works with 3d professionally will tell you the same (obviously, that does not apply to solid modeling, which is based on boolean operations anyway). There are good reasons for that, and it is not something either jdudeo or myself just invented. If you see no disadvantages in your own workflow, good for you, but that doesn't mean they aren't there. As for NURBS. I don't use them per se, since I do architectural stuff mostly, so poly modelling is much more suited for my purposes. Plus, I personally find the workflow slow compared to the speed I can get with pure polys. (ie. NURBS in max suck ass and their development was abandoned a long time ago ) Not to mention low-poly modelling is the only way when dealing with gazillions of instances and such. And tehnically speaking, MeshSmooth creates a Catmull-Clark subdivision surface, not NURBS, although it looks and acts similarly to one until converted to regular polys. But now that you mentioned splines, I totally see how you could "simulate" a print in Max with a spline exported from cura. Would be a cool feature, I agree.

No one ever said progress is easy on the fingers. :mrgreen: On a more serious note, I have a feeling we are straying from the original purpose here a bit. Although I like all the new drive mechanism ideas, I think we should focus on something proven, more in the line of Robert's idea. Designing and testing a completely new kind of filament transport takes time, and I'm sure the UM2 guys would love to print sooner than that. I've sent Harma a PM to see if we could get our hands on any solid models of the UM2 extruder, but haven't received a response, maybe Ian could do something about that?

Nice work! I love the super tiny nozzles, and the print look really good.

Installed and printing. I'm using some FormFutura filament, and I get good extrusion at 195C @ 55 mm/s. It seems to me that either this filament has a really low melting point, or my thermistor is showing lower than real temps... Other than that, it seems very good, but I still gotta do some tweaks all around the printer and test some more.