Tormach's deprecation of advanced gCode features - Page 2

Page 2 of 3 FirstFirst 123 LastLast
Results 21 to 40 of 56

Thread: Tormach's deprecation of advanced gCode features

  1. #21
    Member
    Join Date
    Apr 2017
    Location
    Canada
    Posts
    156
    Downloads
    0
    Uploads
    0

    Default help needed testing utilities

    I have completed a starter set of gCode utilities, but I need some help in testing them. I need help in part because one of them (for external thread milling) can't be tested by someone who (like me) doesn't own any thread mills. But more important, I need testing help because gCode programs, like any other programs, can't be said to have been tested until they've been tested by someone other than the person who wrote them.

    To keep the initial code as simple as possible, none of these utilities checks for input errors. For example, the code for cutting a circular pocket doesn't complain if the OD of the specified tool is greater than the ID of the specified pocket. I'll add checks of this sort after we have some experience with the utilities.

    Having editable utilities has some unforeseen benefits. To run these utilities, one must edit in values for feeds & speeds. One can also edit in comments about feeds & speeds that don't work, or feeds & speeds that worked with other uses of the same utilities.

    The numerical components of the names of the utilities were there to remind me about ranges of Oh-numbers to use in the code, anticipating the possibility that some utilities might later be merged.

    The hole-drilling utility decides on its own drilling cycle, drawing on remarks in one of the GWizard blogs. It incorporates a number of arbitrary constants, and I'm not at all confident that the constants now there are optimal. This utility is the one about which I most want suggestions.

    The intent of the "JustShave" option in the rectangle-shaving utility may not be obvious. It is meant to serve the situation in which a rough-cut surface is horizontal in the vise, the tool is a small unmeasured distance above it, and what's wanted is to plane the surface flat, with DOC of a few thousandths at a time, with no specific target Z. The "JustShave" option shaves by DOC, and then it leaves the tool at the level of the cut, so that a new Cycle Start shaves off another DOC.



  2. #22
    Member
    Join Date
    Apr 2017
    Location
    Canada
    Posts
    156
    Downloads
    0
    Uploads
    0

    Default gCode utilities: drilling

    There's not much to know about drilling shallow holes. Given the material of the workpiece and the material & OD of the drill, one looks up the appropriate spindle speed and feed rate, and one is ready to start work.

    Deeper holes (say, deeper than 3 drill diameters) are a different story. Looking at Bob Warfield's page here or at the "custom cycle" tab of his GWizard editor, one might come to believe that the massive feeds & speeds database behind Gwizard must be matched by an equally massive store of drilling lore, and that this store (or a similar one) must be consulted before every hole.

    The truth might be simpler. I have been experimenting with gCode that starts with the shallow-hole speed and feed. It also needs to know the drill's OD and helix angle, and of course it needs to know the intended depth of the hole. It then drills the hole, having calculated the necessary scheme of pecks, dwells, and partial retractions. It has smoothly produced holes up to 10 times the drill diameter; I have not tried any deeper holes, but only because I have no drills longer than that.

    I don't know how it would do with extremely fine drills (say, < 1 mm OD), whose size makes them necessarily less sharp than larger drills.

    In pseudo-code, the algorithm is as follows (a fragment of gCode is attached; it is less readable than the pseudocode):
    Code:
     
    start with the feed and speed appropriate for shallow holes using this drill in this material
    set the peck distance to [3] times the tool OD
    set the chip-breaking distance to [0.4] times the tool OD
    as long as the drill has not reached the desired depth
        drill down by one peck distance, but don't overshoot the desired depth
        dwell long enough for chips to ride the flutes to the surface [this is why the algorithm needs to know the helix angle]
        retract by the chip-breaking distance, but no higher than [0.5] tool ODs below the top of the hole
        reduce the peck size by [50%], but not to less than [10%] of the tool OD
        reduce the feed rate by [10%], but not to less than [10%] of the initial rate  
        reduce the spindle speed by [10%], but not to less than [10%] of the initial speed  
        [double] the chip-breaking distance
    As noted above, this algorithm is working for all of my drilling needs, but the range of my experiments has been limited. The attached spreadsheet shows what to expect.

    The constants shown [thus] above are arbitrary, and I have no confidence that they are optimal. I've set the first peck to 3 drill diameters. Would 4 be better, or only 2? Should the feed rate be allowed to get as low as 10% of its initial value, or should it be held to be no less than 25%? And so on, and so on.

    A more fundamental problem than constant-tuning might arise with a broader range of materials than I have experimented with. For example, can the chip-breaking strategy be the same in cast iron (no real chips, but lots and lots of soot-like powder) and copper (sticky chips)? Using different constants with different materials might be necessary. Even if having different constant-sets were not strictly necessary, it might allow for greater efficiency.

    Have other forum members had experience with similar approaches?

    Attached Files Attached Files
    Last edited by Fenichel; 06-29-2017 at 02:18 AM. Reason: corrected spreadsheet & code in attachment


  3. #23
    Member samco's Avatar
    Join Date
    Jul 2003
    Posts
    1753
    Downloads
    2
    Uploads
    0

    Default Re: Tormach's deprecation of advanced gCode features

    For linuxcnc prime - look at nativecam

    https://forum.linuxcnc.org/40-subrou...atures-renamed

    Looks very powerful. (Take a look at the videos)



  4. #24
    Member
    Join Date
    Nov 2016
    Location
    United States
    Posts
    109
    Downloads
    0
    Uploads
    0

    Default Re: Tormach's deprecation of advanced gCode features

    Great work Fenichel! Would you have an issue if I made a Windows UI from one of your snippets? I want to experiment with creating a link between Windows and LinuxCNC to allow a Windows app take over some conversational tasks (and some control features) from PathPilot. All in an effort to minimize my back and forth between Windows (w/ Fusion 360) and Pathpilot. Someday I’d love to bring the tool length offsets into Windows as well, if I can somehow get around the PP tool database.

    Thanks,
    Pete



  5. #25
    Member
    Join Date
    Apr 2017
    Location
    Canada
    Posts
    156
    Downloads
    0
    Uploads
    0

    Default Re: Tormach's deprecation of advanced gCode features

    @petenc
    If what you're planning to produce will be free, open-source, then sure, go ahead. Put a credit to me (Robert R. Fenichel) in it somewhere. Stay in touch, because I am tweaking the code from day to day.



  6. #26
    Member kstrauss's Avatar
    Join Date
    Apr 2013
    Location
    Canada
    Posts
    1788
    Downloads
    0
    Uploads
    0

    Default Re: Tormach's deprecation of advanced gCode features

    Getting the tool lengths/diameters into Windows is trivial. You will need to setup another Samba share to gain ready access but the tool table is in a space delimited file in \operator\mill_data\tools.tbl Excel parses it easily. See below for a snippet of the file:


    T40 P40 Z+2.635000 ;
    T41 P41 D0.062500 Z+2.752000 ;
    T42 P42 D0.125000 Z+2.668000 ;
    T43 P43 D0.250000 Z+3.400000 ;
    T44 P44 Z+3.162000 ;
    T45 P45 Z+2.937000 ;
    T46 P46 Z+3.592000 ;

    Either update the .tbl file directly or use G10 L1 to move the length data from Windows to PathPilot. Unfortunately, the tool description is *NOT* stored in the tools.tbl file where one would expect to find it.



  7. #27
    Member
    Join Date
    Nov 2016
    Location
    United States
    Posts
    109
    Downloads
    0
    Uploads
    0

    Default Re: Tormach's deprecation of advanced gCode features

    Quote Originally Posted by kstrauss View Post
    Getting the tool lengths/diameters into Windows is trivial. You will need to setup another Samba share to gain ready access but the tool table is in a space delimited file in \operator\mill_data\tools.tbl Excel parses it easily. See below for a snippet of the file:


    T40 P40 Z+2.635000 ;
    T41 P41 D0.062500 Z+2.752000 ;
    T42 P42 D0.125000 Z+2.668000 ;
    T43 P43 D0.250000 Z+3.400000 ;
    T44 P44 Z+3.162000 ;
    T45 P45 Z+2.937000 ;
    T46 P46 Z+3.592000 ;

    Either update the .tbl file directly or use G10 L1 to move the length data from Windows to PathPilot. Unfortunately, the tool description is *NOT* stored in the tools.tbl file where one would expect to find it.
    Thanks Fenichel, if I use it I'll splatter your name all over it. Hmm... good info kstrauss. I noticed that entire file (tools.tbl) updates after each change to the offset table. Looks like they use redis and store the tool names in rdb.dump file, in that same mill_data folder. They store a lot of stuff in that dump.rdb, but I don't see why I couldn't just overwrite tool descriptions and the tool length offsets. However, if the table gets edited, my items would get replaced with what is in the current table. Or maybe just invoke a refresh to the table as soon as I make a change on the Windows side and vice/versa? Not sure yet. Lets move this to another thread. I like what Fenichel is doing and don't want to muddy it up with this stuff. In the end, I'd like Fusion 360 and my Windows custom app to dictate this info. That way I can add a tool wear column, improve searching and organization, and then add "tool cutting conditions" for each tool that would store speeds/feeds for the various materials I run. For me, I am more comfortable developing in .NET, plus my vision is to have that stuff on my PC rather than on the controller.

    Thanks,
    Pete



  8. #28
    Member
    Join Date
    Apr 2017
    Location
    Canada
    Posts
    156
    Downloads
    0
    Uploads
    0

    Default A small point about drilling

    Any good drilling program should make use of the point angle of drills it governs. This is because if the intended depth of a hole is the intended full-OD depth (that is, not counting the little cone at the bottom), then the program needs to know how tall that cone is. That's easy to compute
    tool OD/(2 tan(point angle/2))
    but you need the point angle.



  9. #29
    Member
    Join Date
    Nov 2016
    Location
    United States
    Posts
    109
    Downloads
    0
    Uploads
    0

    Default Re: Tormach's deprecation of advanced gCode features

    Also, Fenichel here is a little snippet I made over a beer bet for creating spirals without using arc's. Proof that loops can save a lot of lines of code, although they are difficult if you want to restart on a certain line number. It uses the polar functions of the control. Your welcome to use it if it helps in your quest for easy to use gcode snippets.

    #<STEPOVER>=.05
    #<DIAMETER>=2.0
    #<DEPTH>=-.25
    #<FEEDRATE>=20

    ;PREP MOVES
    G90 G00 X0Y0Z0
    G91
    G01 X.00001 F20
    G01 Z#<DEPTH> F5
    ;
    #<DIAMETER>=[#<DIAMETER> / 2]
    #<CYCLECOUNT>=[#<DIAMETER> / #<STEPOVER>]
    #<STEPOVER>=[#<STEPOVER> / 360]

    O100 REPEAT[360 * #<CYCLECOUNT>]
    G01 @#<STEPOVER> ^1 F#<FEEDRATE>
    O100 ENDREPEAT


    Tormach's deprecation of advanced gCode features-img_20170629_192228-jpg



  10. #30
    Member
    Join Date
    Apr 2017
    Location
    Canada
    Posts
    156
    Downloads
    0
    Uploads
    0

    Default Re: A much bigger point about drilling

    I'm glad I have GWizard. For example, I don't think I've ever used a 27/64" drill, and I know I've never worked with Incoloy 825. If tomorrow I needed to drill a 27/64" hole in some Incoloy 825, good old GWizard would be there for me.

    For the work I'm likely to do today, I shouldn't need to use GWizard. I might need a clearance hole for an M6 screw, drilled through aluminum 6061-T6. I've done that many times before. The same gCode that knows how to drill a hole should remember the feeds & speeds needed for recurrent jobs.

    Forget Incoloy, which I'd never heard of until I found it in the recesses of GWizard. I'll cross the Incoloy bridge when I need to. I once looked up what I needed to know for that M6 clearance hole in 6061, and now I shouldn't need to look it up again. In general,
    • the drills I own are a small fraction of the drills known to GWizard, and
    • the drills I have ever used are a small fraction of the drills I own, and
    • the materials I have ever used are a tiny fraction of the the materials known to GWizard, and
    • the drill/material combinations I have ever used are a tiny fraction of all of the possible combinations of drill and material on hand.
    What I had been doing, and what similarly-situated forum members probably do, is to take notes somewhere, after I'd looked up a feed/speed package, and then refer to those notes whenever I needed to produce a new instance of a familiar hole.

    Editing the notes into gCode allows for new efficiencies. The code could be slicker if gCode were a less primitive programming language (for example, if it had arrays and enumerated ordinal constants), but it's good enough.

    In my current hole-drilling utility (a fragment of which was shown a few posts ago in this thread), a group of lines at the beginning lets me specify what material I want to drill:
    Code:
    ; ***************** material (pick one) ****************************************
    #<_aluminum_6061> = 1
    #<_steel_1018>    = 0
    #<_steel_12L14>   = 0
    #<_pine>          = 0
    These are not all the materials I've ever heard of, or even all the materials I have on hand. When I need another material here, I'll just edit it in.

    Similarly, the next group of lines is a subroutine, establishing variable names for some drills of interest and setting all of those variables to zero.
    Code:
    ; ***************** drills
    o 1 ; set all drills to be not in use; repository of drill names
        #<_drill_0169_HSS_135_30> = 0 ; HSS drill #18   helix 30° tip 135°
        #<_drill_0204_HSS_135_30> = 0 ; HSS drill #6    helix 30° tip 135° tap M6 aluminum
        #<_drill_0234_HSS_135_30> = 0 ; HSS drill #A    helix 30° tip 135°
        #<_drill_0238_HSS_135_30> = 0 ; HSS drill #B    helix 30° tip 135° clear M6
        #<_drill_0413_HSS_135_30> = 0 ; HSS drill #Z    helix 30° tip 135°
        #<_drill_0453_HSS_135_30> = 0 ; HSS drill 29/64 helix 30° tip 135° clear 7/16
        #<_drill_0500_HSS_135_30> = 0 ; HSS drill 1/2   helix 30° tip 135°
        #<_drill_0750_HSS_135_30> = 0 ; HSS drill 3/4   helix 30° tip 135°
        M99                           ; return to caller
    As is evident, I can use comments here ("clear M6" and so on) to remind me what the various drills are good for. This list is even less complete than the list of materials; as I need to make use of other drills, I'll add them here.

    The drills and materials come together in another subroutine that carries forward what I've learned about drill/material-specific feeds & speeds:
    Code:
    o 2300 ; ************* feeds & speeds
        #<_HelixAngle> = 30  ; set here but could be different for each tool
        #<_PointAngle> = 135 ; set here but could be different for each tool
    
        o 2301 if [#<drill_0169_HSS_135_30>]
            o 23011 if [#<_aluminum_6061>]
                #<_ShallowFeed> = 7.58 #<_ShallowRPM> = 3932 ; tested to 10D
            o 23011 endif
        o 2301 elseif [#<drill_0204_HSS_135_30>]
            o 23012 if [#<_aluminum_6061>]
                #<_ShallowFeed> = 6.7 #<_ShallowRPM> = 2600 ; tested
            o 23012 endif
        o 2301 elseif [#<drill_0234_HSS_135_30>]
            o 23013 if [#<_aluminum_6061>]
                #<_ShallowFeed> = 7.4 #<_ShallowRPM> = 2405 ; per GW
            o 23013 endif
        o 2301 elseif [#<drill_0238_HSS_135_30>]
            o 23014 if [#<_aluminum_6061>]
                #<_ShallowFeed> = 8 #<_ShallowRPM> = 2500 ; tested
            o 23014 elseif [#<_pine>]
                #<_ShallowFeed> = 65 #<_ShallowRPM> = 4411 ; tested
            o 23014 endif
       (abridged)
        o 2301 elseif [#<drill_0453_HSS_135_30>]
            o 23016 if [#<_aluminum_6061>]
                #<_ShallowFeed> = 7.07 #<_ShallowRPM> = 1471 ; per GW, but fails
                #<_ShallowFeed> = 4 #<_ShallowRPM> = 1471 ; fails
                #<_ShallowFeed> = 3 #<_ShallowRPM> = 1471 ; tested
            o 23016 endif
        (abridged)
        o 2301 elseif [#<drill_0750_HSS_135_30>]
            o 23018 if [#<_aluminum_6061>]
                #<_ShallowFeed> = 4 #<_ShallowRPM> = 889 ; per GW
            o 23018 elseif [#<_steel_12L14>]
                #<_ShallowFeed> = 2 #<_ShallowRPM> = 408 ; per GW
            o 23018 endif
        o 2301 endif
        M99 ; return to caller
    Some of the comments here (see the code associated with the 29/64" drill, here called drill_0453_HSS_135_30) usefully remind me of feed/speed combinations that didn't work, so I know not to try them again. Also, if any of my drills had a permanently-assigned tool number in PathPilot, I could record that here.

    Once the drill/material --> feed/speed relationship has been recorded, any further drilling with this drill/material combination is simple. To drill 3 holes, 2 of the same depth, and using 2 different drills, the entire non-subroutine content of the utility might be edited to
    Code:
    ; ************** action starts *************************************************
    M98 P2000                                        ; initialize
    M98 P1                                           ; deselect all drills
    
    #<_ZClear>        = 0.2
    #<_ZTop>          = -0.4
    #<_ZBottom>       = -1.3
    #<_FullODToDepth> = 1    ; if NZ, add depth for tip taper
    
    #<_XCenter> = 1.005  #<_YCenter> = 0             ; hole #1, same depth
    #<_drill_0204_HSS_135_30> = 1 #<_ToolNumber> = 5 ; use drill #6
    M98 P500                                         ; ..
    
    #<_XCenter> = 4.165  #<_YCenter> = 0             ; hole #2, same depth
    M98 P1                                           ; deselect old drill
    #<_drill_0238_HSS_135_30> = 1 #<_ToolNumber> = 6 ; use drill #B
    M98 P500                                         ; ..
    
    #<_XCenter> = 5  #<_YCenter> = 5.6               ; hole #3, same drill
    #<_ZBottom> = -4                                 ; but deeper
    M98 P500
    
    M00                                  ; end of program
    
    ; *************** action ends
    I've attached a copy of my drilling utility.

    Attached Files Attached Files


  11. #31
    Member
    Join Date
    Apr 2017
    Location
    Canada
    Posts
    156
    Downloads
    0
    Uploads
    0

    Default Re: Tormach's deprecation of advanced gCode features

    @petenc
    Spirals without arcs are used in PathPilot's gCode for circular pockets, and I used them in my circular-pocket utility, a version of which was posted here near the beginning of this thread. Neither the PathPilot author nor I thought of using polar coordinates; my gCode stays Cartesian, but then needs to do some trigonometry. The pertinent code in my current version is
    Code:
            o 2511 if [#<RampRadius> GT #<_Stepover>]                       ; *need spiral to fill in
                G01 X [#<_XCenter>] Y [#<_YCenter>]                         ; back to center
                                                                            ; spiral out at this level
                #<Step> = 0                                                 ; ..
                o 25111 repeat [#<SpiralSteps>]                             ; spiral may take several full turns
                    #<Step> = [#<Step> + 1]                                 ; each step is faster and longer
                    #<ArcFeed> = [#<Step> * #<ArcFeedStep>]                 ; ..
                    #<Radius>  = [#<Step> * #<RadiusStep>]                  ; ..
                    #<Angle>   = [#<Step> * #<AngleStep>]                   ; ..
                    F [#<ArcFeed>]                                          ; ..
                    #<XStepEnd> = [#<_XCenter> + #<Radius> * cos[#<Angle>]] ; ..
                    #<YStepEnd> = [#<_YCenter> + #<Radius> * sin[#<Angle>]] ; ..
                    G01 X [#<XStepEnd>] Y [#<YStepEnd>]                     ; ..
                o 25111 endrepeat                                           ; one step complete
            o 2511 endif                                                    ; done with spiral
    Starting with a very slow feed seems wise to me, since the first few steps are pretty much slotting.

    Last edited by Fenichel; 06-29-2017 at 08:42 PM. Reason: needed indication of to whom replied


  12. #32
    Member
    Join Date
    Nov 2016
    Location
    United States
    Posts
    109
    Downloads
    0
    Uploads
    0

    Default Re: Tormach's deprecation of advanced gCode features

    I like your coding style... and I like that code much better. I am trying to wrap my head around the calc's though... takes me a minute. If I understand it right, its the same code (incrementing angle) but rather than flipping to polar you just calculate the point on each iteration?



  13. #33
    Member
    Join Date
    Apr 2017
    Location
    Canada
    Posts
    156
    Downloads
    0
    Uploads
    0

    Default Re: Tormach's deprecation of advanced gCode features

    yes, you understand it.



  14. #34
    Member
    Join Date
    Apr 2017
    Location
    Canada
    Posts
    156
    Downloads
    0
    Uploads
    0

    Default more on spirals

    I'm glad that @petenc got me thinking about spirals, because I've now rethought my use of spirals in my circular-pocket utility. I had started by just recoding the gCode produced by PathPilot's conversational tool. That code did its work in passes, one DOC at a time. It did each pass by
    • plunging the endmill at the center, using a pseudo-G83 technique, and then
    • spiraling out to near the rim, and finally
    • doing a finish cut around the rim

    My initial version did away with the silly plunging step, but it copied the rest, so each pass was
    • ramping down along a helical path just inside the rim, and then
    • feeding back to the center, and then
    • spiraling out to near the rim, and finally
    • doing a finishing cut around the rim.

    This was suboptimal, because the second step, and the beginning of the third, were essentially slotting, requiring reduced feed rates. In my new version of the circular-pocket utility (attached), each pass works by
    • ramping down along a helical path just inside the rim, and then
    • doing a finishing cut around the rim, and then
    • spiraling in to the center.


    Attached Files Attached Files


  15. #35
    Member
    Join Date
    Apr 2017
    Location
    Canada
    Posts
    156
    Downloads
    0
    Uploads
    0

    Default syntax non-checking in PathPilot

    When a file of gCode is loaded for execution, PathPilot provides messages that look like the syntax diagnostics from an ordinary compiler, but they are actually simulation diagnostics. The difference is that
    • steps not executed are not examined, so PathPilot accepts
      Code:
      if [2+2 EQ 5]
        garbage
      endif
      while [1+1 EQ 3]
        more garbage
      endwhile
      without complaint, and
    • errors within subroutines are said to be near the line of the caller, not near the actual line on which they appear

    That's my excuse, anyway, when I publish code that has syntactic errors. A corrected -- possibly still not correct -- version of my drilling utility is attached.

    Attached Files Attached Files


  16. #36
    Member
    Join Date
    Nov 2016
    Location
    United States
    Posts
    109
    Downloads
    0
    Uploads
    0

    Default Re: more on spirals

    Quote Originally Posted by Fenichel View Post
    I'm glad that @petenc got me thinking about spirals, because I've now rethought my use of spirals in my circular-pocket utility. I had started by just recoding the gCode produced by PathPilot's conversational tool. That code did its work in passes, one DOC at a time. It did each pass by
    • plunging the endmill at the center, using a pseudo-G83 technique, and then
    • spiraling out to near the rim, and finally
    • doing a finish cut around the rim

    My initial version did away with the silly plunging step, but it copied the rest, so each pass was
    • ramping down along a helical path just inside the rim, and then
    • feeding back to the center, and then
    • spiraling out to near the rim, and finally
    • doing a finishing cut around the rim.

    This was suboptimal, because the second step, and the beginning of the third, were essentially slotting, requiring reduced feed rates. In my new version of the circular-pocket utility (attached), each pass works by
    • ramping down along a helical path just inside the rim, and then
    • doing a finishing cut around the rim, and then
    • spiraling in to the center.
    what the fup is fup?



  17. #37
    Member
    Join Date
    Apr 2017
    Location
    Canada
    Posts
    156
    Downloads
    0
    Uploads
    0

    Default Re: more on spirals

    Fup rounds up to the nearest integer. It and other functions available in PP's version of gCode are described in Section 7.9.3.2 of the 770 manual, and probably in analogous sections of other Tormach manuals.



  18. #38
    Member
    Join Date
    Jun 2010
    Location
    Australia
    Posts
    4252
    Downloads
    4
    Uploads
    0

    Default Re: Tormach's deprecation of advanced gCode features

    Named parameters, subroutines, math functions, and miscellaneous control structures are explicitly deprecated by Tormach, with the claim that such code is "difficult to debug and very difficult for another operator to understand."
    Ah well, all probably quite true ... IF you are catering for the great unwashed who simply haven't a clue (and who don't care).

    On closer examination: 'difficult to debug' is total crap. A well-written parametric program is very simple to debug. Such a program is so short that understanding the whole of it takes no more than a minute or two - if you have any understanding of programming.

    Equally, 'very difficult for another operator to understand' is also total crap, for exactly the same reasons, and with the same proviso. If you hire crap staff who can not write decent programs, then YGWYD.

    I guess that if mangement wants to replace all skilled operators with raw school-leavers (and a significant salary saving) then Tormach may have a point - up until the time the brown ring forms around the rotary air mover. Or up until the time the customer puts a caliper on the product.

    Fup rounds up to the nearest integer.
    It's part of basic NIST g-code. Every hobby program (eg Mach3, LinuxCNC) supports it.

    Cheers
    Roger



  19. #39
    Gold Member daniellyall's Avatar
    Join Date
    Sep 2009
    Location
    New Zealand
    Posts
    1856
    Downloads
    3
    Uploads
    0

    Default Re: Tormach's deprecation of advanced gCode features

    All the fancy arse Macro_B and sub programming is all coming back in flavor this is where the tormach post is at for their first round of updates from fusion360

    below is 3 holes drilled

    (1001)
    (Z Bearing End Cap Center Op1)
    (post version 41373)
    (post modified 2017-03-23 122510)
    (T1 D=5. CR=0. TAPER=118deg - ZMIN=-19. - drill)
    N10 G90 G54 G64 G50 G17 G40 G80 G94 G91.1 G49
    N20 G21 (Metric)
    N30 G30

    (Drill1)
    N50 G30
    N60 T1 G43 H1 M6
    N70 S5820 M3 M8
    N80 G54
    N90 G0 X-0.348 Y56.215
    N100 G0 Z15.
    N120 G0 Z5.
    N130 G98 G73 X-0.348 Y56.215 Z-19. R5. Q1.25 F728.
    N140 X-95.5 Y10.002
    N150 Y-9.998
    N160 X-0.349 Y-56.213
    N170 G80
    N180 G0 Z15.
    N200 M5 M9

    N210 G30
    N220 M30
    %

    Below is 11 holes

    %
    (1002)
    (Z Bearing End Cap Center Op1)
    (post version 41373)
    (post modified 2017-03-23 122510)
    (T4 D=2.5 CR=0. TAPER=118deg - ZMIN=-19. - drill)
    N10 G90 G54 G64 G50 G17 G40 G80 G94 G91.1 G49
    N20 G21 (Metric)
    N30 G30

    (Drill1)
    N50 G30
    N60 T4 G43 H4 M6
    N70 S10000 M3 M8
    N80 G54
    N90 G0 X103.5 Y42.853
    N100 G0 Z15.
    N120 G0 Z5.
    N130 G98 G73 X103.5 Y42.853 Z-4. R5. Q0.625 F625.
    N140 X39.644 Y72.
    N150 G80
    N170 G0 X-0.348 Y56.215 Z5.
    N180 G98 G73 X-0.348 Y56.215 Z-19. R5. Q0.625 F625.
    N190 G80
    N210 G0 X-42.854 Y49.12 Z5.
    N220 G98 G73 X-42.854 Y49.12 Z-4. R5. Q0.625 F625.
    N230 G80
    N250 G0 X-95.5 Y10.002 Z5.
    N260 G98 G73 X-95.5 Y10.002 Z-19. R5. Q0.625 F625.
    N270 G80
    N290 G0 X-103.5 Y0.002 Z5.
    N300 G98 G73 X-103.5 Y0.002 Z-4. R5. Q0.625 F625.
    N310 G80
    N330 G0 X-95.5 Y-9.998 Z5.
    N340 G98 G73 X-95.5 Y-9.998 Z-19. R5. Q0.625 F625.
    N350 G80
    N370 G0 X-42.855 Y-49.118 Z5.
    N380 G98 G73 X-42.855 Y-49.118 Z-4. R5. Q0.625 F625.
    N390 G80
    N410 G0 X-0.349 Y-56.213 Z5.
    N420 G98 G73 X-0.349 Y-56.213 Z-19. R5. Q0.625 F625.
    N430 G80
    N450 G0 X39.642 Y-72. Z5.
    N460 G98 G73 X39.642 Y-72. Z-4. R5. Q0.625 F625.
    N470 X103.5 Y-42.855
    N480 G80
    N490 G0 Z15.
    N510 M5 M9

    N520 G30
    N530 M30
    %

    If there is plenty of interest they will have it so it pops out like below tormach will hopefully play along

    %
    O1002 (Z BEARING END CAP CENTER OP1)
    (T4 D=2.5 CR=0. TAPER=118DEG - ZMIN=-19. - DRILL)
    N10 G90 G94 G17 G49 G40 G80
    N15 G21
    (T4)
    N20 M98 P1003

    N25 G28 G91 Z0.
    N30 G49
    N35 G28 X0. Y0.
    N40 M30
    %

    <img src="https://ivxo1q-dm2305.files.1drv.com/y4mENMmTr_Cabc7pR0FUdB6gtbADq2JbuG4_rGy0eBQvLJx19pTi6TqMUIJN0xgOyDIc0gWoxYhS38HpbSTFGdfaK-o42IOU6jczrhDpfpCOTNGL1X6hvZCbgj0y35gqmq1YGTrWwShYGV-C7lXA2esy0Pi_WfnBSyroDLSGXwce4uSr1U7op7srdi78rispHCa_K4aFlTlJPVkkNWMfgh_Tg?width=60&height=60&cropmode=none" width="60" height="60" />

    Being Disabled is OK CNC is For fuN


  20. #40
    Member
    Join Date
    Nov 2016
    Location
    United States
    Posts
    109
    Downloads
    0
    Uploads
    0

    Default Re: Tormach's deprecation of advanced gCode features

    Quote Originally Posted by RCaffin View Post
    Named parameters, subroutines, math functions, and miscellaneous control structures are explicitly deprecated by Tormach, with the claim that such code is "difficult to debug and very difficult for another operator to understand."
    Ah well, all probably quite true ... IF you are catering for the great unwashed who simply haven't a clue (and who don't care).

    On closer examination: 'difficult to debug' is total crap. A well-written parametric program is very simple to debug. Such a program is so short that understanding the whole of it takes no more than a minute or two - if you have any understanding of programming.

    Equally, 'very difficult for another operator to understand' is also total crap, for exactly the same reasons, and with the same proviso. If you hire crap staff who can not write decent programs, then YGWYD.

    I guess that if mangement wants to replace all skilled operators with raw school-leavers (and a significant salary saving) then Tormach may have a point - up until the time the brown ring forms around the rotary air mover. Or up until the time the customer puts a caliper on the product.

    Fup rounds up to the nearest integer.
    It's part of basic NIST g-code. Every hobby program (eg Mach3, LinuxCNC) supports it.

    Cheers
    Roger
    We have to remember this is an entry level machine, with entry level controls, and with an entry level audience. The "great unwashed" or not... this is where I come to learn and become intrigued with topics, whereas before, I "simply haven't a clue."



Page 2 of 3 FirstFirst 123 LastLast

Tags for this Thread

Posting Permissions

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


About CNCzone.com

    We are the largest and most active discussion forum for manufacturing industry. The site is 100% free to join and use, so join today!

Follow us on


Our Brands

Tormach's deprecation of advanced gCode features

Tormach's deprecation of advanced gCode features