[rdsi]

Just when I thought it was safe PP plows a 1/4” EM into my work piece. I was using the “Conversational Pocket - CIRC” mode to cut some holes and found that for some values the tool does not follow the expected path – it just goes straight to “Z END”, makes one circle, then retracts. This really makes a mess!

So the tool path window show a series of circular paths to “Z END” but that’s not what happens. For a given set of inputs I can set “Z END” to -0.199 and it works as expected. Set “Z END” to -0.200 and straight to the bottom. Set “Z END” to -0.201, and again works as expected – go figure.

I also tried this on my PP simulator and get the same results.

So here the screen shot of my inputs:

(Note: Tool 8 is 1/4” End Mill)

So with “Z END” set to -0.199 as shown the tool follows the expected path (file “H199.txt”).
Now if we set “Z END” to -0.200 the tool just goes straight to the bottom of the hole, makes one circle, then retracts (file H200.txt).
Now if we set “Z END” to -0.201 things are fine again and the tool follows the path (H201.txt).

This is spooky! Maybe someone could help me verify this?

Running PP V1.9.7

Thanks

[rdsi]

So I had time to try & understand this some more.

Summary: Using the PP Conversational Pocket CIRC function I found a set of values whereas the tool does not follow the expected path. This can break things…

I was using this function to cut a bunch of holes into a 3/16” AL panel so I set my depth or “Z END” to -0.200”. I was using a 1/4” end mill and everything was working well until I got to this hole 0.38” in diameter. Instead of doing the programmed helical path to “Z END” it just goes straight down to bottom depth, -0.200”, does a circle & then retracts. That really sucks…

So I noticed that it works correctly if I set “Z END” to either -0.199” or -0.201” as indicated in the files I posted earlier, H199.txt & H201.txt. These were generated by the PP Conversational Pocket CIRC function.

Anyway, looking at it closer there seems to be an odd relationship between “POCKET DIA”, “Z END”, "Z START" and the tool diameter that causes the problem. The other variables don’t seem to affect it.

At first I thought maybe it was the python code used in the “Conversational” function setting bad values for the G3 commands. Using the “H200.txt” program I substituted G3 with G2, same command just rotates the opposite direction, and things now work as expected.

So it looks like G3 has an issue. This code should produce a helical path, 15 passes, from Z 0.000 to Z -0.200 and it does not:

G3 X 0.0643 Y 0.0095 Z -0.2000 P 15.0000 I -0.0650 J 0.0000

If we use G2 instead:

G2 X 0.0643 Y 0.0095 Z -0.2000 P 15.0000 I -0.0650 J 0.0000

it does the expected move.

I also found some other input values where the problem occurs so I think it needs to be addressed. Because I don’t know how the G commands are implemented in PP I’m at a standstill (does anyone know if the source code is available for these?).

So I’m thinking it’s a bug with G3 & not with the “Conversational” function …

Time for a bug report to Tormach.

[adamvs]

rdsi, whoa, that's kind of a bad one. It looks like a EMC issue not Path Pilot. What version of Path Pilot are you on?

[rdsi]

Ok, I shot a video that highlights what I’m talking about. I’ve changed some of the settings to speed things up and I’m using a “Z END” of -0.1010”, runs as expected, and “Z END” of -0.1000”, tool plows into the work-piece:



Ouch!

These settings depend on the tool size also, as shown my tool 8 is a 1/4" End Mill with 0.2500" set in the offsets page.

Note: This is PathPilot V1.9.7

[rdsi]

I decided to run my files H199 & H200 on LinuxCNC to see if I would get the same results – and I do. Both of these files were created using the PP conversational. So while I was preparing to submit a bug report to the LinuxCNC folks I noticed the values being passed to the G3 command from the conversational are pretty strange.

First, I have to eat my words about a possible bug with the G3 command. The problem really lies with PP conversational generating strange values for the G3 command. The G3 command otherwise does work correctly.

First, both of these files have strange values and neither generate the desired tool path. Its just H200 does so in a more obvious way.

So in PP Conversational, Pocket, Circular (the CIRC button checked) both files want to pocket through a 3/16” panel making hole 0.380 in diameter using a 1/4" end mill. The XY coordinates really don’t matter so they are just set to 0.

>>X CENTER: 0
>>Y CENTER: 0
POCKET DIA: 0.3800
>>>>>Z DOC: 0.050
>>>Z START: 0.0000
>>>>>Z END: -0.1990 or -0.2000

Speeds & feeds don’t matter for this exercise but the tool diameter does & we are using a 1/4” end mill. So what tool number you enter here must equate to 0.2500” diameter.

So with these values the conversational should generate code to produce a helical cut forming a 0.380” diameter hole at some XY location. Well, it kinda of does this but in some cases your gonna break your tool.

If we look at the parameters being generated for the G3 commands they are just strange.

In file H199 we have:

G0 x 0.650 y 0.0000
.
.
G3 X 0.0622 Y -0.0188 Z -0.1990 P 14.0000 I -0.0650 J 0.0000
G3 X 0.0622 Y -0.0188 Z -0.1990 P 1.0000 I -0.0622 J 0.0188

The first G3 does the helical path & stops at the bottom. The second G3 picks up where the first one left off and completes a final circle at the bottom to clean up the remainder. To do what we specified in the conversational the G3 parameters should be:

