Largest Manufacturing Technology Community on the Web
Stay Connected:
Macro Programming Fundamentals
- Thread starter Tonytn36
- Start date
- Replies 1,013
- Views 619,741
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
Shawaiz Liaqat
Plastic
- Joined
- May 16, 2022
control is MSG-805
Shawaiz Liaqat
Plastic
- Joined
- May 16, 2022
control MSG-805
Mori Seiki4000
how to find 3281=0 or 3102#=0 because french language
will you please explain step by step
Mori Seiki4000
how to find 3281=0 or 3102#=0 because french language
will you please explain step by step
angelw
Diamond
- Joined
- Sep 10, 2010
- Location
- Victoria Australia
angelw Wrote:
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.
Stefan’s Reply
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.
angelw reply
Not surprising. When I asked for an official response, I was told that it’s not Fanuc’s policy to answer programming questions and will refer you to the Machine Tool Builder. My contact, where I got my previous statement was on a colleague to colleague basis.
In recent weeks I've contacted the Victorian manager of Renishaw and had a long and unambiguous conversation with him regarding the use of G31; his name is Mike Davies. He confirmed that their practice is to NOT follow a G31 Block with G53.
angelw Wrote:
Thus far the only evidence you have provided has been anecdotal.
Stefan’s Reply
Let me ignore this impertinence.
angelw reply:
You can ignore it all you like, but it doesn’t change the fact that you haven’t offered any example programs and the resulting error you claim, only anecdotes.
Stefan Wrote:
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.
angelw reply
All Fanuc Manuals have the following tables, Copied and Pasted from a Fanuc Manual::
Stefan Wrote:
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.
angelw reply:
The G53 block is NOT needed.
blocks containing M codes for which buffering is suppressed by setting
parameters No.3411 to No.3420, and blocks containing G31 are not preread
What the above means, is that these codes halt buffering. G31 specified on its own, like G53, halts buffering. G31 with arguments halts buffering, is NOT pre-read and therefore, following it with G53 is superfluous.
angelw Wrote:
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.
Stefan Reply
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.
angelw reply:
Not so. Its a known fact that G31specified on it's own with no coordinate addresses, can and is used to halt Buffering, that's well documented in Fanuc Manuals. What I was demonstrating was that G31 executed with coordinate addresses, as when used in its design application, performed in exactly the same manner to halt Buffering. But to satisfy you, here you go then, an example program made and tested today reading System Variable #5063.
The pictures I took with the phone of the program screen were rubbish. Accordingly, the following is the listing of the program. I'll take pictures tomorrow with a better camera and update this Post.
%
O0005
(G31 - G53 BUFFER HALT TEST)
N1 G00 G17 G21 G40 G49 G80 G94
G91 G28 Z0.0
G28 X0.0 Y0.0
T11 M06
G90 G00 G55 X0.0 Y0.0
G43 Z140.000 H11
G91 G31 Z-50.000 F1000
/G53
G65 H01 P#104 Q#5063
/G65 H01 P#105 Q#5063
M00
G91 G00 Z10.000
G28 Z0.0
G28 X0.0 Y0.0
M30
%
The picture following shows the result of executing the above program with Block Delete on, so that G53 and the Macro Statement writing to Common Variable #105 are ignored.
and the result of writing the content of System Variable #5063 into Common Variable #104.
The picture following shows the result of executing the above program with Block Delete off, so that G53 and the Macro Statement writing to Common Variable #105 are executed.
The result? As can be seen, the value read from System Variable #5063 and written to Common Variables #104 and #105 are the same precisely.
The use of G53 following G31 is tantamount to including G01 in consecutive Linear Interpolation Blocks; it does no harm, but its not necessary and it makes no difference to the performance of the program.
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.
Stefan’s Reply
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.
angelw reply
Not surprising. When I asked for an official response, I was told that it’s not Fanuc’s policy to answer programming questions and will refer you to the Machine Tool Builder. My contact, where I got my previous statement was on a colleague to colleague basis.
In recent weeks I've contacted the Victorian manager of Renishaw and had a long and unambiguous conversation with him regarding the use of G31; his name is Mike Davies. He confirmed that their practice is to NOT follow a G31 Block with G53.
angelw Wrote:
Thus far the only evidence you have provided has been anecdotal.
Stefan’s Reply
Let me ignore this impertinence.
angelw reply:
You can ignore it all you like, but it doesn’t change the fact that you haven’t offered any example programs and the resulting error you claim, only anecdotes.
Stefan Wrote:
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.
angelw reply
All Fanuc Manuals have the following tables, Copied and Pasted from a Fanuc Manual::
Stefan Wrote:
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.
angelw reply:
The G53 block is NOT needed.
blocks containing M codes for which buffering is suppressed by setting
parameters No.3411 to No.3420, and blocks containing G31 are not preread
What the above means, is that these codes halt buffering. G31 specified on its own, like G53, halts buffering. G31 with arguments halts buffering, is NOT pre-read and therefore, following it with G53 is superfluous.
angelw Wrote:
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.
Stefan Reply
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.
angelw reply:
Not so. Its a known fact that G31specified on it's own with no coordinate addresses, can and is used to halt Buffering, that's well documented in Fanuc Manuals. What I was demonstrating was that G31 executed with coordinate addresses, as when used in its design application, performed in exactly the same manner to halt Buffering. But to satisfy you, here you go then, an example program made and tested today reading System Variable #5063.
The pictures I took with the phone of the program screen were rubbish. Accordingly, the following is the listing of the program. I'll take pictures tomorrow with a better camera and update this Post.
%
O0005
(G31 - G53 BUFFER HALT TEST)
N1 G00 G17 G21 G40 G49 G80 G94
G91 G28 Z0.0
G28 X0.0 Y0.0
T11 M06
G90 G00 G55 X0.0 Y0.0
G43 Z140.000 H11
G91 G31 Z-50.000 F1000
/G53
G65 H01 P#104 Q#5063
/G65 H01 P#105 Q#5063
M00
G91 G00 Z10.000
G28 Z0.0
G28 X0.0 Y0.0
M30
%
The picture following shows the result of executing the above program with Block Delete on, so that G53 and the Macro Statement writing to Common Variable #105 are ignored.
and the result of writing the content of System Variable #5063 into Common Variable #104.
The picture following shows the result of executing the above program with Block Delete off, so that G53 and the Macro Statement writing to Common Variable #105 are executed.
The result? As can be seen, the value read from System Variable #5063 and written to Common Variables #104 and #105 are the same precisely.
The use of G53 following G31 is tantamount to including G01 in consecutive Linear Interpolation Blocks; it does no harm, but its not necessary and it makes no difference to the performance of the program.
Last edited:
angelw
Diamond
- Joined
- Sep 10, 2010
- Location
- Victoria Australia
The short answer is no. The User Macro is not multi-tasking, as is what you would want, a program running in the background polling for changes in the Z position within one Block movement.
However, when one program is being executed, another program can be called by
inputting an interrupt signal from the machine. This is what you would have to do if monitoring and dealing with either axis, or spindle load being outside a set, upper limit.
Regards,
Bill
dandrummerman21
Stainless
- Joined
- Feb 5, 2008
- Location
- MI, USA
I have a question regarding ASIN
I have a casting that I've ran before on a 18m control, where I have G54 set to the center of a hole (hole doesnt exist yet), and there's a second hole that I need to tap in the middle of an ear.
G54 doesn't change, but the location of the ear changes (castings vary) so I probe it using renishaw macro 9812. After probing, I set the following variables:
#566=#136 (Y LOCATION OF EAR)
#567=ASIN[#566/1.35]
... and use G68 in my program for drilling the hole.
That ran fine in an 18MB control.
Now I've got the same program running on a 0mc control, and after running a couple parts, it is clear the angle isn't calculating correctly.
The last part had #566=.0441 and it calculated the angle #567=.0326667
But it should be about 1.872. Curiously, the angle it calculated seems to be correct, IN RADIANS, not degrees.
But even more curiously, The Smid macro book says this:
ASIN and ACOS functions are not available on 0/16/18/21 model controls !
I don't see limitations mentioned in Sinha's macro book. And the control generates no alarm when trying to use ASIN.
Now, can I (should I) just convert the values it's giving me to degrees? I haven't wandered back to the control to see if it is consistantly giving radians for different amounts. Or should I calculate the angle differently using ATAN (which I know works because I've used it for different situations on a 0m control.) Also, the difference between ASIN and ATAN should be very small since I don't expect the angle to exceed 2 or 3 degrees in the worst case scenario and it looks like the error would be very small (on the order of .02 degrees or less)
Another note, I find it odd that my 18 control worked flawlessly even though the note says it doesn't work on an 18 either...
Insight would be appreciated.
Edit: I also just learned that ATAN needs to be written as ATAN[#566]/[1.35]. Also, ATAN works perfectly and that's actually more mathematically correct for how I'm locating the probe for checking location. So this is what I'm going with.
I have a casting that I've ran before on a 18m control, where I have G54 set to the center of a hole (hole doesnt exist yet), and there's a second hole that I need to tap in the middle of an ear.
G54 doesn't change, but the location of the ear changes (castings vary) so I probe it using renishaw macro 9812. After probing, I set the following variables:
#566=#136 (Y LOCATION OF EAR)
#567=ASIN[#566/1.35]
... and use G68 in my program for drilling the hole.
That ran fine in an 18MB control.
Now I've got the same program running on a 0mc control, and after running a couple parts, it is clear the angle isn't calculating correctly.
The last part had #566=.0441 and it calculated the angle #567=.0326667
But it should be about 1.872. Curiously, the angle it calculated seems to be correct, IN RADIANS, not degrees.
But even more curiously, The Smid macro book says this:
ASIN and ACOS functions are not available on 0/16/18/21 model controls !
I don't see limitations mentioned in Sinha's macro book. And the control generates no alarm when trying to use ASIN.
Now, can I (should I) just convert the values it's giving me to degrees? I haven't wandered back to the control to see if it is consistantly giving radians for different amounts. Or should I calculate the angle differently using ATAN (which I know works because I've used it for different situations on a 0m control.) Also, the difference between ASIN and ATAN should be very small since I don't expect the angle to exceed 2 or 3 degrees in the worst case scenario and it looks like the error would be very small (on the order of .02 degrees or less)
Another note, I find it odd that my 18 control worked flawlessly even though the note says it doesn't work on an 18 either...
Insight would be appreciated.
Edit: I also just learned that ATAN needs to be written as ATAN[#566]/[1.35]. Also, ATAN works perfectly and that's actually more mathematically correct for how I'm locating the probe for checking location. So this is what I'm going with.
Last edited:
Smid's book is not for i-series controls. Therefore, there can be some differences in descriptions if you are working on an i-series.
I had tested these functions on an i-series control. Everything was in degrees. Maybe, on older controls, radian is being used. However, I find it odd that ASIN outputs radian and ATAN outputs degree. Both should be same.
Since -x/y is mathematically same as x/-y, and x/y is same as -x/-y, ASIN and ACOS may not output the correct angle in all cases. These are mainly useful if the angle is expected to lie in the first quadrant (0 to 90 degree). Therefore, it is always better to use ATAN which always outputs the correct angle, in all four quadrants. It has the format ATAN[Perpendicular]/[Base]
I had tested these functions on an i-series control. Everything was in degrees. Maybe, on older controls, radian is being used. However, I find it odd that ASIN outputs radian and ATAN outputs degree. Both should be same.
Since -x/y is mathematically same as x/-y, and x/y is same as -x/-y, ASIN and ACOS may not output the correct angle in all cases. These are mainly useful if the angle is expected to lie in the first quadrant (0 to 90 degree). Therefore, it is always better to use ATAN which always outputs the correct angle, in all four quadrants. It has the format ATAN[Perpendicular]/[Base]
dandrummerman21
Stainless
- Joined
- Feb 5, 2008
- Location
- MI, USA
It is not an i series control, it is a 0m.
And yeah, when I wrote the program a couple years ago, I got my soh cah toa mixed up. 1.35 isn't the hypotenuse, it's the adjacent (base), and the probed value is the opposite (perpindicular), so ATAN is what I should have used from the getgo.
Also, the 0m control doesn't seem to be actually giving ASIN values in radians. It's actually a coincidence that the values it calculated are so close to the radian values.
I just had the 0m control evaluate ASIN[1] which should be pi/2 or ~1.57 in radians, but it simply evaluates it as 1. Pretty dumb that the machine can evaluate ASIN without generating an alarm, while generating a wrong value!
And yeah, when I wrote the program a couple years ago, I got my soh cah toa mixed up. 1.35 isn't the hypotenuse, it's the adjacent (base), and the probed value is the opposite (perpindicular), so ATAN is what I should have used from the getgo.
Also, the 0m control doesn't seem to be actually giving ASIN values in radians. It's actually a coincidence that the values it calculated are so close to the radian values.
I just had the 0m control evaluate ASIN[1] which should be pi/2 or ~1.57 in radians, but it simply evaluates it as 1. Pretty dumb that the machine can evaluate ASIN without generating an alarm, while generating a wrong value!
thesidetalker
Hot Rolled
- Joined
- Jan 11, 2015
- Location
- Bay Area, CA
On Fanuc 30i, is there a way to read diagnostic data into macro variables? Similar to PRM[] for parameters?
angelw
Diamond
- Joined
- Sep 10, 2010
- Location
- Victoria Australia
angelw
Diamond
- Joined
- Sep 10, 2010
- Location
- Victoria Australia
Yes. The method of being able to call a Local Subprogram with the "Q" address was introduced with the FS16i control. If the control has the Local Subprogram function, it will also have the facility to call an External Subprogram and specify a Sequence Number to start from within the Subprogram with the syntax shown in your example.
Regards,
Bill
Thanks Bill
Also found that system parameter #6005 bit#0(SQC) must be set to a 1.
Bill explained this 10 years back.
(Post # 10)
Haas local subroutines
I've used subroutines that are called by an M98P code on both Fanuc and Haas controls. Reading the manual, Haas makes mention of a "local" sub called by an M97 code. However, the manual has no example of how this (M97) is used. Can someone post a simple example of the format that is used for the...
www.practicalmachinist.com
angelw
Diamond
- Joined
- Sep 10, 2010
- Location
- Victoria Australia
Just my luck. I don't live in Pakistan, otherwise I would get ten. Without bad luck, I'd have no luck at all.
Similar threads
