On Mon, Aug 17, 2015, at 12:29 PM, andy pugh wrote: > On 17 August 2015 at 16:49, John Kasunich <jmkasun...@fastmail.fm> wrote: > > If you start thinking about this from a timing/synchronization perspective, > > then > > there is nothing magic about reading the pins when you hit RUN. It could > > just > > as easily be "read the pins when you encounter custom M-code Mxxxx", or > > when you encounter magic comment (halread <halname> <named_param>). > > Maybe I have unnecessarily muddied the waters when I said that the > values are read when you press "Run". > That isn't technically correct. The values are read when the > interpreter interprets the line. What i meant to suggest is that you > wouldn't want to be relying on the G-code seeing your new value if you > change it after the G-code has started.
Yuck. That means if you use a #<_hal[hal_name]> expression twice (or inside a loop), the same expression could give different results if the HAL signal changed. AND, thanks to read-ahead, you don't even know exactly when it will be sampled. I like Ken's version better. The read from HAL happens once (either explicitly at start, or in the case of the magic comment version, when the interp reaches the comment). Then the value is stored in a named parameter, and doesn't change unless the g-code explicitly changes it, either by re-reading, or by assigning to that named parameter. > It would be possible to make the existing format a queue-buster, and > that would have the same effect as the magic-comment. The > magic-comment is just a different way to do exactly the same thing > that Jeff dislikes the idea of. > > (I am not sure I quite understand the basis of Jeff's objections, > unless it is actually that a HAL pin value is being read without > actually appearing in the HAL file?) On that note - I'd favor it being able access HAL signals only, not pins. If you want to access a pin, hook a signal to it. And you can name the signal in a more meaningfull way. > -- > 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 -- John Kasunich jmkasun...@fastmail.fm ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
