Macro Programming Fundamentals - Page 29
Close
Login to Your Account
Page 29 of 39 FirstFirst ... 192728293031 ... LastLast
Results 561 to 580 of 766
  1. #561
    Join Date
    Sep 2010
    Location
    Victoria Australia
    Posts
    3,727
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    1469

    Default

    Quote Originally Posted by rbmgf7 View Post
    #1=8.66 (Z START HEIGHT)
    #2=0.040 (Z DOC)
    #3=6 (Z FINAL HEIGHT)

    N10 (ROUGHING PASS)
    WHILE [#1 GT #3] DO1
    G0Y16
    Z[#1]
    G1Y12.7F300.
    Y1
    Z[#1+.02] (RETRACT)
    #1=#1-#2
    IF [#1 LT #3] GOTO 15
    END1
    Hello rbmgf7,
    Your example is the basic structure I've Posted many times on this Forum; you may even find examples of it in this Macro Fundamental Thread.

    Although its quite legal to use a Conditional Statement to exit a Do Loop, my concept of the same theme is as follows:

    #1 = 0.0 (Z START COORDINATE)
    #2 = -3.0 (Z DOC)
    #3 = -11.0 (Z FINAL DEPTH)

    WHILE [#1 GT #3] DO1
    #1=#1+#2
    IF[#1 LT #3]TH #1=#3 (PREVENT OVER-CUTTING IN Z)
    -------------
    -------------
    -------------
    Machining Code Goes Here
    -------------
    -------------
    -------------
    END1

    Another method is

    #1 = 0.0 (Z START COORDINATE)
    #2 = -3.0 (Z DOC)
    #3 = -11.0 (Z FINAL DEPTH)

    N10
    #1=#1+#2
    IF[#1 LT #3]TH #1=#3 (PREVENT OVER-CUTTING IN Z)
    -------------
    -------------
    -------------
    Machining Code Goes Here
    -------------
    -------------
    -------------
    IF[#1 GT #3] GOTO10

    In a very lengthy program, the method using the WHILE function will be prove to be slightly quicker over all.

    Both methods will result in the correct Final Z being made, irrespective of whether the Final Z is evenly divisible by the DOC. An additional variable can be added to leave a Finish Allowance in Z.


    Regards,

    Bill

  2. #562
    Join Date
    Nov 2018
    Country
    INDIA
    Posts
    1
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    0

    Default

    Hello everyone specially mr.tony . I appreciate the good work you have done .and finally i found a place where i can learn a lot of things . I am a machinist and wanted to learn about macros . My superior has generated a program and generated his own cycles using macros and i am not able to understand the program properly . We operate on siemens control so would you please help me with that .would you please tell me the basics of macros we can use in siemens. Plz do reply .

    Regards
    Sumit singh

  3. #563
    Join Date
    Sep 2010
    Location
    Victoria Australia
    Posts
    3,727
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    1469

    Default

    Quote Originally Posted by Ss427890 View Post
    Hello everyone specially mr.tony . I appreciate the good work you have done .and finally i found a place where i can learn a lot of things . I am a machinist and wanted to learn about macros . My superior has generated a program and generated his own cycles using macros and i am not able to understand the program properly . We operate on siemens control so would you please help me with that .would you please tell me the basics of macros we can use in siemens. Plz do reply .

    Regards
    Sumit singh
    Hello Sumit singh,
    This Thread is more Focused on the Macro Language used by Fanuc, Mitsubishi, Haas and some other controls. The Siemens' Macro Language is more comprehensive than the Macro Executable used by the aforementioned controls. The Macro Language used by these controls has a syntax quite similar to that of BASIC, but the Siemens' control takes it another few steps closer to mimic High Level languages such as BASIC (in particular) "C" and so on. Accordingly, the basics that apply to the Macro Language used by Facnuc/Haas and others, doesn't directly apply to the Siemens' Language.

    If you were able to ask specific questions regarding the use of the Siemens' Macros, then I, or other Forum members will be able to help you out. However, you will come to grips with the Siemens' Macro Language quicker, by arming yourself with the Siemens' Macro Programming Manual, dissecting line by line, an existing Macro Program that you have on your machine and compare any Macro Statement you encounter with the appropriate section in the Programming Manual.

    Regards,

    Bill

  4. #564
    Join Date
    Dec 2007
    Location
    Southeastern US
    Posts
    6,401
    Post Thanks / Like
    Likes (Given)
    845
    Likes (Received)
    2806

    Default

    Quote Originally Posted by angelw View Post
    Hello Sumit singh,
    This Thread is more Focused on the Macro Language used by Fanuc, Mitsubishi, Haas and some other controls. The Siemens' Macro Language is more comprehensive than the Macro Executable used by the aforementioned controls. The Macro Language used by these controls has a syntax quite similar to that of BASIC, but the Siemens' control takes it another few steps closer to mimic High Level languages such as BASIC (in particular) "C" and so on. Accordingly, the basics that apply to the Macro Language used by Facnuc/Haas and others, doesn't directly apply to the Siemens' Language.

    If you were able to ask specific questions regarding the use of the Siemens' Macros, then I, or other Forum members will be able to help you out. However, you will come to grips with the Siemens' Macro Language quicker, by arming yourself with the Siemens' Macro Programming Manual, dissecting line by line, an existing Macro Program that you have on your machine and compare any Macro Statement you encounter with the appropriate section in the Programming Manual.

    Regards,

    Bill
    Agree with Bill on this, but would like to state that the fundamentals of how things are programmed isn't much different. The difference is in the syntax of how it's actually written, not in the process of "how to do it". There won't be much of a difference in the way you lay out your program, except to take advantage of additional functionality that is available in the Siemens control.

  5. #565
    Join Date
    Sep 2010
    Location
    Victoria Australia
    Posts
    3,727
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    1469

    Default

    Quote Originally Posted by Tonytn36 View Post
    Agree with Bill on this, but would like to state that the fundamentals of how things are programmed isn't much different. The difference is in the syntax of how it's actually written, not in the process of "how to do it". There won't be much of a difference in the way you lay out your program, except to take advantage of additional functionality that is available in the Siemens control.
    Hello Sumit singh,
    Tony is quite correct and unfortunately, none of the Machine Programming Manuals focus much on the structure of a Macro Program, but more on showing the syntax of and explaining the use of various features.

    The main tool in designing a Software Application is a Flowchart. The symbols used are universal across all languages and they allow the planning of (as the name implies) the Flow of the program.

    There exists some High Level Software Programming applications that allow Programs to be created by constructing Flowcharts using Graphic Symbols (such as those shown in the following Flowcharts) whilst in the background, the typical Text Syntax is being created.

    Following are two very simple Flowcharts

    basic-flow-chart1.jpg

    Example 7. shows the use of a conditional statement to determine if a branch to another parts of the program should occur based on the value of N.

    In conjunction with your Siemens' Programming Manual, getting hold of an Introduction to BASIC Language Programming will be helpful to you. Invariably, Flowcharts will be covered as well as good programming structure. All such skills are directly transferable to all the Machine Tool Macro Programming Languages. In fact, when writing Macro Programs for any of the Machine Control Macro Languages, I do so using a Visual Basic Compiler and convert the finished program after debugging, to the appropriate Macro Language Syntax.

    Regard,

    Bill

  6. #566
    Join Date
    Dec 2018
    Country
    UNITED KINGDOM
    Posts
    3
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    2

    Default

    Good day to you all guys! New to the forum, very cool place and very helpful indeed. I actually found it when searching for examples of thread miling with live tooling on the lathe and seen a thread in the general section, only just seen this macro bit. Macro programming changed me from being an ordinary operator in to a super confident operator and programmer, it almost helps you to think in terms of how the machine would go about an operation. For me it made machining so easy, I can’t understand how it is not taught anywhere in depth, I am sure most of you learned how to go about it yourself too? Seems crazy to me, I always show the guys how to go about it in my work now, especially apprentices. Anyway this thread is great and hats off to you all for learning and sharing! I’ll share a link to a video so you can see an example of a macro I made for thread milling a bolt circle on a lathe with no Y axis. It makes the program short and simple and has been working great. If anyone wants to know anything let me know. Russ

    Russell Hunter on LinkedIn: "No Y axis? No problem! An example of a Macro program that I made to help take some of the strain off of the horizontal borers. Drilling and hobbing a PCD using the Z X and C axis on one of our lathes. When capacity on the borers is an issue you have to work around it. This way we get to add to the skill set of the guys in the shop and we also keep our customers happy. The video isn't the most exciting thing in the world but the end result is, for a CNC geek like me anyway #Macro #CNC"

  7. #567
    Join Date
    Jun 2013
    Location
    Muskegon
    Posts
    88
    Post Thanks / Like
    Likes (Given)
    17
    Likes (Received)
    13

    Default

    Today as I was trying to figure out how to not let a calculation equal out to infinity which pisses off Fanuc controls, I ran across ADP[#} in the manual. What is this and how is it useful?

  8. #568
    Join Date
    Sep 2010
    Location
    Victoria Australia
    Posts
    3,727
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    1469

    Default

    Quote Originally Posted by tteitgen View Post
    Today as I was trying to figure out how to not let a calculation equal out to infinity which pisses off Fanuc controls, I ran across ADP[#} in the manual. What is this and how is it useful?
    Hello tteitgen,
    This function will be of no help with your problem.

    The ADP function is to add a decimal point to an argument passed (variables #1 to #33) with no decimal point to a Macro Program.

    Example:
    In the Macro Program called with G65 P_X10;, the value of ADP[#24] is a value to which a decimal point is added at its end (that is, 10.). Use this function when you do not want to consider the increment system in the Macro Program. When bit 4 (CVA) of parameter No. 6007 is set to 1, however, the ADP function cannot be used because 10 passed as an argument is converted to 0.01(Metric System) the moment it is passed.

    Regards,

    Bill

  9. #569
    Join Date
    Sep 2010
    Location
    india
    Posts
    1,262
    Post Thanks / Like
    Likes (Given)
    73
    Likes (Received)
    229

    Default

    ADP is a new function, not available up to Model C.
    It could be useful on machines which treat, for example, X10 and X10.0 differently.
    Other than this, I do not see its any use.

  10. #570
    Join Date
    Jun 2013
    Location
    Muskegon
    Posts
    88
    Post Thanks / Like
    Likes (Given)
    17
    Likes (Received)
    13

    Default

    Thanks guys. Figured it was pretty useless. Would be nice if you could control the decimal output like you can with DPRNT.

  11. #571
    Join Date
    Sep 2010
    Location
    india
    Posts
    1,262
    Post Thanks / Like
    Likes (Given)
    73
    Likes (Received)
    229

    Default

    There is no integer number in Fanuc. All are real numbers.
    For example #1.0 is same as #1
    In fact, automatic rounding is also done in some cases.
    I have verified that #0.4 is same as #0, and #0.5 is same as #1
    Ridiculous!

  12. Likes TeachMePlease liked this post
  13. #572
    Join Date
    Feb 2019
    Country
    UNITED STATES
    State/Province
    Alabama
    Posts
    42
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    5

    Default

    These variables are local to the program. Normally used to transfer values to a cycle call, or as intermediate mathematical value holders. I hate using local variables because of one major issue with them. They are reset to null (not 0) when the control is reset or the program ends. While perfectly fine for use in transferring variables to canned cycles, etc. They can get you in trouble if you use them for other things. I, just by policy, never use them for anything. In Fanucese, these are typically #100-#499 (if you have that many available). Local variables are only available to the program in which they are used.

  14. #573
    Join Date
    Sep 2010
    Location
    india
    Posts
    1,262
    Post Thanks / Like
    Likes (Given)
    73
    Likes (Received)
    229

    Default

    Although not recommended (in the interest of a safe programming
    practice, as most of the people believe that the local variables
    and the common variables in a new program start with null values),
    the following parameter setting would retain the values stored in
    local and common variables, even after system reset (though power
    OFF will still clear them):
    Parameter 6001#6 = 1 (Retains common variables even after system
    reset)
    Parameter 6001#7 = 1 (Retains local variables even after system
    reset)
    The default setting for these parameter bits is 0, which clears the
    stored values, if any, whenever the system is reset.

  15. #574
    Join Date
    Sep 2010
    Location
    india
    Posts
    1,262
    Post Thanks / Like
    Likes (Given)
    73
    Likes (Received)
    229

    Default

    Except for EQ and NE, a null variable is equivalent to arithmetic zero.

  16. #575
    Join Date
    Sep 2010
    Location
    Victoria Australia
    Posts
    3,727
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    1469

    Default

    Quote Originally Posted by stargrit View Post
    These variables are local to the program. Normally used to transfer values to a cycle call, or as intermediate mathematical value holders. I hate using local variables because of one major issue with them. They are reset to null (not 0) when the control is reset or the program ends. While perfectly fine for use in transferring variables to canned cycles, etc. They can get you in trouble if you use them for other things. I, just by policy, never use them for anything. In Fanucese, these are typically #100-#499 (if you have that many available). Local variables are only available to the program in which they are used.
    Hello stargrit,
    Using Global scoped variables where its unnecessary is poor practice in any programming language. Most who program in that way tend to not use structured routines, but one big Spaghetti Code main.

    Variables #100-#499 are not Local Variable, but Common (Global in scope), Volatile Variables. A well structured program uses the fact that Local (Local in scoped) variables are available in the program in which they are used, to its advantage.

    Good programming practice is to initialize variables for every use of the application. If a value needs to be kept from one use to the next, these values can be stored in whatever Common, Nonvolatile variables that are available, or Offsets that are unlikely to be used elsewhere, if there are no Series #500 variables available.

    Regards,

    Bill

  17. #576
    Join Date
    Feb 2014
    Location
    Sunny South West Florida, USA
    Posts
    2,898
    Post Thanks / Like
    Likes (Given)
    10716
    Likes (Received)
    3292

    Default

    Quote Originally Posted by angelw View Post
    Hello stargrit,
    Using Global scoped variables where its unnecessary is poor practice in any programming language. Most who program in that way tend to not use structured routines, but one big Spaghetti Code main.

    Variables #100-#499 are not Local Variable, but Common (Global in scope), Volatile Variables. A well structured program uses the fact that Local (Local in scoped) variables are available in the program in which they are used, to its advantage.

    Good programming practice is to initialize variables for every use of the application. If a value needs to be kept from one use to the next, these values can be stored in whatever Common, Nonvolatile variables that are available, or Offsets that are unlikely to be used elsewhere, if there are no Series #500 variables available.

    Regards,

    Bill
    Bill.. He's a spammer... He just copy/pastes other peoples' responses from earlier in threads, to drive his post count up, and then occasionally puts in SEO data for his foundry in India. I've reported him 4 or 5 times and still have not managed to get him banned.

  18. #577
    Join Date
    Apr 2010
    Country
    UNITED STATES
    State/Province
    Wisconsin
    Posts
    6,108
    Post Thanks / Like
    Likes (Given)
    4195
    Likes (Received)
    3761

    Default

    Quote Originally Posted by Tonytn36 View Post
    I needed to profile an aluminum bracket. Since I wasn't holding it very well, I wanted to go in 1 mm depth increments. Rather than program the profile 12 times, or call a sub 12 times, I did a simple little increment counter and check. See below:

    (OUTSIDE)
    G0 G90 G40 G80 G17 G64 ( SET DEFAULTS )
    M08
    #750=-1.0 (INITIAL DEPTH)
    G100 G56 T12 G43 H12 D12 X-85. Y50.0 Z0. S10000 M03 A0.B0.
    N25 G0 Z#750
    G1 G41 X-66. Y31.5 F3200 (START PROFILE)
    G1 X34.25 Y31.5
    G2 X34.25 Y-31.5 I0. J-31.5
    G1 X-66.Y-31.5
    G1 X-66. Y-16.5
    G1 X-41. Y-16.5
    G1 X-41. Y16.5
    G1 X-66. Y16.5
    G1 X-66. Y40.
    G1 G40 X-85. Y50. (END PROFILE MOVE OFF PART)
    N500 IF [#750 EQ -12.0] GOTO 900 (CHECK FOR FINISH DEPTH)
    #750=#750-1.0 (DECREMENT DEPTH)
    GOTO 25 (LOOP PROFILE)
    N900 G0 Z60. (CLEAR Z)
    M09
    M30
    Bit of a reach back, but have a situation that this applies to very well, and I am not understanding some of what you wrote. ( that is completely my own lacking ) Thus, this post in effort to learn. Somehow, I am not seeing the logic that compares and controls the depths each time.

    Basically, I have a total depth described as #607 ( a calculation was performed to achieve said depth, hence it's being a 6XX value ) and a total number of cutting depths desired to achieve that depth, described as #505. ( a user input value )

    I want to write a macro that will be called by the main macro or program that will then run a path described, at the value that is returned by #607/#505 until it reaches that final depth, and then returns these to the calling program/macro. Clear as mud?


    Thanks.

  19. #578
    Join Date
    Sep 2010
    Location
    Victoria Australia
    Posts
    3,727
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    1469

    Default

    Quote Originally Posted by Zahnrad Kopf View Post
    Bit of a reach back, but have a situation that this applies to very well, and I am not understanding some of what you wrote. ( that is completely my own lacking ) Thus, this post in effort to learn. Somehow, I am not seeing the logic that compares and controls the depths each time.

    Basically, I have a total depth described as #607 ( a calculation was performed to achieve said depth, hence it's being a 6XX value ) and a total number of cutting depths desired to achieve that depth, described as #505. ( a user input value )

    I want to write a macro that will be called by the main macro or program that will then run a path described, at the value that is returned by #607/#505 until it reaches that final depth, and then returns these to the calling program/macro. Clear as mud?


    Thanks.
    Here is another version using Tony's profile. The advantage is that the DOC doesn't have to be evenly divisible into the Full Depth. The IF[#1 LT #3]TH #1=#3 Block will ensure that there is no over cutting in Z irrespective of the DOC used.

    #1 = 0.0 (Z START COORDINATE)
    #2 = -1.0 (Z DOC)
    #3 = -12.0 (Z FINAL DEPTH)
    G100 G56 T12 G43 H12 D12 X-85. Y50.0 Z0. S10000 M03 A0.B0.
    WHILE [#1 GT #3] DO1
    #1=#1+#2
    IF[#1 LT #3]TH #1=#3 (PREVENT OVER-CUTTING IN Z)
    G0 Z#1
    G1 G41 X-66. Y31.5 F3200 (START PROFILE)
    G1 X34.25 Y31.5
    G2 X34.25 Y-31.5 I0. J-31.5
    G1 X-66.Y-31.5
    G1 X-66. Y-16.5
    G1 X-41. Y-16.5
    G1 X-41. Y16.5
    G1 X-66. Y16.5
    G1 X-66. Y40.
    G1 G40 X-85. Y50. (END PROFILE MOVE OFF PART)
    END1
    G0 Z60. (CLEAR Z)

    If you wanted to have the profile in a Macro, the Z Start, Z DOC and Z Full Depth could be passed as arguments to the Macro. However, unless the Tool Path is one that you will use often, with varying Full Depth and DOC, or one where numerous tools will follow the same path, then there is little sense in creating it as a separate Macro Program.

    Regards,

    Bill

  20. #579
    Join Date
    Apr 2010
    Country
    UNITED STATES
    State/Province
    Wisconsin
    Posts
    6,108
    Post Thanks / Like
    Likes (Given)
    4195
    Likes (Received)
    3761

    Default

    Thanks for weighing in Bill. I discovered your take on it late yesterday when you answered someone about a face milling routine.

    This is always going to be for one, single tool. This particular one is for a keyway mill to open up a slot ( along X axis ), both in depths of cut, as well as vertically, up and down. My intent is to have the macro calculate the depths of cut only, and return those values to the calling program to be used in conjunction with the Y distances and Z heights. Both those, being variables themselves.

    Knowing that, would you still do this the same way?

    Thank you very much.

    EDIT - Or, would it be better to have this macro call those moves and their values FROM the calling program and iterate them here, in this macro? ( more like you have illustrated )

  21. #580
    Join Date
    Sep 2010
    Location
    Victoria Australia
    Posts
    3,727
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    1469

    Default

    Quote Originally Posted by Zahnrad Kopf View Post
    Thanks for weighing in Bill. I discovered your take on it late yesterday when you answered someone about a face milling routine.

    This is always going to be for one, single tool. This particular one is for a keyway mill to open up a slot ( along X axis ), both in depths of cut, as well as vertically, up and down. My intent is to have the macro calculate the depths of cut only, and return those values to the calling program to be used in conjunction with the Y distances and Z heights. Both those, being variables themselves.

    Knowing that, would you still do this the same way?

    Thank you very much.

    EDIT - Or, would it be better to have this macro call those moves and their values FROM the calling program and iterate them here, in this macro? ( more like you have illustrated )
    Hello Zahnrad,
    I'm not sure what you mean by "up and down"; is this a Horizontal Mill and you're referring to the Y to widen the slot?

    You could use the same logic as shown in my example and nest a second WHILE/DO, also using the same logic, only the variables are for another axis.

    Regards,

    Bill


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •