4 hours ago, Leon82 said:

Our original IT company didn't think we needed a good graphics card

That always cracks me up.  As I sit here on my expensive can't even function as a boat anchor laptop.

Has great specs.  Can't handle Windows, no less actually running mastercam.

Generally speaking here is what I lead with.  I'll just post it up here as people are interested.  I'll let you guys figure out who I work for now if I didn't already spill the beans before.  Should be pretty obvious.

From around .5" to .625" and less I will lead with solids either our GOdrill or Y-Tech drills.  Above that size mark, depending on depth requirements I'll switch to KSEM.  This is in Inconel anyway.   Non S materials, I would be using KenTip FS above about .250".

The GOdrill is the low cost solution of the two solids I like, the Y-Tech can be and usually is looked at as a problem solver.  Now, I have found the GOdrills to work in just about any material, key is looking at the chips and making adjustments to the parameters to optimize.  I just ran an 8xd 8mm full depth without pecking at 85 SFM, and .0018" feed.  Could it be faster, sure likely, but our chips looked good and the drill doesn't look used after 8 holes.  It has a little trouble getting the chips out for the last .5" or so, but it doesn't seem to show up in the hole finish.  This drill has a marginless design so it doesn't rub, but this also means that if you damage the point, it may have a tendency to walk a little bit.  If this becomes an issue, that is when you enter in with the Y-Tech drill which is a 3 margin design, this cuts down on drag vs a 4 margin design, but yet still provides extra guidance and stability.  The Y-tech has a slightly different point geometry, but it is more optimized for S type materials.  This drill also is better at evacuating chips at the longer depth to diameter ratios.

For the bigger holes, I suggest the KSEM platform.  Plain and simple, it just works.  As long as you have a good stable part, you can go well over an inch and diameter with this tool, there are flat bottom geometries as well (FEG).  FEG's aren't ideal for Inco, but work very well in Titanium, Steels, and Cast Iron.  For normal angled drill points, I suggest the SPL point, it makes a beautiful hole in Inconel.  The SPL point should now have a margin-less first margin and a normal secondary margin for stability.  This reduces drag and work hardening of the wall if you have to counter-bore the hole or something after, not to mention the reduction of heat generation, which we all know likes to destroy any and all cutters.

Anyway, got to run.  If any of you would like to run any of these drills, or have tried and failed in the past.  Feel free to reach out to me and we will see what we can do to help.

Husker

On 9/18/2019 at 7:02 PM, Colin Gilchrist said:

And yes, drilling Inconel, especially 718, is terrible.

In comparison to other materials, yes.  But it can be done with a relatively high level of process security.  It just depends on what you are trying to do.  Generally speaking, drilling in 718 is fine up to 8xd or 2" deep, whichever you hit first.  Depths less than that are easy peasy as long as you don't get greedy.  You just need the right tool for the job.  We have three drilling platforms that are very capable of removing 718 material, good, better, and best.  I won't advertise here, but if you would like to know which I speak of, please feel free to ask.

Now, tool cost to drill 718, well that is a completely different story, it can get pricey, fast.  But then again, isn't mechanical material removal by all methods expensive in nickel based super alloys?

Interesting.  You learn something new everyday.

Last I checked you couldn't run cutter comp using Helix bore due to not being able to start comp on a circular move on a fanuc and some other controls (pretty sure not all though).....  That said, I typically use circle mill to get around that limitation.  It would be nice if we had the ability to add a tangent or perp line on start and exit with helix bore just for cutter comp.  Of course I may be missing something here...

You could add that capability to your post tied to a mics int/real, but IMHO, it's not worth it.  If you are going to run a regrind on a dynamic mill path you are likely best off just letting it run on center-line and add a second semi finish pass around the perimeter with comp to cleanup.  The reason for this is due to the nature of the dynamic paths being point to point or having a high likelihood of some short line to line segments which is hard for the control to calculate comp vectors to.  This will result in potentially unreliable/non-executable NC code as you change the comp value.  Just kind of the way it is.  Could this "shortcoming" be overcome with some clever "look ahead" buffering in the post.  Sure.   Are there many people up to the task, nope, probably not enough monetary need out there to make it happen. 

