Steve Stallings wrote:
> One of the many problems with Jog under Pause is
> that a pause can interrupt a partial move.
>
Neglecting specially-shaped cutters (keyway, T-slot), and also
neglecting niceties like tangent arc entries to arc moves (probably
impossible since EMC doesn't know what the part is), this isn't a huge
issue. Linear moves are trivial to continue from where they were left
off, and arc moves aren't terribly hard ("simply" save the center point
and radius, and you can figure out where in the arc the program was
stopped. It's not necessary to go to exactly that spot, and in fact it
would be nice to have an option of backtracking along the move a little
anyway)
> Run From Here can get you back to the beginning
> of the interrupted move.
>
This is probably the best thing to do in most cases anyway, the notable
exceptions being loooooong moves (boring!) or canned cycles.
> How hard would it be to have EMC figure out how
> to break the interrupted move into two pieces so
> that it could bring you back to the splice point?
>
Or close to the splice point - easy. In fact, I think there's a
variable in the motion controller that goes from 0 to 1 as a move is
executed - it lets the motion controller know how far it has to go in
this move. (I don't know the specifics, I just recall that there's a
variable for that)
> Could this be successfully managed even if the
> interrupted move was in a subroutine?
>
Depends on where you do the interrupting. The motion controller sees a
bunch of motions in the queue, not a loop or subroutine. It does arcs
and lines, and manages blending between them (as well as accel/vel
constraints and such). A subroutine or loop just results in more than
one motion being put in the queue. Note that variable values, loop
conditions, etc. are all irrelevant at the motion controller level - all
the motion parameters are just numbers at this level.
> If it could be done, it should be a way to allow
> tool offsets to be altered during the pause.
>
It seems a lot of people either didn't fully read John's email, or
didn't fully understand the implications of it. (I'm just responding to
Steve because this happens to be the last email I read - nothing
personal :) )
Offsets are applied in the interpreter, and the already-offset motions
are queued for the motion controller to execute. If you change the tool
offset, the queue has to be discarded and re-filled with a new set of
offset motions. Executing G-code can change the interpreter state, e.g.
by changing variable values (or coordinate offsets, G90/91 motion modes
...). This increases the complexity of re-running code quite a lot,
since we would need a way of returning the interpreter to the state it
was in when the executing motion was queued. That's not an easy problem.
- Steve
------------------------------------------------------------------------------
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
