DMU 70 with Heidenhain Mill Plus in G7 Mode and Vericut 7.3.

[mcpgmr]

This might be a better question for CGTech but I thought I would start here first. In G7 mode (3 + 2) Vericut runs without fail but the machine alarms because of travel limits. My guess is that G7 is not supported in Vericut. The feature I'm cutting is an edge profile that has both rotary axis's positioned so that the cut actually looks like it's almost along the "Y" axis of the machine but the control only shows the "X" axis moving. I checked all the settings in Vericut as far as travel limits go and they seem to be set right. Has anyone else ever experianced this? This part has to be done in 2 ops now when it was actually quoted to be 1 setup and 1 op. Doh!

[Watcher]

This might be a better question for CGTech but I thought I would start here first. In G7 mode (3 + 2) Vericut runs without fail but the machine alarms because of travel limits. My guess is that G7 is not supported in Vericut. The feature I'm cutting is an edge profile that has both rotary axis's positioned so that the cut actually looks like it's almost along the "Y" axis of the machine but the control only shows the "X" axis moving. I checked all the settings in Vericut as far as travel limits go and they seem to be set right. Has anyone else ever experianced this? This part has to be done in 2 ops now when it was actually quoted to be 1 setup and 1 op. Doh!

 

G7 is perfectly supported in VERICUT.

 

Are you sure that travel limits are defined properly on your VERICUT VMC? If you think so, report it to CGTech. They should work.

 

The reason you see X on the control is because G7 applies a kinematic transformation, which you can see in VERICUT by toggling the coordinate systems on...

 

This is very unlikely as well, but there are macros that turn off the travel limits...

 

These are a few of them... Please go to help, "On VERICUT"-> "Back to CGTech Help Library" -> "VERICUT Macros" and read about them... maybe one of them or a combination is affecting the travel limits checking behavior... the macros are very well documented and refers all the time about how they play with travel limits...

 

Ijk2AbcIgnoreLimits

Ijk2AbcType

TravelLimitErrorReporting

TravelLimitGroup

TurnOnOffCompTravelLimits

TurnOnOffSubsystemTravelLimits

TurnOnOffTravelLimits

WorkingPlane2AbcSolution

WorkingPlane2AbcType

[mcpgmr]

Thank you! I understand the Kinematics but added that comment to try and make it more clear to anyone reading the message. Thanks again.

[mcpgmr]

Well I contacted Vericut and they are working on it. Seems the travel limits in Vericut are set but not being adjusted in G7 mode. I have a feeling this is gonne get expensive.

[Watcher]

Well I contacted Vericut and they are working on it. Seems the travel limits in Vericut are set but not being adjusted in G7 mode. I have a feeling this is gonne get expensive.

 

If it is a problem or a bug and you're on maintenance, it won't cost you nothing more than the annual maintenance fee...

 

On my experience, they always fix issues and help customer whenever is possible. You should expect an answer soon...

[mcpgmr]

We are on maintenance thankfully. Here is a screen shot of the issue I'm having. The edge profiles are angled sort of like a knife edge Not perpendicular to the surface contour.This causes the rotary axis's to bring the edges normal to the spindle so I can use the side of the end mill to cut them. Also, all the fastener holes are locally normal to the surface so the machine needs to position normal to spindle for drilling and countersinking. I thought about custom dove tail cutters for machining the edges. This would reduce the angle positions which would buy back some of the travel I'm losing but I still have to drill the holes so that idea doesn't help.

[mcpgmr]

Thought I attached a picture. I'll try again.

[mkd]

nice part.

I've been making those too. how much are you charging?

 

first time i programmed those i got allot of potential overtravels on a head head machine, which translate into unwinds with a good post. Part looks simple but gives MC swarf fits.

 

 

on a side note it was pretty "fun" doing those compound holes on a 4axis Haas with only 20" on the Y. MC verify saved my bacon.

[Jim at Gentex]

I program for a DMU 80 and I also run into similar problems.

 

As to the G7 overtravel alarms, Daniel's explanation is a good one.

Once that kinematic model is transformed, axis labels change accordingly.

It is confusing at first, but once you become accustomed to it you do get a good feel for which axis is doing what.

 

Also, I've found that there is a 'working envelope' in that G7 mode.

Sometimes just changing the initial position of the tool before the G7 transformation can eliminate the overtravel alarms at the machine.

 

 

 

Part looks simple but gives MC swarf fits.

 

 

Any time I have trouble with a swarf toolpath, I've found that most of the time I can use a 5 axis curve path instead.

I simply use the bottom spline of the swarf surface as the drive chain, and the vertical lines that define the normality of that surface as the tool axis control lines.

 

Works like a charm!!

[mcpgmr]

