[tmarks11]

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.

[kstrauss]

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?

[Fenichel]

@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

o 100 if [#5410 GT 0.5]
    G01 kjhkjh
o 100 endif

[GITERDUN]

@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

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

[TurboStep]

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

[tmarks11]

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.

[kstrauss]

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.