What's new
What's new

FANUC 21M Rigid Tapping Issue

Ok so this code does actually run and make very nice threads, but remove the M5 and no go. And If I substitute M95 for the M5 I'm sure it would work as well but I haven't tried it. Thanks everyone for trying to help, much appreciated!!

And to answer your question Dan. M95 on this machine is Spindle Stop and Coolant Off.

N4G17G80G40G90G49G0
T4M06 ( #2-56 CUT TAP )
G90G54
G90G0X2.805Y-.0075
G43Z.1H4
M08
M84S1500
G84G98X2.805Y-.0075Z-.34R.1F26.78571
X2.055
X1.59
X.84
X.375
X-.375
X-.84
X-1.59
X-2.055
X-2.805
G80M5
G0Z.1
M09
G91G28Z0.
G0G90G53X0.Y0.
M30
I see in your iteration above, you have dropped the S1500M03 from the code example in your earlier Post. The Rigid Tapping Cycle should be allowed to start the spindle; my Fanuc colleagues have mentioned numerous times that having the spindle running before initiating Rigid Tapping can cause unusual results.

Did you introduce G80 M5 at the same time you dropped the S1500M03 from your program? If so, it may be the omission of the S1500 M03 that now makes your program work; does the program still halt if you omit M5 from the block containing the G80 and with the S1500 M03 omitted from your program?

The way you have your program configured with the following:
M84S1500
G84G98X2.805Y-.0075Z-.34R.1F26.78571
you would have to have parameter 5200.0 set to "0" and "84" registered in parameter 5210 (specifies the "M" code to start Rigid Tapping).

Automatic Teller Machines go by the acronym ATM and the quick Covid Test, the Rapid Antigen Tests by the acronym RAT. Many people call these respectively ATM Machines and RAT Tests, which translates to Automatic Teller Machines Machines and Rapid Antigen Test Tests. It's somewhat similar when M84 is used as the "M" Code to initiate Rigid Tapping.

As mentioned by Sinha, by setting parameter bit 5200.0 to "1", Rigid Tapping is initiated with G84 and without the requirement of an "M" code. However, this then doesn't allow the use of conventional tapping, should, for some reason, you may want to use it.

By setting parameter 5200 to "1", the "M" code can be omitted and Rigid Tapping will be initiated by G84; the "S" code can be specified in the G84 Block. If parameter 5200 is set to "0" and parameter 5210 also set to "0", the default "M" code M29 is judged to be have been set.

What is parameter bit 5200.2 set to? If set to "0", try setting it to "1".

Any Group 1 G Code will also cancel a Canned Cycle, such as G84. Although G80 should work (and it may be the setting of parameter bit 5200.2 that is upsetting it), try dropping the G80 M5 from the extract from your code below:

G80M5
G0Z.1
and just have G0 Z0.1, it should have the same affect as G80.

Regards,

Bill
 
Last edited:
I thought I had deleted that post after seeing what you were tapping at. I added another stating that the reverse may be true and you might be tapping too fast.

I see in your iteration above, you have dropped the S1500M03 from the code example in your earlier Post. The Rigid Tapping Cycle should be allowed to start the spindle; my Fanuc colleagues have mentioned numerous times that having the spindle running before initiating Rigid Tapping can cause unusual results.

Hello angelw,
I knew you'd see this post eventually so I dropped that S1500M03 line just for you. However, Our Cam posts it that way and we run It that way on 4 different Fanuc's without Issue. At least on our machines I see no difference In the result with or without It In the code.


Did you introduce G80 M5 at the same time you dropped the S1500M03 from your program? If so, it may be the omission of the S1500 M03 that now makes your program work; does the program still halt if you omit M5 from the block containing the G80 and with the S1500 M03 omitted from your program?
Removing the S1500M03 did not remedy the hanging Issue. And yes the program will still hang after removing the S1500M3 line If the M5 is removed.

The way you have your program configured with the following:
M84S1500
G84G98X2.805Y-.0075Z-.34R.1F26.78571
you would have to have parameter 5200.0 set to "0" and "84" registered in parameter 5210 (specifies the "M" code to start Rigid Tapping).

Per my posts above that is exactly how the parameters are set. If I change 5210 to 29 the machine throws an alarm. And per the Chiron manual they are using M84.

Automatic Teller Machines go by the acronym ATM and the quick Covid Test, the Rapid Antigen Tests by the acronym RAT. Many people call these respectively ATM Machines and RAT Tests, which translates to Automatic Teller Machines Machines and Rapid Antigen Test Tests. It's somewhat similar when M84 is used as the "M" Code to initiate Rigid Tapping.

As mentioned by Sinha, by setting parameter bit 5200.0 to "1", Rigid Tapping is initiated with G84 and without the requirement of an "M" code. However, this then doesn't allow the use of conventional tapping, should, for some reason, you may want to use it. With your code above, it would indicate that "84" is set in parameter 5210 and in an obscure method, will also only allow the use of Rigid Tapping.

By setting parameter 5200 to "1", the "M" code can be omitted and Rigid Tapping will be initiated by G84; the "S" code can be specified in the G84 Block. If parameter 5200 is set to "0" and parameter 5210 also set to "0", the default "M" code M29 is judged to be have been set.

What is parameter bit 5200.2 set to? If set to "0", try setting it to "1".
Here's your answer Dan so I hope you see this. Parameter 5200.2 was Indeed set to 0. And as long as It Is the machine will hang at the end of the tapping cycle unless you have G80M5 and I'm guessing maybe Its just looking for the spindle stop not really the G80, but I didn't try that. When I turn 5200.2 on. The problem goes away and the machine will run without the M5 and In fact will run without G80M5 and not hang. So thank you Mr angelw for the parameter fix to this issue. And the link below would have helped us figure that out. But I didn't find that one until I started searching for parameter 5200.2.



Any Group 1 G Code will also cancel a Canned Cycle, such as G84. Although G80 should work (and it may be the setting of parameter bit 5200.2 that is upsetting it), try dropping the G80 M5 from the extract from your code below:
If I remove the G80M5 the machine will still hang at the end of the cycle. However with 5200.2 turned on It does not hang without the G80M5. Thank you again sir for pointing us to an alternative fix via parameters.
G80M5
G0Z.1
and just have G0 Z0.1, it should have the same affect as G80.

Regards,

Bill
 
Last edited:
Per my posts above that is exactly how the parameters are set. If I change 5210 to 29 the machine throws an alarm. And per the Chiron manual they are using M84.
I'm glad the parameter 5200.2 change sorted your issue.

With regards to M29 raising an alarm, that's very unusual, as M29 is the Fanuc default "M" code for initiating Rigid Tapping. If Zero is registered in parameter 5210, M29 is assumed by the control.

Regards,

Bill
 
……..With regards to M29 raising an alarm, that's very unusual, as M29 is the Fanuc default "M" code for initiating Rigid Tapping. If Zero is registered in parameter 5210, M29 is assumed by the control.

Regards,

Bill
I’m curious what alarm was raised with M29. I’ve never seen it, but suspect that the builder could raise a PMC alarm when M29 is commanded despite the Fanuc side parameters being set for its use.
 
I’m curious what alarm was raised with M29. I’ve never seen it, but suspect that the builder could raise a PMC alarm when M29 is commanded despite the Fanuc side parameters being set for its use.
If I change 5210 to 29 and put M29 in the code rather than M84 It throws 205 RIGID MODE DI SIGNAL OFF. If I leave the M84 in the program It will not run but generates no alarm.
 
If I change 5210 to 29 and put M29 in the code rather than M84 It throws 205 RIGID MODE DI SIGNAL OFF. If I leave the M84 in the program It will not run but generates no alarm.
This is pretty clear evidence that the builder's PMC ladder program is decoding M84 to send the CNC the input signal for rigid tap mode. Also quite likely that M29 is forcing the input off via the ladder.
 
Good to know that 5200#2 = 1 solves the problem.

IIRC, somebody had reported long time back that two consecutive G80 also solves the problem.
 
Good to know that 5200#2 = 1 solves the problem.

IIRC, somebody had reported long time back that two consecutive G80 also solves the problem.
I've always considered fixes via parameter to be the best solutions, as most of the "work arounds" are generally fudges that have been stumbled upon, like VTM's G80 M5 solution. There is no documentation for that being a fix, it would be something that he tried and happened to work.

Regards,

Bill
 
Yes.
However, the reason for the hang, as perceived by him, seems to be correct. It is because of look-ahead feature. The control tries to implement the block next to G80 in the rigid mode, and gets "confused".
With the parameter change, the rigid mode is immediately cancelled by G80, which obviates the problem.
 
Last edited:
However, the reason for the hang, as perceived by him, seems to be correct. It is because of look-ahead feature. The control tries to implement the block next to G80 in the rigid mode, and gets "confused".
With the parameter change, the rigid mode is immediately cancelled by G80, which obviates the problem.
Hello Sinha,
I think its different to that, or that two consecutive G80 codes don't actually work to resolve the issue. The reason I say that, is because any Group 1 "G" Code will cancel Canned Cycles; that fact is well documented in Fanuc Manuals. VTM's code at the completion of the Tapping Cycle (with the M5 omitted) was as follows:

G80
G0Z.1

G0 is a Group 1 "G" Code, therefore, in effect, the above code, disregarding the Z.1, would be the same as:

G80
G80

Regards,

Bill
 
Probably, G00 without a Z would have worked. Or, maybe, just an extra EOB after G80.
The description of 5200#2 is related to timing of rigid signal being OFF. That is why it looks to be a look ahead issue.
 
Probably, G00 without a Z would have worked.
The coordinate makes no difference to the affect of a Group 1 "G" Code on a Canned Cycle. In the following example:

G90 G00 G54 X0.0 Y0.0
G43 Z10.0 H01
G98 G82 Z-3.0 R1.0 P100 F100
X20.0 Y10.0
G00 X40.0 Y20.0
X60.0 Y30.0
X80.0 Y40.0
G80
-----------------
-----------------
-----------------

A hole will be spot drilled at X0.0 Y0.0 and at X20.0 Y10.0. From the Block containing the G00 and thereafter, the axes will move at Rapid to the specified coordinates, but no drilling operation will occur. The G82 cycle is cancelled by the G00, with or without a coordinate.

Regards,

Bill
 
This is how 5200#2 is described ...
1666546370124.png
This indicates that if set to 0, the control may read the next block (after G80) before the rigid mode actually ends. If the next block in meaningless in rigid mode, the control may hang.
Of course, it can be a matter of interpretation.
 
Rigid tapping is a different animal.
Drilling cycles never hang.
Yes, I understand that and your Post that followed. What I'm saying is that I'm skeptical that two successive G80 commands would be a fix and I made the point that in the OP's program before he stumbled onto including M05 as being a workaround, his code included two successive Rigid Mode cancel commands in the following:
G80
G0Z.1
Whether the Cancel Commands were G80, or G00, or any other valid Cancel Command seems irrelevant to me.

In fact, the G0Z.1 is superfluous in his program because Z0.1 is his Initial Level and the Z axis slide would gave returned to that point after the Cycle was completed; the program is commanding a move to the Z location that its already at. The "R" plane is also the same as the Initial Plane. I think I read one of the OP's replies stating that the program is the result of a CAM Post. That being so, its a case of a not so flash Post Processor.

I don't see any issue with interpreting the instruction from the Fanuc Manual and I don't consider G00 as being meaningless in Rigid Tapping; its a valid Cycle Cancel command the same as G80 is.

Regards,

Bill
 
It is a matter of verification if G80 followed by another G80 or G00 (without Z) or just an extra EOB works, even with 5200#2=0.
if OP has time, maybe he can experiment.

But, I believe, it is a look ahead issue. G80 followed by G31 should work, irrespective of parameter seeing.
 
It is a matter of verification if G80 followed by another G80 or G00 (without Z) or just an extra EOB works, even with 5200#2=0.
if OP has time, maybe he can experiment.

But, I believe, it is a look ahead issue. G80 followed by G31 should work, irrespective of parameter seeing.
I don't think it has anything to with a look ahead block, as G80 (or any other Cycle Cancel code is part of the program structure. It would be a bit like saying that, due to the look ahead feature (buffering), that an axis coordinate following a Group1 G Code is being missed. It's totally different to trying to read an axis coordinate while motion is taking place.

Buffering is all about pre-reading the commands. The reason it has an adverse affect when trying to read a coordinate from a System Variable, is because the instruction to read the System Variable is executed before the axis slide gets there. From what I understand of the OP's issue, is that the program doesn't hang until the Tapping Cycle has been completed and then reads the G80.

To stop buffering with G31 (or any other buffer preventing code) it would have to go before the G80, not after it and I suspect that G31 would not be seen as a valid Canned Cycle Code and would probably cause an issue.

Regards,

Bill
 
Last edited:
Look ahead seems to me the only plausible explanation for the hang, as the control tries to interpret something irrelevant in the rigid mode.

If you believe that it is not the reason, what could be the possible reason?
 
Look ahead seems to me the only plausible explanation for the hang, as the control tries to interpret something irrelevant in the rigid mode.

If you believe that it is not the reason, what could be the possible reason?
It just doesn't seem like a function that would be affected by Buffering and I very much doubt that it is.

All PLCs have a scanning rate and this scanning rate has diminished down to minuscule levels over the years. But in the early days it was a distinct consideration when planning the structure of a program so that an event wasn't missed in the scan.

I've not encountered the issue the OP had and I mess with a considerable mix of machines on a weekly basis. If it was being caused purely by a Buffering issue, I'm sure you would see it more frequently.

It could be something to do with how the PLC program has been written; there has already been some anomalies identified, in that the OP's machine doesn't use the Fanuc default "M" Code for initiating Rigid Tapping and appears not to like any other number than "84".

Regards,

Bill
 








 
Back
Top