Tom,

As I said, I currently only call InitializeInterpreter one time, immediately after the app starts up, when I first "connect" to the board. I won't call it again unless the connection to the board is lost, then re-established, which basically never happens.

Yes, the "G0 Z0" is an MDI command, which is executed by writing it to a temp file, then calling the interpreter. So, for all practical purposes, an MDI command is just another G-code file.

Under what circumstances *should* InitializeInterpreter be called? It's not clear to me exactly what it does, or when it's necessary to call it.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Tom Kerekes wrote:
>
> Hi Ray,
>
> Yes.  So what are you saying?  You did call it before the "G0 Z0" or not?  Was that issued with an MDI command?
>
> Regards
> TK
>
>
>
> ________________________________
> From: himykabibble
> To: DynoMotion@yahoogroups.com
> Sent: Friday, January 11, 2013 10:44 PM
> Subject: [DynoMotion] Re: StopImmediate...
>
>
>  
> Tom,
>
> No.... I only call InitializeInterpreter when I first connect to the board. Should that be done each time a G-code file is loaded (which is what MDI does)?
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes wrote:
> >
> > Hi Ray,
> >
> > If you are not doing a InitializeInterpreter() it would be expected to do such a thing as it is expecting that you wish to resume midway the original line of GCode "G1 X1 Y1 F5" .  Is your code calling InitializeInterpreter()before the MDI command of "G0 Z0"  ?
> >
> > Regards
> > TK
> >
> >
> >
> > ________________________________
> > From: himykabibble
> > To: DynoMotion@yahoogroups.com
> > Sent: Friday, January 11, 2013 9:40 PM
> > Subject: [DynoMotion] Re: StopImmediate...
> >
> >
> >  
> > Tom,
> >
> > I know I've seen it happen in the past on jogs, using my pendant, not going through the interpreter at all. I've actually made a habit of turning off the servos, and manually running the quill up until the tool is clear of the work, before doing ANY moves of any kind after a Stop because I've been bit so many times.
> >
> > I just tried right now on my backup board (no machine, no jog keys, no pendant). I zeroed all axes, then executed "G1 X1 Y1 F5". When I did the Interpreter.Halt, all axes stopped mid-move, as they should. I then went to KMotion, and did a "Move Z = 10000", and only the Z axis moved. But when I then did "G0 Z0", X, Y and Z ALL moved. Z went to 0, as it should. X and Y moved a few tenths, both stopping at the same, seemingly random, position between 0 and 1.
> >
> > It's always appeared to me it was doing the equivalent of what Mach3 calls a "preparatory move" to put the machine back to where the KFlop or the interpreter felt the machine *should* be. I could probably go do a video of it tomorrow if you want - I'm still running the old code on the machine.
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes wrote:
> > >
> > > Hi Ray,
> > >
> > > I'm stuck on your statement:
> > >
> > > >> My InterpreterStop was doing nothing more than a Interpreter.Halt, and
> > > this WILL consistently do an uncommanded move on the next commanded move following the Interpreter.Halt
> > >
> > >
> > > You aren't being clear on whether you are talking about a Jog or running GCode.  It makes a big difference.
> > >
> > > Regards
> > > TK
> > >
> > >
> > >
> > >
> > >
> > > ________________________________
> > > From: himykabibble
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Friday, January 11, 2013 8:19 PM
> > > Subject: [DynoMotion] Re: StopImmediate...
> > >
> > >
> > >  
> > > Tom,
> > >
> > > I can't explain it either, but it's quite consistent. With my kludgey work-around, it seems to work perfectly.
> > >
> > > You are correct about the confusion in terminology. I think we're on the same page on FeedHold - this is the "FeedHold" button in KMotionCNC, and the "Pause" button in Mach3. What I call "Stop" is, more or less, the StopSign button in KMotionCNC.
> > >
> > > FeedHold should gracefully stop all motion reasonably quickly - not instantaneously. I should then be able to resume motion by clicking it again. This works properly in my app, using StopImmediate0 to FeedHold, and StopImmediate1 to resume.
> > >
> > > For Stop, I may be looking for slightly different behavior than you have in KMotionCNC. Stop should stop all motion as quickly as possible, short of simply killing the axes, and also turn off the spindle and coolant (not your problem, obviously). If I want a "Stop right this instant, dammit!", I'll use E-Stop, which shuts down the servo drives. Ideally, Stop will stop in a state from which it can resume, assuming it was no in the middle of something that cannot be simply re-started from the current position. For example, if I hit Stop in the middle of an arc move, I expect to have to move the machine back to the start point of the arc, manually re-set the next G-code line, then hit Start. In general, I will not be able to simple hit Run to continue, but the machine should be left in a consistent state from which I CAN continue with just a little manual effort. But, I should NOT have to re-reference the machine. I would use this, for example,
> when
> > > I'm running a new program for the first time, and I can see it's headed for trouble. I want to make it quickly stop what it's doing, but in a way that I can easily back up a line or two, and re-start it, after correcting whatever problem I saw.
> > >
> > > My InterpreterStop was doing nothing more than a Interpreter.Halt, and this WILL consistently do an uncommanded move on the next commanded move following the Interpreter.Halt. The uncommanded move appears to be on whatever axes were moving when the Interpreter.Halt was issued.
> > >
> > > This sequence *seems* to reliably do what I want, I just can't explain why:
> > >
> > > KMController.WriteLine("StopImmediate0");
> > > KMController.CoordMotion.Interpreter.Halt();
> > > KMController.CoordMotion.Interpreter.Abort();
> > > KMController.WriteLine("StopImmediate2");
> > > KMController.WriteLine("StopImmediate1");
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes wrote:
> > > >
> > > > Hi Ray,
> > > >
> > > > I don't understand the un-commanded move following a Halt.ÃÆ'‚  There is a special condition that exists after a Halt.ÃÆ'‚  It is extremely complex to Halt the Interpreter in the middle of executing GCode and to be able to resume.ÃÆ'‚  There is a lot internal state that needs to be preserved so things can be handled properly.ÃÆ'‚  And if you do not want to make use of all this to resume the GCode sequence then you must clear the CoordMotion.m_PreviouslyStopped condition before launching the Interpreter.ÃÆ'‚  Calling the .NET interface InitializeInterpreter should clear this for you.
> > > >
> > > > But none of these issues should affect a Pendant Jog after a Halt and before doing any new GCode.ÃÆ'‚ 
> > > >
> > > >
> > > > KMotionCNC does NOT disable any axes on Halt.
> > > >
> > > > I think maybe we are confusing the terms "Halt" and "Stop".
> > > >
> > > > In KMotionCNC:
> > > >
> > > > "Stop" the big red Stop Sign is very simplistic and the most severe thing.ÃÆ'‚  It immediately Disables All Axes and immediately Kills the Interpreter no matter what it was doing.ÃÆ'‚  This should never really be required.ÃÆ'‚  The system is in a undefined state after this and must be re-initialized.
> > > >
> > > >
> > > > "Halt" is much more complex and graceful.ÃÆ'‚  First it FeedHolds all axes to bring them to an immediate controlled stop.ÃÆ'‚  It then clears the feedhold condition (StopImmediate2) which puts KFLOP in an idle state no longer executing coordinated motion. ÃÆ'‚  It then determines the point in time where the Axes really stopped.ÃÆ'‚  It then rewinds the Interpreter (which might be currently hundreds of GCode Lines and mode changes ahead) back to that point in time.ÃÆ'‚  And there are other considerations if a line of Gcode that was partially executed is to be later resumed.ÃÆ'‚  It sets the CoordMotion.m_PreviouslyStopped condition.ÃÆ'‚  It then sets the Abort condition to cause the Interpreter to terminate.ÃÆ'‚  On termination, callbacks to your application are made to inform the Application what really happened and the true state
> of things.
> > > >
> > > >
> > > > I don't see how at the point after a Halt has completed and everything is idle a Jog would not work correctly.
> > > >
> > > > Regards
> > > > TK
> > > >
> > > >
> > > >
> > > > ________________________________
> > > > From: himykabibble
> > > > To: DynoMotion@yahoogroups.com
> > > > Sent: Friday, January 11, 2013 5:59 PM
> > > > Subject: [DynoMotion] Re: StopImmediate...
> > > >
> > > >
> > > > ÃÆ'‚ 
> > > > Tom,
> > > >
> > > > But it doesn't.... I consistently get that destructive un-commanded move on the first move following the Halt. In fact, it even happens if I use the pendant to make the move, which does a jog, not involving the interpreter at all. I know you don't see it in KMotionCNC, but in there you're disabling all axes on a Stop, after doing a Halt followed by an Abort. I don't want to disable the axes, because then the machine needs to be re-referenced.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com, TK wrote:
> > > > >
> > > > > Regarding the StopImmediate 0, 1, 2 and KFLOP that is correct.
> > > > >
> > > > > But regarding the rest, no all you should need to do is issue Halt. All the rest should happen automatically.
> > > > >
> > > > > TK
> > > > >
> > > > > On Jan 11, 2013, at 5:17 PM, "himykabibble" wrote:
> > > > >
> > > > > > Tom,
> > > > > >
> > > > > > Tell me if this is correct:
> > > > > >
> > > > > > StopImmediate0 will set FeedHold, and stop all motion
> > > > > > StopImmediate1 will clear FeedHold, and resume motion from where it left off
> > > > > > StopImmediate2 will clear FeedHold, but will not resume motion
> > > > > >
> > > > > > After playing with it, this appears to me to be correct, which makes the answer to my other question:
> > > > > >
> > > > > > To Enter FeedHold => Do StopImmediate0
> > > > > > To Exit FeedHold => Do StopImmediate1
> > > > > > To Stop =>
> > > > > > Do StopImmediate0 to immediately terminate all motion
> > > > > > Do Halt
> > > > > > Do Abort
> > > > > > Do StopImmediate2
> > > > > > Do StopImmediate1
> > > > > >
> > > > > > Seems like a lot of steps, but the above *appears* to do what I want - Stop always stops all motion ASAP, but leaves the machine in a state where I can re-start the G-code execution from the line that was being executed (with the proviso that the start point *may* no longer be "correct" - for example if a G2 or G3 was in-process. Worst case, I can back up a few lines to code that re-positions the machine using G0/G1 moves to re-position the machine, then re-start execution.
> > > > > >
> > > > > > Does that seem correct to you?
> > > > > >
> > > > > > Regards,
> > > > > > Ray L.
> > > > > >
> > > > > > --- In DynoMotion@yahoogroups.com, TK wrote:
> > > > > > >
> > > > > > > That is correct. 1 - starts moving and will resume/finish the motion. 2 - exits the Feedhold state.
> > > > > > >
> > > > > > > TK
> > > > > > >
> > > > > > > On Jan 11, 2013, at 4:04 PM, "himykabibble" wrote:
> > > > > > >
> > > > > > > > Tom,
> > > > > > > >
> > > > > > > > I'm still confused about StopImmediate. The documentation says:
> > > > > > > >
> > > > > > > > 0 - Stops the axes motion (equivalent to User C Program function StopCoordinatedMotion)
> > > > > > > > 1 - Resumes the axes motion (equivalent to User C Program function ResumeCoordinatedMotion)
> > > > > > > > 2 - Clears the Feed hold state (equivalent to User C Program function ClearStopImmediately)
> > > > > > > >
> > > > > > > > What is the difference between 1 and 2? To my untrained eyes, they sound like exactly the same thing. Does not 0 *set* the Feed hold state? Or does 2 clear Feed hold, but does NOT resume motion?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Ray L.
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Brad,

I actually seem to recall being told, I believe by you, a year or more back that I only needed to call InitializeInterpreter one time, on startup. I believe I was previously calling it each time I fired off a new interpreter. I have no problem with calling it whenever needed, I just need someone to tell me when it's necessary. That said, my current kludgey work-around is working perfectly so far.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Brad Murry wrote:
>
> I looks like InitializeInterpreter is calling GcodeInterpreter.cpp->IntializeInterp after setting the origin to the first one in collection.
>
>
>
>
>
> In KMotionCNC, it looks like IntializeInterp is called when parameters are loaded in KMotionCNCDlg.cpp ->ExternalRestore()
>
>
>
>
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of himykabibble
> Sent: Saturday, January 12, 2013 2:34 AM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Re: StopImmediate...
>
>
>
>
>
> Tom,
>
> As I said, I currently only call InitializeInterpreter one time, immediately after the app starts up, when I first "connect" to the board. I won't call it again unless the connection to the board is lost, then re-established, which basically never happens.
>
> Yes, the "G0 Z0" is an MDI command, which is executed by writing it to a temp file, then calling the interpreter. So, for all practical purposes, an MDI command is just another G-code file.
>
> Under what circumstances *should* InitializeInterpreter be called? It's not clear to me exactly what it does, or when it's necessary to call it.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com , Tom Kerekes wrote:
> >
> > Hi Ray,
> >
> > Yes. So what are you saying? You did call it before the "G0 Z0" or not? Was that issued with an MDI command?
> >
> > Regards
> > TK
> >
> >
> >
> > ________________________________
> > From: himykabibble
> > To: DynoMotion@yahoogroups.com
> > Sent: Friday, January 11, 2013 10:44 PM
> > Subject: [DynoMotion] Re: StopImmediate...
> >
> >
> > Â
> > Tom,
> >
> > No.... I only call InitializeInterpreter when I first connect to the board. Should that be done each time a G-code file is loaded (which is what MDI does)?
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com , Tom Kerekes wrote:
> > >
> > > Hi Ray,
> > >
> > > If you are not doing a InitializeInterpreter() it would be expected to do such a thing as it is expecting that you wish to resume midway the original line of GCode "G1 X1 Y1 F5" . Is your code calling InitializeInterpreter()before the MDI command of "G0 Z0" ?
> > >
> > > Regards
> > > TK
> > >
> > >
> > >
> > > ________________________________
> > > From: himykabibble
> > > To: DynoMotion@yahoogroups.com
> > > Sent: Friday, January 11, 2013 9:40 PM
> > > Subject: [DynoMotion] Re: StopImmediate...
> > >
> > >
> > > ÂÂ
> > > Tom,
> > >
> > > I know I've seen it happen in the past on jogs, using my pendant, not going through the interpreter at all. I've actually made a habit of turning off the servos, and manually running the quill up until the tool is clear of the work, before doing ANY moves of any kind after a Stop because I've been bit so many times.
> > >
> > > I just tried right now on my backup board (no machine, no jog keys, no pendant). I zeroed all axes, then executed "G1 X1 Y1 F5". When I did the Interpreter.Halt, all axes stopped mid-move, as they should. I then went to KMotion, and did a "Move Z = 10000", and only the Z axis moved. But when I then did "G0 Z0", X, Y and Z ALL moved. Z went to 0, as it should. X and Y moved a few tenths, both stopping at the same, seemingly random, position between 0 and 1.
> > >
> > > It's always appeared to me it was doing the equivalent of what Mach3 calls a "preparatory move" to put the machine back to where the KFlop or the interpreter felt the machine *should* be. I could probably go do a video of it tomorrow if you want - I'm still running the old code on the machine.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com , Tom Kerekes wrote:
> > > >
> > > > Hi Ray,
> > > >
> > > > I'm stuck on your statement:
> > > >
> > > > >> My InterpreterStop was doing nothing more than a Interpreter.Halt, and
> > > > this WILL consistently do an uncommanded move on the next commanded move following the Interpreter.Halt
> > > >
> > > >
> > > > You aren't being clear on whether you are talking about a Jog or running GCode.ÃÆ'‚ÂÂ It makes a big difference.
> > > >
> > > > Regards
> > > > TK
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ________________________________
> > > > From: himykabibble
> > > > To: DynoMotion@yahoogroups.com
> > > > Sent: Friday, January 11, 2013 8:19 PM
> > > > Subject: [DynoMotion] Re: StopImmediate...
> > > >
> > > >
> > > > ÃÆ'‚ÂÂ
> > > > Tom,
> > > >
> > > > I can't explain it either, but it's quite consistent. With my kludgey work-around, it seems to work perfectly.
> > > >
> > > > You are correct about the confusion in terminology. I think we're on the same page on FeedHold - this is the "FeedHold" button in KMotionCNC, and the "Pause" button in Mach3. What I call "Stop" is, more or less, the StopSign button in KMotionCNC.
> > > >
> > > > FeedHold should gracefully stop all motion reasonably quickly - not instantaneously. I should then be able to resume motion by clicking it again. This works properly in my app, using StopImmediate0 to FeedHold, and StopImmediate1 to resume.
> > > >
> > > > For Stop, I may be looking for slightly different behavior than you have in KMotionCNC. Stop should stop all motion as quickly as possible, short of simply killing the axes, and also turn off the spindle and coolant (not your problem, obviously). If I want a "Stop right this instant, dammit!", I'll use E-Stop, which shuts down the servo drives. Ideally, Stop will stop in a state from which it can resume, assuming it was no in the middle of something that cannot be simply re-started from the current position. For example, if I hit Stop in the middle of an arc move, I expect to have to move the machine back to the start point of the arc, manually re-set the next G-code line, then hit Start. In general, I will not be able to simple hit Run to continue, but the machine should be left in a consistent state from which I CAN continue with just a little manual effort. But, I should NOT have to re-reference the machine. I would use this, for example,
> > when
> > > > I'm running a new program for the first time, and I can see it's headed for trouble. I want to make it quickly stop what it's doing, but in a way that I can easily back up a line or two, and re-start it, after correcting whatever problem I saw.
> > > >
> > > > My InterpreterStop was doing nothing more than a Interpreter.Halt, and this WILL consistently do an uncommanded move on the next commanded move following the Interpreter.Halt. The uncommanded move appears to be on whatever axes were moving when the Interpreter.Halt was issued.
> > > >
> > > > This sequence *seems* to reliably do what I want, I just can't explain why:
> > > >
> > > > KMController.WriteLine("StopImmediate0");
> > > > KMController.CoordMotion.Interpreter.Halt();
> > > > KMController.CoordMotion.Interpreter.Abort();
> > > > KMController.WriteLine("StopImmediate2");
> > > > KMController.WriteLine("StopImmediate1");
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com , Tom Kerekes wrote:
> > > > >
> > > > > Hi Ray,
> > > > >
> > > > > I don't understand the un-commanded move following a Halt.ÃÆ'Æ'‚ÃÆ'‚ÂÂ There is a special condition that exists after a Halt.ÃÆ'Æ'‚ÃÆ'‚ÂÂ It is extremely complex to Halt the Interpreter in the middle of executing GCode and to be able to resume.ÃÆ'Æ'‚ÃÆ'‚ÂÂ There is a lot internal state that needs to be preserved so things can be handled properly.ÃÆ'Æ'‚ÃÆ'‚ÂÂ And if you do not want to make use of all this to resume the GCode sequence then you must clear the CoordMotion.m_PreviouslyStopped condition before launching the Interpreter.ÃÆ'Æ'‚ÃÆ'‚ÂÂ Calling the .NET interface InitializeInterpreter should clear this for you.
> > > > >
> > > > > But none of these issues should affect a Pendant Jog after a Halt and before doing any new GCode.ÃÆ'Æ'‚ÃÆ'‚ÂÂ
> > > > >
> > > > >
> > > > > KMotionCNC does NOT disable any axes on Halt.
> > > > >
> > > > > I think maybe we are confusing the terms "Halt" and "Stop".
> > > > >
> > > > > In KMotionCNC:
> > > > >
> > > > > "Stop" the big red Stop Sign is very simplistic and the most severe thing.ÃÆ'Æ'‚ÃÆ'‚ÂÂ It immediately Disables All Axes and immediately Kills the Interpreter no matter what it was doing.ÃÆ'Æ'‚ÃÆ'‚ÂÂ This should never really be required.ÃÆ'Æ'‚ÃÆ'‚ÂÂ The system is in a undefined state after this and must be re-initialized.
> > > > >
> > > > >
> > > > > "Halt" is much more complex and graceful.ÃÆ'Æ'‚ÃÆ'‚ÂÂ First it FeedHolds all axes to bring them to an immediate controlled stop.ÃÆ'Æ'‚ÃÆ'‚ÂÂ It then clears the feedhold condition (StopImmediate2) which puts KFLOP in an idle state no longer executing coordinated motion. ÃÆ'Æ'‚ÃÆ'‚ÂÂ It then determines the point in time where the Axes really stopped.ÃÆ'Æ'‚ÃÆ'‚ÂÂ It then rewinds the Interpreter (which might be currently hundreds of GCode Lines and mode changes ahead) back to that point in time.ÃÆ'Æ'‚ÃÆ'‚ÂÂ And there are other considerations if a line of Gcode that was partially executed is to be later resumed.ÃÆ'Æ'‚ÃÆ'‚ÂÂ It sets the CoordMotion.m_PreviouslyStopped condition.ÃÆ'Æ'‚ÃÆ'‚ÂÂ It then sets the Abort condition to cause the Interpreter to terminate.ÃÆ'Æ'‚ÃÆ'‚ÂÂ On termination, callbacks to your application are made to inform the Application what really happened and the true state
> > of things.
> > > > >
> > > > >
> > > > > I don't see how at the point after a Halt has completed and everything is idle a Jog would not work correctly.
> > > > >
> > > > > Regards
> > > > > TK
> > > > >
> > > > >
> > > > >
> > > > > ________________________________
> > > > > From: himykabibble
> > > > > To: DynoMotion@yahoogroups.com
> > > > > Sent: Friday, January 11, 2013 5:59 PM
> > > > > Subject: [DynoMotion] Re: StopImmediate...
> > > > >
> > > > >
> > > > > ÃÆ'Æ'‚ÃÆ'‚ÂÂ
> > > > > Tom,
> > > > >
> > > > > But it doesn't.... I consistently get that destructive un-commanded move on the first move following the Halt. In fact, it even happens if I use the pendant to make the move, which does a jog, not involving the interpreter at all. I know you don't see it in KMotionCNC, but in there you're disabling all axes on a Stop, after doing a Halt followed by an Abort. I don't want to disable the axes, because then the machine needs to be re-referenced.
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com , TK wrote:
> > > > > >
> > > > > > Regarding the StopImmediate 0, 1, 2 and KFLOP that is correct.
> > > > > >
> > > > > > But regarding the rest, no all you should need to do is issue Halt. All the rest should happen automatically.
> > > > > >
> > > > > > TK
> > > > > >
> > > > > > On Jan 11, 2013, at 5:17 PM, "himykabibble" wrote:
> > > > > >
> > > > > > > Tom,
> > > > > > >
> > > > > > > Tell me if this is correct:
> > > > > > >
> > > > > > > StopImmediate0 will set FeedHold, and stop all motion
> > > > > > > StopImmediate1 will clear FeedHold, and resume motion from where it left off
> > > > > > > StopImmediate2 will clear FeedHold, but will not resume motion
> > > > > > >
> > > > > > > After playing with it, this appears to me to be correct, which makes the answer to my other question:
> > > > > > >
> > > > > > > To Enter FeedHold => Do StopImmediate0
> > > > > > > To Exit FeedHold => Do StopImmediate1
> > > > > > > To Stop =>
> > > > > > > Do StopImmediate0 to immediately terminate all motion
> > > > > > > Do Halt
> > > > > > > Do Abort
> > > > > > > Do StopImmediate2
> > > > > > > Do StopImmediate1
> > > > > > >
> > > > > > > Seems like a lot of steps, but the above *appears* to do what I want - Stop always stops all motion ASAP, but leaves the machine in a state where I can re-start the G-code execution from the line that was being executed (with the proviso that the start point *may* no longer be "correct" - for example if a G2 or G3 was in-process. Worst case, I can back up a few lines to code that re-positions the machine using G0/G1 moves to re-position the machine, then re-start execution.
> > > > > > >
> > > > > > > Does that seem correct to you?
> > > > > > >
> > > > > > > Regards,
> > > > > > > Ray L.
> > > > > > >
> > > > > > > --- In DynoMotion@yahoogroups.com , TK wrote:
> > > > > > > >
> > > > > > > > That is correct. 1 - starts moving and will resume/finish the motion. 2 - exits the Feedhold state.
> > > > > > > >
> > > > > > > > TK
> > > > > > > >
> > > > > > > > On Jan 11, 2013, at 4:04 PM, "himykabibble" wrote:
> > > > > > > >
> > > > > > > > > Tom,
> > > > > > > > >
> > > > > > > > > I'm still confused about StopImmediate. The documentation says:
> > > > > > > > >
> > > > > > > > > 0 - Stops the axes motion (equivalent to User C Program function StopCoordinatedMotion)
> > > > > > > > > 1 - Resumes the axes motion (equivalent to User C Program function ResumeCoordinatedMotion)
> > > > > > > > > 2 - Clears the Feed hold state (equivalent to User C Program function ClearStopImmediately)
> > > > > > > > >
> > > > > > > > > What is the difference between 1 and 2? To my untrained eyes, they sound like exactly the same thing. Does not 0 *set* the Feed hold state? Or does 2 clear Feed hold, but does NOT resume motion?
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Ray L.
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>