mkd, This is 1 of 8 different extension panels that I have to do. These are development parts that will go to production this year. What material are your parts made of? These are near net molded composite parts. All I have to do is trim and put in fastener and nut plate holes. 2 setups since the machine is not big enough. We are getting quotes on production machines now and it looks like the Mazak I7000 with paletec or Mori Seiki NMV8000 with a palette system will be the two we choose from. Yes these are fun parts. I designed the fixtures for machining and the CMM plus programmed them. Having a blast!

[mcpgmr]

_{Hi Jim, I'm actually not using any swarf cuts in this program, The edges are ruled so I just position and cut. When you say there is a working envelope in G7? How do you determine that before hand? This is what I'm trying to get Vericut to do. CGTech is looking into it for me. One would think that a software like Vericut could do that.}

[mkd]

mkd, This is 1 of 8 different extension panels that I have to do. These are development parts that will go to production this year. What material are your parts made of? These are near net molded composite parts. All I have to do is trim and put in fastener and nut plate holes. 2 setups since the machine is not big enough. We are getting quotes on production machines now and it looks like the Mazak I7000 with paletec or Mori Seiki NMV8000 with a palette system will be the two we choose from. Yes these are fun parts. I designed the fixtures for machining and the CMM plus programmed them. Having a blast!

CF

two ops; ouch. Kinda hard to hold true position, eh?

those are some fancy machines for these parts, but if the money is in it why not.

 

how you doing the countersinks?

[crazy^millman]

One would think that a software like Vericut could do that.

 

Kind of what happens when you do not make the posts. When you take complete ownership of the prcoess from the posts to the simulation to the control emulation then you can know that understand that and make code to run that way. Vericut can only take what it is given and show you what is going on. The ability to fix it before it becomes a problem is normally where the PP takes control, but since they do not do post they have no idea. Like James has said about CamPlete they take control of the whole process. ICAM does that as well. Now you will probably have to buy some other expensive option from Vericut that will now take that into account. If they controlled the PP they would have taken the limits and kinematics of the machine into account and positioned correctly for the Verification. They have no idea they can only take what a PP gives them and show you that. Then you have to invoke this or that to then hope it finally gets dialed in. Good luck and sounds like you got some fun ahead of you and hopefully not a lot of money.

[mcpgmr]

• 
  CF
  two ops; ouch. Kinda hard to hold true position, eh?
  those are some fancy machines for these parts, but if the money is in it why not.
   
  how you doing the countersinks?
  

Not too bad actually. The parts re position themselves pretty well using high quality aerospace grade flat head socket head screws.

 

Fancy machines? Yes but we have many different parts beside these that will keep them busy. May add a horizontal to the cell later on. Depends on how busy we get.

 

 

How do I counter sink? With just counter sink thats all. Do you have issues with countersinking?

[Watcher]

Now you will probably have to buy some other expensive option from Vericut that will now take that into account.

 

No. This is merely a configuration issue. There's no VERICUT option to handle this specifically... But ICAM should do it better since it posts too and checks coordinates against machine limits all the time I guess...

 

I agree that with ICAM and CAMplete the embedded post-processor would solve these issues, using for example features like Rotary-turn-around (RTA) option.

 

Every system has its pitfalls... arc filtering is included in the basic package from VERICUT, but it is an option in ICAM (NURBS & ARC Fitting).

 

Not sure if the last still true for ICAM, but their website says so.

[crazy^millman]

Every system has its pitfalls... arc filtering is included in the basic package from VERICUT, but it is an option in ICAM (NURBS & ARC Fitting).

 

Not sure if the last still true for ICAM, but their website says so.

 

Yes it is still very true.

[mcpgmr]

BTW, The post I'm using is from Cimco. Seems to do the job.

[crazy^millman]

The post should be taking the axis limits into account and giving you the out codes you need based off those requirements.

[mcpgmr]

