On Tue, 18 May 2010 10:43 +0100, "Andy Pugh" <[email protected]> wrote: > On 18 May 2010 01:01, John Kasunich <[email protected]> wrote: > > > I'll bet anyone a pint of their favorite beer that for any suggested > > implementation of run-from-line, I can come up with g-code that breaks > > it. > > On the basis that I owe all the devs a fair number of beers already: > > Pause is hit: > Save all modal parameters (spindle speeds, coolants, all variables-I > don't think we can allow changes to any variables)
The variables are maintained by the interpreter. The interpreter runs many lines of g-code ahead of the actual cutting operation. So when you hit pause while the cutter is cutting line N1000 of the g-code program, the interpreter is reading, interpreting and queuing line N1365 or so, and the interpreter state is whatever corresponds to line N1365. The variables and interpreter state as it was at line N1000 no longer exists, so it can't be saved. > Save the motion queue and the fraction of the current move completed. The motion commands in the queue are in absolute machine coordinates, with no offsets, etc. That is all you can save. > Clear the queue > Allow one straight, linear jog out of the work and save its end point. Are you saving this position in absolute machine coordinates, or in "g-code" coordinates (corresponding to the number on the DRO, which includes the effects of G54, etc.)? > (If you can't get out in one linear jog, sorry) > Allow freeform jogging to do whatever you want to do. > Hit resume. > Rapid to the end of the "escape" jog. Rapid back to the same absolute machine position? or to the same DRO reading? If the latter, what happens if one of the things you did while out of the cut was either change the offsets, or select a new coordinate system? > Rapid to the saved position in relative coordinates. I'm not sure what you mean by relative here. > Compare the current absolute position to the prior absolute position. > calculate any offsets. > if there are any offsets, then add the offsets to all moves in > the old motion queue. Oh, I think I'm finally (on the third reading) figuring out what you are up to. You are avoiding my initial objection (interp at line N1365 while tool is stopped at line N1000) by NOT re-interpreting any lines, you simply apply corrections directly to the queue data. Interesting approach. I'm pretty sure it would work if the only thing that you did was change offsets in X, Y, and Z. It would be bad if you actually selected a new coordinate system (G55, etc), but that doesn't seem like something you would do. Not sure what effect it would have on a 5 axis system if you changed one of the angular axes. But one thing that would kill it is if you changed tool diameter (replaced a broken tool with a regrind for example). Cutter diameter compensation is done by the interpreter, and you can't simply add new offsets to all the moves in the queue to change the amount of cutter comp. Imagine an uncompensated path that looks like: N1010 G1 X0 Y0 N1020 G1 X1 N1030 G1 Y1 The uncompensated path goes right, then up. If you are conventional milling, the cutter is on the right side of the cut line. Assume a cutter radius of 0.1". The actual path goes from X0 Y-0.1, in a straight line to X1 Y-0.1, then in an arc to X1.1 Y0, then in a line to X1.1 Y1. If you change the tool radius to 0.2 inches, the first line of the new path moves down in Y, the arc keeps the same center but gets a bigger radius, and the second line moves to the right in X. That can't be done by simply offsetting each item in the motion queue. > Restore the modal parameters. Restoring the interpreter state back to what it was after interpreting line N1365. > Restore the motion queue. Restoring the data for lines N1000 thru N1365 (potentially modified to account for offset changes). > > Continue. This is a clever approach to avoiding the problem of winding the interpreter back to line N1000 where you stopped. I don't know if the cutter comp issue is the only thing that would break it, that needs more thought. Regards, John Kasunich -- John Kasunich [email protected] ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
