On Mon, Aug 17, 2015, at 02:11 PM, John Kasunich wrote: > > > 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.
To elaborate on this a bit. All the use cases so far would be perfectly happy reading when you press RUN. And if you put the magic comments before any motion commands, that is exactly what you'd get. All the reads would happen in the first millseconds of the program run, before anything winds up in the queue. So if someone nudges the GUI widget one hour into your two hour program, no harm done - the value of the widget is safe in the named parameter. If you want the operator to set the widget at some point in the program, you can program a comment telling him what to do, then a pause, then after the pause you use magic comments to re-read the GUI widget into the named parameter again. > > It would be possible to make the existing format a queue-buster, and > > that would have the same effect as the magic-comment. Except the magic comment lets you do it once, instead of every time you evaluate the expression. In addition to the risk of the value changing, you'd rather not generate a queue buster every time you evaluate the expression, if it is in a loop or something. > > 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?) > > -- > > atp -- John Kasunich jmkasun...@fastmail.fm ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