_{I'll take a look and see if there is any referances to G7 and axist limits in the post. Could be that it was never configured properly. Thanks.}

[Jim at Gentex]

_{Hi Jim, I'm actually not using any swarf cuts in this program, The edges are ruled so I just position and cut. When you say there is a working envelope in G7? How do you determine that before hand? This is what I'm trying to get Vericut to do. CGTech is looking into it for me. One would think that a software like Vericut could do that.}

 

Honestly, I've done it by trial and error.

Sometimes it works and sometimes it doesn't.

When I use the term 'working envelope' I mean that the travel limits are contingent upon the active G7 toolplane.

As far as defining that envelope beforehand I don't know of a way to do that.

 

I'll give you an example of what I mean:

 

I have a program that begins with a G7 transformation of the tilt axis B @ -45 degrees.

We like to position the head far enough away from the fixture / workpiece to avoid a collision as the head rotates to B-45

I have the default value for that set at X-20 (inches) and Y at zero.

 

What I have seen in the past is that the tool will move to the preset location @ X-20 Y0 and safely perform the transformation to B-45.

However, when the program then calls for the initial positioning move for the tool in that toolplane, the machine will sometimes give a Z or X limit alarm.

This tells me that the tip of the tool is now outside of that invisible envelope that the machine sees for that toolplane.

When that happens, I will often change the initial position to X-15 or X-10 (depending upon the length of the tool and toolholder) to see if the B axis rotation can still be done safely.

Often if it can still clear the fixture / workpiece at X-15 or X-10, it will be able to do the B-45 transformation, then move to the initial position in that toolplane without causing an alarm because the tip of the tool is now within that invisible envelope.

 

I don't know if I explained that clearly, but that has been my experience.

[mcpgmr]

I see what you mean Jim. Thanks for the explanation.

[Watcher]

The post should be taking the axis limits into account and giving you the out codes you need based off those requirements.

 

Is not that simple Ron. The "physical" axis limits lies on the original cartesian plane, without any transformation. However, when G7 is active, this plane is then rotated. And the control is able to know the limits because it constantly check the motions against these "non-transformed" planes and also the mechanical switches. Software emulating this requires some configurations as the switches do not exist...

 

In Millplus, there's the G74 command which allow you to move a transformed axis to its limits, taking into account the current transformation. On a DMU 80 machine where the head tilts for example, a complete retraction along the current tool axis on a given vector other than 0,0,1 will cause X to move as well, along with Z (Table). Well, if you want to retract the tool along the current Z of a tilted plane to the maximum position without worrying about how far the machine's X can go, program a G74 Z1=0 and voila!, the control will coordinate the axes so that Z moves to the maximum possible value without overtravelling X...

 

Of course that being a DMU70 a vertical 5x machine (Z is always vertical) G74 Z1=0 always behave the same way...

[mcpgmr]

Good stuff! Now if vericut could just follow those rules I'd be in good shape! They are working on it.

[Watcher]

Good stuff! Now if vericut could just follow those rules I'd be in good shape! They are working on it.

 

If memory serves me correctly there's a DMU100 with MillPlus on VERICUT's library. You can test this stuff with it.

 

If CGTech realizes they can't support what's said above, they will make it. That's my experience with them. They're currently developing a dynamic overtravel detection algorithm for one of our MillTurns with dual channels. All I had to do was to setup a conference call with one of their corporate support guys and once he got the idea he took it to R&D.

 

I worked with DMU70 and Vericut 5.x seven years ago. I remember they're able to support it well back them. It should be even better now.

 

Let's hope for the best. Let us know if they get it fixed for ya...

 

Daniel

[Watcher]

Is not that simple Ron. The "physical" axis limits lies on the original cartesian plane, without any transformation. However, when G7 is active, this plane is then rotated. And the control is able to know the limits because it constantly check the motions against these "non-transformed" planes and also the mechanical switches. Software emulating this requires some configurations as the switches do not exist...

 

In Millplus, there's the G74 command which allow you to move a transformed axis to its limits, taking into account the current transformation. On a DMU 80 machine where the head tilts for example, a complete retraction along the current tool axis on a given vector other than 0,0,1 will cause X to move as well, along with Z (Table). Well, if you want to retract the tool along the current Z of a tilted plane to the maximum position without worrying about how far the machine's X can go, program a G74 Z1=0 and voila!, the control will coordinate the axes so that Z moves to the maximum possible value without overtravelling X...

 

Of course that being a DMU70 a vertical 5x machine (Z is always vertical) G74 Z1=0 always behave the same way...

 

My point here is that although I know it's mathematically feasible, I don't know about posts that re-map/project every coordinate and intermediary positions from a transformed plane onto the machine's non-transformed plane to check against limits... maybe ICAM can do it because of the embedded simulation, but my gut says that they don't do it out-of-the-box... they can catch it during the simulation but not during the post-processing, as the only way to do this effectively is linearizing in small segments every motion and re-map them on the basic orientation, what would impact the post-processing time significantly because of the extra re-mapping.. That's why I believe no PP does it out-of-the-box. Linearization of 5 axis motion is hard enough already. (And ICAM does it nicely AFAIK).

 

Notice I'm not talking about solving limits in multiaxis toolpaths (swarf, curve 5x, etc) but rather about solving a simple overtravel issue on a tilted plane (3+2), For multiaxis RTA (Rotary-Turn-Around) would work, as long as the PP is able to check against the machine physical limits, which as I said, lies on a non-transformed orientation. I bet my best beef that the control does this by projecting the transformed plane coordinates in the non-transformed plane in order to foresee and detect overtravels.

 

Most of 5x paths are linearized anyway, specially if the tool vector changes. But modern PPs can also filter linear motions with unchanged vectors (Spitting out colinear moves or arcs), and this may pose even more challenges because the post would have to linearize what has been filtered already. Crazy eh?

 

I may be deadly wrong of course, but the above makes sense to me...