Fuel Injection Manifold

[BobWarfield]

Took me a few hours to get rid of all the darned "Boolean xxx Failed", but I was pretty happy with the result in the end:

http://www.thewarfields.com/img/Toys...erspective.jpg

A few more shots here for those interested:

http://www.thewarfields.com/MT/CC351CEFI.html

I wish I could give newcomers some good tips to eliminate those model problems (e.g. Boolean operation failed), but it boiled down to doing exactly what the Rhino FAQ says to do. I had the best luck analyzing the edges and eliminating the naked edges. The big issue was with the highly irregular blended shape that is the port passage:

http://www.thewarfields.com/img/Toys...latePersp4.jpg

It's the green piece. I was able to gradually work out all the naked edges. The last trick was it turned out that moving it ever so slightly when I wanted to difference it out of the blue piece suddenly made things start working. Go figure!

I had no luck fiddling with tolerances at all. In any event, the whole drawing took about 2 1/2 hours to do, and I'm pretty pleased with how it came out.

It's funny, but I find myself wishing all software would pan or repeat the last command with the right mouse button after using Rhino for a little while!

Cheers,

BW

[chmillman]

If you know that you are designing a boolean "cutter" best practice is to design it a little longer than you need (so that the cutter fully penetrates the object to be cut and sticks out of the outer surfaces a bit). Rhino has trouble with concurrent surfaces and edges sometimes (V4 is a good bit better than V3).

If you are having consistent failures, try running the Intersect command between the objects - with closed polysurfaces you should get one or more closed loops. If even one of those loops is open, the boolean will fail.

Remember also that anything you can do with a boolean operation can also be done with manual trimming and joining. Sometimes this is simply the easiest thing to do rather than going to look for why the boolean failed.

Good to know people are reading the Wiki FAQ to find answers. --ch

[BobWarfield]

I found Intersect (also mentioned in the FAQ) to be much less useful than analyzing the edges for naked edges. Intersect revealed tons of issues, but it was not clear what to do about them, whereas knowing where the naked edges are it becomes relatively easy to work on it.

Normally I do make the intersect objects a lot larger. In this case, I needed to plan ahead more. I was so focused on creating the complex shape, I made it exactly the right size instead of slightly larger. One more thing to add to the benefits experience brings.

Given how much trouble this causes people, I am surprised they haven't worked harder to automate fixing it. If the heuristics in the FAQ worked for me, and are sufficiently mechanical (they were), they could have been automated. Doubtless every case would not be handled, but I'd bet a fair number could be.

Best,

BW

[Adobe Machine]

Very nice work Bob...Funny a long time ago we built almost the same shape injectors ( 5 pieces , this was long before CNC ) that were for a 214 CID Offy engine..each funnel had a single nozzel, using an Enderle 80 A alcohol pump. Injector pressure at the nozzel was a whopping 230 lbs..Estimated wet flow was a !wow! 180 cfm per injector!.. Yours would have to flow, maybe what ? 260-300 cfm ?

Can you estimate flow with your program ?Can you show estimated flow pattern ?.. The reason I ask is I'm trying to develope a 4 valve , dual cam set of heads ( hemi style) that have a BB Chevy bolt pattern .Aries did this, but used the regular cam location . This set up worked, but our flow was restricted due to push rod location. DuaL over-head cam ( per head) set up would improve this, but I'm having a problem calculating total flow..
The Big piece of 6061 billit I have purchased for this project is so expensive, I just hate to start milling untill I have the total flow calculated and a flow pattern inside the intake port on the head...I'm just a little slow with the computor and CAD programs ( really, really slow ) so any help would be appreciated..

Thanks

Adobe (old as dirt)

[BobWarfield]

Adobe, sorry, I do not have software that will estimate the flows. For my purposes, a street driven hot rod, this thing will be way overkill anyway.

Your DOHC project sounds killer. Any pix to share?

I suspect there isn't any software that would calculate head flows very accurately anyway. Fluid dynamics and all, ya now. But perhaps I'm behind the times.

Best,

BW

[chmillman]

Well, as far as naked edges go, it's best if you don't have any... Since Rhino is surface modleing software, it will let you make almost anything, but it doesn't absolutely guarantee that it will be "watertight". A solid modeler will only let you do that, if it's not watertight, it isn't allowed (the operation fails). So, learning to model in Rhino without creating naked edges is an important skill.

