bug in PathPilot 1.9.13

Results 1 to 12 of 12

Thread: bug in PathPilot 1.9.13

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

    Default bug in PathPilot 1.9.13

    The Oh-numbers of a gCode program must be unique, and PathPilot will not accept code like
    Code:
    o 100 repeat [5]
        G00 X1
        G00 X2
    o 100 endrepeat
    o 100 if [#1 GT #2]
        G00 X3
    o 100 endif
    If the same Oh-number is used in two different filed subroutines, one might expect either that
    • their scopes would be construed as limited to their respective files, so the authors of the two subroutines would have no obligation to coordinate their work, or
    • PathPilot would complain about the conflict.

    In fact, neither of these happens. What seems to happen (I have not done extensive testing to characterize the bug, but I think this is right) is that the second appearance of the Oh-number is ignored, and references to that Oh-number will be taken to refer to its appearance in the subroutine called earlier.

    For example, if the calling program is
    Code:
    o <first> call
    o <second> call
    M30
    and the two subroutines are
    Code:
    o <first> sub
        (msg, first)
        M98 P100
    o <first> endsub
        o 100  (internal subroutine)
            (msg, first)
            M99 (return to caller)
    and
    Code:
    o <second> sub
        (msg, second)
        M98 P100
    o <second> endsub
        o 100  (internal subroutine)
            (msg, second)
            M99 (return to caller)
    then the output is not first-first-second-second. Instead, it is first-first-second-first.

    Similar Threads:
    Last edited by Fenichel; 11-18-2017 at 04:37 PM. Reason: typo


  2. #2
    Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    666
    Downloads
    0
    Uploads
    0

    Default Re: bug in PathPilot 1.9.13

    Try with

    O103 repeat 22
    O103 endrepeat

    22 must be between brackets but can't find them on my keyboard
    Jeff



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

    Default Re: bug in PathPilot 1.9.13

    @jeffrey001
    I think you missed my point. The first example I gave was intentionally bad:

    • oh-numbers must not be reused,
    • it's easy enough to avoid reusing them within a given program, whether one is writing it oneself or designing a CAM system to generate gCode, and
    • PathPilot properly discovers within-file violations, as in my first example.

    My point was that without knowing what oh-numbers were used within a filed subroutine, it's impossible to reliably avoid reusing oh-numbers. PathPilot might construe oh-numbers within filed subroutines to be scoped there, or it might detect the reuse as a conflict. Instead, it allow for results that are unlikely ever to be intended.

    Get a proper keyboard.



  4. #4
    Member tmarks11's Avatar
    Join Date
    Jul 2004
    Location
    United States
    Posts
    1424
    Downloads
    0
    Uploads
    0

    Default Re: bug in PathPilot 1.9.13

    I wouldn't call it a bug if you improperly write g-code, and then somehow expect Pathpilot to debug your code for you.

    Naming two subroutines the same, and then complaining because Pathpilot is happy to execute the code, just ignoring all future instances of the same named subroutine? Not a bug.

    PathPilot is there to execute g-code, not help you write it.

    btw, this is the way EMC has always worked. Which is the core of Pathpilot.

    Tim
    Tormach 1100-3 mill, Grizzly G0709 lathe, PM935 mill, SolidWorks, HSMWorks.


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

    Default Re: bug in PathPilot 1.9.13

    I took a look at https://searchcode.com/file/99892174...terp_o_word.cc

    From a very quick look it appears that LinuxCNC thinks that it is an error define the same O-word in two files. That is O-words are global. I haven't spent nearly enough study to understand how the test could fail and allow duplicate O-words to be defined.

    I'm unclear from your code snippets. Are the duplicate O-words in separate files?



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

    Default Re: bug in PathPilot 1.9.13

    @tmarks11
    I named two internal subroutines identically so as to demonstrate the problem. The subroutines intended to be visible had different names, of course.

    In mature software environments, people who trust each other exchange subroutines, often without the desire or competence, and sometimes without permission, to look into their innards. If the subroutines are not buggy or malign, there is no need to look inside them. That's been the key idea behind subroutines since, well, the days of Ada Lovelace.

    It should be possible for mutually-trustful members of the gCode community to confidently exchange subroutines, or confidently to call multiple subroutines from an upper level program, without regard to the subroutines' internals. Now it isn't.

    @ken strauss
    Yes, they were in separate files.

    My model of what is going on is that the phenomenon demonstrated here is another manifestation of PathPilot's non-separation of parsing and interpretation. If PP separated the two, invocation of a filed subroutine would presumably lead to that subroutine being parsed, identifying syntactic errors and (where possible) internal links. Then, the interpreter would be set loose on the output of the parse. Instead, we know that PP does no more parsing (not even lexical analysis) than it absolutely has to, so syntactic errors are discovered one at a time (or, depending on the data, never*), and the only scoping is that of non-underscore parameter names. The result here is that when an Oh-number referenced inside a filed subroutine has been seen by the interpreter in another subroutine, the interpreter has no way of knowing that the intended target of the reference is closer at hand.

    The clean fix here would be to have Oh-numbers within filed subroutines scoped to their respective files. I can imagine some (dirty) code that would be broken by this, so this fix might not be politic for Tormach to implement. The less-clean fix (issuing a Duplicate Oh Number diagnostic) might be technically harder, depending on the implementation of the interpreter.

    I will be putting together a Windows program to scan a collection of gCode subroutines to harvest a list of all the Oh-numbers in use.

    * For example, PathPilot will only sometimes detect the syntactic error in
    Code:
    o 100 if [#5410 GT 0.5]
        G01 kjhkjh
    o 100 endif


    Last edited by Fenichel; 11-18-2017 at 10:42 PM. Reason: identify addressee of replies


  7. #7
    Member
    Join Date
    Feb 2009
    Location
    usa
    Posts
    152
    Downloads
    0
    Uploads
    0

    Default Re: bug in PathPilot 1.9.13

    Quote Originally Posted by Fenichel View Post
    @tmarks11
    I named two internal subroutines identically so as to demonstrate the problem. The subroutines intended to be visible had different names, of course.

    In mature software environments, people who trust each other exchange subroutines, often without the desire or competence, and sometimes without permission, to look into their innards. If the subroutines are not buggy or malign, there is no need to look inside them. That's been the key idea behind subroutines since, well, the days of Ada Lovelace.

    It should be possible for mutually-trustful members of the gCode community to confidently exchange subroutines, or confidently to call multiple subroutines from an upper level program, without regard to the subroutines' internals. Now it isn't.

    @ken strauss
    Yes, they were in separate files.

    My model of what is going on is that the phenomenon demonstrated here is another manifestation of PathPilot's non-separation of parsing and interpretation. If PP separated the two, invocation of a filed subroutine would presumably lead to that subroutine being parsed, identifying syntactic errors and (where possible) internal links. Then, the interpreter would be set loose on the output of the parse. Instead, we know that PP does no more parsing (not even lexical analysis) than it absolutely has to, so syntactic errors are discovered one at a time (or, depending on the data, never*), and the only scoping is that of non-underscore parameter names. The result here is that when an Oh-number referenced inside a filed subroutine has been seen by the interpreter in another subroutine, the interpreter has no way of knowing that the intended target of the reference is closer at hand.

    The clean fix here would be to have Oh-numbers within filed subroutines scoped to their respective files. I can imagine some (dirty) code that would be broken by this, so this fix might not be politic for Tormach to implement. The less-clean fix (issuing a Duplicate Oh Number diagnostic) might be technically harder, depending on the implementation of the interpreter.

    I will be putting together a Windows program to scan a collection of gCode subroutines to harvest a list of all the Oh-numbers in use.

    * For example, PathPilot will only sometimes detect the syntactic error in
    Code:
    o 100 if [#5410 GT 0.5]
        G01 kjhkjh
    o 100 endif
    Try running this program- it may solve all your issues

    G0 x.5
    E1 y9
    T-. 7
    A .84
    L- 00
    I x40
    F.99
    E .01



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

    Default Re: bug in PathPilot 1.9.13

    Quote Originally Posted by GITERDUN View Post
    Try running this program- it may solve all your issues

    G0 x.5
    E1 y9
    T-. 7
    A .84
    L- 00
    I x40
    F.99
    E .01




  9. #9
    Member tmarks11's Avatar
    Join Date
    Jul 2004
    Location
    United States
    Posts
    1424
    Downloads
    0
    Uploads
    0

    Default Re: bug in PathPilot 1.9.13

    Quote Originally Posted by Fenichel View Post
    In mature software environments, people who trust each other exchange subroutines, often without the desire or competence, and sometimes without permission, to look into their innards. If the subroutines are not buggy or malign, there is no need to look inside them. That's been the key idea behind subroutines since, well, the days of Ada Lovelace.
    That might be true in software programming, but that principle really doesn't relate to industrial machining. Companies don't swap g-code subroutines back and forth.

    Trusting somebody else has programmed without reviewing it can easily be a $15k mistake. Little different than getting a syntax error when you try to run software.

    Shops might share CAD models in DXF or SLD form, but not g-code, since that tends to be machine specific.

    Tim
    Tormach 1100-3 mill, Grizzly G0709 lathe, PM935 mill, SolidWorks, HSMWorks.


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

    Default Re: bug in PathPilot 1.9.13

    A library of trusted subroutines is really no different from Tormach providing a library of fancy canned cycles with a UI that they call "conversational programming". I would love a library of well documented subroutines to implement special actions which my CAM doesn't nicely handle.



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

    Default Re: bug in PathPilot 1.9.13

    Is this a Pathpilot specific thing or generic to LinuxCNC? If the latter, Tormach is unlikely to address it themselves.

    Agree that G-code is extremely rarely shared in industry. Too many machine, tool, material and setup-specifics that aren't abstracted.

    It's like sharing assembly-language routines. Few people do it and fewer yet do it without examining the code. CAD models are the "high-level language" of CNC.



  12. #12
    Member
    Join Date
    Oct 2010
    Location
    USA
    Posts
    253
    Downloads
    0
    Uploads
    0

    Default Re: bug in PathPilot 1.9.13

    Just gonna put in my 2cents:
    1) I hate o-code. This is linuxCNC attempt at giving gcode 'some' features of a modern-ish language, such as branching, variables, indirection. But it's just a big f'ing kludge. It's not generated by any CAM program I know of, not portable, so on.
    2) Pretty sure, Lady Ada's intent was the storage problem they had in those days. You know like 500 cogs .. which never got built BTW,



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

bug in PathPilot 1.9.13

bug in PathPilot 1.9.13