Hi Everyone, I want to finish a mould with the hybrid 3D HST. I am machining with a 10mm ball mill. The mould is cut thru (has no floor) and in order for the ball cutter to finish the walls comletely I have to go in the Z direction below the actual wall by about 5mm (radius of the ball cutter). I used min and max Z in the "Steep/Shallow" tab (put "maximum depth to about 5mm deeper) and it doesn't work - the toolpath still finishes in Z equally to where the driving solid/surface ends. What am I doing wrong? Can You help? Thanks in advance Guys.

Thanks JP

Hi guys, Does anyone know wether MC X8 works with GPU parallel processing cards like Nvidia Tesla? These cards are very expensive ($10k +) - hence the question. Thanks in advance.

Sorry, let's try again (my internet session got busted) : MIKO ELLO, I had this problem with "looping" on fanuc OI-MB aswell - for me it's 99,9% machine tool issue. Take a look at parameter #5008 of your fanuc control (set bit QCR to "1"). This worked for me - but I'm not sure if it's the right solution (maybe I had plain luck...) Another thing is to use AI/APC (G5.1 Q1) - take a look here (read it all ) : http://www.emastercam.com/board/topic/79128-arc-issue-on-fanuc/page-2 let me know if it worked for you

MIKO ELLO, I had this problem with "looping" on fanuc OI-MB aswell - for me it's 99,9%

Thanks BenK! That definetely was it :-) It does what I want it to do - I omitted that option (my brain has defects hehehe). Anyway - thanks a milion

Hi Guys, I need help with the surface HST HYBRID toolpath. It misses some Z-depth cuts on steep walls. It's shown on the picture below. Can you give me some help? Thanks in advance.

JP, I made some tests today with my faulty program. When I worked with AIAPC/AICC (G5.1 Q1) on - the EXACTLY SAME NC prog that made the loop before - got executed properly (no loops)... I don't know what to think about this... I took this test when prm #5008 bit QCR was "0" (look at my previos post, but Tim says it's obsolete on newer fanucs). Can you try this with your faulty program and give info if it worked for you aswell..? Tim - what do you think of all this...? I am still struggling that "my" workaround with the problem might be just plain luck - and you never know when it will hit you again... I don't know for 100% - just don't know...

Hi guys, I've also had this problem this week at a 2D HST FILTERED toolpath. The filter made "milions of arcs" and one of then made the loop. Fortunately the toolpath was at a high Z and the loop simply stopped on the proximity of the machine... What I did was changed bit #5 (QCR) of parameter #5008 from ZERO (the FS16 format) to ONE (the FS15 format). The program continued properly. Give it a try. You can find more info in the Fanuc parameter guide. I did this on the 0i-MB. Let us know if it worked and what you think about it.... P.S. From the Fanuc parameter guide: "FS0 (FS16) and FS15 determine the travel distance in different ways if the radius of arc at the start point of circular interpolation is different from that at the end point (if the end point is not on the arc). By this parameter, the method of determining the travel distance of circular interpolation can be selected."

Reko - it's a good idea - I've just tried it out on the "buggy" operation I was talking about. It sure well stopped in the place where it wanted to engage too much DOC. Thanks again for the tip.

Thanks Tinyfxds - this works for X8 also. It's one of those "little" things that make your life GREATLY easier... thanks again

