PathPilot Conversational Drilling Op producing tool crashes due to flawed coding

[aftcargoheat]

I just assembled a brand new Tormach 770MX with ATC and have come across what I believe is a coding error in PathPilot. The problem causes a tool crash only in a special case. It is difficult to explain, but if I summarise and someone has the time to try what I am saying, then maybe someone will either agree or tell me where I am wrong.

Special case: all these must be true...

1. conversational drilling op (or use drilling op in fusion 360 Tormach post processor gives same issue)
2. must call drill from ATC, not load manually
3. drill in the toolholder is a long one, such that it reaches down to lower Z than top of your work in the vice, when it sits in the carousel of the ATC

This will result in a crash.

Why?

Because after the tool change command and the new drill is loaded, the very next command is always move in X and Y to bring the work back from the "safe" G30 position and under the spindle ready for the next hole to be drilled, and THEN after that, the spindle is moved to "Z clearance" height. It is too late by then!

This should not happen. There is no issue with having a long drill in the ATC. That is why we specify "Z clear" in the conversational, or "clearance height" in CAM.

If you reverse the two lines of code so you do the Z clear move first then the X,Y, then the crashes stop!

I am using latest version of PP, ver. 2.7.4

I have asked Tormach about this, but no response so far.

Does anyone have any comments on this? I would be really grateful for others' input.

If you didn't happen to use a long drill, you would not see this problem. If you loaded the tool manually, you wouldn't either. But does anyone else see what I mean?

Similar Threads:

• Newbie- PathPilot - Left Handed Grooving Tool - M04 Reverse in Conversational
• Conversational causes crashes
• Need Help!- pathpilot homing crashes
• Drilling holes using PathPilot conversational

[aftcargoheat]

drill practice G code.txt

Here is the code PathPilot produced.


There are three separate drilling ops. In each one, you can see...

G0 X50. Y-11.5
G0 Z15.

These two lines ought to be reversed I believe.G0 Z15. is the move to my Z clearance height.

But every time, PathPilot produces the code with the lateral XY move first.

[shred]

These two lines ought to be reversed I believe.G0 Z15. is the move to my Z clearance height.

But every time, PathPilot produces the code with the lateral XY move first.

Long tools in the ATC have always been an issue. It sounds like your drill is so long it would crash into the work just sitting in the carousel if the table was jogged over there?

I've messed with the Fusion 360 post. It doesn't do any moves after the toolchange as far as moves to a safe Z, but you could insert a move to a high machine-Z easily enough if you plan to do this kind of thing a lot.

[aftcargoheat]

Hi shred

thanks for engaging. Yes you are right. But my point is simply, if they placed the "move to Z clearance height" as the next thing after any tool change, then it would never be an issue. That is why CAM software asks you for a "Z clearance figure" so why wouldn't PathPilot make use of that number ?

I don't plan to jog my vice over towards the ATC, and I have set a G30 so the vice in fact goes the other end out of the way. But what PathPilot does is call a G30 at initialisation, and after every operation with a tool, but crucially it does not call one after a tool change. That would be a way of solving this, but the correct way would be, as I suggest, to make the next move after a tool change a Z move to "Z clear".

It would never be an issue again!

[shred]

Hi shred

thanks for engaging. Yes you are right. But my point is simply, if they placed the "move to Z clearance height" as the next thing after any tool change, then it would never be an issue. That is why CAM software asks you for a "Z clearance figure" so why wouldn't PathPilot make use of that number ?

Unless you have high-end CAM and rigidly sync everything, it has no idea what the kinematics of your machine and placement of vises and fixtures and tool change height and toolchanger movements and contents and exact tool lengths and so on. The CAM clearance plane is for each operation and in the work coordinates you are in which it also doesn't know how those map to your machine coordinates, so not really a thing CAM can do much about.

I can see a 'retract to top of Z after toolchange' option, but for most users, it would be a waste of time and extra wear on the machine to do so for every tool change.

[aftcargoheat]

shred, I fully get what you are saying, and you are right of course. But here's the thing. The PathPilot software does actually make a note of the clearance height that the user sets in Fusion 360 Tormach Post Processing for every operation. And furthermore, it does move the spindle in Z axis to that clearance height. But nobody has so far given a good reason why it does this AFTER moving the work under the spindle.

If it is as useless a height as you suggest, then why even use it at all? But they do.

[shred]

shred, I fully get what you are saying, and you are right of course. But here's the thing. The PathPilot software does actually make a note of the clearance height that the user sets in Fusion 360 Tormach Post Processing for every operation. And furthermore, it does move the spindle in Z axis to that clearance height. But nobody has so far given a good reason why it does this AFTER moving the work under the spindle.

If it is as useless a height as you suggest, then why even use it at all? But they do.

PP has no idea that's the clearance height, it's just where the next operation starts from, so it goes there. Why PP (and Autodesk) made the choice to move in X and Y first I have no idea. Maybe to avoid problems with 'dogleg rapids' depending how the machine moves.

You can fix it in the F360 post by adding a G53 Z0 after each tool change like so--- writeBlock(gFormat.format(53), ("Z0")) .or fool with the isHeadConfiguration stuff, but I've not messed with that.