5 hours ago, daskas272 said:

you mean to specify the card reader as the data server host

no, i don't think so, we are working on old memory here...  You would be specifying the destination on the data server.

If you can see the program on the card, it should be just the same as pushing from CNC memory to the Data Server.  As long as you have specified the data server as the current device (Device Change), then activated the folder in the data server, you should be able to punch the card program to the data server.

Have fun with that one....  I'd say sink that thing.  Definitely less aggravation.  I've never ran endmills that small in 718.  I've been doing some seal grooves lately with .078" tools, but they are shallow and those tools are stumpy.  That gives enough grief.  I can't imagine trying to do what you are looking to do, without burning through a tool or two.  If you do end up machining them, I'd really like to know the process and tooling you settled on.  That's good spankbank material right there.

On 9/5/2019 at 4:11 PM, PAnderson said:

Problem is, this is a customer that is brand new to 5 axis and thinks picking a different style of toolpath is a "work around".

Well, I would agree with them....  With a properly setup post and a properly corresponding machine parameter set using TCP you should get what you are looking for.  I'm curious why the post isn't outputting XYZ moved with the rotary since you are running table coordinates.    But at the same point, it's interesting that even though only the rotaries are specified, I would think it would still result in linear machine movement.   Anyway, yeah likely a different toolpath, or just changing the way that toolpath is processing is the best approach.

Best of luck.

2 hours ago, PAnderson said:

Just an update. Still not solved.

What do you have in 19696 #6?

2 hours ago, Thad said:

JP is no longer a forum member.

I was wondering what was going on there.  Did he quit or get asked to leave?

8 hours ago, M4573RMZD said:

I came across this thread but I cannot get the "Dynamic Database" The link is gone.

It's in the pinned important topics thread.  But appears to be broken.  I guess we will need to see if JParis can resurrect.  This came up the other day and I regret I don't recall if a new link was made.

24 minutes ago, PAnderson said:

but that might not work for every case.

Good thoughts.

Have you tried programming in workpeice coordinates instead of table coordinates where the programmed point is in relation to the moving part instead of fixed to the machine base axes, might force proper xyz output and resolve a feedrate properly?

I'd also look at trying Inverse time feedrate and see if the problem goes away.  I personally don't think it should make a difference, it seems there is something else off parameter wise that is preventing the machine from "speeding" up and resolving the proper feedrate.  Is it supposed to be feeding in part coordinate XY but accomplished only with rotary motion?

Firstly is this a head/head, table/table, or head/table machine?  This will make all the difference in the world.

When there is no linear motion it just becomes degrees per minute.  IIRC there is a parameter setting in the control that will control the machine behavior in this case, making it move at the speed and accel limits that AICC sets, and move at "rapid" when there is no "xyz traverse" associated @ TCP.

I'd start there, or just switch to metric feed rates so the angular rates "become" much higher , or inverse time as said above would certainly help.

Bottom line, proper settings with TCP you should never need inverse time, and if you have no XYZ, properly setup in the parameters, should move at max "safe" speeds as determined by AICC.

On a table/table machine, you could also change to output code in part coordinates, which would force x/y/z on all moves and then the machine would be forced to calculate feedrates on every move.  However it should be doing this anyway.  Something seems funky with your machine parameters.

Anyone else been noticing that sometimes when you go in to edit parameters in a 3D  or 3D chamfer contour toolpath that it will change back to 2D randomly and unless you keep a watchful eye could cause you a crash or serious material gouge.

I have now seen it in 2020 and 2019.