I put it through X8. Opened the old MCX7 file in X8 and made a regen on the "buggy" toolpath operation (it came in clean to X8 but I did a regen at it to let X8 toolpath algorithms overwrite the X7's). And guess what? X8 made it right!! That's definetely good news! This gives some proof (for me at least) X8 is more reliable and has less bugs in HST!. Good, because I was worried that X8 mainly changed with the graphics (which is also very useful and cool)..! Well - my faith in opti and HST grew slightly, looking at X8 from this point of view. I hope this doesn't change. We'll see what the future brings....

Hi Guys, Thanks for the tips. I guess some have to be addressed to Cnc Software for future releases / MU's... Josh - the overcut wasn't on a backfeed - the toolpath went to do upsteps WITHOUT roughing out the stock first. When I changed the path boundries (see attached JPEGs) in either way - the problem dissapeared. I still have no explanation for that - maybe someone from Cnc Software can help? Please.... It must be a bug issue. What is quite vital is that it happened to me in X7... So... The BIG QUESTION is -> was X8 more thoroughly tested and had all found bugs removed regarding the HST??? I think this is CRUCIAL for all machinists(no need to explain why) using MC. So... can someone from Tolland let us know about this...? I would be grateful... :-) Anyway - I will try to put the "buggy" toolpath thru X8 - the exact file - and will let you know about the results. Reko - thanks for your suggestion - I'll give it a shot. I hope you will NEVER experience a "feed crash" with HST. My feelings for HST in MC from now on also became a little bit mixed. I know OPTI (the "upstep" approach, stock awareness, etc.) is definetely HUGE! That's the road it should take - it's a BRILLIANT strategy! But - it must be (as close as possible to) PERFECT! This is a must - no questions asked. HST means running your machine tool at feeds that are corrsponding to RAPIDS in some older machines! That's nice, but also - serious. This is really where SECOND BEST won't cut it! So - to the Creators - MAKE MC THE BEST! I believe in you! ......so does my maintenance bill....... Thanks again Guys!

OOOps... I forgot the .mcX8 file - here it is OPTIREST.zip

Hi Guys, Does anyone know how to spot a collision in X8 Simulation? I mean not a holder to workpiece/fixture collision etc but when the tool engages an absurd amount of material (ex. a 1/2" cutter buried 1" in material taking a full-width cut). The question came to me when I had a complicated part being machined with OPTI AREA/ OPTI REST. The toolpath had a bug in it that I didn't spot on simulation before letting it run on the miller. My 1/2" endmill just snapped away when it attempted to mill thru a full-width cut being buried 1/2" in material with a feedrate of 200IPM. I'd be surprised if it lived thru such a heavy and couragous cut... ;-) And adverts on Youtube say that "the side step is never exceeded".... Now I have a problem because I don't believe it... I have another problem - I like the OPTI toolpaths too much to just let them go... Hence my question... Sitting by the simulator and looking for such a collision could take ages and You still need luck to spot it without any automation (call it "too much cutting collision detection") :-) Thanks for the help. P.S. Does anyone know how to make the simulator remember the "5 axis" setting in the "FILE-OPTIONS" menu? It makes me wild changing that everytime I use it... Thanks again.

Hi Gentlemen, I came up wih an issue while machining with OptiRest in X8. The thing is that it machines a very small slot (pocket) when it is not supposed to. The slot is only 9.5mm wide (it is very long though - but this shouldn't matter - the smallest dimension should be taken into account). I put 22 mm under "Cut parameters" -> "Transitions" -> "Skip pockets smaller than". Besides that that the "entry method" is "Helix only" which should mean that engaging a closed pocket/area shouldn't be posible thru profile or medial ramp - and this is what Mastercam is doing with my toolpath... Why? Is something wrong with MC...? ...or is it me......? If I'm wrong - please lighten my mind... Thanks very much in advance.

Yeah Foghorn... I had that thought in the back of my head writing the reply.... But on the other hand I thought... what the hell! :-) Hey! I'm a newbie after all...

Yeah... well... better later than never... Maybe it's not obsolete yet.... :-)

Nope - it's a radio button - only one choice possible. But You can use "unit/min" for the linear movement and "inverse feed" for the rotary movement under the "4 axis feed options" (and "5-axis feed options"). It works like this (assume you have unit/min for linear and inverse feed for rotary): When there is no rotary movement in the block (no "A", "B" or "C" address) - the post outputs a G94 code ("unit/min") - the value after "F" is in IPM or mm/min. When there is rotary movement within the block, the post outputs a G93 code, which means the machine tool uses inverse feed under every F command. Both functions are modal. This is how it works under FANUC/HAAS posts. I haven't seen IPR (Inch Per Round) option in the control def - not for for milling. It propably exists for turning. At least it's what I would suspect - but are not 100% sure. Hope it helped...

