From HAAS's own website: https://diy.haascnc.com/umc-common-applications-problems#gsc.tab=0 These are not high precision machines. At best they are a cheap step in to 3+2 and mild multi-axis machining where positional tolerance is not critical between faces. This un-checks a bunch of boxes for me. We have 8 TR160-2 trunnions that have been nothing but trouble accuracy wise. The A axis have scales and had to be ball screw corrected as much as .025° to get accurate between A0-A90 and reputability isn't great either. My impressions from word around the web is that I shouldn't expect much better from these. We have a handful of variaxis and a Matsuura that work excellent and repeatable every day. Not without their own quirks to be sure, but far, far better. Get your foot in the door to 5 axis machining without breaking the bank and buy something good when you get competent and sell it. That's the most I'd recommend of one of those barring personal experience with them.

Will be a HAAS TR-160 to start. Unsure of the future machine, but likely a trunnion style with hydraulics. Thanks for the link.

Is anybody using vacuum fixtures on table-table style 5 axis? I'm looking for ideas on hose management. Any info, help or references would be appreciated. Thanks Greg

Our MAM72-35 had an issue where it would make "chatter" marks when running certain directions, but usually when doing the odd radii or off perpendicular cut. Turned out, one of the ball screws was a little loose and the scale feedback a was causing oscillation while it was self correcting along the cut. Changed the ball screw and it went away. Weird that it would happen on two different machines though. Greg

You have mail. Greg

HAAS Milling

I've looked around int the settings and haven't found anything labeled "filter", can you be more specific?

