Tormach's deprecation of advanced gCode features - Page 3

Page 3 of 3 FirstFirst 123
Results 41 to 56 of 56

Thread: Tormach's deprecation of advanced gCode features

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

    Default Re: syntax non-checking in PathPilot

    There is another consequence of PathPilot's code-loading process entailing simulation, not syntax checking.

    Starting with a rough-sawed surface, I sometimes want to shave it down to flatness without specifying how far down to go. The idea is to cover the surface with Dykem and keep shaving until all the Dykem is gone. The obvious gCode is something like
    Code:
        o 401 else if [#<_Action> EQ #<_ShaveNonstopFromTop>]
            (MSG, pay attention)                        ; this could run away
            M1                                          ; ..
            #<ZOld> = [#5422]                           ; .. sysvar = current Z
           o 4012 while [1]                             ; infinite loop
                M8 M3                                   ; spindle & coolant on
                G01 X [#<_XStart>] Y [#<_YStart>]       ; .. G01 (vs G00) conservative
                #<_ZCut> = [#<ZOld> - 0.005]            ; .. one shave
                M98 P410                                ; (subroutine scours the surface at Z = #<_ZCut>)
                G00 Z [#<ZOld>]                         ; get clear so user can evaluate
                G00 X [#<_XStart>] Y [#<_YStart>]       ; ..
                M5 M9                                   ; ..
                G04 P [10]                              ; chance to reset
                #<ZOld> = [#<_ZCut>]                    ; ready for another shave
            o 4012 endwhile
    where the 10-second pause would give me time to see that the job is done, whereupon I'd hit Reset.

    This code is syntactically correct, but PathPilot doesn't accept it. PP's mode of rejection is to freeze, disabling the keyboard, touchscreen, jogger, and mouse. The only escape from the freeze is a power cycle.

    The problem is that PathPilot is trying to simulate this code to completion, and of course it isn't meant to run to completion. Other users may have run into similar problems with gCode that could complete, but only in a very long time.

    Requiring a power cycle is not a good form of diagnostic message. The PathPilot simulator should have a timeout mechanism.



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

    Default Re: syntax non-checking in PathPilot

    I don't know how path pilot works - but in the linuxcnc Axis interface - you can hit the escape key to have it stop drawing an infinite loop. (there are also gcode comments that turn off the preview drawing like

    '(AXIS,stop) Stops the preview from here to the end of the file.'

    AXIS GUI





    Quote Originally Posted by Fenichel View Post
    There is another consequence of PathPilot's code-loading process entailing simulation, not syntax checking.

    Starting with a rough-sawed surface, I sometimes want to shave it down to flatness without specifying how far down to go. The idea is to cover the surface with Dykem and keep shaving until all the Dykem is gone. The obvious gCode is something like
    Code:
        o 401 else if [#<_Action> EQ #<_ShaveNonstopFromTop>]
            (MSG, pay attention)                        ; this could run away
            M1                                          ; ..
            #<ZOld> = [#5422]                           ; .. sysvar = current Z
           o 4012 while [1]                             ; infinite loop
                M8 M3                                   ; spindle & coolant on
                G01 X [#<_XStart>] Y [#<_YStart>]       ; .. G01 (vs G00) conservative
                #<_ZCut> = [#<ZOld> - 0.005]            ; .. one shave
                M98 P410                                ; (subroutine scours the surface at Z = #<_ZCut>)
                G00 Z [#<ZOld>]                         ; get clear so user can evaluate
                G00 X [#<_XStart>] Y [#<_YStart>]       ; ..
                M5 M9                                   ; ..
                G04 P [10]                              ; chance to reset
                #<ZOld> = [#<_ZCut>]                    ; ready for another shave
            o 4012 endwhile
    where the 10-second pause would give me time to see that the job is done, whereupon I'd hit Reset.

    This code is syntactically correct, but PathPilot doesn't accept it. PP's mode of rejection is to freeze, disabling the keyboard, touchscreen, jogger, and mouse. The only escape from the freeze is a power cycle.

    The problem is that PathPilot is trying to simulate this code to completion, and of course it isn't meant to run to completion. Other users may have run into similar problems with gCode that could complete, but only in a very long time.

    Requiring a power cycle is not a good form of diagnostic message. The PathPilot simulator should have a timeout mechanism.




  3. #43
    Member
    Join Date
    Dec 2008
    Location
    Switzerland
    Posts
    740
    Downloads
    0
    Uploads
    0

    Default Re: syntax non-checking in PathPilot

    Not long ago you started a thread as a "Newbie"
    Quote Originally Posted by Fenichel View Post
    I am trying to learn gCode technique by examining code produced by experts, including code produced by the PathPilot wizards....
    Just a week later you start ranting about the "deprecation of advanced gCode features". Now you're writing infinite loops and complaining that the interpreter doesn't behave the way YOU would like it too.
    Quote Originally Posted by Fenichel View Post
    ...This code is syntactically correct, but PathPilot doesn't accept it. PP's mode of rejection is to freeze, ... The problem is that PathPilot is trying to simulate this code to completion, and of course it isn't meant to run to completion...
    Sorry, but infinite loops are BAD programming in ANY language.
    Step



  4. #44
    Member
    Join Date
    Apr 2017
    Location
    Canada
    Posts
    156
    Downloads
    0
    Uploads
    0

    Default Re: syntax non-checking in PathPilot

    In the situation I described, PathPilot freezes before it has changed to the screen on which the preview is visible, so it wasn't obvious what was happening. In any event, ESC didn't break out of the freeze.

    The AXIS interface sounds very good. The pseudo-comment you mention (AXIS, stop) seems best-adapted to old-fashioned unstructured programs, but I see that (AXIS, hide) and (AXIS, show) can be used more selectively. I will suggest to Tormach that in the next version of PathPilot,
    • the sequence
      • load file
      • simulate
      • show main screen with simulation results

      be changed to
      • load file
      • show main screen
      • simulate, showing results

    • ESC be accepted to abort a simulation
    • pseudo-comments like (AXIS, hide) and (AXIS, show) be accepted to work as these do in AXIS


    Last edited by Fenichel; 07-03-2017 at 05:38 PM. Reason: wrote 'stop' instead of 'show'


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

    Default Re: syntax non-checking in PathPilot

    @TurboStep
    I'm new to CNC, but I've been programming for a while. My first article in the Communications of the Association for Computing Machinery was published in 1968 [sic]. There were others.

    Infinite loops have to be understood in context.
    Code:
    Stop when I say 'when'
    is an infinite loop on its face, inasmuch as the termination condition is not necessarily going to occur. Operating systems use infinite loops to scan their message queues, terminating only on receipt of a message that may never arrive. On a manual lathe, every powered run toward the headstock is an infinite loop on its face. In all these cases, and in my example of shaving a surface down to squareness, {the instructions/the code/the engagement of the power feed} do not specify a completion, but we expect the environment to provide a termination sooner or later. In the case of my code for shaving a surface down to squareness, PathPilot prefers
    Code:
    o 4012 while [#<ZCut> GT [#<ZOriginal> - 5]]
    to
    Code:
    o 4012 while [1]
    . Either of these will lead to disaster if unattended. The only difference is that the purpose of the second is clearer.



  6. #46
    Member
    Join Date
    Jun 2005
    Location
    USA
    Posts
    653
    Downloads
    0
    Uploads
    0

    Default Re: Tormach's deprecation of advanced gCode features

    The basic issue is G-code is the Assembly Language of CNC. Fewer and fewer people program in it every year since CAD and CAM turn out code much faster while providing version control, machine portability and so on.

    It's the same old Assembly-versus-C arguments software engineers went through years ago.

    If you want to mess with it, by all means, and IMO CNC machinists should be able to read & write enough of it to do basic tasks and know what code does, but most CNC machinists aren't formally trained programmers and don't really care to learn the finer points, so it's not too surprising Tormach chose to put their limited resources onto other things.



  7. #47
    Member
    Join Date
    Jun 2010
    Location
    Australia
    Posts
    4252
    Downloads
    4
    Uploads
    0

    Default Re: Tormach's deprecation of advanced gCode features

    I have to plead my ignorance of PathPilot here, but I thought it was derived from LinuxCNC? If so, it should support certain things.

    The use of FUP[] is heart and soul to good parametric programming. Consider the following:
    #1=5.38 % start position for machining
    #2=5.12 % end position
    #3=[#1-#2] % distance to be machined
    #4=0.35 % maximum safe cut
    #5=fup[#3/#4] % N the number of machining cycles needed for that depth with less than max cut
    #6=[#3/#5] % the machining depth per cycle needed for N cycles
    #7=#1 % working axis parameter
    m98 p10 L#5 % machine N cycles

    If you want to machine down until the Dykem is all gone, you are mixing manual machining with CNC. You can do it if you think it through.
    Step 1: run the above with 'safe' values for start and end.
    Step 2: estimate how nuch deeper you need to go. EDIT program, making #2=(old #1), and make new #2=(that much deeper).
    Step 3: rerun program.
    Most of my utility programs are set up this way.

    I use Mach3, and it too can hang if it encounters an infinite loop. Sometimes it stops in disgust and tell me about it; other times I just hit STOP (not eStop) and the program stops. Can't you do this in PP?

    Someone complained that PP does not support arrays of variables. Mach3 certainly does, WITHIN NIST G-CODE, so PP should also. You use them like this:
    #1=27 % index pointer within array
    #2=100 % array start in parameter space
    #3=#[#2+#1] % #3 = #[100+27] = #127
    I routinely load about 400 parameters from an auxiliary file into a program and access them this way.

    Conditionals: not so easy, but still can be done within NIST g-code. For a start, consider:
    m98 p10 L#1
    This will call SR o10 IF #1>1, but it will not call it if #1=0. How to set up #1 is simple maths. There you have an IF THEN statement. A little more cunning in manipulating #1 can give you the ELSE part.

    Cheers
    Roger
    Disclosure: like Fenichel, I too started programming around 1968.



  8. #48
    Member
    Join Date
    Jun 2010
    Location
    Australia
    Posts
    4252
    Downloads
    4
    Uploads
    0

    Default Re: syntax non-checking in PathPilot

    PS: drills under 1 mm.
    They get expensive, especially if you want good ones. Dormer and some swiss brands are good. Doubtless there are others.
    Tormach's deprecation of advanced gCode features-7785-jpg
    This is a sub-1 mm drill going into 2.4 mm 6Al-4V titanium wire, fully CNC. The hole is too small to use a starting centre drill, so there are no drill changes.

    Cheers
    Roger



  9. #49
    Member
    Join Date
    Apr 2017
    Location
    Canada
    Posts
    156
    Downloads
    0
    Uploads
    0

    Default tiny drills

    @RCaffin re tiny drills
    That's an impressive picture. I mentioned tiny drills only because I was (and am) unsure that my generic deep-drilling program would work with them. How deep (in drill diameters) do you go with them? Do you use a simple G83 routine, or do you have your own cycle, specially adapted for the tiny drills?



  10. #50
    Member
    Join Date
    Jun 2010
    Location
    Australia
    Posts
    4252
    Downloads
    4
    Uploads
    0

    Default Re: Tormach's deprecation of advanced gCode features

    Hi Fenichel

    I am not sure whether I was using g83 or a special routine - I use either at times. There is in fact not much difference between the two unless there are special requirements (which sometimes happen). No real allowance for the drill diameter, apart from selecting the usual parameters (spin, feed, peck etc). TIR matters, of course.

    The obvious problem with a tiny drill is that the flutes don't have a lot of space for the chips. I go quite conservative about chip clearing. I normally use an air blast and pulsed misting, but I can't have been doing so in this photo. I may have turned the air blast off just for this photo.

    How deep - at least 3D. If the peck is no more than D/5 the flutes don't fill up. That swarf was very thin: it looks lumpy because it is coiled up.

    Good drill brands like Dormer go down to 0.3 mm with a conventional drill design. Below that I use swiss drills with something like a 1 mm shank. I find a head-mounted magnifier essential too!

    EDIT: what was critical to the success was the rigidity of the bottom part of the jig. I use PE for the top part - flex there does not matter, but I had to use Corian for the bottom part. I also had to get the hole or grovve just right. Otherwise any movement of the Ti wire would wreck the whole exercise.

    Cheers
    Roger



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

    Default Re: Tormach's deprecation of advanced gCode features

    Quote Originally Posted by RCaffin View Post

    The use of FUP[] is heart and soul to good parametric programming. Consider the following:
    #1=5.38 % start position for machining
    #2=5.12 % end position
    #3=[#1-#2] % distance to be machined
    #4=0.35 % maximum safe cut
    #5=fup[#3/#4] % N the number of machining cycles needed for that depth with less than max cut
    #6=[#3/#5] % the machining depth per cycle needed for N cycles
    #7=#1 % working axis parameter
    m98 p10 L#5 % machine N cycles
    Yes, I use fup everywhere, almost always in the same way you do, starting with a raw DOC or WOC, seeing how many of those it would take to get to where I want to go, and then taking fup(that many) passes, reducing DOC or WOC so that it comes out even.

    If you want to machine down until the Dykem is all gone, you are mixing manual machining with CNC. You can do it if you think it through.
    Step 1: run the above with 'safe' values for start and end.
    Step 2: estimate how nuch deeper you need to go. EDIT program, making #2=(old #1), and make new #2=(that much deeper).
    Step 3: rerun program.
    Most of my utility programs are set up this way.
    That would work, but I'm happy waiting for the Dykem to go away and hitting reset. It really is like waiting for the right moment to disengage the power feed on a manual lathe, although it's easier, because one can build a pause into the gCode.

    I use Mach3, and it too can hang if it encounters an infinite loop. Sometimes it stops in disgust and tell me about it; other times I just hit STOP (not eStop) and the program stops. Can't you do this in PP?
    No. When PP is busy simulating, it is incommunicado.

    Someone complained that PP does not support arrays of variables. Mach3 certainly does, WITHIN NIST G-CODE, so PP should also. You use them like this:
    #1=27 % index pointer within array
    #2=100 % array start in parameter space
    #3=#[#2+#1] % #3 = #[100+27] = #127
    I routinely load about 400 parameters from an auxiliary file into a program and access them this way.
    It was I who complained, and as a formal matter you're certainly right. I knew that gCode's # operator could be used like this, and so yes, one can create arrays of the numbered parameters, but I was thinking of arrays of named parameters. There's no functional difference, but I have trouble keeping track of things that don't have names.

    Conditionals: not so easy, but still can be done within NIST g-code. For a start, consider:
    m98 p10 L#1
    This will call SR o10 IF #1>1, but it will not call it if #1=0. How to set up #1 is simple maths. There you have an IF THEN statement. A little more cunning in manipulating #1 can give you the ELSE part.
    I knew that this could be done. Indeed, NIST gCode is a Turing machine. But again, I find these constructions so opaque compared to the control structures available in PathPilot's version of gCode that I wrote them off. If I had been limited to bare-bones NIST gCode, I might not have bothered to try to create utilities for myself. Alternatively, I might have written some sort of compiler to generate gCode from some sort of structured language; that would have been a fun project, I guess, but I'm still glad I never felt the need to do it.

    Disclosure: like Fenichel, I too started programming around 1968.
    Well, I actually started a bit before that, but my first publication (not counting some squibs in Computing Reviews in 1967) was in 1968.



  12. #52
    Member
    Join Date
    Jun 2010
    Location
    Australia
    Posts
    4252
    Downloads
    4
    Uploads
    0

    Default Re: Tormach's deprecation of advanced gCode features

    Going below 0.3 mm is a bit more tricky because of TIR.
    Attachment 366832
    Precision mounting jig for the part to be drilled in the lathe chuck, but really if the hole is 0.2 mm off centre it is not a problem. The Albrecht chuck holding the drill bit is mounted on the saddle with a precision vertical slide holding it. That lets me adjust both horizontal and vertical offset to within 10 microns of the actual spindle axis, so the drill tip does not wiggle too much. I do use a 1 mm D-bit as a starter for this as there may be a tiny pip on the part face. Drill depth is about D or 2D. I don't overshoot by much - maybe another D.

    But brass is easy.

    Cheers
    Roger



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

    Default Re: syntax non-checking in PathPilot

    You`re Robert R. Fenichel of garbage collection fame?



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

    Default Re: Tormach's deprecation of advanced gCode features

    Your link doesn't work for me.

    Be that as it may, the rest of your post continues to impress me. As I noted a few posts ago, I may be an old programmer, but I'm new to CNC. What is the project that requires your ultraprecise work?



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

    Default Re: syntax non-checking in PathPilot

    @kstrauss
    Yes, I admit it.

    Last edited by Fenichel; 07-03-2017 at 07:24 PM. Reason: added indication of addressee


  16. #56
    Member
    Join Date
    Apr 2017
    Location
    Canada
    Posts
    156
    Downloads
    0
    Uploads
    0

    Default Re: syntax non-checking in PathPilot

    Quote Originally Posted by Fenichel View Post
    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
    I found myself wasting too much time tracking down syntax errors in subroutines, so I wrote a gCode syntax checker. It covers most of the syntax accepted by PathPilot. Look here to get a copy.



Page 3 of 3 FirstFirst 123

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