Largest Manufacturing Technology Community on the Web
Stay Connected:
Macro Programming Fundamentals
- Thread starter Tonytn36
- Start date
- Replies 991
- Views 615,323
angelw
Diamond
- Joined
- Sep 10, 2010
- Location
- Victoria Australia
Hello Stefan,
The above program proves nothing, other than it may be the policy of the company, or the style of the programmer; it doesn't make it right. Certainly the code shown in Red should be preceded by a Buffer Prevention Code, but its unnecessary following the G31 Skip Function. I can post many examples of genuine Renishaw Programs that contain the G31 Skip Function where there is no other Buffer Prevention Code separating the G31 Block and a Block where the Skip Function System Variable is read.
Neither G31 nor G53 were designed to be stand alone Buffer Prevention Codes. In early days, G04 or a number of EOBs were specified in the Fanuc Manual for that purpose. The use of G31 and G53 for this purpose came about through dumb luck, where someone stumbled onto the fact that either of these codes could be used to Prevent Buffering and eventually, accepted by the factory.
Following is an example where a "G" Code that is not Buffered can still work to Prevent Buffering even when used for it's design purpose, one that you're familiar with, G53.
The following pictures show a simple program that includes G53 to position the X and Y axis at the Machine Coordinate Position specified in the G53 Block. The Block includes the Block Delete symbol so that the program can be executed with and without the G53 Block being executed to demonstrate that the Buffer Prevention still occurs even though G53 is being used for its design purpose.
Firstly, my apologies for the rubbish picture quality.
Again for clarity a Text copy of the simple program shown in the picture follows:
O6015
(BUFFER HALT TEST)
N1 G17 G21 G40 G49 G80 G90 G94
G91 G28 Z0.0
G28 X0.0 Y0.0
G90 G00 G54 X-246.0 Y0.0
/G53 X-50.0 Y0.0
G65 H01 P#100 Q#5021 (COMMON VARIABLE #100 ACCEPTS THE VALUE)
G91 G28 X0.0 Y0.0
M30
%
The following picture shows the result when the above program was executed with the Block Delete Switch turned ON:
The above picture shows that a value of -1.2mm being read due to no Prevention of Buffering occurring prior to the Read Macro Statement and represents the value read after a time period of circa 7.2ms after the Cycle Start Button was pressed. This is totally understandable, for the #502_ System Variables can't be read during movement; this is clearly spelt out in all Fanuc Manuals
The following picture shows the result when the above program was executed with the Block Delete Switch turned OFF:
The above picture shows that a value of -50.0mm being read due to Prevention of Buffering occurring prior to the Read Macro Statement. This represents the value read after the G53 Function had completed.
The exact same scenario occurs when G31 is executed in the manner it was designed for, that being to detect a Skip Signal and skip to the next block in the program. Just like the G53 example above, it also acts to Prevent Buffering even when being executed in it's design capacity.
By your reckoning, the program code would have to be as follows:
/G53 X-50.0 Y0.0
G53
G65 H01 P#100 Q#5021
Not so.
Today, I also took the matter up with resident Japanese, factory trained, Fanuc control and programming expert and he confirmed that G31 and G53 will prevent buffering irrespective of whether they are being used as a stand alone "G" code, or being executed for their design purpose.
When asked about the Caution Posted earlier in this Thread, he simply replied "translation" and reiterated that G31 requires no further Buffer Prevention code to follow it.
Regards,
Bill
Yes.
Any number in the range 0-255 can be specified, including pre-defined codes, which will then serve dual purpose.
M00, M01, M02, M30 always prevent buffering, even if not specified in these parameters.
PROBE
Hot Rolled
- Joined
- Jan 23, 2003
- Location
- Tel Aviv, Israel
Hi Bill,
1. First of all I wish to emphasize: I WAS WHITNESSING THIS BUFFERING PROBLEM AFTER G31 STATEMENT MANY TIMES, STAND ALONE G53 IN G31 FOLLOWING BLOCK WAS THE ULTIMATE ANTIDATUM.
Renishaw programs are not consistent regarding the use in standalone G53. Some do, some don’t. I experienced many times the problems with “G53 lacking” programs. As preemptive action I edited accordingly each and every program I dealt with, and spared to myself the necessity to deal with it in the field.
2.
3.
4.
For me, by the way, the directives of the CAUTION are clear. What bothers me is its last sentence: "To avoid this phenomenon, specify such M codes or G codes before the macro statement, if necessary."
The words if necessary have no place in technical language and any engineering document. Either it is imperative or not needed. No other option exists. Otherwise the bridges are falling, the buildings are crushing and probes are smashed.
Regards,
Stefan
1. First of all I wish to emphasize: I WAS WHITNESSING THIS BUFFERING PROBLEM AFTER G31 STATEMENT MANY TIMES, STAND ALONE G53 IN G31 FOLLOWING BLOCK WAS THE ULTIMATE ANTIDATUM.
Renishaw programs are not consistent regarding the use in standalone G53. Some do, some don’t. I experienced many times the problems with “G53 lacking” programs. As preemptive action I edited accordingly each and every program I dealt with, and spared to myself the necessity to deal with it in the field.
2.
Blum deals with nothing but probing. Maybe it is the matter of the temper of each of us, but I certainly would never undermine their programming staff’s skills and ability to understand the problem. They decided to use the G53 for a reason, technical reason.
3.
With all respect to this expert, your expertise, as well as mine, are as good as his. Facts count only. You say you never witnessed this phenomenon, I say I experienced it many times. Assuming that we both say truth, logically the problem exists.
4.
This is very poor explanation. Translation ??????? We both, as well as all Fanuc users, are entitled to something much better.
For me, by the way, the directives of the CAUTION are clear. What bothers me is its last sentence: "To avoid this phenomenon, specify such M codes or G codes before the macro statement, if necessary."
The words if necessary have no place in technical language and any engineering document. Either it is imperative or not needed. No other option exists. Otherwise the bridges are falling, the buildings are crushing and probes are smashed.
Regards,
Stefan
angelw
Diamond
- Joined
- Sep 10, 2010
- Location
- Victoria Australia
Hello Probe,
The Caution from the Fanuc Manual that tteitgen posted in his #951 Post and the text from which you have continued to use, is a general caution related to "Processing Macro Statements", as the heading of the article implies, and NOT related to G31 specifically, with G31 being included as the one of the solutions NOT part of the problem. The text that precedes that image should have been included to put it more in context. The more complete extract is shown below:
I've taken this matter up with the Resident Fanuc Engineer again and he is aliment that a Buffer Preventing Code is not required between a block containing a Buffer Preventing Code and a Macro Statement. This fellow is a career, Fanuc Company person who has been with Fanuc for the more than 30 years and I put far more stock in his opinion than example code written by a second party. The example you published with G53 following the Block containing G31 will work but it's not the presence of the G53 that makes the code work. The G31 Block completes before the next Block is executed because the G31 Block contains a Buffer Preventing Block, that being G31. I think your solution is a simply a solution looking for a problem.
The key word in the text of the picture above and that which is underlined in Red is "Containing". Whether the Buffer Preventing Code is Stand Alone in a Block or used in the manner for which it was designed, makes no difference; any Block that Contains a Buffer Preventing Code will Halt Buffering and have that Block complete before executing the next Block. The following extract from the text in the picture above and the Graphic representation of the program flow clearly indicate that the Block containing a Buffer Prevention Code will complete before the next Block is read.
At the blocks containing M00, M01, M02 or M30, blocks containing M-codes for which buffering is suppressed by setting parameters Nos. 3411 to 3420 and No.3421 to 3432, and blocks containing prevention buffering G codes such as G31 or G53, the CNC stops to preread the NC statement after that. Then, the stop of the macro statement execution is guaranteed until such M codes or G codes complete its execution.
Even the "if necessary" is a valid comment in the true context of the text in the picture above, as not all position System Variables need to have Buffering prevented before they can be accurately read. Any where their "Read operation during movement" is listed as Enabled can be read without Buffer Prevention; Block End Point, #5001–#5008, for example, is another that doesn't require Buffer Prevention for it's System Variable to be read and so, the following is allowed:
G90 G00 G54 X-100.0 Y0.0
#1=#5001
No Buffer Prevention necessary.
Regards,
Bill
The Caution from the Fanuc Manual that tteitgen posted in his #951 Post and the text from which you have continued to use, is a general caution related to "Processing Macro Statements", as the heading of the article implies, and NOT related to G31 specifically, with G31 being included as the one of the solutions NOT part of the problem. The text that precedes that image should have been included to put it more in context. The more complete extract is shown below:
I've taken this matter up with the Resident Fanuc Engineer again and he is aliment that a Buffer Preventing Code is not required between a block containing a Buffer Preventing Code and a Macro Statement. This fellow is a career, Fanuc Company person who has been with Fanuc for the more than 30 years and I put far more stock in his opinion than example code written by a second party. The example you published with G53 following the Block containing G31 will work but it's not the presence of the G53 that makes the code work. The G31 Block completes before the next Block is executed because the G31 Block contains a Buffer Preventing Block, that being G31. I think your solution is a simply a solution looking for a problem.
The key word in the text of the picture above and that which is underlined in Red is "Containing". Whether the Buffer Preventing Code is Stand Alone in a Block or used in the manner for which it was designed, makes no difference; any Block that Contains a Buffer Preventing Code will Halt Buffering and have that Block complete before executing the next Block. The following extract from the text in the picture above and the Graphic representation of the program flow clearly indicate that the Block containing a Buffer Prevention Code will complete before the next Block is read.
At the blocks containing M00, M01, M02 or M30, blocks containing M-codes for which buffering is suppressed by setting parameters Nos. 3411 to 3420 and No.3421 to 3432, and blocks containing prevention buffering G codes such as G31 or G53, the CNC stops to preread the NC statement after that. Then, the stop of the macro statement execution is guaranteed until such M codes or G codes complete its execution.
Even the "if necessary" is a valid comment in the true context of the text in the picture above, as not all position System Variables need to have Buffering prevented before they can be accurately read. Any where their "Read operation during movement" is listed as Enabled can be read without Buffer Prevention; Block End Point, #5001–#5008, for example, is another that doesn't require Buffer Prevention for it's System Variable to be read and so, the following is allowed:
G90 G00 G54 X-100.0 Y0.0
#1=#5001
No Buffer Prevention necessary.
Regards,
Bill
Last edited:
PROBE
Hot Rolled
- Joined
- Jan 23, 2003
- Location
- Tel Aviv, Israel
Hi Bill,
Unfortunately it is not so simple and easy.
It is pity, that the way the technical document is written opens the case to Talmudical Debate. You are presenting your arguments, I mine. For each of us his own arguments are convincing. Up to this moment there is no presence of "Higher Instance" (all incognito Fanuc coworkers, local specialists, japanese speakers etc. are meaningless) to rule the final verdict. As reluctant to contact the "authorities" as I am, I decided to approach Fanuc official way, through their web site CONTACT US channel. I received the automatic confirmation, which even quotes the content of my question:
"QUESTION: The attached picture is an excerpt from page 555 of FANUC-30i-63944EN_03-UserManual. In the given example: N1 G31 X100.0 N2 #100=1 the macro statement in block N2 is not using the skip position data generated in preceding block N1 G31 X100.0. But if the block N2 would be N2 #100=#5061, should the program, according to CAUTION highlighted directive, be: N1 G31 X100.0 N12 G53 (NOT BUFFERED G-CODE) N2 #100=#5061 or just N1 G31 X100.0 N2 #100=#5061 Regards, Stefan Rubin Cogito Ergo Sum".
Let's hope that they promptly will furnish an answer, signed by somebody whos name and position will be mentioned.
Final remark: It was many times mentioned and repeated by me , that I personally have been experiencing this buffering problem in reality in the field, and that it was always solved on the spot by adding G53 just after G31 block. Contrary to you, I wouldn't ignore such testimony. But this of course is your shot.
Stefan,
Cogito Ergo Sum
angelw
Diamond
- Joined
- Sep 10, 2010
- Location
- Victoria Australia
Similarly, this is not my first rodeo where Macro Programming is concerned and I suspect that I've had as much experience with Probing Macro applications as yourself; I've been in this game since 1979. I've never experience any issue whatsoever reading the value of a Skip Function System Variable, nor has any problem associated with that ever been reported to me.
As I have mentioned previously in this Thread, the addition of G53 will do no harm, but as your entry into this discussion was in the pursuit of accurate facts, this is the reason I'm persisting with putting the records straight.
Yes. lets hope that you get a reply in a timely manner. With regards to my source being incognito, I will provide his contact details to you, but I doubt that he would appreciate his details being published on a Forum for all and sundry to start contacting him.
1. Thus far the only evidence you have provided has been anecdotal.
2. There is no comments whatsoever in any Fanuc Manual that indicates that a Block containing the Buffer Preventing Code G31 must be followed by another Buffer Preventing code so that a Skip Function variable can be correctly read.
3. In fact the extract from the Fanuc Manual included in my previous Post states that a Block containing a Buffer Prevention code, such as G31 or G53, can be used to halt buffering.
4. It also states in Fanuc Manuals that #506_ System Variables can be read during movement.
5. I've Posted recent program examples, run on a machine and not just text listing of a program, showing that a G31 Block used for the purpose it was designed, does indeed Buffer Prevent.
Regards,
Bill
Processing Faster
Is there any way to make the below process faster? Currently takes 15 seconds for the whole program. This is section one of three sections. Looking at all of the work offsets to see if any have been moved more than a set tolerance. Really wanted to make the IF statement a WHILE statement, but due to nesting limitations had to go with the IF.
IF[#4000NE#920]GOTO9000
G53
#920=#4000
#1=.009(Tolerance)
(Start Scan Values)
#2=5221.(G54 X)
#3=5222.(G54 Y)
#4=5223.(G54 Z)
#5=5224.(G54 B)
#6=670.(Macro #)
#7=1.(Scan Sequence)
WHILE[#5LT5324]DO1
WHILE[[#[#2]GT[#[#6]+#1]]OR[#[#2]LT[#[#6]-#1]]]DO2(X)
GOTO#7
END2
G53
#7=#7+1.
#6=#6+1.
WHILE[[#[#3]GT[#[#6]+#1]]OR[#[#3]LT[#[#6]-#1]]]DO3(Y)
GOTO#7
END3
G53
#7=#7+1.
#6=#6+1.
WHILE[[#[#4]GT[#[#6]+#1]]OR[#[#4]LT[#[#6]-#1]]]DO2(Z)
GOTO#7
END2
G53
#7=#7+1.
#6=#6+1.
IF[[#[#5]GT[#[#6]+#1]]OR[#[#5]LT[#[#6]-#1]]]GOTO#7(B)
#2=#2+20.(G54 X)
#3=#3+20.(G54 Y)
#4=#4+20.(G54 Z)
#5=#5+20.(G54 B)
#6=#6+1.(Macro #)
#7=#7+1.(Scan Sequence)
END1
Is there any way to make the below process faster? Currently takes 15 seconds for the whole program. This is section one of three sections. Looking at all of the work offsets to see if any have been moved more than a set tolerance. Really wanted to make the IF statement a WHILE statement, but due to nesting limitations had to go with the IF.
IF[#4000NE#920]GOTO9000
G53
#920=#4000
#1=.009(Tolerance)
(Start Scan Values)
#2=5221.(G54 X)
#3=5222.(G54 Y)
#4=5223.(G54 Z)
#5=5224.(G54 B)
#6=670.(Macro #)
#7=1.(Scan Sequence)
WHILE[#5LT5324]DO1
WHILE[[#[#2]GT[#[#6]+#1]]OR[#[#2]LT[#[#6]-#1]]]DO2(X)
GOTO#7
END2
G53
#7=#7+1.
#6=#6+1.
WHILE[[#[#3]GT[#[#6]+#1]]OR[#[#3]LT[#[#6]-#1]]]DO3(Y)
GOTO#7
END3
G53
#7=#7+1.
#6=#6+1.
WHILE[[#[#4]GT[#[#6]+#1]]OR[#[#4]LT[#[#6]-#1]]]DO2(Z)
GOTO#7
END2
G53
#7=#7+1.
#6=#6+1.
IF[[#[#5]GT[#[#6]+#1]]OR[#[#5]LT[#[#6]-#1]]]GOTO#7(B)
#2=#2+20.(G54 X)
#3=#3+20.(G54 Y)
#4=#4+20.(G54 Z)
#5=#5+20.(G54 B)
#6=#6+1.(Macro #)
#7=#7+1.(Scan Sequence)
END1
dandrummerman21
Stainless
- Joined
- Feb 5, 2008
- Location
- MI, USA
I'm wondering if this would be faster:
IF[ABS[ABS[#[#2]]-ABS[#[#6]]]GT#1]GOTO#7(X)
Double check i got the right number of brackets.
I'm not sure if doing a bunch of ABS[] would be faster, but I think it would, because this is doing ONLY ONE check. It isn't checking both the positive and the negative, it is only checking if the difference of the two values is greater than #1
I don't know off the top of my head, and i'm on the way out, but I believe you can have an if inside a while. replace your do2 loops with this if.
unless the parts of your program that you don't have posted (such as what your goto#7's actually go to) somehow don't permit this to work?
IF[ABS[ABS[#[#2]]-ABS[#[#6]]]GT#1]GOTO#7(X)
Double check i got the right number of brackets.
I'm not sure if doing a bunch of ABS[] would be faster, but I think it would, because this is doing ONLY ONE check. It isn't checking both the positive and the negative, it is only checking if the difference of the two values is greater than #1
I don't know off the top of my head, and i'm on the way out, but I believe you can have an if inside a while. replace your do2 loops with this if.
unless the parts of your program that you don't have posted (such as what your goto#7's actually go to) somehow don't permit this to work?
Thanks dandrummerman21. Took your method and modified it a little. It now processes in 8 seconds instead of 15. See below. The GOTO#7 statement takes you to the corrsponding N number where there is a #3000 alarm. For the out of tolerance offset. Checking for those fat fingers.
#1=.009(Tolerance)
(Start Scan Values)
#2=5221.(Work Offset Axis)
#6=670.(Macro #)
#7=1.(Scan Sequence)
#8=1.(Loop Counter)
WHILE[#2LT5324]DO1
WHILE[#8NE4]DO2
WHILE[ABS[ABS[#[#2]]-ABS[#[#6]]]GT#1]DO3
GOTO#7
END3
G53
#2=#2+1.(Work Offset Axis Change)
#7=#7+1.(Scan Sequence)
#6=#6+1.(Macro #)
#8=#8+1.(Loop Counter)
END2
#2=#2+17.(Work Offset Coordinate Change)
#6=#6+1.(Macro #)
#7=#7+1.(Scan Sequence)
#8=1.(Loop Counter)
END1
PROBE
Hot Rolled
- Joined
- Jan 23, 2003
- Location
- Tel Aviv, Israel
Even in not conservative standards, 2 weeks is way beyond “a timely manner”. As to the “incognito source” – don’t bother, I am not looking to contact him.
Let me ignore this impertinence.
Regretfully, you continue to give generalized opinions on content of any Fanuc manual. Just let me remind you the quote from your post from 12.05 2020:
Needless to say, the reference was given to you on the spot. And the information was adopted by you in quite hearty matter (see your paragraph 3). Small “sorry, you were right” would be nice, but of course not obligatory.
The “CAUTION” extract included in your previous posts indicates exactly the need of Buffer preventing block after G31 move block:
Specially, in case of reading/writing the system
variables to control signals, coordinates, offset
value, etc., it may different system variable data by
the timing of the NC statement execution. To avoid
this phenomenon, specify such M codes or G
codes before the macro statement, if necessary.
Unfortunately, the example given in this remark is poor and meaningless. As mentioned before, if they would use the N2 #100=#5061 instead of N2 #100=1. , everything would be clear. No NOTE, which with time became !CAUTION, would be needed. But they did not.
The operation of touch trigger probe is based on the fact that the data is collected “on the fly”. This is obvious. Once the trigger is executed, the 506* registers are refreshed with the new data. The problem is, which 506* data are used in the next macro statement. In order to prevent the use of old (before the trigger being executed) data, the G53 block is needed.
Unfortunately, in none of these examples the data of collected in 506* registers was use in macro sequence following the G31 move, therefore they are meaningless to the matter of this discussion.
Stefan
Cogito Ergo Sum
Last edited:
PROBE
Hot Rolled
- Joined
- Jan 23, 2003
- Location
- Tel Aviv, Israel
Duplicated,
sorry for that.
Stefan,
cogito ergo sum
sorry for that.
Stefan,
cogito ergo sum
Micro Buffering
While writing the program below, I found that if I didn't add a G53 buffering command, I would get un-expected errors in the processing of the statement. But I did not want to add the G53 because it caused the program to take longer to process. So I decided to add a NC statement, just a random N number in the statement and it eliminated the processing error. Does this N number act as a micro buffering statement. Anyone else find this to be true. I am programming on Fanuc simulation software, so maybe it's just a glitch to the software.
N400
(Start Values)
#31=1.(Tool Number)
#32=#1(Tolerance)
#33=#101(Nominal)
WHILE[#31LE30]DO1
WHILE[[#[2200+#31]GT[#33+#32]]OR[#[2200+#31]LT[#33-#32]]AND[#[2200+#31]NE0]]DO2
IF[#33EQ0]GOTO[#31+300]
GOTO[#31+200]
END2
N44444
#31=#31+1.
#32=#[#1+1]
#33=#[100+#31]
END1
While writing the program below, I found that if I didn't add a G53 buffering command, I would get un-expected errors in the processing of the statement. But I did not want to add the G53 because it caused the program to take longer to process. So I decided to add a NC statement, just a random N number in the statement and it eliminated the processing error. Does this N number act as a micro buffering statement. Anyone else find this to be true. I am programming on Fanuc simulation software, so maybe it's just a glitch to the software.
N400
(Start Values)
#31=1.(Tool Number)
#32=#1(Tolerance)
#33=#101(Nominal)
WHILE[#31LE30]DO1
WHILE[[#[2200+#31]GT[#33+#32]]OR[#[2200+#31]LT[#33-#32]]AND[#[2200+#31]NE0]]DO2
IF[#33EQ0]GOTO[#31+300]
GOTO[#31+200]
END2
N44444
#31=#31+1.
#32=#[#1+1]
#33=#[100+#31]
END1
dandrummerman21
Stainless
- Joined
- Feb 5, 2008
- Location
- MI, USA
If your control was looking several (or hundreds of) blocks ahead, instead of just one or two, G53 would accomplish what you need while another empty block will not.
And, the other way would be to insert hundred empty blocks (assuming hundred look-ahead feature) to prevent buffering
BluishInventor
Aluminum
- Joined
- Jul 7, 2020
Hey all,
Anyone ever use this Fanuc Macro B linter? Macro Executor Language - Visual Studio Marketplace
Maybe know of a better one?
Thanks,
--B
Anyone ever use this Fanuc Macro B linter? Macro Executor Language - Visual Studio Marketplace
Maybe know of a better one?
Thanks,
--B
Shawaiz Liaqat
Plastic
- Joined
- May 16, 2022
hello i need help to change the language Mori Seiki accumill 40000(MSG-805)
French to English
thank you in Advance
French to English
thank you in Advance
Similar threads
