safe and clearance height

[freman]

The first is an old one, may be i forget to change the link... It's a label "Start Height" at it, - we have a "Start Depth" at Path WB.

Start height is consistent with my suggested behaviour modification. However, since start height is a parameter of each operation the dual use of this term may cause confusion. The current "safe height" is a parameter of the job, there is a start height for each op. It is probably important not duplicate use of the term.

Maybe retract height is clearer for this reason. ( Assuming this behaviour is implement as I suggested ).

Maybe this was the original thinking and the confusing "safe height" was itself confused.

For the moment, I think the main documentation change needed is for a caveat that this space is not safe and the user is expected to ensure there are no clamps in this volume or if there, to set safe-height = clearance height in that case.

Can anyone see a problem is using rapids between safe and clearance as I propose?

[herbk]

Hi Freman,

atm there is no Start Height at an OP,- At least not at my AppImage..

At Heights i have Save Height and Clearance Height, At Depths i have Start Depth, Final Depth and Step Down (at contour OPs)

As long as it is at FC like this, we should have it at the wiki to in my mind...


OS: openSUSE Leap 15.1 (KDE//usr/share/xsessions/plasma5)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.22894 (Git) AppImage
Build type: Release
Branch: master
Hash: 9eb080488d970d313c538473e7272117ea0a7cd1
Python version: 3.8.6
Qt version: 5.12.5
Coin version: 4.0.0
OCC version: 7.4.0
Locale: German/Germany (de_DE)

[freman]

My apologies, I was thinking of Start Depth, but that rather proves my point about the possibility for confusion.

Current params are Safe height and Clearance height and current doc should reflect that. Thanks for your attention to fixing the doc.

@all :

Since there is already a Start Depth, I'm wondering why the confusing duality of safe/clearance exists at all.

Why not automatically rapid from clearance to the op's Start Depth , cut the pocket, drill, whatever, then retract ( presumably at cutting v-rate ) to the same Start Depth when done, then rapid out to clearance height and move to next X,Y ?

This safe/clearance thing is often a point of confusion for users. Is there any need for it at all?

[sliptonic]

Consider model #1 below:
If pocketing only the two rectangular pockets (1,2), you obviously don't want to rapid between them at the top of the model. It's not a big deal with just two pockets but would be incredibly inefficient if there were 100. On the other hand, if you're also pocketing #3 you HAVE to go all the way up. So the safe-height is effectively the local high point inside the boundbox of the operation.

But maybe the user still doesn't want the wasted rapid time between pockets 1 and 2. In that case, he can configure two operations. One has pockets 1, 2 and the other has just pocket 3. The safe-height for the first op can be set at the local high point between them and it will be efficient. When moving from the first op to the second, the system will go to clearance height and avoid the tower.

safeclear1.png (9.01 KiB) Viewed 1728 times

Now consider model #2. Maybe this is a second operation to clear an even lower part of the two pockets (1,2). The safe height is still the same but the start point and end points have changed.

safeclear2.png (8.58 KiB) Viewed 1728 times

This should show that there are three separate ideas:
Safe height being the height at which rapid moves INSIDE the boundbox of an operation are safe.
Clearance height being the the height at which rapid moves BETWEEN operations are safe.
Start depth being the point at which cutting starts.

But this is just concept. I'm not saying anything about whether Path gives reasonable defaults for these things. I'm also not saying whether or not Path actually follows the concept universally in every operation. You might be right that drilling can be improved here. I haven't had time to look at it.

[chrisb]

Is there any need for it at all?

Yes. For toolchanges you may need a different height, usually higher than what you need for horizontal moves. This may be neglectable for the hobbyist, but can cost considerable time if the difference is big. For an SK50 tool holder you need more than 100mm additional space for tool changes and it would be a complete waste of time to add them to each vertical move.

[GeneFC]

In the attached FCStd I have a series of drill holes. The approach to the first one is done at clearance height but in between all others it skims along at safe height.

[Rant on]

Unfortunately, an occasional forum participant dropped in a bit more than a year ago and made arguments to greatly change the behavior of canned cycles, G81 and G83. He then proceeded to create pull requests which were accepted, against my vehement arguments. The result was that the industry standard behavior of these canned cycles was completely destroyed. Each hole drilled is followed by cancellation of the canned cycle. Then a new canned cycle is started. Makes no sense, but that's the way it is.

That is why the height behavior is so strange.

I fixed the problem through custom mods, so I no longer care. But it is still a big problem overall for the Path WB.

[Rant off]

[freman]

Is there any need for it at all?

Yes. For toolchanges you may need a different height, usually higher than what you need for horizontal moves. This may be neglectable for the hobbyist, but can cost considerable time if the difference is big. For an SK50 tool holder you need more than 100mm additional space for tool changes and it would be a complete waste of time to add them to each vertical move.

I'm not familiar with this kind of high end equipment.

It seems that is different from the question of safe and clearance ht. , maybe it is a convenient misuse of having these two heights.


@ sliptonic.

Thanks for taking the time to rough up a couple models and explain specific cases where this may be relevant.

This should show that there are three separate ideas:
Safe height being the height at which rapid moves INSIDE the boundbox of an operation are safe.
Clearance height being the the height at which rapid moves BETWEEN operations are safe.

The geometry you indicate seems to show that there is NOT as safe height between pockets within the bounds box. Sometime it works , sometimes not.

I would think that typically rapids are several times faster than cutting moves. Unless you construct a contrived example with C.Ht. > 10x S.Ht is this really a problem?

My clamps are 20mm, with the 5mm tool I'm dropping 1mm per second plunging into stock , I do not want to wait 20s up + 20s down while it cuts air.

@Gene , can you share the mods you apply locally. If there is no agreement of improving this , I may take the same route.

[sliptonic]

@ sliptonic.

Thanks for taking the time to rough up a couple models and explain specific cases where this may be relevant.

This should show that there are three separate ideas:
Safe height being the height at which rapid moves INSIDE the boundbox of an operation are safe.
Clearance height being the the height at which rapid moves BETWEEN operations are safe.

The geometry you indicate seems to show that there is NOT as safe height between pockets within the bounds box. Sometime it works , sometimes not.

That's why I said "boundbox of the operation". If the operation was trying to pocket all three rectangular pockets, the safeheight would need to be the same as the clearance height. In my example, the user is only pocketing 1 and 2 specifically so a lower safeheight can be used.

I would think that typically rapids are several times faster than cutting moves. Unless you construct a contrived example with C.Ht. > 10x S.Ht is this really a problem?

I made a 'contrived example' specifically to answer your question about whether we need both clearance and safe height. I'm trying to make clear that these are different concepts specifically introduced to add flexibility and path efficiency. If we eliminate one of them, we reduce the ability to configure operations efficiently in certain demonstrable cases.

[freman]

Yes, I realise the example was exaggerated for clarity, my point was that this is probably not a likely usage case so the claimed advantage of not doing rapids to the height of the penthouse suite may not be relevant in practice.

If there is a feeling that this is useful it needs to be clearly explained. I find these two terms confusing and when I refer to the doc, it tells me it's about clamping when this does not work for clamps anyway.

The main time waster in the current behaviour is all the air drilling as I have already pointed out. That could be improved.

[sliptonic]

@genefc @freman, Can I get a review from you guys on this PR?

https://github.com/FreeCAD/FreeCAD/pull/4026