umc 750 programming woes

[voc177]

I need a little help here machine is umc 750  2015 model, using mc2017 im trying to program this part  but having some issues b and c axis appear to position correctly so does y but x is off ... a lot when using g254 by like 12 inches in x if I turn 254 off its much closer but still not correct. the part is positioned dead center of the table on a 1.035 riser plate tools touched off the table and part modeled in mc as seen in machine. My reseller and I worked all day yesterday trying different part z origins  and still nogo maybe you guys can shed some light on this. the post is from postability.  Thanks for any help!! Ive been using mc since version 6 so I know my way around pretty well just venturing into the 3+2 world and i"m a little stuck.

SK88081 - Turbo Speed Rework3.mcam

[Reko]

I think your planes are incorrect.

The WCS is okay as long as you are probing that point below the part you have set to zero... but the "Tool Plane" and "Comp/Construction Plane" need to be set together to the detail you are machining.

 

[Reko]

BTW, you do realize when you say, "the part is positioned dead center of the table," that it is not necessary to do that. 

The beauty of G254, dynamic work offset, is that you can program everything off a simple pick up for the operator... say, centerline at the top of the part... then program from the same point in Mastercam... and off you go.

[voc177]

I changed the planes like you said still no go. If I leave g254 in the posted code I goes about x-12. which is pretty much hitting the tool setter. NO where near my part. not sure whats going on with that. Machine was just calibrated with mrzp (machine rotary zero point)  a week ago..

[?Mark]

What you're seeing sounds like a post issue. I've seen similar behavior on fanuc controls where TCP and G68 where called out in the wrong sequence. Can't help you with the haas though, not familiar with it.

[DUM1]

don't know how old your post is but ours was updated 5-20-16 from postability and works flawlessly

[voc177]

our post is also from postability just received it last week from our reseller

[mkd]

post up some code. Seems you are saying there are some big 12"+ values in the code.

[Colin Gilchrist]

Are you calling the Work Offset (G54), BEFORE G254? That is a requirement of the UMC-750 controller...

[voc177]

heres some sample code.

 %