G3 X 0.0650 Y -0.0000 Z -0.1990 P 4.0000 I -0.0650 J 0.0000
G3 X 0.0650 Y -0.0000 Z -0.1990 P 1.0000 I -0.0650 J 0.0000

So the conversational in this case produces the hole but its not using complete circles, also the depth of cut gets adjusted to 14 passes instead of the expected 4 with DOC of 0.050” - is this intended? Even though the values seem strange they are on the correct path, they just don’t make a complete circle.

Now when we change Z END to -0.2000 things get more interesting. So in file H200 we get:

G0 X 0.0650 Y 0.0000
.
.
G3 X 0.0643 Y 0.0095 Z -0.2000 P 15.0000 I -0.0650 J 0.0000
G3 X 0.0643 Y 0.0095 Z -0.2000 P 1.0000 I -0.0643 J -0.0095

Well, all we did was change Z END from -0.1990 to -0.2000 so the G3 parameters really should not change except for Z, from -0.1990 to -0.2000. So that’s right, except now where the hell did all these new XYJI numbers come from? For both files they should be the same and they should be the corrected values shown above. I can only theorize the reason H200 plows into the work-piece is because it’s actions are undefined in the G3 reference guide to specify an end point that’s beyond the start point – you can’t do more that 360 degrees.

Now the really crazy thing is when we increase the pocket diameter thing starts to pan out the way they should.

If we just set the POCKET DIA to 1.000” the right code gets produced:

G0 X 0.3750 Y 0.0000
.
.
G3 X 0.3750 Y 0.0000 Z -0.2000 P 4.0000 I -0.3750 J 0.0000
G3 X 0.3750 Y 0.0000 Z -0.2000 P 1.0000 I -0.3750 J -0.0000

Exactly as it should be, plus the right number of passes are generated – 4.

I don’t know but is there some obscure reason to do partial circles & more passes when making small pockets compared to the tool diameter? I thought maybe something with the feedrate but changing it has no affect.

Anyway, plowing into the part is a no-no so I sent a bug report to Tormach. In the meantime I’ll be nosing around in their Python code to see what crazies I can find. I'm thinking maybe a loss of precision or a strange algorithm gone a muck, but who knows???

[GLCarlson]

Tormach's implementation of conversational routines have some unstated assumptions, which are "known" but not well documented. You may be hitting one of those. Tormach has been quite helpful when I crashed on some threading problems a while back.

[rdsi]

Yeah, I have found my share of those assumptions alright. The thing about this conversational is that it does not do what the manual says, plus it has some bugs.

In the manual (UM10349...0916A) it states:

If the tool just fits within the pocket diameter:

• A straight Z plunge in the pocket center is used, therefore a center cutting end mill is needed. Next comes a single pass around the perimeter. This is repeated for each Z Depth of Cut pass.

If the pocket diameter is greater than 2x tool diameter:

• This allows a helical entry which cuts a hole of 2 x tool diameter in center of pocket. Material clearing is done with a spiral cut out to the pocket diameter, plus a cut around the perimeter.

If it did this I wouldn’t have an issue. After taking the code apart what it does is something totally different. So basically as the pocket diameter approaches the tool diameter, the helix angle starts increasing. Instead of “2 x tool diameter” the cutoff is 2 degrees on the helix angle, then the process tries to maintain this angle by increasing the number of Z passes while decreasing the feedrate. This is where things go a muck. Try entering a pocket dia the same size as the tool diameter. The file will not post because there is a division by zero. You would think that would generate a status error message but it does not. So then try something like a pocket dia of 0.251” using a 1/4” end mill. You will get 1824 passes at 0.04 feedrate. Granted, this is at an extreme, but I think it’s typical to drill a 1/4” hole then follow it up with 0.277 bore using a 1/4” EM. Well you would get 68 passes at a feedrate of 0.97 in/min. Then also, certain values from this routine will cause the G3 command to just plunge to the bottom without doing any interpolation.

So I think it’s a bug and sent Tormach a bug report. In the meantime I patched the code to make it work the way I want it. Yeah, if it did the peck thing at DOC like the manual says it would be OK but a little hard on your center cutting EM. An easier fix is just let it helix in no matter the angle & don’t let the feedrate go below 0.5 in/min.

So this is my pocket/hole cut after the patch:



Attached are my conversational files for before and after the fix. I don’t have a video of the before because it plows the tool into my work piece. My previous video shows the path it takes before the fix.

If anyone is interested in this patch you can apply it as follows:

Boot into your systems desktop and download the attached script file “PP_PCP_fix.sh” into your “\home\operator” directory.

Open a terminal up in the “home\opeator” directory. To get this script to work you must give it permission using the command:

operator@tormach:~$ chmode +x PP_PCP_fix.sh

Note: linux is case sensitive.

Now you can do the fix like this:

operator@tormach:~$ ./PP_PCP_fix.sh fix

The scripts save all the changes made so that you can restore your system back to it’s original state like this:

operator@tormach:~$ ./PP_PCP_fix.sh restore

If PP is already running you need to restart it for the changes to take effect. Also, this will work on all the released versions.
After downloading and extracting these files you should have:

H380_Before.nc
H380_After.nc
PP_PCP_fix.sh