Normally I am a top poster, but I will try to insert my replies below as Stephen did.
> -----Original Message----- > From: Stephen Wille Padnos [mailto:[email protected]] > Sent: Monday, May 17, 2010 10:15 AM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] Jog under PAUSE / tool cnange > > 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) Backtracking would be nice, but I figure it is best to keep the problem and proposed solution as simple as possible at first. > > 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. In this case, I am only considering Run From Here as that seems to me to be the only way to reliably restore the machine state. > > 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) Yes, I was hoping that after Pause brought the machine to rest, that there would be information available about exactly where along the cut path the machine stopped. Reversing the math of offsets etc. to determine the proper values in G code to represent the location where the machine Paused will be tough because (I assume) that this information is only available in absolute machine coordinates. > > 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. Hopefully using the Run From Here approach would recreate the current machine state accurately. The only place I expected to get down to the motion control level was in extracting the information needed to break the motion command into two parts. > > 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. No offense taken about understanding John's comment. I acknowledge that I am trying to fiddle with the design of something that I have not taken the time to fully understand. In my defense, I did say that I only expect the proposed approach to work if you are willing to use Run From Here to re-read and process the file to re-establish the valid machine state. One thing I now see that I overlooked is the effect of blending on the data available for constructing the splice point. Steve Stallings ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
