It's passing through a singularity. There is no direct way that I know of to do what you want with the post you have.  That said you could reorient the part to make the peak not pass directly through a singularity and would thus run well, though the head would always stay positive, it just wouldn't have to flip the C in one line, it would do it gradually and in a smooth fashion.

Post a zip to go of your whole file.  It will be easier for us to help that way. 

Few stabs in the dark:

It could possibly in your mics int settings.  It could also be toolpath related.  You could also look at a related setting, though I'm not sure because you haven't given us much, is you should try changing bias_null from 0 to 1 in the post (post line 517).  IIRC this will make the post respect the misc ints for every operation.

Good Luck,

Husker

50 minutes ago, jmk021083 said:

I really don't see what could change or needing updates with the machine environment? 

If I had to venture a guess you are paying maintenance on that machine environment and they will guarantee to keep it functional as they make updates and changes.

The amount of "coast" after the touch is purely decel.  Likely your time constant is pretty large, or it has very low acc/dec parameters.  These should have little effect on the probing accuracy as the "high speed skip" doesn't care what the machine is doing.  It takes a snapshot of axis position when the skip signal is read.  The probe position is not the position that the machine stops at.   Should have less error than you are measuring to.  The most important thing for probing accuracy is making sure you are at a constant/stable velocity when you make the touch.  Violent acc/dec parameters will invariably cause false triggers, and machine vibration which will affect accuracy.  More trigger approach distance usually is the solution for this.

I would look into the acc/dec time constant parameter.  Is it possible you are running the probe in AICC?

You may need to install a fresh version of the autodesk utility that does the translation.

11 hours ago, Leon82 said:

I haven't used the Toolpath editor, I'll have to give it a shot

Toolpath editor is very handy.  You will use it more once you get a feel for how to use it.  It is absolutely necessary from time to time to get a good output in the multiaxis world.

Another deficiency that I have begun to hate is the lack of ability to combine the last finish multipass with the depth cut finish pass.  Not really an issue I ever noticed cutting metal,  but cutting wood it is just a pain in the but to have to create another op for the wall, and final floor finish.  I have started just deleting the unneeded pass using toolpath editor.

7 hours ago, LucasGC said:

and just have it offset the 'from' curve

This would be where parallel comes in.  You just have to get creative on thinking about how to apply the parallel path.  Morphing to a line is the likely the best method.

If you aren't in XY YZ or XZ planes you can't filter for arc output.  It is possible per say to command the machine to do a "3D Arc" using three points but the filter inside mastercam and the post aren't setup to generate them.  I don't know of any way to get mastercam to do it as it isn't possible to define an off plane arc in the NCI without defining a new tool plane, or GCode class.  

The "output 3D arc entry motion" is for filtering a helical approach from point to point into a arc/helix.  It is not creating a "3D" arc.

3 hours ago, Mauricio DH said:

Their reseller couldn´t help us to solve this.

I highly doubt they can't help. It's more likely they don't want to, or that they have a good reason not to.  If a reseller can't help with simple post edits like this they shouldn't be a reseller. I'd be highly annoyed as a customer if I was treated this way.

Where are you located?

I'm trying to get this to work for a thread mill...

I have been successful in getting the output to come out right, mind you I am not along an axis per say, so the trick was to use linearize helix to make it work.  Anyway, I have the head offsets defined in the machine definition, they are there and I can go get the angled head and whatnot but I can't see it in the machine definition after I save it.  I have the ofsets defined, but it will not apply the offsets to the NCI output.

Any idea's?

I have attached a really dumb sample file. Basically a stock MPMAster Vertical.  I would assume the code should have a 100mm z offset from zero?  Not to mention the x offset.

RAH_Husker.mcam

21 hours ago, dstryr said:

Idk why shrink fit / tool grinders aren't in sync on this....

That is industry as we know it...  Rarely does everyone get in sync near the level of potential that they have.

21 hours ago, dstryr said:

Yes!  Some grinding company sells a little bench top unit with an ER32 fixture that is meant for cut offs. It was like $3500 and I sent it back the day I opened it. POS.

If I were to build something I would want it to cut off and break the corner, not create a mess, and be easy to configure / operate.  Auto operation would also be nice, that way it wouldn't have to be super quick, but you could load it and walk away and work on something else while it cuts.  Otherwise it would likely be a colossal waste of time.

20 hours ago, JParis said:

we have a new 4 machine Palletech line arriving

ooooo, sounds like fun, been a while since I played with an FMS

I'm thinking this might be a good product idea.  Many tool cribs and small shops could use something small and self contained,

I always just used to use a surface grinder and a wheel similar to what you bought with a mister blowing on it.  IMHO, every shop needs a surface grinder, bridgeport, and at least a small manual lathe.  If you have a lathe, I would use that before I used the mill.  Mount the tool in the toolpost and wheel in the spindle.

1 hour ago, Colin Gilchrist said:

I think you'll need to use the "update global" functions to pull this off.

That was what I was thinking, I can't seem to figure out though what variable I need to update using update global though...  It doesn't appear to be str_pri_axis,  somewhere in the .bin they are attaching the prefix string to p_out.  Would you have any idea on that?

