Try with
O103 repeat 22
O103 endrepeat
22 must be between brackets but can't find them on my keyboard
Jeff
The Oh-numbers of a gCode program must be unique, and PathPilot will not accept code like
If the same Oh-number is used in two different filed subroutines, one might expect either thatCode:o 100 repeat [5] G00 X1 G00 X2 o 100 endrepeat o 100 if [#1 GT #2] G00 X3 o 100 endif
- 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
and the two subroutines areCode:o <first> call o <second> call M30
andCode:o <first> sub (msg, first) M98 P100 o <first> endsub o 100 (internal subroutine) (msg, first) M99 (return to caller)
then the output is not first-first-second-second. Instead, it is first-first-second-first.Code:o <second> sub (msg, second) M98 P100 o <second> endsub o 100 (internal subroutine) (msg, second) M99 (return to caller)
Similar Threads:
Last edited by Fenichel; 11-18-2017 at 04:37 PM. Reason: typo
Try with
O103 repeat 22
O103 endrepeat
22 must be between brackets but can't find them on my keyboard
Jeff
@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.
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.
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?
@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
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.
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.
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.
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,