Hi Jeff,
I agree with you from an information hiding standpoint.
Here is an example where I found it useful.
I built a probing program that is tied to my MPG (using xhc-hb04). I
modified the driver so that some of the pins show the direction of the last
motion -- which axis and which direction.
Then, when I hit the button on the MPG labelled probe-z, the probe will
move in the direction of the last motion and finds the edge.
This functionality relies on existing code that can cause a gcode
subroutine to be called based on assertion of a hal pin. The called
subroutine is specified in the ini file.
I could have specified a separate subroutine for each axis and direction
(six in my case), but that would lack elegance. [Actually, I would need six
MDI commands specified in the ini file, but all of them would call the same
subroutine, but with differing arguments. That doesn't seem too bad --
although it would require additional changes to xhc-hb04.cc.]
I would be happier if the "driver" could just read and set values of
(global) named parameters. [I'd also like MDI commands to have access to
named parameters. -- but that's a different issue.]
Getting back to your the crux of your argument (I agree) that hal pins are
creatures belonging to developers and integrators, I would suggest that
(named) parameters belong to users. Then using (global) named parameters
for this function would be appropriate.
Now all we need is a hal component that can convert a pin value into a
named parameter value (and vice versa). That would become a place where the
integrator and user meet.
Regards,
Ken
On Mon, Aug 17, 2015 at 10:24 AM, Jeff Epler <jep...@unpythonic.net> wrote:
> I remain very strongly opposed to rs274ngc reading HAL values directly.
> Use the existing M-codes for that purpose.
>
> The design of HAL is that components create pins, and integrators use
> signals to link pins to create working systems.
>
> This means that for example, motion doesn't have to have any knowledge
> about whether a commanded position goes to stepgen.0.position-cmd
> or to pid.0.input.
>
> 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 appreciate that some people feel the functionality available from
> M-codes is too restricted, but this is not the right solution.
>
> We should start with some well-motivated examples ("user stories") where
> the current M-codes are not adequate, and design a new solution which
> does not break the normal abstraction of HAL.
>
> Jeff
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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