While you're modeling, if you're working surface by surface, my advice is to join things up as you go and check for naked edges. If something has trouble joining, or you see a naked edge, go back immediately and correct the problem before continuing. This way, when you get to the end of your task, you will not need to go looking for naked edges. It is a lot harder to fix a finished part that has a bunch of naked edges or tolerance problems than it is to build it correctly in the first place.

As far as automating the proces of "correction", it's pretty hard to do, there are so many possible problems. One thing that has been done for V4 (and in fact is being done continuously) is to improve the intersector function, which affects pretty much all the major operations - trims, splits, booleans, fillets, etc. So there are fewer problems with these operations and they are sucessful far more often. --ch

[NC Cams]

Adobe = Cyril Batten, of Batten Heads fame, already did that nearly 10 years ago (4V dohc head on BB Chevy block).

He used an Arias block due to bolt pattern issues. The project was called "B4" and there are still a few floating around out there someplace, mostly in drag boats and some tractor pulling if I recall.

We built the cams for a few of them - that's the sort of trick stuff we specialize in - and we already know what NOT to do with regard to cam drive and other valve train issues.

[BobWarfield]

Originally Posted by chmillman Well, as far as naked edges go, it's best if you don't have any... Since Rhino is surface modleing software, it will let you make almost anything, but it doesn't absolutely guarantee that it will be "watertight". A solid modeler will only let you do that, if it's not watertight, it isn't allowed (the operation fails). So, learning to model in Rhino without creating naked edges is an important skill. While you're modeling, if you're working surface by surface, my advice is to join things up as you go and check for naked edges. If something has trouble joining, or you see a naked edge, go back immediately and correct the problem before continuing. This way, when you get to the end of your task, you will not need to go looking for naked edges. It is a lot harder to fix a finished part that has a bunch of naked edges or tolerance problems than it is to build it correctly in the first place. As far as automating the proces of "correction", it's pretty hard to do, there are so many possible problems. One thing that has been done for V4 (and in fact is being done continuously) is to improve the intersector function, which affects pretty much all the major operations - trims, splits, booleans, fillets, etc. So there are fewer problems with these operations and they are sucessful far more often. --ch

CH, I added a "mini-tutorial" on my web page for this drawing that details what I did:

http://www.thewarfields.com/MT/CC351CEFI.html

I hear what you are saying, but based on what I did, and on what the program is capable of doing, I remain unsatisfied with how hard it was to get there. Now perhaps my technique was not ideal, you can see what it was based on said tutorial, but the operations used were pretty simple, it seemed obvious what was wanted, and Rhino could have done better.

How?

Well let's just consider the BlendSurface command I used to join the round throttle body inlet to the square intake port outlet. Why would it ever be a good idea for that command to leave naked edges between those surfaces? You can't just tell users it's a good idea not to have any Naked Edges when they didn't think they created any in the first place!

If it ever was a good idea, why wouldn't the default be to eliminate them automatically?

The program could do what I manually had to do, which was to identify the naked edges and then do JoinEdge between each two with its neighbor. By considering only the edges of the original 2 surfaces and the new blending surface together with their proximity, this seems like something that could have been automated for 90% of cases to produce a good result.

Let's consider the second case. Once I had a closed surface with no naked edges for the intake port solid, I wanted to use Boolean Difference to cut these ports out of the manifold billet. Once again: "Boolean operation failed."

Why?

Apparently the edges of my port solid were too close to the edges of the billet. Once again, I can ask the same question. Why is it ever a good idea for the operation to fail in that case? There are several options:

1. Make the default behavior not to fail but provide an option to fail if desired.

2. If it's never a good idea to fail, err on the side of making the "subtracted" object large enough to pierce the "remaining" object.

- or -

3. Cut the cavity even though it doesn't pierce the surface. This may be what the user wants.

Having an operation fail with no clue what to do next is just the worst program design short of failing with hidden data corruption (that happened too, but v4 is a Beta, so it's okay! ).

Note how I am approaching this. Never mind what the program does. When is it ever a good idea to do that? Why do we need it to do that? Is it a common desire for it to do that, or a seldom used special case? Is the program just doing it because its hard not to? Why force these burdens onto the user?

In software design, you can expose too much of the internal complexity, erring on the side of complexity because your view is you can't decide for your users what they want and you just want to give them the most power and flexibility. In my experience (yep, I'm a software guy, written a lot of it, run a lot of engineering groups, Quattro Pro is one I wrote, Borland is one engineering group I ran), this is a mistake, particularly if the internal complexity is as hard to understand as is the case here.

