Messages

1

Mach4 General Discussion / Re: Hazardous Motion - Mach4 Software

« on: May 14, 2021, 11:53:21 AM »

Thanks Nick952.  I think that is exactly what happened and the screen shot confirms my opinion that there is a bug to be fixed.

2

Mach4 General Discussion / Re: Hazardous Motion - Mach4 Software

« on: May 13, 2021, 01:14:40 PM »

Thanks Cnckr.  That may be exactly the right solution.  I've noticed that occasionally and not related it to this problem.  It sure would be nice if the fix is as easy as that!  Appreciate your suggestion.

Brian

3

Mach4 General Discussion / Re: Hazardous Motion - Mach4 Software

« on: May 13, 2021, 01:09:12 PM »

Guys, I really do appreciate that you are trying to educate me about how Mach4 and ESS interact.  Despite being a mechanical engineer and having programmed NC mills since 1973, I'm still confused on Mach4's interaction with ESS.  Perhaps a numerical example will help me understand...

Let's deal with just one linear axis - the X axis.
Let's deal with a single screen button press to do a 0.001" jog
The speed slider on the jogging screen is set to 1% of maximum velocity

My X axis lead screw has 5 threads per inch
My X axis motor is accurately tuned at 10,000 pulses per rev
My X axis motor is tuned to a maximum velocity of 180 inches per minute (= 3.0 inches per second)
My X axis motor is set for an acceleration of 5 inches/sec-sec

So, 10,000 pulses to the servo generates 0.200" movement on the axis (1/5 inch)
Thus 0.001" movement requires 10,000 * 0.001/0.200 = 50 pulses  (This becomes a constant in this example.)

1% of the maximum axis velocity is 0.030 inches per sec.
.001" movement thus requires  .001"/.030 ips = .0333 sec (=33.333 milliseconds)

So, ignoring acceleration and deceleration, the 50 pulses will be sent in 33.333 milliseconds.
If the accel/decel happens within the 33.33 ms, then the 50 pulses will be spaced unevenly to accomplish this.
If the accel/decl is outside the uniform time of 33.33 ms, then the 50 pulses will be spaced over a longer than 33.33 ms time slot but again will be spaced unevenly.

If I understand Andrew's description correctly, it seems that Mach4 must be figuring out the accel and decel to predict the axis location at the end of the next time slice.
ESS then determines how many pulses to send and spaces them correctly for the time slice.


The Left Down action for this screen button is "Jog X-" and the Left Up action is "Jog X Off".  It is not explained what "Jog X-" is programmed to do.
If it is a "one shot" trigger, then presumably a command is sent to the core to generate 50 pulses on the X- axis.  If so, then there seems to be no need for the "Jog X Off".
If it is not a one shot, then it appears possible that holding down the jog button could generate more than one command to jog, hence requiring the "Jog X Off" on button release.  I've been repeatedly assured there is no bug in the Mach4 jogging function, so I have to assume there is some way to ensure there is only one set of 50 pulses being commanded and that the "Jog X Off" is merely there as a safety feature.

Andrew has been clear that "there is no such thing as an after run", but there is a (user determined sized) motion buffer which has to empty out.  (My buffer remains at the default size of 0.18 sec.)  But since ESS only creates pulses in accordance with the Mach4 determined position at the end of the next time slice, it would seem any additional (i.e. unwanted) pulses have been required by the Mach4 calculations.  (I hope we all agree on that.)

JoeAverage and Smurph are definite that the unwanted motion is due to some incorrect configuration setting on my machine.  I've turned off soft limits, hoping to ensure that potential cause is eliminated.  I have yet to try JoeAverage's experiment of increasingly small jog increments, but cannot get my head around his comment "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."  Would this not just put me back into exactly the same situation of too big a jog increment leading to unwanted motion?

As always, I appreciate the time you are all taking to help me understand.

Brian

 

4

Mach4 General Discussion / Re: Hazardous Motion - Mach4 Software

« on: May 12, 2021, 07:42:45 PM »

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

5

Mach4 General Discussion / Re: Hazardous Motion - Mach4 Software

« on: May 12, 2021, 04:53:20 PM »

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

6

Mach4 General Discussion / Re: Hazardous Motion - Mach4 Software

« on: May 12, 2021, 02:46:36 PM »

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

7

Mach4 General Discussion / Re: Hazardous Motion - Mach4 Software

« on: May 12, 2021, 12:56:59 PM »

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

8

Mach4 General Discussion / Re: Hazardous Motion - Mach4 Software

« on: May 11, 2021, 04:08:38 PM »

Hi Craig.
I really didn't want to get into a discussion of whether this is a bug or not.  Clearly I think it is and you and smurph do not.  OK, let's not argue about that.  The purpose of my post was twofold.  One to advise others of this potentially hazardous situation.  Two, to get help on preventing it from happening again.

smurph believes the problem is my soft limits, but not only were they configured properly according to his linked post, but they were not turned on at the time of the incident.  So, that's not helping me avoid the problem in future.

Your suggestion is to reduce the jog increment down so few steps are in the buffer.  OK, the jog increment was 0.001" - I guess I could go to 0.0001" if you think that would help.  As far as knowing how many steps are in the buffer, how do I determine that?  If not determinable, is there some command to flush the buffer that a user can trigger?

Any help is appreciated.

Brian

9

Mach4 General Discussion / Re: Hazardous Motion - Mach4 Software

« on: May 11, 2021, 12:11:02 PM »

Hi Craig.  Thanks for your response.  It does make sense that an unemptied buffer could cause the problem, but I would call that a bug.  If the expectation is that jogging will stop when the button is released (I'm using a screen button not an MPG) then that's what should happen and the buffer should be flushed.  Any unexpected motion is cause for serious concern.  There should be no "catches you by surprise" when dealing with machine motion.

However, in my situation with the X axis movement, all motion had stopped before I switched to incremental mode at 0.001" per jog.  The very first button push caused the run-away.  If that was due to unused steps in the buffer, how does the operator know that or force a buffer flush?  By the way, the jog rate was at 4% on the slider scale - that is all that prevented blood on the machine.  With the jog increment at 0.001" and the velocity at 4%, I would expect the machine can keep up without any difficulty.  I've seen it process G code at rates much higher than this set up jogging.

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.

10

Mach4 General Discussion / Re: Hazardous Motion - Mach4 Software

« on: May 10, 2021, 08:38:56 PM »

I am using Mach 4 build 4612 and ESS build 268.

As I said at the beginning of my first posting, I'm quite prepared to accept I've made some configuration problem.  However, I have checked that the soft limits are in place and appear to be both logically and physically correct.  They were set up just as you outlined in the link you provided.  I'm still baffled how a soft limit that was inches (over 3") away from the tool position could cause continuous motion when jog motion was commanded. Should I turn off Soft Limits and wait/hope the problem goes away or is there a better solution?

And yes, I do have a properly wired E-stop which I mentioned I had to use to stop the runaway motion.  I trust the "Disable" button will work as well, but did not try that in the panic of the moment.

Taking the Microsoft approach ("That's not a bug, its a feature") is not helpful.  If it is a common problem (to quote you and as seen on the forum) then it needs to be addressed either through warnings or a software fix.  I'm pretty sure that NewFangled Solutions insurance company would not be sanguine to realize that there is a "common" situation which causes damage and potential injury that is not being addressed.  For example, having provided a button labelled "STOP" which does not actually stop the machine is easily misconstrued.  I could go on, but you get my point.

I do appreciate the fact you are attempting to assist me with this problem and am quite willing to follow suggestions to make sure the situation does not reoccur, but if it is not due to soft limits, what do I do next?