Is Z value needed on G43.4 line?

[Ben Wood]

Occasionally I'm getting Z+ overtravel alarms when activating TCP (G43.4) on a Yasda YBMVi40 table-table 5 axis.  The post is pre positioning using tilted work plane (G68.2) and then turning it off (G69) and activating G43.4 which normally works well.  On large parts when my Z0 is set near the upper limits of my z travel I sometimes get overtravel alarms.  When it reads the G43.4 line the machine is still treating the Z value as if the part wasn't tilting even though it is.  In the couple of experiments I've done it seems like simply eliminating the Z value from the G43.4 line will solve the problem.  Before I request a post edit I want to get some advice on whether this is a good idea.  Is anyone using G43.4 without a Z value on the same line?  Does anyone know of a reason why I shouldn't do this?  I have workarounds to the problem but if this works I could quit fighting this issue.

 

Sample code that is giving me a Z+ overtravel alarm.   It works correctly after removing the Z value.

G54 G17 G90
G00 B-90. C-180.
G68.2 X0. Y0. Z0. I90. J90. K0.
G53.1
X-1.8735 Y3. S1000 M03
G69
G05 P10000
G43.4 H10 Z6.7       <-----------------  Can I eliminate this Z value ??
X6.7 Y-1.8735 Z3.     <-----------------  X6.7 on this line is actually a Z move.  Machine moves to correct Z value even without Z on line above.
Z-.99445
X6.1
G01 X5.7 F25.

[Colin Gilchrist]

I'd suggest the opposite > try adding all three values (XY & Z) on the G43.4 line.

As an alternative, I would suggest having the Post modified to include a G43 Hxx Zxx line, inside the G68.2 call, to pre-position the Tool Tip, to the same position as where the start of the G43.4 toolpath move is.

If you do this, be sure #5006.6 is set to prevent "motion on G49", and also that "G49 comes just before "G69", then you can invoke TCP.

G54 G17 G90
G00 B-90. C-180.
G68.2 X0. Y0. Z0. I90. J90. K0.
G53.1
X-1.8735 Y3. S1000 M03

G43 H10 Z6.7

G49

G69
G05 P10000
G43.4 H10 
X6.7 Y-1.8735 Z3. 
Z-.99445
X6.1
G01 X5.7 F25.

 

[Ben Wood]

I tried adding all three values (XY & Z) on the G43.4 line but got weird undesired motion.  I tried your second suggestion of using G43 inside the G68.2 call and that seemed to work.  I tried it without changing the 5006 parameter and didn't get any Z motion with the G49.  Is this the parameter I should change?

[TFarrell9]

17 hours ago, Ben Wood said:

I tried adding all three values (XY & Z) on the G43.4 line but got weird undesired motion.  I tried your second suggestion of using G43 inside the G68.2 call and that seemed to work.  I tried it without changing the 5006 parameter and didn't get any Z motion with the G49.  Is this the parameter I should change?

That's bit #2. Bit count moves from right to left, starting with zero. "TOS" is bit #6.

[rgrin]

Here is some code that is running on a Yasda H40i

 

N1(T13019600: 5mm 2Flt Ball TaperNeck AlTiN)
T13019600
M06
G49G53Z.0
M302(Semi Finish Machining Mode)
G5P10000
S12650M03
M11M71

G00G90G54B4.125C90.0
G68.2 X0.0 Y0.0 Z0.0 I180.0 J4.125 K-90.0
G53.1
X.00751Y11.66382B4.125C90.0
G69
M08M51M44
(G43.4 Note: Absolute Z Approach Move)
G43.4Z3.63437H400
(G43.4 Note: TCP Coordinates Active)
X-11.66382Y.22389Z3.0
Z-1.05819
Y.18073Z-1.65663

 

Parameter #5006.6 is set to 1 for me right now

[Ben Wood]

On 4/26/2024 at 10:23 AM, TFarrell9 said:

