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

[freman]

Hi,

I have been using boundary dressup on arcs and it seems it is losing G2 speeds on some lines.
The contour gets expected F600 but when I add the dressup it hobbles around at F120 which is the z cutting speed.

Code: Select all

M3 S20000.0
(Finish operation: T8: 8mm endmill)
(Begin operation: Contour+4)
(Path: Contour+4)
(Contour+4)
(Compensated Tool Path. Diameter: 8.0)
G0 Z3.000
G0 X51.622 Y51.598
G0 Z2.000
G1 X51.622 Y51.598 Z-1.000 F120.000
G2 X0.140 Y-72.999 Z-1.000 I-51.610 J-51.610 K0.000 F600.000
G2 X-8.000 Y-65.000 Z-1.000 I-0.140 J7.999 K0.000 F600.000
G1 X-8.000 Y65.000 Z-1.000 F600.000
G2 X-0.657 Y72.973 Z-1.000 I8.000 J-0.000 K0.000 F600.000
G2 X51.622 Y51.598 Z-1.000 I0.669 J-72.984 K0.000 F600.000
G1 X51.622 Y51.598 Z-2.000 F120.000

Code: Select all

M3 S20000.0
(Finish operation: T8: 8mm endmill)
(Begin operation: DressupPathBoundary+4)
(Path: DressupPathBoundary+4)
(Contour+4)
(Compensated Tool Path. Diameter: 8.0)
G1 X0.000 Y0.000 Z1.000
G1 Z2.000 F120.000
G0 Z3.000
G0 X51.622 Y51.598
G0 Z2.000
G1 Z1.000 F120.000
G1 X51.622 Y51.598 Z-1.000
G2 X65.818 Y31.559 Z-1.000 I-51.610 J-51.610 K0.000
G1 Z2.000 F120.000
G0 Z3.000
G0 X65.818 Y-31.582
G0 Z2.000
G1 Z-1.000 F120.000
G2 X0.140 Y-72.999 Z-1.000 I-65.806 J31.570 K0.000
G2 X-1.000 Y-72.937 Z-1.000 I-0.140 J7.999 K0.000

There is also a spurious cut to 0,0,1 which I did not spot before it dug a hole in my clamps. I don't know where that came from. The safe ht was 3 and this was respected in the contours.

0.19 master.

[chrisb]

It's the same reason as in the discussion about ramping. The dressups have a sloped vertical movement and this is done with vertical speed. If it can be done faster, just adapt the vertical speed of your tool and avoid plunging into the material by using ramp entries.

[freman]

Thanks Chris. Firstly, I asked for a boundary dress up so if it is adding ramps there is a problem.
Secondly:

Code: Select all

G1 Z1.000 F120.000
G1 X51.622 Y51.598 Z-1.000
G2 X65.818 Y31.559 Z-1.000 I-51.610 J-51.610 K0.000

there is no Z change in the 2nd and 3rd lines there, why are they not getting the horizontal speed ?

[chrisb]

Good point, speed is missing in the third line. I would guess it's an issue in the dressup.

[freman]

Thanks for the confirmation, I'll try to find time to open a bug report.

For the record, the second of the three lines also needs the horizontal cut speed too. This is not just one line I had to go through the whole file by hand adding speeds to nearly every arc which was cut. There was just the last segment before the drop in z each time which got the correct speed.


Now what about the extra cut which is getting inserted below safe height. Smashing the tool into clamps is not good. Luckily was an ali clamp and did not destroy the tool. It shaved a lump out of the clamp though which is not cool.

In the contour op the first thing it does is move to clearance ht , then move to the start point of the path. After dressup it inserts a CUT from wherever the machine happens to be resting to 0,0,1 for no reason I can find, which is NOT safe. It then CUTS upwards to clearance ht.

Code: Select all

G1 X0.000 Y0.000 Z1.000
G1 Z2.000 F120.000
G0 Z3.000
G0 X48.790 Y48.790

There's a lot of this cutting upwards going on, I don't think this limited to the dressup. The 0,0,1 cut is a nasty bug in the dressup. If it was (0,0,clearance) it would be less destructive but this cut should not be there at all.


