On 2020-04-10 4:02 a.m., andy pugh wrote:
On Fri, 10 Apr 2020 at 00:53, Chris Morley <chrisinnana...@hotmail.com> wrote:
I could definitely see that in remap, though I thought you could do this
already with python.
and python not gcode is the way i would keep it.
Python remaps are not a particularly convenient way to do tool changes
that need axis movement.
There are lots og G-code remaps out there for tool changing, automatic
tool length measurement and such.
The main application for this would be to read the _current_ state of
HAL pins without having to wire them up to a motion.analog-in-nn pin
and play the #5399 game.
Currently the trick is to use an M66E0L0 dummy command, as that causes
a synch. In fact it is already accepted that M66 and (input) friends
have to be queue-busters.
It was recommended to me by Mah that using gcode remaps for more then
simple things is fraught with problems. Some one did come across this -
I brokered a fix - and it required using python rather then gcode. IIRC
Mah said that it would be a lot of work to fix the problems with gcode
remaps. Making something that is brittle easier might not be the way to
go. Gcode is for running the machine, we should be careful about
exposing too much of linuxcnc's internals to an operator.
If we truly want to make tool change movement flexible (and many other
things such as jog while paused), I think we should think about Mah's
multiple interpreter list work.
Anyways if you want to remap linuxcnc's internal code, I think learning
a little python is not too much to ask. We really should add more
example and docs though.
Chris
Chris
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