Hi Greg, Go to: Settings -> Control Definition Manager -> Find "FEEDS" in tree and enter it. At the "Rotary" section choose "unit/min" instead of "deg/min". You can also use "inverse feed" (it's the best choice). Anyway... Your problem should disappear. Save your Control definition. Good luck!

Hi Happycat, Did You solve the problem?

Yaeh, I'm on the subject doing so. Will let You know what I find out.

Acording to the specs (from haascnc.com website) Your trunnion has a max speed in both axis (A-tilt and B-rotary) of 50deg/s. If You were incrementing the angle in each block by 3 deg and Your feed was at 999.9 inverse time, then You made Your trunnion axes travel at this speed: 3deg / (60/999.9) = 49.95 deg/s -> the TOP PHYSICAL SPEED LIMIT of Your trunnion. Maybe on relatively "flat" areas it handled the job, but at those 4 points where rotary travel had to be significantly large in comparison to the actual movement of the tool on the surface - it lost sync and gouged the part. Look at Your NC code in the 4 "tough" areas - maybe the block-to-block swing was even larger at those 4 points - then the max speed was for sure even further more exceeded... It might be that You asked your poor trunnion to "rock and roll" faster than it physically could.... You then stepped down to F150 inverse and You completed the job with no gouges. But this speed on the other hand was very sssslow at overall and increased Your cycle by 6+ times... I don't blame You complainig there - after all time is money :-) Maybe the job would be ok if You went down by half the speed (You'd have about 2 safety factor from the max speed of your trunnion) - I don't know. But I am verey curious about Your NC-code fragment in the areas of the "tough" cuts. I also agree with Aaron and the other Guys that increasing the amount of vectors would be definetely a plus. Guys - I dont think that Haas ever said that the trunnion speed limit is 1000, 4000, 40000, 60000 or whatever else inverse time feed. In my opinion this is for the user to figure out because it depends on the angle increments you ask it to take in one block. You have to calculate the max feed inverse time you want to make it move by - taking into account the max speed of your table. Correct me if I'm wrong (it's late here and I might talk bull*) :-) I am having a similar issue I'm working on - only in 4-axis with HRT160 - if I have something wise to tell You I will :-). An additional thing I had to do is change parameter 104 for the A-axis ("in position limit" or something like that). It was set originally to 4000 and I changed it to 20000 (!!!) because otherwise at about 4 angle increments (block to block) and at inverse feeds greater than 200 on a CYLINDER (don't laugh - I was jus testing :-))) my table was jerking like a wild horse. That's a separate thread I started ("Haas rotary parameters") - don't want to get asked out by the Moderator for not staying with this subject :-) Reko - good luck and give us some info on Your further thoughts.

Hello, Has anyone messed with Haas A-axis parameter no 104 - "In Position Limit"? I have a HRT160-P1(purchased in 2012) rotary table used on a VM-3 (2008). The factory-set value for parameter 104 was 4000. I had to change it to 21000 (!!!) to get reasonable feedrate for Mastercam-generated 4axis rotary toolpath. With the original 4000 value it ran very very very slow. When tried to increase feed - it was mega-jerking.... I used inverse feed - the max I was able to pull out of it was F200 (with no jerking) - It took about 30 seconds to make one full 360deg rotation - the diameter of the part is 3.07" (78mm). I tried G187 at P1 (rough), P2 (medium) and P3 (finish) - no noticable effect. Toolpath tolerance set to 0.0008", filter tolerance to 0.002" When I changed the mentioned parameter to 21000 (more than 5 times the original value) - the toolpath movement became about 4-5 Times faster with ZERO jerking. It ran perfectly and the SPEED was satisfactory. My concern is - will the change of this parameter impact the accuracy of the A-axis positioning / table life or any other thing? Has anyone tested this? Maybe someone from HFO or HAAS factory could help me with this on the forum? Big Thanks in advance.

Why would You not? I have 2 Haas machines (VF-2SS and VM-3). They do the job in ALU (I have a blurry feeling though, that their HSM capabilities sometimes lack a little but have no real comparison). I really don't do much heavy machining - so can't really say to the end what they're worth. That's why I would really like Your thoughts about this. I'm thinking of getting another VF-3 maybe VF-4 with trunnion.... Should I not go that road....? What's the "blind spot"? I would really appreciate Your point of view. I've got a little blind by the amount of meetings with machine tool dealers. They always say that their machines are the best and the others are crap (with no specific technical argumentation why - pure marketing - makes me sick). My brain is washed - please help...