Guys, this is getting ridiculous.
Attached is a file, where I'm trying to do a pocket in 2 Z levels due to a tool length of 3" ( the pocket is 2" below the top of the actual part)
Anyway, the pocket itself is .5" deep and I'd like to make a pass at the wall first @ .25 depth, then move to the bottom, spiral ramp to .5 and then
finish the bottom and the wall at this depth.
All is well right?
Well, FC - for some unexplainable reason - first spirals to .250 depth ( into non-existant material ), finishes the wall, and then it just straight plunges
to the .5 depth ( where there IS material ) and then finishes the bottom!

I know for a FACT that this did in fact work properly before!

What gives????

I'll talk to support today, but wonder if you guys can find what I'm doing wrong.

Thanks

Nothing is attached?

Hmm....
I did try it, AGAIN ! and got the message on top of the forum:
"Temporary folder could not be found. Please check your PHP installation."

Guessing that something is up with the server, as I did attach a file not that long ago and it worked.

Anyway, I'll try again later.

Thanks

Guys, I did manage to upload the file, see the previous post.
There are 2 versions of the same pocket, one with ramp, the other with plunge.
Note the clear difference between the 2 versions of the same pocket, most notably the code when one Z-level
finishes and the other starts.

Thanks

Seymourdumore,

You might already know this, but if you uncheck "Min.Retract" on the strategy tab, it will ramp in for both passes. Not sure this helps but just one thing I found.

Dan

Dan. thanks.
I did not notice that before.
With the Min Retract unchecked, it does ramp in both depths.
BUT!!!
#1: It does not need to ramp in the first pass. There is no material to do so.
#2: It ignores the Plungepoint setting for the second pass. Honors it for the first one, ignores it on the second, where it would actually be important.

Can someone from FC chime in please????

Are you sure it worked before? I just tried it in 15.2.0.64 and it behaved the same way. By the way, df is right about the Minimum Retract; it usually causes more problems than it solves.

I'd shoot this one to whomever does your support (dealer/direct). This looks like an "unintended enhancement" to me.

Marshall

Marshall

Yup, it seemed to have worked in V14 as I have a couple of older programs with 2" deep pockets and they do the ramping just fine.
Just recently deleted the older release files so can't go back to check and pulling it into V16 will obvioulsly updates to the current
"enhanced" strategy.

But do tell me if I'm wrong or not about it being incorrect!

Thanks

SEYMOURDUMORE

Here is what I have found out about your problem thru some talking with support and numerous e-mails. Starting in V15 the developers started tweaking the ramping code for the "PART LINE PROGRAMMERS". As far as what I can see this caused an unintentional result in these very strange ramping behaviors. I think they have been working on a fix but as far as I can tell they haven't figured one out yet. Somehow I don't think I'm communicating the problem clear enough to them or they just don't know how to make part line programming work without this strange ramping algorithm. I would post the email trail that I have on this but I don’t think the FC guys would appreciate it. (Not that it was bad or anything it’s just that it was between 2 of us trying to hash a solution for this very problem). If someone from FC says it is ok to post I will but it won’t solve the problem.

In my humble opinion I think part line programming should be done away with. It really is a crash waiting to happen. If you forget to put in the tool diameter comp in the machine you scrap a part. It’s just bad juju! It has also caused FC to implement this crazy ramp code into the program. Again bad juju!

As far as a work around is concerned… I haven’t found one. I have been setting my ramp angle to “0” but this just causes the endmills to pounce directly into the bottom on the finish bottom passes. It may be possible to fix your problem with 2 separate features one set at the .250 depth with ramp angle set to 0 and one set to .5 deep with a ramp angle.
Sorry this is the best answer I can give… Very frustrating!

Matt

Also the problem is not isolated to pocketing. You can really get some funky code generated from ramping in the Boss features as well. That has been driving me insane lately. Not that I have that far to go before those guys in the white jackets stop by again.

I wish they would focus like a "LASER BEAM" on this one issue until they get it right. Alas, I am but one voice that is just a rambling "ramping" mad man in the desert. No reason to listen to me!







Matt

Hoy Matt! I must respectfully disagree with you there to the highest possible degree!

In fact, the ability to part line program any and all features for rough and finish is what convinced me to give FC a second look when I was
purchasing my new CAM software.
As a matter of fact, I most importantly have dumped OneCNC for that reason above all. ( and took a $2K bath in the process )
One thing for certain. I can unequivocally say that this shop will never ever run, create or even store any programs of any kind under
any circumstances that do not use part line programming.
Opinions are like assholes, everyone's got one, and that is irrevocably mine.

Aw, come on- quit sugar coating it!!

Part-line vs. Centerline again...

And people think Creation vs. Evolution is a big deal!!

SEYMOURDUMORE

I guess we need to agree to disagree on part line programming.

One thing we can both agree on is that this code is funky, to say the least! It seems like it would be possible to have our part line programming and not the crazy zig zags that cut away imaginary material. You have to agree that this would be a good thing for the FC guys to focus on. It is amazing how much cycle time is gobbled up in these crazy zig zag moves.

Matt

Oh, I definitely agree. It is incorrect!