Need Help!- Fanuc Oi MC not completing canned tapping cycle

[slinky]

I have a Fanuc control Oi MC system that seems to be completing its sequence fine but occasionally one of the tapping operations is not reaching the bottom of it's travel. There are no alarms and the system seems fine.

It is not the same tapping operation this is happening on and there are two identical machines this is happening on.
The machines are 3 axis and part of a robot cell with 3rd party PLC control.
The PLC control has interface inputs and outputs hardwired.
The PLC outputs that I would imagine could affect this are Feed Hold, Reset and rewind (which has no logic assigned to it in the PLC program) and block skip.

Could anyone explain to me any reason that this could happen without interrupting the machine cycle?
The PLC code seems to be fine.
Could it be a parameter setting or something in the PMC ladder?

We are really confused by this and a concern has been raised that parts could be shipped to the customer without being complete.

There is a separate tool monitoring system fitted that has not logged any alarms at the times of these parts being produced.

Example of MC code below:

N434 G98 G84 Z#537 R#536 F#104

Any help in this matter would be graciously received.

Thank you

[angelw]

Originally Posted by slinky I have a Fanuc control Oi MC system that seems to be completing its sequence fine but occasionally one of the tapping operations is not reaching the bottom of it's travel. There are no alarms and the system seems fine. It is not the same tapping operation this is happening on and there are two identical machines this is happening on. The machines are 3 axis and part of a robot cell with 3rd party PLC control. The PLC control has interface inputs and outputs hardwired. The PLC outputs that I would imagine could affect this are Feed Hold, Reset and rewind (which has no logic assigned to it in the PLC program) and block skip. Could anyone explain to me any reason that this could happen without interrupting the machine cycle? The PLC code seems to be fine. Could it be a parameter setting or something in the PMC ladder? We are really confused by this and a concern has been raised that parts could be shipped to the customer without being complete. There is a separate tool monitoring system fitted that has not logged any alarms at the times of these parts being produced. Example of MC code below: N434 G98 G84 Z#537 R#536 F#104 Any help in this matter would be graciously received. Thank you