O0001 (1)
(MASTERCAM - 2017)
(POST      - MPPOSTABILITY_HAAS_UMC-750.PST)
(PROGRAM   - 1.NC)
(DATE      - MAR-07-2018)
(TIME      - 12:48 PM)
(T1   - 0.375 FLAT ENDMILL   - H1   - D1   - D0.3750")
N100 G00 G17 G20 G40 G80 G90
N110 G53 Z0.
N120 G53 Y0.
N130 M11
N140 M13
N150 G91 G28 B0. C0.
N160 (OPERATION NO - 1)
N170 T1 M06 (0.375 FLAT ENDMILL)
N180 G54 G17 G90
N190 S3600 M03
N200 G00 B54.009 C-30.
N210 G254
N220 M10
N230 M12
N240 G187 P2
N250 X-.905 Y-.0423
N260 G43 H1 Z6.976
N270 Z4.476
N280 G95 G01 Z3.976 F.0018
N290 G41 D1 X-.9529 Y-.0003 F.0069
N300 G03 X-.857 Y-.0843 I.0479 J-.042
N310 X-.857 Y-.0843 Z3.964 I-.0959 J.084
N320 X-.857 Y-.0843 Z3.952 I-.0959 J.084
N330 X-.857 Y-.0843 Z3.94 I-.0959 J.084
N340 X-.857 Y-.0843 Z3.928 I-.0959 J.084
N350 X-.857 Y-.0843 Z3.916 I-.0959 J.084
N360 X-.857 Y-.0843 Z3.904 I-.0959 J.084
N370 X-.857 Y-.0843 Z3.892 I-.0959 J.084
N380 X-.857 Y-.0843 Z3.88 I-.0959 J.084
N390 X-.857 Y-.0843 Z3.868 I-.0959 J.084
N400 X-.857 Y-.0843 Z3.856 I-.0959 J.084
N410 X-.857 Y-.0843 Z3.844 I-.0959 J.084
N420 X-.857 Y-.0843 Z3.832 I-.0959 J.084
N430 X-.857 Y-.0843 Z3.82 I-.0959 J.084
N440 X-.857 Y-.0843 Z3.808 I-.0959 J.084
N450 X-.857 Y-.0843 Z3.796 I-.0959 J.084
N460 X-.857 Y-.0843 Z3.784 I-.0959 J.084
N470 X-.857 Y-.0843 Z3.772 I-.0959 J.084
N480 X-.857 Y-.0843 Z3.76 I-.0959 J.084
N490 X-.857 Y-.0843 Z3.748 I-.0959 J.084
N500 X-.857 Y-.0843 Z3.736 I-.0959 J.084
N510 X-.857 Y-.0843 Z3.724 I-.0959 J.084
N520 X-.857 Y-.0843 Z3.712 I-.0959 J.084
N530 X-.857 Y-.0843 Z3.7 I-.0959 J.084
N540 X-.857 Y-.0843 Z3.688 I-.0959 J.084

[voc177]

MKD no big 12 inch values are in the code because g254 is active the machine display shows its at the g54 programmed position. then when you reset control the display reverts back to its real g54 position

[So not a Guru]

I had a GR510 here that had a g92 value in one of the registers near the bottom. It was giving us a similar problem, until I noticed it & removed it. Scroll to the bottom of your work offsets & check that.

[WestRiver]

We too have a Haas umc 750 and a Postability Post. Ours comes up with error codes 2.103 y axis servo error too large , 9971 excessive axis speed or acceleration , 949 internal feed error detected. The machine just stops, right after gouging my part, started doing it when I first started doing 5 axis simultaneous machining now it is doing it on simple surfacing. It has ruined (5) , 3500.00 parts in the last 2 weeks. Haas finally fessed up to the fact that they have a software issue and are going to up grade the software  some day soon  I hope .I would double check the   WRZP numbers as I don't see any 12" numbers in the code you have posted It could be the software with yours as well. Good luck!

[voc177]

had 3 has application engineers here all day today redid mrzp installed new software same problem. first time they ever seen anything like it. a simple 30 degree angle in b sets x off by 12 inches or so,  smaller angle smaller x value. WE are waiting on a response from Haas. probably gonna replace the processor. uuggghh.

[MSL]

Can you show us the User preference Post Setup Switches section of your post?

 

[MrFish]

Posted out your file with our Postability UMC750 post that is pretty dialed and the code looks very similar to yours, well certainly in the important areas. So sounds like you have a machine or machine setup error.

[MrFish]

5 hours ago, WestRiver said:

We too have a Haas umc 750 and a Postability Post. Ours comes up with error codes 2.103 y axis servo error too large , 9971 excessive axis speed or acceleration , 949 internal feed error detected. The machine just stops, right after gouging my part, started doing it when I first started doing 5 axis simultaneous machining now it is doing it on simple surfacing. It has ruined (5) , 3500.00 parts in the last 2 weeks. Haas finally fessed up to the fact that they have a software issue and are going to up grade the software  some day soon  I hope .I would double check the   WRZP numbers as I don't see any 12" numbers in the code you have posted It could be the software with yours as well. Good luck!

Hmm, Interesting. When we are doing surfacing work we have to either run it in Feed Mode (G01) for all rapids or manually set the rapid over ride to 5% or we get gouging on some of the rapid re-position moves.

[crazy^millman]

13 hours ago, MrFish said:

Hmm, Interesting. When we are doing surfacing work we have to either run it in Feed Mode (G01) for all rapids or manually set the rapid over ride to 5% or we get gouging on some of the rapid re-position moves.

Dog leg Rapids problem is what that sounds like. Why you should only use G1 and then you can Rapid at 100% and not have the issue. I do this on $2million Gantry machines that people bought the G0 5 Axis TCP options for $25k. Rapid is not feed and will gouge parts on those machine because the feed move is controlled the rapid move is somewhat controlled, but not the same way a feed move is.

[MrFish]

4 hours ago, C^Millman said:

Dog leg Rapids problem is what that sounds like. Why you should only use G1 and then you can Rapid at 100% and not have the issue. I do this on $2million Gantry machines that people bought the G0 5 Axis TCP options for $25k. Rapid is not feed and will gouge parts on those machine because the feed move is controlled the rapid move is somewhat controlled, but not the same way a feed move is.

Nope not dog legs , been tested and proven to be a software issue on the Control. But I here what you are saying about G0 vs G01

[crazy^millman]

27 minutes ago, MrFish said:

Nope not dog legs , been tested and proven to be a software issue on the Control. But I here what you are saying about G0 vs G01

Okay well then not to rub salt on the wound, but you get what you pay for. Hopefully they get it fixed on their end. I would be very upset if I was scrapping parts due to machine errors.

[MrFish]

6 hours ago, C^Millman said:

Okay well then not to rub salt on the wound, but you get what you pay for. Hopefully they get it fixed on their end. I would be very upset if I was scrapping parts due to machine errors.

now now, all machines have issues, some are just harder to swallow ;-)

[Brian@PC]

Make sure no one inverted a sign when they entered in the MRZP parameters(CHC) or settings (NGC). The MRZP cycle stores the offset in macro variables, then you have to type it in manually into the settings or parameters depending on the control. Very possible being this far off. Plus if something was in G52 or G92 you would see it when not using DWO as well. 

 

[voc177]

I double checked the mrzp settings you'd think they would auto update but alas they don't.. so Haas application engineers are coming out again today . They think it might be a parameter. We will see.

[Brian@PC]

Not a good idea to auto populate. If you had a bad hit from having the artifact in the wrong spot, your center point would be updated incorrectly, without giving you a chance to rationalize it. 

[crazy^millman]

32 minutes ago, Brian@PhillipsCorp said:

Not a good idea to auto populate. If you had a bad hit from having the artifact in the wrong spot, your center point would be updated incorrectly, without giving you a chance to rationalize it. 

Brain, almost every probe process is auto populate because they take the error already figured out on the machine and apply it to the hit. The idea is to center your probe over the sphere and run the routine and then let the process help you solve the center of rotation to get it correct. Doing in manually would scare me that you could mis-type a number and could crash the machine. Please explain better as that statement confused me.