How about tagging each move? Each move has a unique number. If you stop to change tool halfway through the system knows exactly what move it is on and how far through that move it is. For instance you may be 50% through move 5227.
When you restart, the interpreter dry runs the code using the new tool offsets until it hits move 5227. This could be in the middle of a subroutine, or canned cycle. It doesn't matter where it is. You now need to set the coolant/spindle outputs to the result of the dry run then restart from half way through that move. This is pretty much a variation of the existing 'run from here' code that my tool change hack takes advantage of. The current code already tags moves with the current line number so this would just be extending that function. If you are part way through a CV blended move you won't be able to start in exactly the same point you stopped but it should be close enough to make no real difference. Pausing and restarting with the existing code probably results in slightly different blended tool paths. I suppose in theory you could tag the output of the TP and dry run it as well. This should end you up in exactly the same place you started. The only time I can see that this would fall over is if you use incremental code from the start or if you use clever subroutines that generate different code for every run. I don't think any system is going to be totally fool proof. However the current 'run from here' code has the same limitations and has been in use for some time now. Les Stephen Wille Padnos wrote: > > 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