There are also bugs relating to visibility.

When I create a dressup, it makes the underlying operation non visible. If I toggle active state off then on, when it comes back to active, both the op and the dressup become visible which means the user needs to hide it again manually. Toggle visibility on the dressup does nothing, whether the op is visible or not the dressup stays visible. It would be nice if that was tidied up.

[chrisb]

For the record, the second of the three lines also needs the horizontal cut speed too.

The second line is going from Z1 to Z-1, so there is vertical movement down involved, which at the current state does so with vertical speed.

If this vertical/horizontal is reworked, it should respect the difference between going down with limited speed and going up, where vertical speed is pointless (don't know if it already does.

[freman]

My apologies, I had not noticed is was 1 and -1 probably since z=1 is not in the contour at all I must have been assuming it was the first cut in the path at -1.

Which raises the questions , what is the this z=+1 level all about ? I thought the first line which is crashing the tool was a one-off, it seems to be adding them at every cut level.

[chrisb]

I think it comes from the dressup, i.e. the combo StartDepth=0, SafeHeight=2, and boundary Z offset =1 to the inside.

[freman]

Well spotted. I just set z boundaries to 4mm ( safe is 2; clearance is 3 ). The crash path has gone. Clearly boundary should not be clipping safe/clearance heights and this is a spuriously inserted cut.

Incidentally the actual stock boundary is at z=0, so the cut to z=1 is pointless. This may be relevant in trigger the bug.

As noted above only the final G2 arc before step-down gets a speed param. , thus they inherit the vertical speed from the prior G1 plunge.

Code: Select all

G0 Z3.000
G0 X48.790 Y48.790
G0 Z2.000
G1 X48.790 Y48.790 Z-2.000 F120.000
G2 X64.818 Y23.654 Z-2.000 I-48.790 J-48.790 K0.000
G1 Z2.000 F120.000
G0 Z3.000
G0 X64.818 Y-23.654
G0 Z2.000
G1 Z-2.000 F120.000
G2 X0.070 Y-68.999 Z-2.000 I-64.818 J23.654 K0.000
G2 X-0.000 Y-69.000 Z-2.000 I-0.070 J3.999 K0.000
G1 Z2.000 F120.000
G0 Z3.000
G0 X0.000 Y69.000
G0 Z2.000
G1 Z-2.000 F120.000
G2 X0.070 Y68.999 Z-2.000 I0.000 J-4.000 K0.000
G2 X48.790 Y48.790 Z-2.000 I-0.070 J-68.999 K0.000 F600.000
G1 X48.790 Y48.790 Z-4.000 F120.000
G2 X64.818 Y23.654 Z-4.000 I-48.790 J-48.790 K0.000

My earlier comment that there were other z=1 moves was incorrect, just unnecessary upward cuts. These are a serious pain in machine time and are the reason I always trim my clearance ht as low as possible. Often it spends as long upcutting air as it does cutting metal , very frustrating.

Code: Select all

G2 X-0.000 Y-69.000 Z-18.000 I-0.070 J3.999 K0.000
G1 Z2.000 F120.000
G0 Z3.000
G0 X0.000 Y69.000
G0 Z2.000
G1 Z-18.000 F120.000

The image below shows the spurious path when not preceded by another op is still there in gcode but small and descrete. So the tool crash was due to it trying to cut from the end of last op to (0,0,boundary-z) before moving onto cut the true path. That should be easy to find and fix in the code.

[freman]

I have located the offending line in PathDressupPathBoundary.py

Code: Select all

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

This inserts an arbitrary and spurious machine position of ( 0,0,0 )
This is changing the first command in the actual path , which supposed to be a z only vertical move to clearance ht, into a cut from where the machine really is to (0,0,safeHeight).

In the tool crash I witnessed the machine was already parked above clearance height and thus it produced a downwards x,y,z cut path into NON clearance space.

https://www.freecadweb.org/wiki/Path_Workbench
The space between safeHeight and clearanceHeight is labelled as "space for clamping". The boundaryDressup creates paths with run cut paths through clamps.

I will try to find a solution which does not involve injecting spurious machine positions into a valid path.