Ticket #4260 - dressup losing speeds and adding unsafe cuts.

[mlampert]

I have located the offending line in PathDressupPathBoundary.py

Code: Select all

            pos = cmd.Placement.Base  ### this is causing spurious tool-crashing path.

That is certainly not the problem. The problem is that you have restricted the z-axis of the BoundaryDressup to be below your safe/clearance height.

[freman]

thanks for the input.

Maybe I'm misreading this but the boundary of the dressup is where I want to limit the cut paths to , it should not limit safety and clearance moves ( and it does not ). I should be free to set the misnamed boundary "stock" of the dressup to whatever I need to selectively limit the existing cut paths. That may include top of the physical stock or even inside it ( that need was discussed elsewhere and I need to submit the PR to free up clamping dressup boundary to be >= stock ).

The problem with the current implementation is that, because it does not know the machine position from the information available in the path commands, it is making one up and inserting it to get an 'edge' to work from as it does for subsequent path where it does have the position.


This results in the insertion of a new cut path to a point which has nothing to do with the input data, in order to have somewhere to attach an edge to the true start position of the actual path we are trying to crop.

It is also a consequence of the defect ( which was discussed elsewhere ) that it is "cutting upwards" to safe ht before moving to clearance. Normally this is just an annoyance ( very slow non cutting moves up ) since the upwards cut is vertical, it's just raising the tool. In this case it becomes 3 axis cut ploughing through protected space.

Talking this through, it seems it may be better if it used (0,0,clearance) rather than (0,0,0) as the fake point but [ but this would still be problematic in some cases ], I think the real solution is to avoid the need for inserting a fake machine position and removing the unnecessary cut-to-safe and go straight for move-to-clearance, as is specified in the original path.

Code: Select all

(Compensated Tool Path. Diameter: 8.0)
G0 Z3.000  # clearance ht
G0 X68.000 Y1.000

I was considering exempting the first two moves : move to clearance and move to (xstart,ystart, clearance) from the processing loop. They should not be affected by the dressup anyway and at that point the algo would have a valid x,y,z for the calculations. I'm not sure whether that is totally safe for all existing paths it may be fed, though. Can we count on all ops beginning with those two moves? Can you advise on that?

[Kunda1]

OP opened issue #4260. Thread has been renamed to reflect this

[freman]

thanks, I forgot to do that.

[freman]

I was considering exempting the first two moves : move to clearance and move to (xstart,ystart, clearance) from the processing loop. They should not be affected by the dressup anyway and at that point the algo would have a valid x,y,z for the calculations. I'm not sure whether that is totally safe for all existing paths it may be fed, though. Can we count on all ops beginning with those two moves? Can you advise on that?

I have a provisional mod which applies that strategy and seems to fix the tool crash problem.

Any comment of suitability of this approach?

[freman]

adding feedrates to this line in PathDressupPathBoundary.py seems to fix the missing feedrates on G2 paths:

Code: Select all

  commands.extend(PathGeom.cmdsForEdge(edge, flip, False,50,tc.HorizFeed.Value,tc.VertFeed.Value)) # add missing HorizFeed

[mlampert]

I have a provisional mod which applies that strategy and seems to fix the tool crash problem.

Any comment of suitability of this approach?

Yes, the dressup does what you told it to do. If you limit the height below the safe/clearance hight it's your own doing. And it does correctly limit all moves of the original app to the height you set. The moves which go above that are the moves the dressup inserts because you excluded the original path.

[mlampert]

adding feedrates to this line in PathDressupPathBoundary.py seems to fix the missing feedrates on G2 paths:

Code: Select all

  commands.extend(PathGeom.cmdsForEdge(edge, flip, False,50,tc.HorizFeed.Value,tc.VertFeed.Value)) # add missing HorizFeed

what if the edge is horizontal?

[freman]

adding feedrates to this line in PathDressupPathBoundary.py seems to fix the missing feedrates on G2 paths:

Code: Select all

  commands.extend(PathGeom.cmdsForEdge(edge, flip, False,50,tc.HorizFeed.Value,tc.VertFeed.Value)) # add missing HorizFeed

what if the edge is horizontal?

Good question. Both vspeed and hspeed are supplied with the mod I suggested, rather than both defaulting to zero at present. Pathgeom.py seems to deal with this is a sensible way already if it is given a chance:

Code: Select all

def speedBetweenPoints(p0, p1, hSpeed, vSpeed):
...
    print("  pitch = %g %g (%.2f, %.2f, %.2f) -> %.2f" % (pitch, math.atan2(xy(d).Length, d.z), d.x, d.y, d.z, xy(d).Length))
    speed = vSpeed + pitch * (hSpeed - vSpeed)
    if speed > hSpeed and speed > vSpeed:
        return max(hSpeed, vSpeed)
    if speed < hSpeed and speed < vSpeed:
        return min(hSpeed, vSpeed)
    return speed

Maybe that code can be reviewed against the recent discussion on this point.

[freman]

I have a provisional mod which applies that strategy and seems to fix the tool crash problem.

Any comment of suitability of this approach?

Yes, the dressup does what you told it to do. If you limit the height below the safe/clearance hight it's your own doing. And it does correctly limit all moves of the original app to the height you set. The moves which go above that are the moves the dressup inserts because you excluded the original path.

Yes, for the most part it does exactly what I asked it to. All the original paths are cropped correctly and have safe and expected moves between the ends of now cut segments. That much is perfect, even when I limit the height at which I cut-off the paths.

The one thing I did not ask it to do and which is not in the original path is the new 3 axis cut path from the actual machine position to a derivative of a faked machine position at (0,0,safeheight) .

This move is supposed to be part of the initial move to clearance ( which is getting split into G1 + G0 ) which is always a vertical upwards move in the original path. A safety move has been converted into a tool crash, that is not what I told it to do.

If this was resulting in G0 into the stock on existing plunge paths, "it's your own doing" maybe a legitimate though unhelpful response. It does not, the code handles this perfectly and does G0 to safeheight only.

I would also point out that with the workpiece stock legitimately bounded at z=0 , the z=1 is the default for the boundary for the dressup "stock", so I won't be the last person to do this.

Clearly this is a circumstance which the original code failed to anticipate. I have identified a situation which leads to a serious tool crash and machine damage and have coded a potential solution. I think it would be more productive to discuss whether this solution ( which avoids inserting fake points and inherent risk of spurious, unanticipated 3 axis cuts in safe space ) is a robust solution.

All the AreaOp path tools seem to start with this G0 to clearance then a G0 to the x,y of the first true point in the path. My fix relies on these two lines and passed them without modification ( which is what dressup should be doing ) and relies on the latter move to get a legitimate machine position. Are there any tools creating paths which do not start like that?

I lack the breadth of experience with what FC does in all cases. Are you able to help with that?