Put it in this code in function onSection() , either here to do it right after the M6, or you can put it after the coolant and spindle stuff. BTW, there's some Z-checking code in there that's skipped for some reason as well.

if (properties.useM6) {
writeBlock("T" + toolFormat.format(tool.number),
gFormat.format(43),
hFormat.format(lengthOffset),
mFormat.format(6));
writeBlock(gFormat.format(53), ("Z0"));
}

extra credit for making it switchable with a new user-settable variable.

[aftcargoheat]

PP has no idea that's the clearance height, it's just where the next operation starts from, so it goes there. Why PP (and Autodesk) made the choice to move in X and Y first I have no idea. Maybe to avoid problems with 'dogleg rapids' depending how the machine moves.

You can fix it in the F360 post by adding a G53 Z0 after each tool change like so--- writeBlock(gFormat.format(53), ("Z0")) .or fool with the isHeadConfiguration stuff, but I've not messed with that.

Put it in this code in function onSection() , either here to do it right after the M6, or you can put it after the coolant and spindle stuff. BTW, there's some Z-checking code in there that's skipped for some reason as well.

if (properties.useM6) {
writeBlock("T" + toolFormat.format(tool.number),
gFormat.format(43),
hFormat.format(lengthOffset),
mFormat.format(6));
writeBlock(gFormat.format(53), ("Z0"));
}

extra credit for making it switchable with a new user-settable variable.

Wow, that is above my pay grade. But I totally like the idea of a G53 Z0 call after every tool change. Thanks shred.

However, we appear agreed on the fact we don't know why they don't just call the Z move first, then the X and Y moves, for the very next operation after the tool change. Because, it does not matter if the next op is cutting the side of the work, below its top, or cutting from the top of the work, if you do the Z move first, you won't crash. If you do the X and Y moves first, you might. (Assuming you are bringing the work back from a safe G30 location).

[mountaindew]

Not totally clear on what the problem is other then z moving with x and y after tool change and possible crash.
I run into what I think is a similar situation on my 24r router. Problem I had noticed was when spindle required tool change it would go up to z height set in g30 then rapid x,y, over to tool setter "nice and safe" . After changing tool it sets height and returns to preset clearance z height. then spindle would rapid move to position in x,y,z. this is normal on mill and I never noticed a problem. But on router ramping down z "not safe" while also moving x.y over a 4ft area was problematic and if a fixture or material was above that ramp down path it would cause a crash. As I mention I never noticed this as a problem on the mill because of small work area but on router it was very apparent. I notified Tormach of this possible condition. They helped work out cam settings for tool return path that keeps the z at the g30 height until its above the work location, then it lowers and engages. In sprutcam it was simple change to approach rule.
post #14 under tormach 24r router thread by me shows the problem I describe above on a real program.

it looks like you have worked out some code that will keep z at full height until its over work area. And or maybe look for approach and return rules in fusion that might need to be changed.

[shred]

Wow, that is above my pay grade. But I totally like the idea of a G53 Z0 call after every tool change. Thanks shred.

However, we appear agreed on the fact we don't know why they don't just call the Z move first, then the X and Y moves, for the very next operation after the tool change. Because, it does not matter if the next op is cutting the side of the work, below its top, or cutting from the top of the work, if you do the Z move first, you won't crash. If you do the X and Y moves first, you might. (Assuming you are bringing the work back from a safe G30 location).

You can crash moving Z-first if your toolchange height is above your work height and that is not completely clear between the tool change position and the part as the tool rapids down and then moves sideways. It's safest to approach from Z if you are already above the part which I would venture a guess is a far more common situation. Plus most commercial CNC machines generally don't move in XY to change tools, so a tool longer than the distance to the part will need special handling anyway..

PP should have a checkbox that says 'return to Z after ATC toolchange' for people that want it as it would come in handy, and they are the ones moving in Z without CAM knowing about it.

[kstrauss]

PP 2.8.0 appears to improve such. From the release notes;
We improved collision avoidance when using long tools in Automatic Tool Changers (ATCs). Now, after a tool
change involving the ATC, the final Z position is set to whichever is higher between G30 Z and tool change Z.
(PP-3254)

[aftcargoheat]

PP 2.8.0 appears to improve such. From the release notes;
We improved collision avoidance when using long tools in Automatic Took Changers (ATCs). Now, after a tool
change involving the ATC, the final Z position is set to whichever is higher between G30 Z and tool change Z.
(PP-3254)

Yes, I am currently testing this on my machine. They have modified the behaviour of all ATC tool changes so the spindle goes up after every change.

It doesn't reveal itself in the code the conversational produces, nor does it rely on your particular CAM post producing it. So this is an excellent modification.

From what I can see, it goes up to a G53 Z0 which is to the limit switch in Z, rather than just up in Z to the G30 position which is what the Release Notes say as far as I can tell, but that's even better, as it does not rely on the operator setting an appropriate G30.

It has fixed the problem. Great news.


Thank you Tormach for engaging with me over this.