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

[GoogleCodeExporter]

I can see it was something you had to try.

At the small CAD/CAM company I worked at for 11 years, our product used the 
Parasolid
modeller. Somebody there spent months trying to write a solid simulation by 
using the
boolean operations in Parasolid. He eventually had to concede that it was too
unreliable and it was too slow. Users need a smooth simulation.

Original comment by danhe...@gmail.com on 17 Jul 2009 at 9:14

[GoogleCodeExporter]

It's official.  I have given up on this.  I am happy to remove the code if you 
like
but I don't plan to.  I think that most of it is correct and that, if we could 
find a
better solid subtraction routine, the rest would fall into place.  If anyone 
else
wants to pick this up and run with it, please feel free.  I may get back to it 
at
some point but I feel beaten at this stage.

Original comment by David.Ni...@gmail.com on 20 Jul 2009 at 1:45

[GoogleCodeExporter]

Dan,
  I would be happy to help with this but I struggle to understand what flexibility we
have with the licenses.  Most of these libraries would be great to try but 
they're
all using GPL.  Is it enough to create another plugin that is released under 
GPL?  I
assume that, if we did that, we could call a routine from one plugin that was
implemented in another.  Perhaps a callback mechanism whereby the new solids 
plugin
could register itself as implementing particular subroutines.  This would allow
HeeksCAD to just call whatever registered callbacks were found.

  Ta
  David Nicholls

Original comment by David.Ni...@gmail.com on 29 Jul 2009 at 10:54

[GoogleCodeExporter]

no new features, just bug reports in this issue list

Original comment by danhe...@gmail.com on 24 Mar 2014 at 3:36

• Changed state: WontFix