That's bit #2. Bit count moves from right to left, starting with zero. "TOS" is bit #6.

Thanks for clearing that up.  Its been a while since I've had to mess with this stuff and I was vaguely remembering there being something weird about counting bits.

[Ben Wood]

3 hours ago, rgrin said:

Here is some code that is running on a Yasda H40i

I already tried some sample code output from Camplete for Joas's YBM and got the same Z overtravel when I set the Z offset high enough.  I think Colin's idea of using a regular G43 first and then turning on G43.4 afterwards might be the way to go.  My new shop is like my old shop and I'm trying to run parts that barely fit into the machine.

[Colin Gilchrist]

Note that your "TOS" Setting is already on! (That what we're confirming with #5006.6 being "on".)

This means "no Z-Axis motion" with G49, which is the desired outcome.

[cncappsjames]

What is #1301.7 ?

0 = Stroke Pre-Check Off

1 = Stroke Pre-Check On 

I like to have these off when I run 5-Axis machines. From time to time I'll get a false overtravel if certain conditions are present. 

[Ben Wood]

1 hour ago, cncappsjames said:

What is #1301.7 ?

1301.7 is turned on.  I tried turning it off but it didn't help.  It is physically trying to move.  I can see it move up .026 before it alarms.  I'll have to keep this setting in mind if I'm ever getting other false overtravels.

I'm going to look into this a bit more when I have some time.  For now I'm going to set my Z0 off the bottom of the part instead of the top.  Setting the Z0 lower solves the problem.  

[cncappsjames]

Sometimes you have to do something weird with the work offset to get it to work.... but I'm thinking ther may be one or two other parameters... lemme check.

[cncappsjames]

Have you tried

G91

G43.4H?

G90Z...

[Ben Wood]

14 minutes ago, cncappsjames said:

Have you tried

G91

G43.4H?

G90Z...

Just tried that and it didn't work either.

[cncappsjames]

YOu may just end up having to set your Z to another place on the part... that's really weird though. Any chance you can output the parameters and DM them to me? What is the control and about how old is the machine ?

[Ben Wood]

The control is a Fanuc 31i-Model B5 and the machine is a 2019 model.  I couldn't figure out how to message the parameters so I tried to attach them here instead.

CNC-PARA.TXT

[cncappsjames]

Perfect, I'll take a look.

[huskermcdoogle]

Well, I guess I'll chime in here a little bit.  For the question of if you can activate G43.4 H## without a z on a Fanuc 31i, absolutely.  Do it every day.  Not sure on our parameter setup, but there is no movement, but the absolute coordinates jump.  But we are on a head head machine.  Shouldn't make much difference going to a table table design, actually it likely makes it a bit easier.

99% of the time, unless I am up against a barrier, our format is:

G5.1 Q1 R#

G54

G43.4 H

G0 G90 X# Y#Z# B# C# S# M3

 

Basically speaking, I don't see any reason whatsoever if the machine doesn't move calling G43.4 H by itself in the current config.  If the coordinates shift when you execute that line, and it doesn't move, it is configured not to.  Then you can go about business as usual.

Now on another note, and I am by no means an expert on Table/Table machines, but why would one preposition with G68.2 then cancel and run TCP instead?  Seems confusing and cluttery.   In the example above using G68/G53.1, the post has already calculated and moved to the desired table angles, why call it again?  Is it just to make the machine and post are in agreement before you put a tool to the part?

 

Anyway.  Someday I hope to spend enough time on a table/table machines to understand some of these practices.  I have spent ooodles of time tinkering with approach and retract code on the head/head configs, and head/head/table (with TCP on head but not table), and if I had motivation, have notes of thoughts on post structures and methods that would be HUGELY useful for readability and general simplicity of adjustment at the control if one were focusing on short run work.   For the long run stuff it doesn't matter as much because you don't mind going back to CAM for quick edits, but when you are under the gun on a short run part, you just want to fix it in the program and move on.  Then catch the CAM up later when you are back in the office.  But someday I hope to have reason incorporate some really useful 5-axis features into a post.

I'm rambling again....  

[Colin Gilchrist]

1 hour ago, huskermcdoogle said:

Well, I guess I'll chime in here a little bit.  For the question of if you can activate G43.4 H## without a z on a Fanuc 31i, absolutely.  Do it every day.  Not sure on our parameter setup, but there is no movement, but the absolute coordinates jump.  But we are on a head head machine.  Shouldn't make much difference going to a table table design, actually it likely makes it a bit easier.

99% of the time, unless I am up against a barrier, our format is:

G5.1 Q1 R#

G54

G43.4 H

G0 G90 X# Y#Z# B# C# S# M3

 

Basically speaking, I don't see any reason whatsoever if the machine doesn't move calling G43.4 H by itself in the current config.  If the coordinates shift when you execute that line, and it doesn't move, it is configured not to.  Then you can go about business as usual.

Now on another note, and I am by no means an expert on Table/Table machines, but why would one preposition with G68.2 then cancel and run TCP instead?  Seems confusing and cluttery.   In the example above using G68/G53.1, the post has already calculated and moved to the desired table angles, why call it again?  Is it just to make the machine and post are in agreement before you put a tool to the part?

 

Anyway.  Someday I hope to spend enough time on a table/table machines to understand some of these practices.  I have spent ooodles of time tinkering with approach and retract code on the head/head configs, and head/head/table (with TCP on head but not table), and if I had motivation, have notes of thoughts on post structures and methods that would be HUGELY useful for readability and general simplicity of adjustment at the control if one were focusing on short run work.   For the long run stuff it doesn't matter as much because you don't mind going back to CAM for quick edits, but when you are under the gun on a short run part, you just want to fix it in the program and move on.  Then catch the CAM up later when you are back in the office.  But someday I hope to have reason incorporate some really useful 5-axis features into a post.

I'm rambling again....  

So, it is often the case that the starting position for a TCP move can gouge or completely violate the part, if you're starting a path that is "on the far side of the part", or if you're transitioning between one side of the part, to the other.

With a "Dynamic Work Offset or Tilted Work Plane" pre-position move, you're essentially 1) activating a work offset, 2) rotating the table into the correct starting position, 3) calling DWO/RTDFO to "dynamically align the active rotary face (A/C or B/C table position)" to a coordinate system attached to the part, 4) moving into a safe "XY Position", 5) using G43 to preposition Z with Tool Length Offset active, so you're driving the XYZ Tool Tip Position in coordinates which relate to the feature or zero position on the part.

In terms of looking at the code, using G68.2 makes it really easy to gauge position and approach/retract moves, with a WYSIWYG (what-you-see-is-what-you-get) approach.

With TCP on a Table/Table setup, Ben mentioned, "X6.7 is really the Z-Axis". The XYZ Coordinates for TCP are output as if the vectors are related to the "part setup at Rotary Zero", which means just "reading the XYZ values with G43.4 active" is not as straightforward as it would first appear.

The anecdotal evidence I've seen shows that "DWO/TWP Pre-Positioning" generally solves this issue, which is why it is featured as an option in most advanced Post Processors.

In the ideal setup, you pre-position using DWO/TWP, position tool tip using G43 (TLO), cancel TLO with G49, then cancel DWO/TWP (G69), and then invoke G43.4 Hxx, and if you output the same XYZ starting positions (or not), then when the TCP moves start, you're already perfectly in position because of the pre-position moves, and the path essentially "always works", or at least you can catch issues and diagnose root cause, much more easily by observation during the pre-position process.

On a Table/Table VMC machine, using TWP, you're essentially always rotating a plane on an angled face into alignment with the XYZ machine axes. This means in general that "Z = Z" once G68.2 is invoked, provided it is setup properly (machine parameters) and called properly (NC Code).