safe and clearance height

[freman]

I just scanned the code and what it changes is pretty trivial, so code wise it looks straight forward.

I don't have enough experience in industrial use of canned cycles to comment how this relates to common practice though, so I'll let Gene chip in on that.

[GeneFC]

Can I get a review from you guys on this PR?

I tested this yesterday, and the "stay down" part seems to work correctly. Or perhaps I should say, "It works the way I think it should."

The new addition today for the retract height (G83 - Peck) appears to be hard-coded at plus 1 mm over the start depth. Even if I override the value in the task panel the hard-coded value comes back in the generated code.

Otherwise everything seems fine.

Gene

[freman]

I don't have time to do a build to test this right now but I also wondered about retract height.

When pecking I often set retract to a small neg. value ( negative relative to hole entry point ) so that the drill does not repeatedly exit and re-enter the hole at rapid feed rate.

Hard coding this does not seem correct but it looks like this could foul with negative values.

[Wsk8]

The new addition today for the retract height (G83 - Peck) appears to be hard-coded at plus 1 mm over the start depth. Even if I override the value in the task panel the hard-coded value comes back in the generated code.

Is this related to my PR? Im not sure what you are talking about.

[GeneFC]

Is this related to my PR? Im not sure what you are talking about.

https://github.com/FreeCAD/FreeCAD/pull ... 73be32b480

This was one of the links in the earlier forum message from Sliptonic.

Gene

[Wsk8]

Is this related to my PR? Im not sure what you are talking about.

https://github.com/FreeCAD/FreeCAD/pull ... 73be32b480

This was one of the links in the earlier forum message from Sliptonic.

Gene

These lines were removed with the next commit
https://github.com/FreeCAD/FreeCAD/pull ... 5L107-L119

[GeneFC]

These lines were removed

OK.

I am confused by the dates. The link I posted seems to refer to a file created the day after the "removal" you quoted.

But I am probably misreading something.

Gene

[sliptonic]

Are we good on the PR?
Freman, does this resolve the issue you had with heights?

[freman]

I have had the time to do a full rebuild and will not be available for the next few days.

However, having looked at the code it does not seem to address the issue. It seems it only touch Gene's complaint that it breaks the canned cycle being broken and restarted each time. Not issuing the G80 each time ( which breaks any modal operations) seems the right way to go and probably should be the case irrespective of height issues. It probably does not merit an option. It should be done correctly. I'm not sure why the current behaviour is there or what it is supposed to gain. I missed the discussion Gene referred to which seems to predate my interest in FC.

Perhaps Gene could resume the key points.


Having said that, a "keep tool down" option as exists elsewhere in FC seems like it could be useful for simple shapes like a flat plate to save time. In that case the default should probably be false, not true as here. I get the impression that using a "keepdown" feature to counter buggy behaviour here, and which has analogues elsewhere is FC may lead to confusion. Consideration should be give to what "down" means in other existing keepdown options.

This does not seem to address the complaint I had.

Code: Select all

            if obj.KeepToolDown == False:
                # Cancel canned drilling cycle
                self.commandlist.append(Path.Command('G80'))
                self.commandlist.append(Path.Command('G0', {'Z': obj.SafeHeight.Value}))

The existing code here is unchanged, a return to safehieght , which is not safe ! That relates to the discussion we had above. Apart from the admittedly contrived example you presented to clarify the issue, I don't think doing a rapid moving to clearance has a significant real penalty. Not having a safe zone for clamps, despite defining two heights does have a real penalty. Expecting the user to keep an eye on what the software does and ensure it avoids clamps seems counter to the point of having software to take care of the job.


It's great this is getting some discussion but I don't think the current PR really cleans up a rather confused mix of issues. I don't think it intended to address my safe height problem.

My summary of current code issues (without this PR):

1. repeated G80 breaks modal ops unnecessarily (thus incorrectly).
2. Safeheight not safe.

the PR addresses #1 but I'm not convinced an option is required. It probably should simply be fixed.
#2 is not addressed.

my2c.

[sliptonic]

Sorry to be difficult here but I still don't understand what you're getting at...

The existing code here is unchanged, a return to safehieght , which is not safe !

It IS safe as we define safe: IN THE CONTEXT OF THE OPERATION.

Apart from the admittedly contrived example you presented to clarify the issue, I don't think doing a rapid moving to clearance has a significant real penalty.

It does have a penalty. It's slower. How MUCH slower depends on the specific model. You can call my example 'contrived' and say you don't 'think' it's a 'significant' penalty but you can't consider every possible model that will occur. There will be models for which the rapid time is a significant issue. I know because I've had them myself. I was drilling a cribbage board with hundreds of holes on multiple levels. Being able to specify an op specific safe height to drill at each level meant I didn't have to rapid to and from clearance height hundreds of times.

Not having a safe zone for clamps, despite defining two heights does have a real penalty.

Of course there's a safe zone. It is outside the boundbox of the operation. The op should never generate a rapid horizontal move below clearance level in that area.

Expecting the user to keep an eye on what the software does and ensure it avoids clamps seems counter to the point of having software to take care of the job.

The user only has to give special consideration in the rare cases where they MUST put a clamp inside an operations boundbox. That really is an unusual situation. I can only think of one time that I had to do this. In every other case, I was able to split the op into multiple operations specifically to avoid the possibility of a crash.