cutsim material model

[Mark]

Anders,

I believe you said something about wanting more than a simple sphere for cutsim.

In g2m, I had a bounding box in machineStatus. For lines, I simply added points; for curves, I was able to add the entire curve to the bounding box.  Use of a bounding box allowed me to create a rectangular solid as the rough part, always sized properly for the g-code being simulated. Unfortunately, that bounding box class is part of OCC and would have to be rewritten. 

Most of the other stuff in machineStatus wasn't used. My plan was to enable the user to click on a surface or motion segment and find out what line of g-code, tool, spindle speed, etc.

I also wanted to allow the user to color or highlight surfaces based upon different criteria, such as 

• feedrate
• motion type
• coolant status
• tool number/diameter/type/etc
• line number range

This would be handy if someone wished to double-check that all machining of the final surface was done below a certain feedrate, the order in which various tools are used, etc.

I never got to it because I was concentrating on my remaining material model which was very slow, very rough, and very unstable.

Regards

Mark

[Anders Wallin]

> I believe you said something about wanting more than a simple sphere for
> cutsim.

The distance-fields for basic cutter-shapes, cylindrical, ball-cutter,
bull-cutter, are given in the Yau papers
(https://github.com/aewallin/opencamlib/wiki/References)

The naive approach is not to calculate sweeps at all. We just position
the cutter somewhere (x,y,z,a,b,c) and subtract it from the stock. We
then move it slightly along the programmed path, for nice results less
than the resolution of the stock-model, to for example
(x+dx,y,z,a,b,c) , and subtract again.

A smarter approach is to try to calculate the sweep, i.e. a
distance-field for an entire G-code block. For example a cylindrical
cutter moving linearly in the XY-plane would have a sweep consisting
of the start and end positions, and a rectangular "box" of removed
material between these positions. It gets slightly harder if you allow
z-movement also. Ball-cutter is similar. Bull-cutter and arcs are
significantly harder. There's a fair bit written about this in the
papers but I haven't looked much (yet).

I think I have seen this switch between naive/sampling and smart/sweep
in commercial cutting simulation (mastercam X and/or surfcam).
Straight cuts in the x/y plane go very quickly, and the
cutting-simulation slows down a lot with more complex 3D g-code.

> I also wanted to allow the user to color or highlight surfaces based upon
> different criteria, such as
> feedrate
> motion type
> coolant status
> tool number/diameter/type/etc
> line number range
> This would be handy if someone wished to double-check that all machining of
> the final surface was done below a certain feedrate, the order in which
> various tools are used, etc.

This is a good idea. My latest code stores a color for each
tool/volume. When the stock-model gets modified by this tool the newly
generated vertices have the color of the tool. Attaching the whole
machine-status data-structure to each octree-vertex is probably going
to cost too much RAM, but an integer index which is mapped to a
certain machine-status the user is interested in would work.
Similarly it will be possible to define clamps or other "no-go" stock
materials where cutting results in an error or warning.

Like you mentioned, the big task is getting the basic stock-update and
rendering working fast enough. Most of the fancier add-ons are very
doable after that.

Anders

[Mark]

On Sat, Oct 8, 2011 at 5:20 AM, Anders Wallin <anders.e...@gmail.com> wrote:

> I believe you said something about wanting more than a simple sphere for
> cutsim.

The distance-fields for basic cutter-shapes, cylindrical, ball-cutter,
bull-cutter, are given in the Yau papers
(https://github.com/aewallin/opencamlib/wiki/References)

Actually, I was talking about the model of the material being machined rather than the tool model.

Regards,

Mark

[Anders Wallin]

>> The distance-fields for basic cutter-shapes, cylindrical, ball-cutter,
>> bull-cutter, are given in the Yau papers
>> (https://github.com/aewallin/opencamlib/wiki/References)
>>
>
> Actually, I was talking about the model of the material being machined
> rather than the tool model.

ah, OK! If the user does not explicitly define a stock-shape (these
could be rectangular, cylindrical, etc) then I agree it would be
possible to look at the g-code bounding-box and take a guess at a
suitable rectangular stock based on the bounding-box of the G-code.
Linear moves are trivial to add to a bounding box, for arcs a bit of
calculation is required to find the point with max/min coordinate
along x/y/z with which to update the bounding-box.

Anders