What do you need to model up, is it a scan or are you looking to create a surface from a stock model / verify generated stl?

If you have the scan to 3d add in for solidworks you can do it with that as well, though I might add it's a bit cumbersome tool to use, not nearly as good as the others.

So I have a machine with two rotary axes on the table in parallel to each other,  Each gets it own part, one is A1 the other is A2, you use them individually for cutting separate parts.  When the are setup to where they are cutting the same parts (copies) you have to address them separately as you need them.  In this case they are the primary axis.  Anyway, my post is setup for a question to ask which one you want to post to.  This is fine in most cases, but I am sick of hand editing code when I need to go back and forth between them for tool change efficiency.

Anyway, what I would like to do is detect if an op is a transform and accordingly change the axis name prefix string when it goes from the first transform location to the second.  I have a decent grasp of how to do some of the transform side of it, but can't for the life of me change the output prefix from "A1=" to "A2="  I can successfully make them whatever I want in the pprep$ portion of the post, but can't change it after that fact.  I am assuming this is due to what may be in the binned portion of the post.  This post is a heavily bastardized generic 5x post.

Use a standard tool definition, not a custom.  You may not have your tool defined exatcly like it is, but it should do the job properly.  When you use a custom like that it only compensates to the center of the tip.

2 hours ago, RaiderX said:

I would lean toward a carbide tipped gun drill and talk to saleman on feeds-speeds per their tool.

Send it out for gun drilling and be done with it.  If you don't mind buying a gun drill, it isn't hard to do.  

I haven't cut 300m in 13 or so years, but I recall it being easier to work harden than 4340.  4340 was a cake walk in comparison, from 4340 to 300m figure about a 40%-50% difference in yield strength, 75-80% in ultimate, which means it is more likely to make stringy chips.  Of course those numbers are in the heat treated state.  But anyway, it has more of the elements that make 4340 harder to machine than say 1045.  So bottom line it's going to take more force to cut.  Drilling shouldn't be bad, chatter wise.  But as you know this will all be about keeping the cutting edge cool and chips flowing out of the hole.

I wish I understood the Fanuc program restart function on most conventional machines.  I have not been able to make heads or tails of it.  My feeling is that there really needs to be some level of MTB integration for it to work, along with proper program format and syntax, plus very specific instructions on how it functions along with its limitations...  Not as simple as the fanucese manuals make it out to be.

I have never used the Fanuc or Haas restart function, though I have used the Okuma sequence restart, it work beautifully.

My best suggestion is to make sure the program is formatted such that you have logical restart points built into the program wherever you might need them.  All modal and non-modal codes needed are applied at these points such that you can safely start the program from those points.

What series Fanuc control is it?  The 30i series controls have a setting that throws a warning message if you aren't starting the program from the top.  Forces you to press cycle start twice.  If you can, I suggest that you enable/use that setting, it is buried in one of the offset/setting pages (operator limits maybe?) (it's not a parameter).

There's a button for that in the verify screen isn't there?

For a prototypes I typically try to keep the number of ops down to a minimum, lots of changes and whatnot make for a cumbersome file to navigate if you let the number of ops balloon.  When it comes to a long run job I don't care how many ops it takes, because sometimes you just have to split things up to eliminate a few extra retract or clearance moves which end up costing time.

As for dirty ops.  I find it interesting that sometimes you open a file and a few random ops are dirty that weren't when you saved it.  I haven't had much problem with them just nuking themselves.  Thankfully if they do get nuked, say when I decide to nuke a file say because ref points are working (every frickin' project at least once before it's done) it doesn't take but a few minutes to regen.  Though I typically avoid stock models like the plague past my stock prep op, as one of the tools I always use will nuke the file guaranteed.

17 hours ago, Matthew Hajicek™ - Conventus said:

As such I never rely on the speed and feed in the tool library, I recalculate for every operation.

This is me....  I cut wood.  Some would say it's easy.  I'll tell you all otherwise.  It's only easy in that you can rapid a tool through the workpiece and all you will lose is the workpiece.  That's about it.  Feed's can vary based on operation from .002" to .015" per tooth.  Even with the same doc and woc.  It all depends on the setup, and grain direction.  As such I have found that the only useful setting that you usually don't have to play with much is spindle speed.  Some days I wish I could get back to cutting metal, but even in those days, my feeds and speeds were typically set per op, not per tool, too much opportunity for cycle time reduction to leave them alone.  Of course lots of our projects were going run for a few weeks minimum so it was worth the time.  How would you even go about setting up libraries for those cases?

13 hours ago, Grimes said:

never really messed with the holders, why would it be such an issue other than length of the tool to not crash?

I didn't used to do much with them until I started doing a lot of organic surfacing using a multiaxis.  If you are constantly having to deal with long reach tools and whatnot it's a must to have accurate representation of your holders.  Then once you start doing it here and there it's hard to skip past it, especially if you starting using detailed tool reports.  Going through a report and 5 or 8 holders are defined, the OCD kicks in and you just go ahead and define the rest.  Surprisingly it makes it easier for the operators.  (less decisions)  Another point, if you do your own setups, always, and don't have to have good documentation for other people, then unless there is a reach issue or something where you needed backplot to help determine if it would clear, you probably won't find the value.