> > 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 > > > > There is one (nasty) thing when run from line is applied. The queue is cleaned and program resume from selected line but not with correct modal parameters!
For example: I run the program and somewhere hit stop. I do whatever I want and after that resume from selected line. Or example 2: I just finish very long roughting part and decide to turnoff machine beacouse is time to go to sleep. In next day just turn on machine select proper point on program (eg finishing pass) and start from selected line. ... and got error like F parameter not set or similar "nonsense" As run from selected line just do RUN FROM SELECTED LINE! and if machine is metric and in 1'st line you have G20 then part come out realy big. and if somwhere within program some variables are set after Run from selected line they have big chance to be wrong. So be aware from STOP / JOG(go to take beauty sleep) / Run from selected Line sequence. Can be very unpredictable. The solution is that when Run from selected line is executed the parser run program from start without motion til got selected line. Of course this is not easy too. Just imagine probe move here :D Slavko. ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
