safe and clearance height

[sliptonic]

I suspect that the confusion is coming from the fact that 'clearance height' shows up as an op-level property. This, I think, is a mistake. I think the only place the user should see 'clearance height' is at the Job level. It certainly should not be changeable at the operation level.

[chrisb]

certainly should not be changeable at the operation level.

Not quite sure about this. Different operations could need different heights for tool changes.

[sliptonic]

certainly should not be changeable at the operation level.

Not quite sure about this. Different operations could need different heights for tool changes.

I don't understand. Can you explain more?

By design, the operation doesn't generate any commands for the tool change. That's the responsibility of the Tool Controller. So far, that amounts to the insertion of an 'M6 T<tn>' command followed by an 'M3/4/5 T<spindle speed>'

If machine-specific code for the tool change is needed, then the post-processor should handle it.

[chrisb]

Can you explain more?

Let's assume I have three operations, the last one uses a much longer tool, which needs 300 mm of free height to be changed. Then I set the clearance height of the second op to 300 so that the mill goes up to that height at the end of the second op.

If machine-specific code for the tool change is needed, then the post-processor should handle it.

That would indeed be the right place.

[herbk]

Can you explain more?

Let's assume I have three operations, the last one uses a much longer tool, which needs 300 mm of free height to be changed. Then I set the clearance height of the second op to 300 so that the mill goes up to that height at the end of the second op.

In my mind that's theoretical only.
That this retract to becomme sense, there must be a gcode command for pause the gcode processing between two operations. But i think there is no Gcode command for... (at least i don't find one at LinuxCNC)

If you ask me about that:
Clearence Height should be renamed to Start Height und it should be the Z level where the tool retraks to at the end of an job, - only at the end of an job.
To avoid confusion between Start Height and Start Depht, Start Depth should be renamed to Workpeace Top (ore something similar).
Save Height should stay Save Height, because its a Z level above the workpeace where the tool can move around without touching it.

If machine-specific code for the tool change is needed, then the post-processor should handle it.

That would indeed be the right place.
[/quote]

+1

[chrisb]

In my mind that's theoretical only.

Not at all, I use it that way

That this retract to becomme sense, there must be a gcode command for pause the gcode processing between two operations. But i think there is no Gcode command for... (at least i don't find one at LinuxCNC)

You sure know LinuxCNC better, but this surprises me. I would guess that there are manual tool changes in LinuxCNC too, and they should pause the machine. On my machine the manual toolchange is M66 as opposed to M6 for automatic change.
Besides there are pause commands M0 and M1 on my machine, the former pausing unconditionally, the latter pauses if I press an additional button.

FreeCAD supports the M1 Stop command. I currently cannot test due to some uninvestigated errors when trying to postprocess, but I would guess that linuxcnc_post handles this too.

To avoid confusion between Start Height and Start Depht, Start Depth should be renamed to Workpeace Top (ore something similar).
Save Height should stay Save Height, because its a Z level above the workpeace where the tool can move around without touching it.

I hope we all agree on the various existing depths. So it is just the heights we have to find common views.

I see the following heights, and I will try to describe them without reusing the existing notions by numbering the different levels from bottom to top. Not all of these exist in the current Path workbench

1) Height where vertical rapid-down-moves end and motion changes to working speed. This is used so that the tools enter at decent speed into the material

2) Minimum height at which I can move horizontally. This is used e.g. for moves above the surface between clamps and can be used for two adjacent pockets or for drilling operations for several holes if no clamps obstruct the paths between them.

3) Height above the clamps. Used to avoid any crashes

4) Height needed for tool changes. On small machines this may be the maximum height, on bigger machines it may save considerable time to have this below maximum height

5) Start height. First and last move go to that height. If the same height is used for all tools in 4) this will probably be the same again.

6) Maximum height of the machine.

If there are more relevant heights to be distinguished, please list them, even if they are not relevant for FreeCAD's current path implementation, but we should try to avoid any future confusion.

It is not that your life depends on it, but the life of your tools may.

[herbk]

You sure know LinuxCNC better

For that i'm not sure like you...
Of course LinuxCNC have a M0 M1 for pause the programm and a M6 for a toolchange...
The problem (for me) is: i have to touch the new tool to workpeace after a change to fit the Z offset, but at pause mode and can't do that.

To avoid confusion between Start Height and Start Depht, Start Depth should be renamed to Workpeace Top (ore something similar).
Save Height should stay Save Height, because its a Z level above the workpeace where the tool can move around without touching it.

I hope we all agree on the various existing depths. So it is just the heights we have to find common views.

I see the following heights, and I will try to describe them without reusing the existing notions by numbering the different levels from bottom to top. Not all of these exist in the current Path workbench

1) Height where vertical rapid-down-moves end and motion changes to working speed. This is used so that the tools enter at decent speed into the material

2) Minimum height at which I can move horizontally. This is used e.g. for moves above the surface between clamps and can be used for two adjacent pockets or for drilling operations for several holes if no clamps obstruct the paths between them.

