...
In the case of the A axis runaway, I had switched to continuous jogging and the motion continued after the button had been released.  Not just a few steps, but inches of movement as I tried to stop it.  If this was a buffer finishing stored steps, there must have been several thousand steps accumulated and not flushed on button release.

I am still baffled about how to avoid this problem occurring again.

When jogging in continuous mode, the rules of acceleration and decelration are followed. If you have a slow acceleration - or a high max velocity - it will take time for you to get up to speed. Once you get up to speed, it will take the same amount of time to decelerate as it did to accelerate, and the same amount of distance to decelerate as it did to accelerate once you let go of the button. This means that there will be a bunch of deceleration motion produced once you let go of the jog button.  This is normal and what users expect and desire, because the alternative is to go from full speed to a dead stop with a nasty clunk that will start to tear your equipment apart.

Motion in the is consumed and destroyed, and replaced by zero motion commands when nothing is being commanded by a user or GCode program. If communications are lost the buffer empties out and then the SmoothStepper just stops dead.  There is no such problem as a buffer "run on" with the SmoothStepper, because the buffer will be drained in less than 0.5 seconds (by default less than 0.18 seconds) and then all motion will halt unless new motion is commanded by the user or a GCode program.

My next question is do you have your motor tuning configured correctly?  If you zero the X axis and then go to the MDI window and issue a G01 X1.0 F10 command, does the X axis move exactly 1 inch (or mm) in roughly a little over 6 seconds? Ho about all the other axes?  If it goes a lot farther than the 1 unit, or takes a lot longer than 6 seconds there are issues with the motor tuning. 

Andrew

Thank you Andrew.  It is reassuring to know there is no "buffer run on" with ESS.  So no issue with wondering how many uncompleted steps might still exist.

I have confirmed my X axis (the one where the incident occurred) is precisely tuned (within 0.001" over 6") and its velocity matches to under one second on a 60 second movement test.  I have not tested the other axes but I know the Y must be correct as I get perfect circles when I mill a circular hole.  I'm pretty sure I can say with confidence that the motor tuning is correct.

I get it that on a continuous motion movement there will be acceleration and deceleration components.  That is to be expected.  My incident occurred when requesting a 0.001" jog motion, so there would have been negligible time spent on accel/decel.  The issue was that the jog did not happen, the motion was continuous, even after the button had been released.

I'd really like to know what to do differently to ensure this type of situation won't happen again.

Again, thanks for your assistance.

Brian

Hi Brian,

With the incremental jog, there is nothing wrong.  We have tens of thousands of SmoothSteppers out in the field running Mach, with lots on Mach4. We would be hearing endless reports of there are problems with jogging, if there was a problem, we don't. 

We do hear of reports where the soft limits being set up incorrectly (i.e. not how the Mach4 manual tells you to set them up), and then your exact issue is what happens.  That is because Mach is trying to do what it is told to do, even though it was told to do the wrong thing....   It is not a bug, when the Mach4 software is doing exactly what it was set up and told to do.

With regards to what you mentioned earlier regarding which button to press on the screen, that is why we tell EVERYONE to have a physical Emergency stop button.  You press it and the power is taken away from the motor drivers.   https://warp9td.com/index.php/gettingstarted/safety-information

Andrew

Not to be argumentative, but rather to be sure we are all using the same facts...

1.  I do have an E-stop - I've mentioned a couple of time that I used it and it worked.  My point on that issue was that having a button labelled "STOP" on the screen that does not stop motion is, at best, misleading.  I get it that my expectation the button would work the same as in Mach3 was an erroneous assumption, yet perhaps reasonable for someone who has used Mach3 for a decade. (In Mach3, the "Feed Hold", the "Stop" and the "Reset" buttons all stop motion when pressed.)

2.  As you can see from the screen shot I posted in my first message, the soft limits were not enabled at the time (although they were configured).  So, my next question is, "if the soft limits are not enabled, is the issue of soft limit configuration even relevant?"

3.  I have verified that when the soft limits are enabled, X axis soft limits are configured correctly and work as expected.  Next question "what else should I check"?

Again, thanks for any assistance.

Brian

Hi,

There is no such problem as a buffer "run on" with the SmoothStepper, because the buffer will be drained in less than 0.5 seconds

Correct, the jog moves are buffered in Mach NOT the ESS.

I say again, if the continuous jog issues more steps that can be consumed by the machine they get buffered and result in after-run.

Try an experiment, preferably with an MPG so you can vary the input step rate, and try it. With large jog steps you end up with after-run
and with small jog steps you do not. I did this exact experiment six years ago with that conclusion.

Craig

Hi Craig.  That sounds like an interesting experiment but I do not have a MPG.  It is one of the things I've been planning to get for some time.

I've got the jog steps at 0.001", so I'm not sure how small they have to be.  It is frustrating that I cannot repeat the incident on demand to test various parameter changes.

Do you know if there is a command that will flush the buffer to prevent "after-run"?

Brian

Hi,

I've got the jog steps at 0.001", so I'm not sure how small they have to be.  It is frustrating that I cannot repeat the incident on demand to test various parameter changes.

The issue occurs when the product of the jog step rate and the jog increment equal or exceed the max machine velocity. You can use the jog rate slider to
reduce the jog step rate and/or set even lower jog increments. The problem with using very small jog increments is that when you want to touch off in incremental mode
you effectively have to cycle through your programmed jog steps to find a more suitable number.


It won't hurt to try 0.001, 0.0001,0.000001.......it will tell you pretty simply whether you are on the right track.

Do you know if there is a command that will flush the buffer to prevent "after-run"?

No I don't, and I don't believe there is such a command, and even if there were you would be using it to counteract a poorly chosen setting by you.
Establish the 'sweet spot' jog increment and progress from there.

I do rather suspect that you can change the jog step rate within Mach and that I think will be your long term fix....but you can establish the limits
and the nature of the problem by using the slider and/or jog increments.

Craig

Thanks for the clear explanation.  I'll test that out.

...
Correct, the jog moves are buffered in Mach NOT the ESS.
...
Craig

The Mach4 trajectory planner calculates the position that every motor should be at at the end of every time slice (1 millisecond).  The ESS plugin calls that function to see where it should have all the motors at one time slice, and then calls it again to see where they are supposed to be at the next time slice, and repeats indefinitely.  Once the ESS plugin gets the position data for a time slice, it then sends that data down to the ESS's motion buffer for consumption.  The ESS's buffer will typically hold 0.15 second (up to 0.5 seconds) of motion or jogging data that it pulls from Mach4.  Mach4 is calculating and planning that data, but it isn't truly "buffering" that data.

As soon as you let your finger off of the button in a continuous jog at full speed, the next time slice we pull from Mach4 should start showing the deceleration.  It will take the 0.15 seconds (or whatever you have it ESS motion buffer size set to) for that deceleration to work through the ESS's motion buffer.

There is no such thing as an after run.   

You can't call a command to clear the ESS's buffer, other than by hitting EStop or pressing disable, and at that point motion will go to 0 with a clunk.