[5] Inconsistent plunge feedrate in pockets

[lloydsp]

Doing a pocketing operation today, with a pretty small cutter in a fairly large pocket, but not modifying any default parameters concerning stepovers, etc., I had an 'oddity'.

SOMEtimes, it would cut one increment of depth, then rapid back to zero in the middle to start the next increment.

Sometimes, it would use the plunge feedrate, which from a large clearance height, used a lot of time.

I've never noticed this before.  If you cannot reproduce it, I'll give a simplified file to show it.

LLoyd

[pixelmaker]

I'll give a simplified file to show it.

where is it? I never see this.

ralf

[Dragonfly]

I have also noticed on several occasions that in a pocket MOP the horizontal transition (stepover) speed alternates randomly. Although in the MOP it is set to cutting speed, sometimes it moves with plunge speed. I haven't reported it because can't see any regularity.

[lloydsp]

"Regularity...", yes.  That is the problem.  The example I'll post is exquisitely sensitive to changes.  Sometimes a small change that appears meaningless to the issue will change the symptoms entirely.

But this one does it reliably on my computer.

About half the moves to the work surface consist of rapids to within 0.0625" of the surface, then a feed-rate plunge the last 0.0625".  About half are missing the rapid entirely, so they make the full excursion from clearance to worksurface at the slow Z feedrate.

For instance, look at the 'increment layer' between lines #159 and #161 of the g-code.  You'll see the rapid down to near the surface.  Then look at the one after that... only a feed-rate descent.

All the increments prior to 159-161 had a rapid.  The ones between 162 and 243 do not.  Then all the rest do, again.

This seems to 'break' with any little change, including which post-processor is used --- though I can see nothing in the post that's related to this behavior.

I included everything so that Andy may look at it.

Lloyd

[kvom]

I noticed that myself recently as well.  Cutting a profile with several depth increments.  The slow descent was on the last couple of passes.

[dh42]

Hello,

I generate your file with Mach3 standard PP, ... and the same missing Z rapid is present, from Z-0.2 to Z-0.28

The rapid come back for Z-0.3 up to the end.

If I replace the automatic value (-1) in fast plunge height by 0.0625 I get the same problem, at the same positions

With 0.06 instead of 0.0625, the problem is also between Z-0.2 and Z-0.28

++
David

[lloydsp]

Thanks, guys.

It's likely some sort of singularity or rounding issue in the math.

Lloyd

[dh42]

I retry the file up to -1.6 in target depth ... and the problem stay between -0.2 and -0.28, no other missing rapids up to the end ...

++
David

[lloydsp]

Ooooo!  THAT sure doesn't sound like a math problem... more like a variable going wonky on its own!

Could it be related to tool diameter and stepover, somehow?

Does anyone hear "The Twilight Zone" theme playing in the background?
 

Lloyd

[pixelmaker]

Ooooo!  THAT sure doesn't sound like a math problem

No, sorry it again a "operator problem". You use again a spiral leadin without a spiral angle. This work if you use a profile mop.
If you set a spiral angle of 90° degree or above you get your G0 plunge to Z-0.2775.
Then a plunge with G1 to the start of that depth increment.
Perhaps you write a small nota with "no spiral leadin in pockets without spiral angle" and stick it at the middle of your monitor. 
This is a behavior that sometimes work, sometimes not.
It shure works at closed polylines with a profile mop.
Use a profile mop with a cutwidth of 0.5 and a  spiral leadin without angle and it works ok.
But in this case you have to set the max crossover to 0.59 to get a retract to save height. With the standard setting of 0.7  you get no retract to save Z. Cb moves from the outside toolpath to the middle at the cutted level and spirals down to next level.

In the pocket mop the distance between the toolpath is 0.19754. Max crossover of 0.7 is 0.175. It retract.
In the profile mop with cutwith the distance between the toolpath is 0.15036 and there is no retracting movement.

ralf

[lloydsp]

Perhaps you write a small nota with "no spiral leadin in pockets without spiral angle" and stick it at the middle of your monitor.  Wink
-------
No... THAT is a bug if it doesn't work right every time.  If a feature like 'no angle' spiral lead-ins doesn't work, and it isn't prohibited in a particular MOp, then it's a bug, pure and simple.

Not operator error, no.  (ignorance of the bug I'll accept, but not an error in programming the part.)

Lloyd

[pixelmaker]

Lloyd,
What I agree with you is that a pocket should have the same behavior then a profil mop with a cutwith.
By now I prefer the profile mop with a cutwith for pockets.
And using the spiral leadin without an angle not should result in different speeds on different  levels.
That is a bug.

What I learned from CB is that a spiral leadin basically needs a spiral angle. In the manual there is written on the page http://www.cambam.info/doc/plus/cam/LeadMoves.htm : If Spiral Angle is set to 0…..For closed shapes, the lead move will then replace the toolpath at each depth level,
In a pocket the lead move can´t and don´t replace the toolpath. So for me it is consequential that this behavior works only in profile mop. This is how I use this behavior, I use a profile with cutwith for this jobs.

ralf

[Jeff_Birt]

With a spiral leading set to zero what you are asking CamBam to do is plunge to your DOC over then length of the geometry selected. For a profile operation this type of behavior is very handy with a closed polyline as you can do a continuous plunge type operation on something like a bolt slot and remove the material very quickly.

For a pocketing operation what would one expect a spiral leadin set to zero to do? If you are going from the inside of the pocket towards the outside what should the leadin in the center look like? The actual distance traveled to clear the stock in the center will be small so the plunge angle would be steep. Remember a spiral leadin angle of zero is asking CamBam to derive the plunge angle from the length of the polyline but at the center of the pocket does it use the length of the toolpath or the length of the polyline that defines the pocket?

For a pocking operation using a zero angle leadin does not make sense to me as it is not immediately clear what I would be asking CamBam to do. I'm not saying the resultant code your seeing makes sense either but rather wondering aloud what type of result one would expect. When pocketing I will typically set an angle of 5 degrees or so which seems to be fairly gentle on most bits and still provide a relatively quick plunge.

So I guess what I'm asking is what is the use case for a spiral lead in angle of zero with a pocketing operation. If the expected behavior is defined then perhaps Andy will have a better idea of how to approach the problem.

[Jeff_Birt]

Seriously guys I'm curious, what is the behavior you expect when using a zero angle spiral lead-in on a pocket operation. I have been racking my brain for a day now and I can't visualize what I think such a toolpath should look like.

[lloydsp]

I expect it to do exactly what a profile with cutwidth would (because that's all a pocket IS) -- to rapid to a very small distance above the (current) stock surface, to move at feedrate that last tiny bit, to spiral down to the increment DOC in one revolution of the first cut, then to step over to the bounding profile for the rest of that increment.

Then I expect it to retract to clearance and repeat that first paragraph over and over until the target depth and cleanup pass.

Now...
What I get instead is exactly all that, except that sometimes it rapids to the current stock surface, and sometimes (in a weird, non-sequitor range of depths) it moves from clearance to current surface at feed rate.

When my clamps are 2" above the surface, and the current milled surface is an inch below the stock surface, that means moving 3" at a small feedrate, perhaps dozens of times;  it takes huge amounts of unnecessary time.  I want it to rapid on every increment's first move down.

It's not the general behavior of pocketing for which I called "bug", but for that unwarranted inconsistency in the plunge moves.  I believe that was clear to all the other folks who tested and confirmed the same behavior.

LLoyd