Instead, you need successive disclosure (yes, you can turn that on if you must) and defaults that favor the simpler tasks. Or, as Alan Kay once said, "Simple things should be simple and hard things should be possible."

Put another way, Rhino seems to err in some cases on making it easy to do seldom needed things (like creating naked edges) and hard to do things that are needed constantly (like making water tight models).

To be clear, I am still a happy Rhino user, I just think the program should be doing more for me. It has tons of power, but ease of use for a drawing like this one seems a bit elusive. Rhino's forte is supposed to be organic shapes, but that's where I had a lot of trouble. You can leave it to users to figure out "important skills" like not making naked edges, or you can make the software more aware of how the users think. Given that this is the first thing discussed in the FAQ, its clear this is a usability problem for Rhino.

Best,

BW

[ger21]

Fwiw, I've used a lot of different 3D packages over the last 10 years or so, and one thing they all have in common, is that Boolean subtractions will fail at some point. And the failure rate goes up with the complexity of the parts you are subtracting.

[chmillman]

Well let's just consider the BlendSurface command I used to join the round throttle body inlet to the square intake port outlet. Why would it ever be a good idea for that command to leave naked edges between those surfaces? You can't just tell users it's a good idea not to have any Naked Edges when they didn't think they created any in the first place!

OK, here goes - I looked at your tutorial...

Good idea to use the blend surface command, bad execution... You could also have used Loft, Sweep 1 or 2 to create different results.

Blend surface tries to create a tangent surface between the edges indicated - and you don't want tangent there... What you want to do is extrude the circular edge as well as the rectangular edge to make "dummy" surfaces, then BlendSrf between those. Then you delete the dummy surfaces, and join them up to your orginal surfaces. That will create the shape you want, I think.

Also you are expecting BlendSrf to join itself up with the input surfaces - which it doesn't do, as it's not a "solid" command, but a "surface" command. But I think Join might have joined your object up into a solid without JoinEdge (according to your image).

JoinEdge is a no-no, as it is just a local tolerance override and will cause you problems later. You need to get it right without that. (that's in the FAQ as well).

As far as the Booleans go, I'm actually for not having "fuzzy logic". It either fits or it doesn't. The program should not be making decisions for you about what kind of error you will tolerate. That being said, concurrent surfaces should work most of the time now. And I was amazed that yesterday I could BU together dozens of tubes to create a latticework structure, and nothing failed (V3 wouldn't have a chance in hell of doing that).

Making water tight models is a matter of practice. I rarely have a problem, and when I do, it's mostly because I haven't approached the problem correctly.

I'll be happy to comment further, but it's late here and I've got a plane to catch tomorrow morning... --ch

[BobWarfield]

Excellent, the new approach works and leaves no naked edges. I added a "Part 2" to the tutorial.

My reaction at this point remains mixed. It's great that it works, it's great that I learned something, but it just didn't have to be this hard. Rhino just did not do a very good job blending the two surfaces unless I get them moving almost in the right direction to start. Further, I had to know quite a lot about BlendSrf's behavior (the tangency aspect, the naked edge issues, etc.) to get it to work. BlendSrf was evidently the right command, it just is very clumsy to use.

I'll put it more plainly. Gerry says all these packages fail at some point, and it gets more likely as complexity goes up. I'm trying to join up a blinking rectangle and circle and subtract that from a big block solid. If that's viewed as a complex scenario where you have to be an expert with lots of practice to make it work, the program is too darned hard to use and should be simplified. It can be done without loss of power for experts and with great improvement in ease of learning for beginners.

I have OneCNC, and I can download a copy of Alibre. I hadn't bothered to learn the OneCNC modeller, because I thought Rhino was easy (having only messed with rectilinear and cylindrical objects), but I am curious how easy this exercise would be in those programs. If I find time, I will attempt to repeat it and report on the result.

Best,

BW

[ger21]

While it may seem simple, the object in the second from the last pic on your site, http://www.thewarfields.com/MT/CC351CEFI.html , is not a simple shape when it comes to booleans. And I meant all the ones I've tried, not necessarily all of them. But, I've seen it in Alibre Xpress, Rhino, AutoCAD, Lightwave, and probably a few others.