I think the key is finding someone with either proven advanced programming experience on any type of machine, and a track record of having a desire to constantly learn and push the boundaries of their current knowledge.  That person will in short order be able to make that machine do things you didn't think we possible.  Finding someone that already can do what you think you need is obviously a needle in a haystack. Compounded by the fact that you really may not know what he actual qualifications are for the right person.  Sure you might be able to find someone that knows the machine functions and how to tie them together, but will you be able to find someone that has an unbiased view on how to process the parts that you want to throw at it.  Someone that will try three different things just to see which is best, instead of just getting it done with the first method they tried.

I have thought long and hard about this challenge in the past, as we were always looking for someone to take some load off of me at my last job.  To this day, he still hasn't replaced me, and continues to use a contractor that I have mentored over the years.  The key is to develop the skills you need.  To do that you need someone with the desire and motivation to learn by any means and methods available, to the fullest of their potential.

Best of luck.

Just out of curiosity, how many CAM packages out there do have good support for 3D comp, both for 5 axis and 3 axis toolpaths?

My gut tells me we aren't the only ones lacking this functionality.

Correct me if I am wrong but don't we lack surface/tool contact point in the NCI with any of the 3D tool paths which is what you would need to calculate the 3D comp Vector.  IIRC even the MW paths lack this in the NCI, under the hood I would imagine that data is available for all paths.

I would be perfectly happy if they just gave us more framework to work within.  I would have ran with it ages ago, in a previous life, would have made my life much easier doing 3D rotary surfacing.  They could even bother to allow us to post standard comp in the classic 5X paths, for that last few years.  (has that functionality been restored yet?)

On 5/22/2019 at 8:59 AM, Piter69f said:

*my "axis supports continuous positioning" was set to signed continuous and I changed it to signed direction, and shortest direction and it still post as C-60

Is it code, or the machine that is the issue here.  If it is code, then depending on your post you need to look at the misc integers at the operation level in Mastercam.  If it is the machine disregarding the code and going shortest distance, then you need to look at machine parameters.  If you give us some information about the control if it is a machine problem we can likely help point you in the right direction.

On 5/4/2019 at 10:35 AM, NOTW Programmer said:

Can you be a little more specific? Where do you set the limit, in the post or the operation?

As he is stated that he is using vectors for 5x paths, I would guess he is changing the machine axis limits in the machine parameters on the machine, not at the operation level in MCAM or post.  This will allow the machine to decide which way to go to get "proper" angles.

Kind of a clever solution if you ask me.  I have often wondered if using vector programming is actually better practice once you understand how to bend it to your needs.

I would think a good starting place would be good visual management techniques like KanBan or something of the sort.  That combined with an excel database of tools that should be stocked in the crib should suffice.  I would start that with consumable tools, and eventually holders and components, then finally with assemblies.  Any time a tool enters or exits the gate it goes into the sheet under the proper category.  Any time an assembly is broken down, the components are put back into used inventory, both physically and in the sheet.  The physical visual management Kan Ban cards are the tool to make sure the tools are properly logged in the system.  Eventually, the system will know roughly where everything in the shop is supposed to be, and have a decent idea of it's status.

38 minutes ago, Colin Gilchrist said:

f you go the neutral route, I have found that fillets, faces, and sometimes entire features, will get missed by the conversion process.

There are things you can do on the settings side of Creo/ProE to make these problems go away with almost 100% certainty.  I don't have the instructions off hand, but it's in the history on here.  Been floating around for over a decade.

Can you give us anything more as to what you were editing, or did this just come out of nowhere?  We can gladly help, but can't help if we don't know what is going on.

You will need to look at the structure of the string select table in question and see why it might be erroring out.  If you added to it you just need to readdress the table length.

Backplot would have to be kinematically aware in order to give you accurate kinematic angular output.  So as 5th axis has stated, machine sim would be the place to make that happen for now.  For truly accurate values you would want a post linked machsim.

1 hour ago, David Conigliaro CNC Software Inc. said:

Changes to chaining go far beyond the interface in 2020.

Has there been any documentation/explanation of these changes yet to showoff the new features?