On 17 August 2015 at 15:24, Jeff Epler <[email protected]> wrote: > As implemented, HAL access from gcode appears to refer directly to *pins > created by other components*, breaking this structure. So for instance > if an integrator writes remap code which refers to > #<_hal[stepgen.0.position-cmd]> that code is not going to work on a > system which uses anything but software step generation.
I can't decide whether you think that this would be a plausible use case? I can certainly see no reason that G-code would want to read-in a stepgen position, (or a pid command, for that matter). The typical use-case is passing values from a PyVCP or Glade panel into a piece of mutable G-code. One could legitimately argue that mutable G-code is also an abomination of non-portability, as one can't guarantee that it will run on any machine that it is taken to. It all depends where one draws the line. Taking the example of a PyVCP panel that supplies information to a threading routine. Pitch, depth, nominal diameter, tool number, surface speed etc _can_ all be passed in via Analog-inputs (if you reconfigure motion to have enough of them) but it is a bit clunky. You also need to keep track of which numbered pin is connected to which PyVCP pin at the point that you read them in to the G-code parameters. Even in this caase, portability is not assured, because once again the HAL config might be different. At least if the G-code is trying to read #<_hal[PyVPC.thread_pitch]> it either gets the right number or (I think) raises an error rather than accidentally picking up the spindle temperature. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
