ArcEye
commented
6 years ago 
This is quite clear in it’s description of the structure and limitations of the existing architecture. I need to think on your new requirements a bit, and don’t want to give you a reply that is not well thought out. However, my VERY initial impressions are that we still have some things pathologically coupled, left over from our legacy. Just thinking aloud at the moment, but want to give you food for thought.
Can we make an interpreter instance stateless relative to machine state? Each interpreter instance is a process, and furthermore, it is recursively executable. Let’s try to eliminate the notion of a periodic SYNCH in favor of a different paradigm.
We have a situation today where task and interpreter have a little dance, each keeping a copy of “state,” and the notion of queue-buster and synch due to redundant and possibly outdated machine states. The "state” should be thought of as it’s own object, and maintained as such, as a shared service with multiple subscribers, and NOT an attribute of any interpreter instance. Of course it would have the appropriate integrity structures build around it to prevent concurrent/destructive update as in any shared data structure. But, primtiives such as get_state and set_state should be interlaced throughout an instance of any interpreters execution (and everybody else’s execution who consumes or updates it). It is each subscribers responsibility to get the current state prior to initiating any actions. In the interpreters case, this would be its output.
The only state the interpreter needs to keep as it’s own are variables related to looping and conditionals in G code. But here is where the beauty of recursion comes in. The instance of the interpreter that is running a conditional block keeps the looping context (this is an appropriate state for the instance to keep as it is a function of that instance, not the machine), and delegates the execution of each line within the block to recursive execution. Given such a structure, hitting PAUSE in the middle of a conditional block of code that relies on a PARAM, then executing a MIDI line which changes that PARAM , then resuming with CYCLE start and having the loop behavior change should not be an issue at all. In other words, one can always execute a single line of G-code from anywhere.
My ignorance of Linuxcnc may come out here, so what follows may be useless opinion. Each line of code needs an identifier, as you aptly pointed out, so that all subscribers know exactly where the code was when a stop or abort occurs. The current line should be part of the system state, set by each interpreter instance. We need a way to properly denote MDI vs file originated lines of code. For that matter, the “current line” needs to be a stack structure. Think in terms of a main line g code program, executing an O work file, which is interrupted by a PAUSE, and then a MDI line, and then resumed via RUN. Each interpreter instance involved in this stream needs to add and delete it’s current line from the stack as appropriate. If motion control is executed synchronously (not sure if this is possible), as opposed to consuming Canon’s output queue, keeping track of where we are relative to source input becomes a matter of popping the “ current line “ stack. If this is not possible, then the current line id needs to be interjected into motion control’s input queue as a bookend structure.
Some other thoughts on enhancements top think about later. Solicitation of input from the user from the interpreters context, and allowing for blocking is handled nicely by your scheme. However, the practicalities of getting the input can be dicey from a GUI and programming point of view. Let’s make it simple for the non-programmer to get user input. Might it be possible to invent some G or M codes that can be embedded in an O word routine that would allow users prompt the machine operator easily. Perhaps a dialog box in the GIMP window? Or a message text field that appears in that window? Some PARAM that can be tested with G-Code when the dialog box is answered. I know that Tormach is playing with a similar implementation for their mill controller.
The way the G-code interpreter is integrated into task is seriously convoluted and suggests reconsideration.
This document describes the status and issues: https://github.com/mhaberler/asciidoc-sandbox/wiki/Interpreter-control-flow-explained
A prelimimary requirements draft is here: https://github.com/mhaberler/asciidoc-sandbox/wiki/Interpreter-API-requirements
The removal of NML does require a revision of task, interpreter and the task/motion interfaces anyway, so it makes sense to redesign this API.
This is a high-priority item because it needs to be addressed before the task/motion/interpreter complex can be switch away from NML.