Simulation - Solid

[GoogleCodeExporter]

Make a simulation with solid removal, maybe using voxels.

I had started this project http://code.google.com/p/voxelcut/

Ideally this should work purely from the "NC Code" object ( a child of
"Program" ), so that it double checks the NC file, without using the
original operations, and also it can be used with old NC files.

Original issue reported on code.google.com by danhe...@gmail.com on 16 Jul 2009 at 8:56

[GoogleCodeExporter]

I have started this work.  I have added the GetShape() method to the 
CuttingTool and
NCCode classes to return a solid representing the tool (and the tool along the 
path).
 I have also extended the NCCode class to accept the tool number along with the line
and arc movements.  My difficulty is with interpolating the solid along the 
paths.  I
have also had trouble with the subtraction of the tool solid from the data model
solids.  They sometimes work fine (for drilling, for example) but other times it
seems to leave shells rather than solids.

I was hoping to add a 'number of flutes' parameter to the cutting tool so that, 
along
with the feed rate found in the GCode, we could calculate the material removal 
rate.
 I saw a demonstration of an NC generation program that kept track of the material
removal rate so that it sped up on the straight lines and slowed down when 
moving
through a concave corner.  The idea is to keep the load on the tool constant.  
I'm
not at this level yet but I was hoping to be on the way.

I also like the idea of being able to 'apply' the NC operations to the data 
model
solids so that the user could then use the 'edges' that are created to add 
subsequent
NC operations.  It's more intuitive, at times, to model by starting with a raw 
block
and adding machine operations to it.

All in all, the idea is something that apeals to me.

I haven't looked at the VoxelCut code so I may be on the wrong track.

Original comment by David.Ni...@gmail.com on 16 Jul 2009 at 9:27

[GoogleCodeExporter]

David,

Creating solids for the tools is useful for visualising them.

However, using the solid modeller to subtract solids for a simulation is asking 
too
much of it.
A solid simulation needs a very reliable subtract function.
I don't believe there are any solid modellers that can reliably do hundreds of 
solid
subtractions without making errors.
Open CASCADE is not the most reliable, either.

Solid simulations are usually done with simplified data.
1. Using a facetted model, triangles and/or polygons, like MachineWorks
http://www.machineworks.com/ ( I have integrated this into commercial software 
and it
works well, but it's not free ).

2. Use a 2D height map. This is only good for 3 axis milling, where there are no
undercuts and the tool is always vertical.

3. Use a voxel model. This is what I was trying to do with voxelcut ( using Ken
Silverman's code ). The resolution is fixed at 1024x1024x256 voxels. It is 
amazing
how he makes it work so smoothly, but this can't give a good enough accuracy for
engineering parts.

4. For turning only, it might be possible to store the remaining material using 
a 2D
"area" from the libarea project http://code.google.com/p/libarea/, this does 
very
reliable boolean operations with regions made from lines. The arcs can be
approximated by little lines and it is quite fast.

Dan.

Original comment by danhe...@gmail.com on 16 Jul 2009 at 11:30

[GoogleCodeExporter]

Dan,

I agree that the itterative subtraction of solids is what supercomputers are 
for but
I'm going to keep playing with it for a little while yet.  My efforts are due 
to the
fact that, not being a machinist, I am trying to get the software to warn me as 
often
as possible that I'm asking it to do silly things.  The design rules check is an
example of this.  I would love to get it to the point that it recommends feed 
rates
and spindle speeds based on tool type, material type and machine rigidity.  
Once I
get a feel for a material removal rate that my machine can handle, I am hoping 
that I
can set this in the data model and have the software warn me that it will be 
exceeded.

As I said, I agree that it is an exceedingly slow process.  It's just that I 
think
I'm reasonably close to a solution.  I would be happy to replace it with a 
faster
solution when one comes along.  Until then I'll keep playing.

There is the GNU Triangulated Surface Library (GTS) that can do the 
add/subtract as
an STL model but it uses GPL and I haven't used it before.

Your other idea about the libarea code interest me.  If we model the cutting 
tool as
a series of lines describing its cross section, we could move the cross section 
along
the tool paths to produce the triangulated surfaces.  It's something else for 
me to
think about.

As I said, I am quite happy to retire the code I'm adding when an alternative
arrives.  My method will be, as you say, extremely slow.  Perhaps even an 
overnight run.

Ta
David

Original comment by David.Ni...@gmail.com on 16 Jul 2009 at 11:52

[GoogleCodeExporter]

David,

The work you are doing for solid simulation will mostly be re-used, if we use a
different system for solid subtraction, so I'm pleased you are doing it.

The thing you are doing with "design rules", where I change the tool diameter 
and it
changes the other variables, is looking really good. Thanks for this.

GNU Triangulated Surface Library: I had forgotten about this. This might be 
ideal; it
mentions "Robust set operations on surfaces (union, intersection, difference)" 
which
is what we need. We already have functions to convert our solids into a list of
triangles ( so we can draw them ). I wonder if it's fast enough.

Dan.

Original comment by danhe...@gmail.com on 16 Jul 2009 at 12:13

[GoogleCodeExporter]

OK Dan,  I'm starting to see reason.  I can make this module work for drilling 
holes
and it sometimes works for profiles but it's intermittent.  It sometimes seems 
to get
into an infinite loop when intersecting TopoDS_Shape objects.  Other times it 
has
trouble adding the resultant shapes back into the data model.

I'm almost at the point where I will concede that you were right and that the
OpenCascade intersections code is just not the right idea.

I won't put that in writing of course.

Original comment by David.Ni...@gmail.com on 17 Jul 2009 at 7:06