If there is no specific reason for using a common variable for Z, I would use a local variable (#1 - #33) instead, in case #537 is being altered in a Macro program that you're not aware of.

Regards,

Bill

[JimBoyce]

A tension/compression tap holder with a very dull tap could cause a short thread (about 1/8"). Instead of tapping, the dull tap slides on the part and compresses the holder while the z axis comes down. Eventually the tap bites and starts tapping. The machine knows where the z axis and the holder is, not where the tap is. This condition would cause unconsistant thead depths.

[slinky]

Thnks for your info.

I forgot to mention.
The hole is tapping short by around 10mm in depth, so, quite a lot really.
There is definitely no possibility of it being mechanical i.e. the holding of the part, as this is spotfaced prior to tapping.
The hole tapping depth is around 60mm overall.

A part is machined around 1 per minute. Three holes are spotfaced and tapped. Occasionally 1 of these holes is not reaching full tapping depth. When I say occasionally, maybe 1 to 10 per day.
We cannot identify any possible cause for this.

If it is a macro or something else changing the variable, then it must be changing it back prior to the next cycle because the next parts are fine.

This makes me think it is not something changing the variable, otherwise it would hve to add back on what it subtracted etc. or store the previous value and reload it.

I am more inclined to believe it is some parameter or other that is affecting this.

[stevo1]

Bill may be correct so I would not rule out the variable so quickly. When it comes to macros you never know when or how these are being set. It could have been a simple over sight. Maybe there is a check/condition right before the 3rd hole is tapped changing the variable. Then because it is fine on the next part most macro programmers always reset there variables at the end or beginning of the code to ensure that this exact mistake does not happen.

Is it always on the same hole every time this happens? If so which hole is it?

If the above is true then I would probably breakdown the code to make sure there is no error. If you are not very experienced with macros then maybe putting a variable right before the tapping cycle to check the status of #537 before tapping and if you find the hole to be shallow you can see what the value is set to. You would have to find a variable that you are not using.

Stevo

[angelw]

Originally Posted by slinky Thnks for your info. I forgot to mention. The hole is tapping short by around 10mm in depth, so, quite a lot really. There is definitely no possibility of it being mechanical i.e. the holding of the part, as this is spotfaced prior to tapping. The hole tapping depth is around 60mm overall. A part is machined around 1 per minute. Three holes are spotfaced and tapped. Occasionally 1 of these holes is not reaching full tapping depth. When I say occasionally, maybe 1 to 10 per day. We cannot identify any possible cause for this. If it is a macro or something else changing the variable, then it must be changing it back prior to the next cycle because the next parts are fine. This makes me think it is not something changing the variable, otherwise it would hve to add back on what it subtracted etc. or store the previous value and reload it. I am more inclined to believe it is some parameter or other that is affecting this.

What Stevo suggested would be a good way to determine if the variable is being changed, and you could expand on this by branching to an error routine when the value of #537 is incorrect and having the machine stop, or log the error. You could create a counter, incremented every time a hole is tapped, and log the counter value and #537 by sending it via the RS232 port to a PC. This way you will know if the part is incorrect and you won't be sending faulty parts out the door.

Regards,

Bill

[sinha_nsit]

Try a different floating tap holder or rigid tapping.

[slinky]

Originally Posted by sinha_nsit Try a different floating tap holder or rigid tapping.

We are using rigid tapping M29 I believe.

[slinky]

Originally Posted by stevo1 Bill may be correct so I would not rule out the variable so quickly. When it comes to macros you never know when or how these are being set. It could have been a simple over sight. Maybe there is a check/condition right before the 3rd hole is tapped changing the variable. Then because it is fine on the next part most macro programmers always reset there variables at the end or beginning of the code to ensure that this exact mistake does not happen. Is it always on the same hole every time this happens? If so which hole is it? If the above is true then I would probably breakdown the code to make sure there is no error. If you are not very experienced with macros then maybe putting a variable right before the tapping cycle to check the status of #537 before tapping and if you find the hole to be shallow you can see what the value is set to. You would have to find a variable that you are not using. Stevo

This is what got me. I thought it would be the last hole, but it wasn't it was the second?????? There are different variables for all three tapping depths though, so it could be the variable.

How does it reset itself to its previous state for the next cycle though.

Another thing. I can't find any RS232 comms port and can someone tell me where I can find the macros or anything that may be altering the variables.

I am from a controls background, Electrical, PLC and robotics, and not too familiar with CNCs, but having been thrown in at the deep end, am learning fast.

The manuals are very long winded.

[angelw]

Originally Posted by slinky This is what got me. I thought it would be the last hole, but it wasn't it was the second?????? There are different variables for all three tapping depths though, so it could be the variable. How does it reset itself to its previous state for the next cycle though. Another thing. I can't find any RS232 comms port and can someone tell me where I can find the macros or anything that may be altering the variables. I am from a controls background, Electrical, PLC and robotics, and not too familiar with CNCs, but having been thrown in at the deep end, am learning fast. The manuals are very long winded.

How do you upload programs to the machine? Your control may have an Ethernet connection, but even so, machines so equipped normally have an RS232 interface included. The connector will be a DB25 female, often confused by some as being a parallel port.

The variable #537 you're using is a common variable meaning that its value is global and can be accessed and defined by Macro statements in other Macro programs. For example, a common variable used in one program can be redefined if its also used in, say, a tool change routine. Such programs are commonly recorded in the 8000 or 9000 series programs and therefore can be hidden from view. In this situation, variables used in one program can be redefined by the hidden program without the user being aware. Accordingly, if the variable is being redefined by another program, it can be difficult to track down. One way is to set the parameter to allow the macro statements to be executed in single block mode and step through the program and view the value of #537 as you go. However, as the error in the depth does not occur every time, this may be a very long winded exercise.

You could do as Stevo suggested and interrogate the value of #537 just before each drilling cycle. Something like the following:

A question first, is there a pattern of holes tapped with the one G84 cycle and the second hole is incorrect? If this is the case, you would have to interrogate #537 before each hole is tapped, not just before the cycle is called.

Use a variable not used elsewhere to preserve the value of #537 immediately before its used in the tapping cycle. Lets say its #1, and hard code the desired value of #537 in the following conditional statement. Lets say the #537 should have a value of -10.000

#1 = #537
IF [#1 NE -10.000] GOTO555
--------
#1 = #537
IF [#1 NE -10.000] GOTO555
--------
#1 = #537
IF [#1 NE -10.000] GOTO555
--------
N555 G80
IF [#1 EQ -10.000] GOTO556
M00
N556

In the above code, the program will jump to G80 and apply a compulsory stop if #537 has the wrong value. This approach will only tell you that the variable is being changed, not where its being changed.

To find what other programs may be using #537 is to download the complete program registry of the control to a PC as one long program. O-9999 punch or Punch All will do it, then use the search function of the Editor/Comms software to find all occurrences of #537 and what program its occurs in.

The simplest resolve would be to do as I suggested in my first post and that is to define the Z value for the tapping cycle locally in a local variable (#1 - #33). If the same variable is used by another program, it won't effect the value where its being used locally.

Regards,

Bill