What's new
What's new

Crash on NGC with 5-Axis Contour and TCPC/DWO

sdinzy

Aluminum
Joined
Dec 21, 2019
I'm using the newest Haas NGC post supplied by Autodesk, with the options for A & C axes on. DWO & TCPC are enabled, which I have for my machine.

I set my work offset (G54) for some stock, set my tool offsets, ran a bunch of 3+2 operations without issue, then went to run a simultaneous 5-axis operation (with one of the same ball mills that had been used in 3+2, no changes to tool offsets), and right off the bat the machine crashed the tool holder right into the part at the high feed rate (fml). Looking at the g-code (which I'm new at) and comparing it to the 3+2 code, looks like everything was positioned properly while G254 enabled (using DWO to position piece), then G255 was called (which apparently is standard for 5-axis operations). The subsequent G234 command causes the crash, lowering the Z-axis to it's near Z-minimum. Was Z0.3, which I don't see how translates to the spindle being in that location. I'm not sure if the person who trained me didn't instruct me on how to set something up for 5-axis, or if I'm missing something else. Thanks for your help in advance.



Here is the code that caused the crash:

O00001 (Tail Flow + Sole Flow Test)
(Using high feed G1 F500. instead of G0.)
(T3 D=0.375 CR=0.1875 - ball end mill)
N10 G90 G94 G17
N15 G20
N20 G53 G0 Z0.

(Flow1)
N25 T3 M6
N30 S14260 M3
N35 G54
N40 M11
N45 M13
N50 G0 A-75. C91.5
N55 M83
N60 G254
N65 G0 X0.0362 Y0.3628
N70 G255
N75 G234 X-2.5216 Y-0.0298 Z0.3 H3
N80 G1 A-75. C91.5 F60.
N85 Z-0.3614
N90 X-2.5209 Z-0.3683 F80.
N95 X-2.519 Y-0.0297 Z-0.3751
N100 X-2.5158 Y-0.0296 Z-0.3813
N105 X-2.5116 Y-0.0295 Z-0.3869
N110 X-2.5063 Y-0.0294 Z-0.3915
N115 X-2.5003 Y-0.0292 Z-0.3951
N120 X-2.4938 Y-0.0291 Z-0.3976
N125 X-2.4627 Y-0.0283 Z-0.4059
 
Here are my MRZP, work offsets (was using G54), and tool offsets (was using tool #3, which had been used in the previous 3+2 operation).

MRZP Settings
MRZP Settings.jpg

Work Offsets
DWO Settings.jpg

Tool Offsets
Tool Offset Settings.jpg
 
Last edited:
What cam package are you using, and if its fusion, do yoy have the commercial license. Do you have a copy of cimco edit? if you are using hsm then the answer should be yes, although it will be called hsm edit.

In Cimco edit there is a very nice backplot function, you have to configure it for your machine.

See if you have it, then I can walk you through configuring the backplot for your machine.

Lastly, did you use the ball endmill in any other tool paths succesfully, and you sure its zeroed correctly?

Sent from my Phone 2 using Tapatalk
 
Also Im not familiar with haas's g234 command, I've only done 5 axis with a fixed coordinate system, which now that I think about it, I solely use now after learning to do 5 axis work.

I can see how if you used a probe to determine the location of your part this could save some time. That being said I pass through a snippet of code to use my tool as a pin stop to locate my stock If ik using a collet, or dovetail vise or normal vise.

Sent from my Phone 2 using Tapatalk
 
Hi D,

I am using HSMWorks, and yes I have the commercial license. I’m not sure Cimco edit will catch it due to the TCPC offsetting, which is done in the control; simulation with HSMWorks obviously didn’t catch the crash. The G234 command is positioning command using TCPC.

Yes the 3/8” ball was zeroed correctly using Haas’ probing system, and I know it was correct because I used it in the 3+2 operation preceding the crash.
 
couple of things -

Those MRZP values seem screwy, I'd double-check the MRZP calibration, also be thorough about checking the calibration of the spindle probe itself before checking MRZP. This is on a VF with a trunnion instead of a UMC?

When I do the VPS rough and finish calibration on the UMC, the only values that I touch are MRZP X Y Z offsets. The master and slave values I always leave blank. Double-checking with my guy, he says that the main vs master/slave settings are to be used "either / or". Looks to me like you've got an awful lot of cumulative Y offset.

The one tricky part is that during calibration you have to manually pass values from the macro vars #10121-10123 into settings 255-257 (once for rough, again for finish, see P. 214 in mill manual). I was just fighting overtravel problems last week due to lingering master and slave values.

Which line did your machine crash on? N75?

Also, when weird things happen, DON'T TOUCH ANYTHING before you get an error report from the machine. Leave it in the alarm / crash state and hit SHIFT then F3 to generate an error report (make sure you have a USB stick in the machine). That saves diagnostic information that your HFO or Haas can use to figure out what the problem is rather than trying to troubleshoot over internet forums.
 
Last edited:
Hi Coyoinu,

Thanks for all the great info! This is a DM-2 with a TRT160. The AE who set it up was VERY good & knowledgeable, but unfortunately he is off duty for a couple weeks getting married. We very carefully copied the values over manually and then double checked them. But yes, all the information I've read online says the offsets are to be set, not the master slave values, hence why I'm trying to get them verified. I've also sent all this information to Selway, whose other AE's are reviewing.

And yes, N75 crashed. I've been trying to figure out what happened and why (if it's not an MRZP related issue), and I believe I've made a little headway. So the AE preferred the A-axis setting in the post to be "Reversed", as opposed to "Yes", so that the TRT160 tilted towards the operator by default instead of away, so that it's easier to see during cutting. I had been doing all my posting without touching that setting. While I was playing around with 5-axis stuff, I changed that setting to "Yes". I have since reverted that setting to "Reversed", and the resulting g-code seems to produce the desired cut, although I am far from satisfied. In reviewing both versions of the resulting the g-code (both for "Yes" & "Reversed"), all this does is simply invert the values for the A-axis (A-75 becomes A75, etc); it doesn't change anything else (all other X/Y/Z/C values remain exactly the same). I'm not sure if TCPC is supposed to account for this when crunching the g-code and applying its offsets, but it certainly appears to NOT be the case, or it's not doing it correctly, or something. After plugging both versions of the code into the machine (without a workpiece or toolholder in place), I'm seeing very different behavior. For the crashed version, the surface-to-be-cut was rotated completely away from the cutting bit, and while it's tough to tell, it almost seems like the machine was trying to cut the opposite side of the surface, which is obviously a solid body. Seems very strange. I've sent all this to Selway, curious to see what they say. I don't know how changing the A-axis orientation preference can result in the machine trying to cut the wrong side of a surface, but it looks to be the case.
 
Sounds like maybe you need to make sure the rotary is rotating the correct direction your program is telling it to? And, the post generating the correct direction for the model. For example, my post for my CAM inverts the B-axis for my UMC750 so everything runs the correct direction.


But that's weird you say the 3+2 stuff is correct?


Say you program a cube. Drill a hole on the rear face (Y+ side). Does it rotate toward you? So part is close to you and the bottom of C-axis pointing rearward? (Y+) That should be A90. right?

Drill a hole on the left (x-) face. Does it rotate A90. C90.?
 
All the 3+2 stuff was correct, but keep in mind, I used the "reversed" setting for that stuff. It wasn't until I changed the setting to "yes", aka non-reversed, that I crashed it. I'm starting to wonder if the "reversed" setting is REQUIRED for correct operation. The AE told me that it was his preference to have it in the "reversed" setting, but didn't allude to it being a requirement. Turns out the crash bent the studs that anchor the TRT to the machine table, so I'm going to have to recalibrate everything before I can do any test cuts.
 
So I just posted a previously-successful 3+2 operation in 4 different configurations: combinations of "yes"/"reversed" with the Y-axis in correct/reversed orientation (in CAM). The results are:
*Changing the Y-axis in CAM software has zero affect on the orientation of the workpiece; it looks like the A-axis setting in the post takes precedence.
*The "yes" oriented code resulted in workpiece positioning that would have cut on the wrong side of the surface. Really, the code wouldn't even run (regardless of Y-axis orientation in CAM), as I got a Y-travel range alarm. The alarm part doesn't really make sense to me, since the TRT is located in the exact middle of the machine table, and the Y-travel is pretty much symmetrical on each side of the spindle; I don't see any reason why the A-axis oriented in one direction wouldn't work with the A-axis oriented in the other direction.

So it seems like the post MUST be in "reversed" A-axis orientation to work correctly. This is baffling to me.
 
Hmmm I know for my machine I had to edit the rotary axis settings in the post since my Machine's A axis is a b axis by definition, So the default was -1,0,0 I had to change it to 0,1,0. This is in the .cps file, not the drop down menus in fusion.

Let me look up your machine and see which axis is called which.

What machine do you have and how are your rotary axiis oriented?

Sent from my Phone 2 using Tapatalk
 
It's a new DM-2 with the TRT160 tilting rotary table in an A/C orientation. So tilting around X, rotating around Z.
 
Latest Haas generic from Autodesk.

Latest generic for which machine configuration? For TRT tables, setup on right side of table like yours? (btw it is possible to set those up Y-direction)

For UMC machines?

What about the TR200Y?

One post isn't going to work for all of those machine configurations.

I don't use any autodesk products, but if my assumption is correct, you probably still need to configure which direction it is setup to generate code and your machine settings need to match. If the post is simply "Haas 5-axis" you'll need to adjust some settings...
 
Since we're talking about posts, you may want to consider the first line of G234 to call up the tool height without a Z move, then move on X and Y, and then move on Z, all on separate blocks. Rapiding (at 100%?) on all 3 axes at the same time will guarantee you more crashes in the future, especially on a quick machine like the DM

Originally:
N75 G234 X-2.5216 Y-0.0298 Z0.3 H3

A safer solution looks like:
N75 G234 H3
N76 X-2.5216 Y-0.0298
N77 Z0.3

As far as the NGC control is concerned, in the rotary page, there's options for every rotary profile in both a forward and a reverse configuration (reverse denoted by -R at the end of the name).
 
Hi All,

I wanted to follow up on this post. So after talking to another AE at my local HFO, it turns out you cannot change the rotary axis settings (“yes or “reversed”) without also changing the rotary setup within the Haas control itself; the settings between the post & control must be in alignment. So it was a miscommunication between the AE who installed my machine & myself.
 
This sounds similar to what we went through although this stuff is super confusing. I'm going to relate this story in case it is helpful to anyone. We have a TRT160 on a VM-3, which is big enough you can nicely align the trunnion so the tilt is along Y as a B axis as opposed to the more common A-axis tilt where it's along X. There is a nice interface on the NGS control to set up these axes the way you want. What is not clear however, and NO ONE EXPLAINS, is that if something like this makes a rotary axis go in a different sense (counterclockwise vs clockwise), as happened to us, the method for changing it is TOTALLY DIFFERENT FROM THE AXIS ALIGNMENT SETUP. If you look at this video: YouTube they are showing how you load files for your specific trunnion, in this case the TRT-100. Now you see here for the TRT-100 that there are actually four files: TRT100-P3-TLT and -ROT and -TLTU and -ROTU. The new TRT-160 is the same, though it wasn't on the control when this video was made. Now it turns out that in our case, with the tilt going the wrong sense, you have to load -TLTU rather than -TLT. THEY NEVER EXPLAIN THIS. AND OUR HFOs DIDN'T KNOW THIS AND WERE TOTALLY LOST. In the video above, you can see these files but they don't ever say what they're for. Further, the extra files for the opposite rotation may be a feature only of the new trunnions, not the previous versions. Fortunately we have a toolmaker/CNC programmer-operator with 30 years of experience and a professional engineer with a physics PhD and working together in the best Kelly Johnson tradition, we figured it out. What we found was you did the setup and then when it went to run the program to get the MZRP coordinates, it was obviously moving the wrong way. Then we reloaded with the new file, and the MZRP program was fine. Another thing that Haas didn't seem to communicate with the field service people is that these smaller tables don't need the alignment ball that you need for the UMC machines. They just get the MZRP numbers right off the platen and it seems to work fine. There seemed to be both poor communications from Haas to our HFO and within our HFOs techs and it was a bit of a saga.

By the way, regarding CAM and posts, for MasterCAM the ABC vs XYZ axis business and rotational direction of these axes is all in the Machine Definition file. Once you have that set up correctly, the post, as supplied by our VAR, seems to take care of itself.
 
Since we're talking about posts, you may want to consider the first line of G234 to call up the tool height without a Z move, then move on X and Y, and then move on Z, all on separate blocks. Rapiding (at 100%?) on all 3 axes at the same time will guarantee you more crashes in the future, especially on a quick machine like the DM

Originally:
N75 G234 X-2.5216 Y-0.0298 Z0.3 H3

A safer solution looks like:
N75 G234 H3
N76 X-2.5216 Y-0.0298
N77 Z0.3

As far as the NGC control is concerned, in the rotary page, there's options for every rotary profile in both a forward and a reverse configuration (reverse denoted by -R at the end of the name).


No, no, no, this is dangerous and will produce dog-leg rapid moves! The code as the OP originally posted is correct and safe, to move to initial XY position in G254, then approach in G234 XYZ as one move. This will produce a "Z-only" move approaching a tilted table for 4/5-axis milling.

The only way approaching with G234 in XY first, then Z, which will make a Z-only move, is if the table is not tilted. At A or B0 initially, then a tilt move is applied. However, this is not a safe practice either... If trying to reach between a feature you could put the tool shank/holder into the work piece. This is not safe or practical to use as an index move between 5axis toolpaths. IE retract in Z, then tilt table back to 0, reapproach and tilt again. Well I suppose you could, although is a lot of wasted motion (and still could be dangerous)
 








 
Back
Top