3) Height above the clamps. Used to avoid any crashes

4) Height needed for tool changes. On small machines this may be the maximum height, on bigger machines it may save considerable time to have this below maximum height

5) Start height. First and last move go to that height. If the same height is used for all tools in 4) this will probably be the same again.

6) Maximum height of the machine.

If there are more relevant heights to be distinguished, please list them, even if they are not relevant for FreeCAD's current path implementation, but we should try to avoid any future confusion.

It is not that your life depends on it, but the life of your tools may.

1) and 2) can be the same in my mind... and is what we have as Save Height now. Where do you see an advantage to split it?

3) dos not make much sense if we not have an area where the clamps are (also just my mind)

4) the "bigger machines" argument counts, but for 5) and 6) again i see no advantage to split it.

If the machine is not at its maximum height, i would not like if the first move is up to max. height and then down to the work... Starting from that Z level "where the tool is", is a useful behavior. i think.

[chrisb]

1) and 2) can be the same in my mind... and is what we have as Save Height now. Where do you see an advantage to split it?

You are probably right, that there is no need to differentiate between them in FreeCAD. I wanted to describe different heights independent from their usage in FreeCAD. And these two have a very different meaning. (I can even think of rather special use cases where I can imagine them being different. Think of a thick carpet-like material which you cut with a dragknife. You can well move rather far down, when you start cutting, but for horizontal moves you should move up a bit further.)

3) dos not make much sense if we not have an area where the clamps are (also just my mind)

I think it makes very much sense because we don't know where the clamps are: We simply make horizontal moves above them.

4) the "bigger machines" argument counts, but for 5) and 6) again i see no advantage to split it.

If the machine is not at its maximum height, i would not like if the first move is up to max. height and then down to the work... Starting from that Z level "where the tool is", is a useful behavior. i think.

Again you are right. We don't need the maximum height for path creation. It could, however, be used for sanity checks if the machine height is sufficient for the model.

[freman]

Thanks to Chris for detailing all the different height requirements. It is very helpful to take an objective overview of all different functional heights before trying to decide which can safely and usefully condensed into a single parameter. Good initiative.

2) Minimum height at which I can move horizontally. This is used e.g. for moves above the surface between clamps and can be used for two adjacent pockets or for drilling operations for several holes if no clamps obstruct the paths between them.

This seems to be the key point of discussion. Maybe part of the problem is calling this "safe height" when it is not safe. It seems to be intended as a clearance height above the work surface for features grouped into the same operation. This tacitly expects the user to ensure no clamps are in this region ( this must be explicitly documented and hopefully made a lot clearer in the naming conventions ). Part of the problem here is that there is little control of how drill, helix et al will group them and which path it will take from one to the other. I raised the question of having more control over the order by editing the base geometry list elsewhere.

If the user is expected to avoid clamps, he either has to break the job down in to many separate ops or iteratively fiddle with how the automatic routing from one feature to the next turns out. If the order of the base geometry list could at least optionally be taken as significant in determining order of machining and was editable it would make avoiding clamps a lot easier.

It is important for all of us not assume that our particular machine, workpiece or stock is typical and can form the basis of what is "best" or "usually" required. We're probably all guilty of this at times, no finger pointing intended.

My rapid Z moves are pretty rapid, moving up and down say 20mm to a clamp-safe height is not an issue. Maybe someone tuning for a production run may be a lot more interested in shaving off that "wasted" time and optimising working around clamps. Again, more control over the routing process would be beneficial.

Some will be used to having ample stock with cut-off wastage where clamps are peripheral and not an issue. I've had lots of jobs where that is the case or the work is held in a machine vice where at least the clamping at a lower level. The particular job I'm working on now involves cutting features into an extruded ali bar. The bar is the workpiece, there is no wastage and all clamps are in the working zone. Many other times I find a suitable peice of stock but it's not much larger than the part to be machined. I'm much less inclined to accept large amounts of wastage when working with lumps of ali than when cutting flat bits of wood.

Since this height #2 is necessarily related the operation and not the job, it should be a param of the operation.

3) Height above the clamps. Used to avoid any crashes

There could be an argument for making #3 a param of the job.

1) Height where vertical rapid-down-moves end and motion changes to working speed. This is used so that the tools enter at decent speed into the material

This seems to be one which is not fully cater for at the moment or at least there is some overlap and loss of functionality in reducing these three heights into two params.

Maybe wsk8's keep tool down idea could be a means of introducing a third param. If default behaviour was retract to #3 then keep tool down could offer the existing group behaviour where there is only retraction to #2.

[herbk]

Hi,

This seems to be the key point of discussion. Maybe part of the problem is calling this "safe height" when it is not safe.

i don't see the name "save height" as a problem, because it's possible for everyone to make this height save...
The only problem regarding heights seams to be the name "space for clambing" at the wiki page. I will change it to "space for toolchange" asap...

Like say'd above: as long as we not have the knowledge where clamps are placed, to split the this save height to a height between clamps and a height above clamps...