What's new
What's new

Macro Programming Fundamentals

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:

Buffering1.jpg

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:
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:

View attachment 346815

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

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
 
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

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
 
There is no nesting limitation in your program. You have used only two levels of nesting.
Inside a WHILE_DO loop, you can have unlimited number of independent WHILE_DO loops.
 
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?
 
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?

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
 
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.
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.

1. Thus far the only evidence you have provided has been anecdotal.
Let me ignore this impertinence.

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.
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:
The following is a direct extract from a Fanuc Manual.
blocks containing M codes for which buffering is suppressed by setting
parameters No.3411 to No.3420, and blocks containing G31 are not preread.

It can't be much clearer than that.
Find me any such reference in any Fanuc Manual for G53, or any manual of controls that use G53, for that matter. You won't, as there is none.
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.

4. It also states in Fanuc Manuals that #506_ System Variables can be read during movement.
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.

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.
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:
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
 
I thought that was only used for single block. Not as a processing stop. What's the point of G53 then.

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.
 
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 :)
 
If the control is Fanuc Model C, set 3102#2 = 0
If it is Model D, set 3281 = 0 or any number except in the range 1-19 (Byte-type parameter)
 








 
Back
Top