Oi Mate TC incremental problem

[nracingdev]

Guys,

We have a cylindrical 2 axis grinding machine. The bed is the Z axis, and the Wheel is the X. X negative moves wheel toward part and vice versa. I have been having issues with this machine doing very unpredictable issues that I usually can find work arounds. This problem however I have been unsuccessful.

I basically have a bunch programs all working together: O1405 parent grinding program, O1406 plunge sub, O1407 traverse grinding sub, O1409 safety program, and O9012 is my wheel dressing program.

The issue I am running into is the parent program will call the plunge routine, and after a pass will pull the wheel back and run the dress program. When the dress cycle ends the X axis returns home via G28. From here the program drops back into the plunge routine which calls my safety program. The safety program calls up the correct Csys and tool offsets. After this it commands small incremental moves of each axis (G01 U-.01 W-.01) as I have had issues with the correct positions not being displayed without a movement command after the offset and Csys change.

My problem is that on the first return from dress and the incremental command is called, only the X axis fails by trying to move positive. The screen shows the Z axis distance to go is -.01 however the X shows +.3845. When the axis is at home this causes it to overtravel in the positive direction displaying errors 500, and 410.

Sorry for the long post if anyone wants more code please let me know because this machine is killing me with its unpredictability.
Thanks,
Chris

[fordav11]

did it work properly at all? Meaning could it be purely a machine fault or if it never worked right it could be a program issue? If the latter please post your program(s)

[G0G90]

Has this worked in the past?
It really sounds like something in your code is to blame.

can you post your code or attach it?

[nracingdev]

this issue does not appear in all programs. It is very hit or miss.
I have another "manual" program I wrote O9016 which this issue happens only the first time from return from dress cycle. After the first failure, the control runs the program as written.

I will attach all of the programs but i will warn you, they can be somewhat difficult to follow as they are quite parametric. Thanks for the concern guys

[nracingdev]

uploaded files

[G0G90]

Understandably, this is difficult to go through without any values.
However, I did notice several instances on your conditional logic (IF, THEN) without contingencies of ELSE that would leave the program miscalculate.

Example;
N50IF[#607EQ1.0]GOTO21;
IF[#607EQ2.0]GOTO22;
;
N21#606=#673-#615;

In the above, if both statements are FALSE, it drops onto the next N21, anyways.
Is this the desired effect?
As I'm reading this code through, there is no initial value assigned to #607 ???

At the bottom of O1408, N20 - the M99 will execute prior to assigning #607 and therefore will not assign the value to it

[nracingdev]

GOG90,

Thanks for checking out my programs. The conditional values you specifically called out refer to a value that is entered by the operator. It is to select 1 for diameter one of a part or 2 for diameter 2. If the parent program is run from the beginning, it will automatically change the value to 2 forcing the logic to move on to the second diameter of the part.

as for the N20 at the bottom of 1408, you definitely pointed out a flaw in the program. The first M99 was supposed to be removed and the value assignment happens before the M99 is issued.

[nracingdev]

I think all of this parametric programming is too confusing to sort through to diagnose the problem. I originally found this issue with the manual program O9016 so lets look at this. Which now I am realizing I uploaded to the post the incorrect revision. First thing tomorrow morning I will upload the correct version.

As I said in the earlier post, this happens when returning to O9016 from the dress program O9012.

When completing the dress program my Csys is G56 using T4848 which locates the dresser. I am not at the control now so I cant tell you what the actual offset numbers are but lets be abstract here.
So we are complete with O9012, and call up O9016. O9016 starts by calling Csys G55 and T6262. I have found on this particular control that the Tool offsets do not affect the size on screen until a movement command is issued. Because of this I issue a G01 U-.01 W-.01; command which should move the wheel (X toward part .01") and move the table (Z left .01"). It is then followed by G01 U.01 W.01 which should return both axis to where they were before the first movement command.

What actually happens on the first command is the distance to go for Z is correct at -.01 and the table moves there. The X however goes crazy and shows on the screen a large incremental positive move which when the head is where it starts from (ZRN) causes the axis to over-travel.

[nracingdev]

here is the correct O9016. Thanks for the attention guys

[fordav11]

most Fanuc controls I've worked wont apply a tool offset unless there's a G00 on the same line. In that case the control will sit waiting for tool movement but because there is no G0 or G1 it hangs.
So..... G00 T6262

also, try writing the program a more standard way without macro variables. just stick in some fixed numbers and it should just work.

O9016 (MANUAL INFEED AUTO TRAV)(MERANI DEC 06, 2010)
G55
G98
G00 T6262
G97 S200 M3
G00 X25.0 Z0 M8
G01 X24.936 F50.
G01 Z-15.0 F100.
G04 U2.5
G01 Z0 F6.
G04 U2.5
G01 Z-15.0
G04 U2.5
G28 U0 W0
T6200 M5
M30
%

[nracingdev]

adding G00 in front of the tool call did absolutely nothing. The machine still fails to adjust the positions until a move is initiated.

As for removing the macro variables, what is the point. I am well aware that the machine can be programmed with absolute numbers and will function satisfactorily. The reason we use macro programming is that we are a job shop doing small production runs and one off parts. We are cylindrically grinding with tolerances down to .0001". Because of this the program needs to be intuitive to where the operator can change a specific macro variable without modifying the program and let the program do the logic.

Does anyone know how to contact a local fanuc rep to have them come out and see what this POS is doing?

[gbowne1]

It's interesting to note that the MTB used a 0i Mate TC control. Instead of one of the FANUC "G" controls on a grinder.

But really, it looks like too much code. I like fordav11's approach.

O9016 (MANUAL INFEED AUTO TRAV)(MERANI DEC 06, 2010)
G55
G98
G00 T6262
G97 S200 M3
G00 X25.0 Z0 M8
G01 X24.936 F50.
G01 Z-15.0 F100.
G04 U2.5
G01 Z0 F6.
G04 U2.5
G01 Z-15.0
G04 U2.5
G28 U0 W0
T6200 M5
M30
%