We've been having weird numbers come up when getting toolpath statistics from Cimco Edit 8 since we updated. For instance, it's telling me my cut time is 7:52 (mastercam backplot says 18:06 so I'd expect at least close to that). It's also telling me that Rapid time is 42:21 which is a total crock. Anyone have any suggestions. We can't seem to find any settings that are incorrect to fix it. Thanks Greg

We have an Integrex MK-IV 200ST. This is a Matrix 1 control and has the lower Turret and second lathe spindle. I am just starting G-code programming of it (we've done mazatrol for a while now) and I have a problem with the lower turret, where if I touch the tool off for a grooving tool (internal or external) and Auto-set the tool for the second spindle, it will offset the width of the grooving tool. This in effect sets the tool zero point to the back edge of the instead of the leading edge. Mastercam obviously does not program this way. It programs with the leading edge of the groover (with an additional offset available to adjust the back edge as an option). For the time being I am leaving the Tool Data width and edge radius columns at 0 and it is serving my needs. Does anyone have any suggestions or "this is how I do it" tales. I would like to maintain tool use between G-code and Mazatrol and that's currently not possible. I've contacted Mazak and they're solution is for us to utilize multiple tool offsets (use A,B,C,D) and at a basic level this works, but is not ideal. Just hoping someone has a work around. I've tried several parameters at Mazak's suggestion and haven't come up with anything that does what I'm looking for. Thanks for any help guys.

We use this stuff too. Has worked out so far. 3mm EM to prep and done. Greg

We had Haas come in and tried to work with them. I don't remember anything about having them calibrated. I remember going back and forth to get the ball screw length comp page unlocked so I could do my own calibrating, but I didn't go through every angle combo. Do you have any more info on PQI, I've not heard of them. I'd be interested in at lease learning more about them. I still would have thought that with the addition of a scale, it would be a bit more accurate out of the box. Greg

We installed 8 TR160-2's with New VF-4's several years back. I had a lot of issues with accuracy, in particular on the A axis tilts. We would zero out the platter and tilt to 90° and it would be out by .001"+ over 4.5". This doesn't seem bad until you start working on long objects high off the platter 6-8" and you have taper in your part because the platter isn't really at 90°. The error would double when working on 180° faces, so thicknesses would be off by as much as .004-.006" depending on the setup. Keep in mind, new trunions are supposed to have a scale now. I had to have Haas unlock the ball screw comp page in the control to work this issue out. Still from time to time I have to comp odd A-tilt angles when tight part tolerances are out of spec. All of the trunions had these issues. Other thing is the brakes are pitiful (200 ft-lbs holding). I've overcome the brake with relatively small drills (7/16 I believe was the smallest) unless you want to slow down what you're doing. So if these headaches are acceptable it's a pretty cheap way into 3+2. But if you're considering new machines to get into the 5 axis realm, I would seriously consider others. I did price out a comparable Koma precision table and it nearly cost what the machine cost to begin with. But the brakes were 8000 ft-lbs holding with hydraulic pressure and certainly much more accurate and robust. We also have Mazak variaxis and matsurra MAM and their accuracy is excellent as well as holding power, with much larger working areas. Good luck Greg

I got boned the other day from a similar deal where I had a solid chain not regenerate properly. I could not save without the solid regenerating (which for the life of me I couldn't figure out why it wouldn't). I eventually had to ditch the file and open at my last save point and lost 1/2 hr of programming. I honestly couldn't care less if the entire file was dirty. At some point it's time to go home and it just needs to be saved and dealt with in the morning.

Mazaks interpolate their rapids so that both axis arrive at the same time. This happens a lot on our 5th axis where the rotaries are much slower than the X/Y/Z axis. The rotaries are the slowest so the main axis rapid at a much slower rate, but it's still the fastest combined movement rather than moving the A/C and then X/Y/Z. Which would be slower even though it's visually faster for independent axis. Is this more or less what you're observing?

Update, I sent the post in and it turns out there was something in the PSB file that was blocking the mi and mr variables from moving into the postblocks. I'm not sure of the details, but those with Postability posts may see something like this. Greg

Thanks Colin, Mostly just wanted to see if there was a nulling post block I wasn't seeing, but I'll probably just send this along to Postability and let them handle it. Thanks for everyone's help.

Still looking for help on this.

The "Automatically set to post values" is set to 4 by default, but for my testing purposes, no, it is not checked. Didn't think to check the NCI. It is outputting a 4 like it is supposed to (like I set it).

Sorry, yes there is a star in front of it and it is posting the 0. The "test" output line is within the hsm1_one block right before the if line for 4. in other words, right before it should be posting with mr1 set to 4 (which it skips because it's set to zero). I have tried several positions throughout the post to see if it's being overwritten somewhere with no different results. A search for mr1 in the post does not reveal anywhere obvious that it is being set differently. The post is binned, but typically our post developer hasn't hidden anything that benign in the past.

Hello, I've been working on modifying one of our horizontal posts to work with another horizontal machine we have. Very similar code and has been easy to modify so far. However, the newer machine uses HSM codes (G131 R*) where the older one doesn't. This is an MPPostability post. The problem is that if I use mr1 to set the HSM type it will not post with what I have set on the parameter page. I have set a line in the hsm1_on field right before where it's supposed to post it, like this: *"test ", mr1$, pe to make sure that it is actually taking data and it always outputs: test 0 no matter what I put in it indicating that mr1 is set to 0 (it is set to 4 in the misc values page). I've tried with several other mr variables with the same results. Is there a setting elsewhere in the post that nulls mr outputs that I'm not seeing? Anybody run into this before? I've made this work on 2 other posts including another 5 axis MPostability post that's very similar. Thanks for any help you can give.

Yes, you CAN still program to center of rotation, but it is really handy not to. The book shows part zero's being far from the COR, so the intent of still programming to COR seems murky at best. Like I said, our MAM requires none of this movement. You turn it on and it just knows where it is. I see no reason why this couldn't be so on the Mazak if the software guys wanted it to be, but they may have their reasons for all I know. If I want to re-post from our Mazak to our Mam, I don't want to change my part origin. That's why we use Dynamic offset at part zero. Bit 0 is not in our book, probably because it's a variaxis. Can't help you any more there.

Our MAM with a 30i control requires no movement (or at least the parameters were pre-set that way) when cancelling G54.2. The Mazak manual does describe this movement and the need to calculate the vector on the first move after activating G54.2. G43.4 is not available for use with G54.2 (it will work with G54.4 though) on a Mazak, so that is not an issue, but it does have a parameter for the movement of G43.4 when cancelling on G49. That can be turned off. Set parameter 162.0 to 1 so that G49 will do no movement of the TCP length compensation cancel. However the original question was about G54.2. I looked up parameter F168 and didn't see anything about dynamic offset. But my manual is for a variaxis so that may be the difference, though I've found them to be consistent on our pool of machines/controls. What bit # did you change?

We cancel like this: G53 Z0. H00 G54.2 P0 X#5041 Y#5042 Z#5043 The variables are for the current work coordinate position. So if G54 is active as your center of rotation, you are basically telling it to go where it already is in G54. We have older controls without the parameter to turn off that movement, so to make it consistent we've done this. Haven't worked out how to prevent the movement when turning it on though. It seems to want actual movement to calculate the vector so a simple X/Y position move results in some unwanted Z movement when changing A/C positions. I would love to get around this.

Chapter 26 in our variaxis manual covers G54.4. There doesn't seem to be a G10 line for it as the settings are more comprehensive than X,Y,Z,A,C. You can however set them with variables in the program, which is what I do.

I've succesfully used G61.1, G5 P1 (high speed machining) and G43.4 with G54.4 on our Matrix controlled Variaxis a few weeks back. I'm not sure about G05.1 though. I can't find it on my G-Code list, but I had thought that was a fanuc code. Greg