Avoiding ridges when normal passes vertical

Welcome to BoardCAD forums Software BoardCAD developers Avoiding ridges when normal passes vertical

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #3617

    Anonymous

    I’m getting some annoying ridges with bullnose cutter when the cutter crosses the point where the normal goes from one side of vertical to the other side. This results in the cutter moving from cutting on one side of the cutter to the other side of the cutter, basically jumping the width of the flat section in the center of the cutter. This leaves a nice little ridge the size of the radius of the cutter (roughly). I’ve tried to get around it by cutting with the flat part when the normal angle is low which helps in some cases, but not all. Anyone have a good solution for this short of 1) making a special clean up cut and 2)cutting at a fixed distance apart regardless of surface normal

    #4501

    surfineurope
    Participant

    The default tool path generator cuts along a given path and tool compensates for that.


    while (s<bottom.getMaxS()):
    p=bottom.getPoint(s,t)
    n=bottom.getNormal(s,t)
    p=cutter.calcOffset(p,n)
    bottom_cut.append(p)
    s=s+length_step

    If we instead want the cutter to follow this path after tool compensation, i.e. to cut at fixed distances regardless of the surface normal, we need to search for the surface point that makes the cutter follow this path.


    while (s<bottom.getMaxS()):
    p=bottom.getPoint(s,t)
    z=math.fabs(p.z)
    t2=0
    p=bottom.getPoint(s, t2)
    n=bottom.getNormal(s, t2)
    p=cutter.calcOffset(p,n)
    while (math.fabs(p.z) >= z):
    t2=t2+0.01
    p=bottom.getPoint(s, t2)
    n=bottom.getNormal(s, t2)
    p=cutter.calcOffset(p,n)
    bottom_cut.append(p)
    s=s+length_step

    This makes the tool path generation very slow though…

    /Jonas

    #4502

    Anonymous

    Another alternative is to follow a certain path and use collision testing to lift the cutter above the surface. Still slow though.

    #4503

    surfineurope
    Participant

    Yes, that might be the best method, but will require code changes as collision detection is currently only supported for stl-cutters (and very very slow).

    Regardless of method, cutting at fixed positions does not work on the rail, so we need to handle the rail separately.

    /Jonas

    #4504

    Anonymous

    @surfineurope wrote:

    Regardless of method, cutting at fixed positions does not work on the rail, so we need to handle the rail separately.

    Wouldn’t that work if we did say 10 passes at 3mm apart at distance 0-30mm from the rail? Not that it would be a good way of doing it…

    I think I will try with a different cutter with a smaller ‘flat spot’

    #4505

    surfineurope
    Participant

    If we let the center of the cutter follow the outline and then move the cutter up to avoid collisions (or if we use the algorithm above) we will not cut at the outline.

    If the collision detection moves the cutter in the direction of the surface normal it might work though, but then we will no longer have fixed distances between each cut…

    /Jonas

    #4506

    Anonymous

    @surfineurope wrote:

    If we let the center of the cutter follow the outline and then move the cutter up to avoid collisions (or if we use the algorithm above) we will not cut at the outline.

    True, we would have to start at cutter radius out from the rail and then move it inwards in increments. Still not a good method though

    #4801

    pete_w
    Participant

    Hi guys this topic is pretty old and you probably have already resolved it, but I am dealing with this exact issue at the moment-

    I created a new offset routine to only offset the tool upwards in STLCutter.java, and just switch between the offset methods where necessary (ie the normal method out near the rails, Z-only on the deck).

Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.