Hi Andy,
I haven't looked at that code since I wrote the original and I assume that
it has been modified if not completely replaced. I can probably add some
insight to what is supposed to be happening.
1 -- There are two phases to interpretation of o<xxx> sub lines. In the
first phase, the sub is being defined. In the second phase, the sub is
being executed.
2 -- In the first phase, the o word is defined and the line and file name
are remembered. The rest of the code is skipped until the o<xxx> endsub
line.
3 -- In the second phase, the sub is executed because it has been called.
When a o<xxx> call line is seen, the interpreter saves (pushes) the stack
and jumps to the file and line that has been previously saved. Note that
(if I call correctly), if the sub has not yet been defined, the interp
looks further in the current file and then looks for an external file. In
that case, there will not be a separate first phase.
4 -- When a file is read during the first phase, if a sub with the same
name is hit, a duplicate o word error will be generated. When I say first
phase what I really mean is that a sub has been hit while scanning for the
next line.
I've seen a similar thing happen when I call a subroutine using MDI. First
I call it. That's not a problem. I call it again. That's not a problem. I
see that it isn't working properly for some reason and I edit the file --
adding or removing a line someplace. Then I call the sub again. Now, some o
word has a different line number. That is detected by the interp and an
error is generated. I call the sub a 4th time and it works properly. I'm
not sure if this just occurs with sub lines or other o word lines, too.
So, part of the story is that the interp notices that the o word line no
longer has the same [file, line number]. That might be an important clue.
To try to find the cause of this problem, I'd enable tracing to show the
[file, line number] of each o word as it is interpreted. There might
already be a debug line in the file that does that. If not, it should be
easy enough to add. My guess is that some of the python code is not
preserving the [file, line number] ordered pair.
Regards,
Ken
On Wed, Aug 5, 2015 at 11:08 AM, andy pugh <bodge...@gmail.com> wrote:
> On 5 August 2015 at 15:41, EBo <e...@sandien.com> wrote:
> > What whitespace problem?
>
> A speculative one that might not exist. It was a guess.
>
> The first time through the G-code routine
> 860 if (control_find_oword(block, settings, &op) == INTERP_OK) {
> returns false for both "if" statements.
> The second time through it returns "true" for both "if statements"
> On this second pass, at the first "if" statement
> 861 if (settings->sequence_number != (op->sequence_number + 1))
> returns false.
> The second time line 861 returns true and raises a spurious error.
> On the third and subsequent invocation 860 is back to returning false.
>
> The error is only raised in MDI mode, not when calling toolchanges from
> G-code.
>
> I don't actually understand yet what those test are checking.
>
>
> Sometimes, even more puzzlingly, the error raised is "O word sub
> redefinition" (I will try to get the exact wording when I get home to
> the test machine).
>
> --
> atp
> If you can't fix it, you don't own it.
> http://www.ifixit.com/Manifesto
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
Kenneth Lerman
55 Main Street
Newtown, CT 06470
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
