Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: BrianW on May 09, 2021, 05:45:52 PM
-
I've recently switched from Mach3 to Mach4, so the following problem may be due to my inexperience with Mach4 or some incorrect software setting. However, I encountered a very serious "runaway" situation today and would like to get some advice.
Using the Jogging screen that comes with Mach4, I was setting the tool to the part origin, I had switched to incremental jog mode with increments set at 0.001". (The attached photo shows the preset jogging conditions.) However, when I went to jog the X axis the motion was continuous, not a jog. Worse, it did not stop when I released the button.
I used the hard-wired E-stop to halt motion but by then the tool was destroyed and the part damaged. I'm very glad my fingers were not in the tool path!
But it gets worse...
After releasing the E-stop, I used the jog button for the A-Axis (the Knee) in continuous mode to drop the work clear of the tool collet. Once again, the motion did not stop when the key was released. Neither the Stop Button nor the Reset Button on the main Program Run screen would do more than pause the motion. As soon as they were released, the A-Axis motion continued. Finally I had to use the E-stop to halt the motion.
Can anyone suggest what might have caused this problem and suggest how to avoid it in future?
PS. I'm using ESS to drive DMM servos and motors.
-
It sounds like you are using softlimits and they are not setup correctly. And the planner is trying to "wrap" back around.
Steve
-
Yes, I have soft limits enabled but this problem occurred several inches away from both the soft and hard limits on the X axis. I'll check tomorrow to see if the soft limits have somehow been altered, but more research on the forum tells me that jogging runaway events are not uncommon. If there is a software bug, it needs to be fixed ASAP as it is a safety issue.
-
Yes, the runaway jog issue is a common configuration problem. How do you think I knew you were using soft limits? :) Because it is something that is common, as opposed to a bug. And the result is EXACTLY the symptom you are complaining about. Here is a link where I discuss properly setting the soft limits:
https://www.machsupport.com/forum/index.php?topic=43196.msg279918#msg279918 (https://www.machsupport.com/forum/index.php?topic=43196.msg279918#msg279918)
There are literally tens of thousands of Mach 4 installations. I know pretty quickly when there is a real bug. If you are running a general release (4612), then I pretty confident there is no bug. However, if you are running a dev build, your mileage may vary. But you didn't specify which build you are running, so I don't know.
Also, and this gets people coming from Mach 3, Mach 4 is not Mach 3. Mach 4 acts more like an industrial machine control. The stop button will not stop a jog, it stops a cycle. The reset button will not stop a jog, it resets the interpreter. The thing that would stop a jog is the disable button (if you have your drives connected to the motor enabled signals.) or the physical E-stop button (You have one, right? But again, if that was implemented/wire properly). However, it is your responsibility to make these work in the intended manner. But both of those will stop a runaway machine, no matter what the cause.
Steve
-
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?
-
Hi,
I believe the problem you are experiencing is after-run.
When in continuous jog mode Mach issues a stream of jog steps at the current jog increment. If the machine can move 20mm/sec but the steps
are indicating a move of 30mm/sec then the extra steps get buffered. Thus even when the button is released and Mach stops issuing jog steps the
steps in the buffer still have to execute, and will carry on until the buffer is drained, ie after-run.
You might consider this is a bug, its not. Its is that your selected jog increments mean that the buffer can fill up.......and it catches you by surprise.
If you reduce your maximum jog increment down to a realistic amount the problem ceases to exist.
As an example I used to have my max jog step set at 1mm/step. If I spin the MPG fast the steps exceed the ability of my machine to execute them
immediately, and I would get after-run with the attendant surprise and consternation. I have since set my max jog step to 0.1mm/step. Now I can
spin the MPG as fast as I like and my machine executes all those steps nearly instantly, the buffer never fills up and therefore no after-run.
Another way of saying it is that the maximum jog increment and jog step rate should match the velocity of the machine and thereby avoid
accumulated steps in the motion buffer.
Craig
-
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.
-
Hi,
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.
BS. Mach is doing EXACTLY what its supposed to do, if you issue 211 pulses of 1mm per pulse then it will move 211mm. That a number of those steps are
'in the buffer' and you can't visualize where that 211mm movement is going to end up is your problem......not Machs, it just going to the 211mm mark as
you requested.
When I first encountered this problem six years ago I too thought it a fault, and the hundreds of people since then that have posted about this
in the years since, all imagine its a Mach bug. ITS NOT!!!! If I tell Mach to move to a BS location, it goes there and crashes, its because I told it to go
there, its not up to Mach to try to anticipate my BS mistake.
Reduce the jog increment down to the situation that very few if any steps end up in the buffer and you'll never have the problem again.
Craig
-
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
-
Hi,
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?
That is a good question. In my case, as I use an MPG and do not use on-screen buttons, the solution and result are much plainer.
Lets say for example your machine has a max velocity of 1200mm/min. I choose this number as it suits my mini-mill which because of axis gearing
has relatively low G0 speeds.
1200/60= 20mm/sec.
If I set the max jog increment to 1mm, then if I spin the MPG (100 pulse/rev), at any greater than 20 clicks per second then movement is going to accumulate
in the buffer. Its entirely possible to spin the MPG at 1 rev, or 100 pulse per second, and thus I would have significant accumulated motion in the buffer.
If however I reduce the increment to 0.1mm then that same 100 pulse per second input results in 10mm/sec movement which is within my machine velocity
and therefore no accumulated movement.
The trick here is that I know how many steps per second I am applying by virtue of me spinning the MPG.
In your case using Mach's jog buttons is issuing a certain rate of steps....and exactly what they are I don't know. Lets guess and say that Mach is issuing 1000 pulses
per second, then at 0.1mm jog increment that would indicate a movement of 100mm/sec which exceeds my machine velocity and therefore get motion
accumulation. If I selected a jog increment of 0.01mm then the same 1000 pulse/sec input would result in 10mm/sec movement which is suitably within my machine limits.
I'm not sure off-hand how Mach determines the pulse rate. On the jog screen there is a slider at the bottom which is a percentage of max, whatever max is. Using that slider
you can slow the pulse rate down until you approach the balance point necessary to avoid accumulated motion.
I'm hoping that smurph sees this post and he will surely know how to set the rate. My guess is that once you make an appropriate setting you will then never touch it
again for the life of the machine. Such has been the case with my max jog increment, once I found the 'sweet spot' of 0.1mm it gets left there for months at a time.
I will sometimes drop down to 0.01mm if I have a fine touch off to complete, but even that does not happen that often.
Craig
-
...
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.
-
Hey from Cnckr
Sorry for my bad english."
When you start mach4 and after "configure" and after "restart" Mach4. If you want to use Jogging tab, you need to push Incremental jog Step" at least once or you cannot trust the DRO showing jog step size. After this push I think jogging work as you expected it to.
The motor acceleration may not be too small.
Good luck Cnckr
-
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
-
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
-
Hi Brian,
Don't know if the known bug in the this attachment is related to your problem or not, but may be worth bearing in mind.
Nick
-
Hi,
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.
That is not correct, I can with the jog increment set to 1mm cause the MPG to buffer up moves that carry on motion for several SECONDS after the MPG has
stopped moving. The same can be done with the on-screen jog buttons.
If the movement were restricted to the length of the ESS motion buffer that thread would not exist, there would be no need.....but the motion can persist for SECONDS
Craig
-
Hi,
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.
That is not correct, I can with the jog increment set to 1mm cause the MPG to buffer up moves that carry on motion for several SECONDS after the MPG has
stopped moving. The same can be done with the on-screen jog buttons.
If the movement were restricted to the length of the ESS motion buffer that thread would not exist, there would be no need.....but the motion can persist for SECONDS
Craig
I said *continuous* jog mode where it will move at the full jog speed until you let go of the button and then it will decelerate.
You are talking about *incremental* jog mode. In that version, you are repeatedly increasing the location of the destination, faster than the MPG commanded motion is being output to the motors. Nothing is being buffered up in Mach4 when you spin the MPG wheel fast, but Mach4 realizes that the endpoint is still, for example, 3 inches away, and Mach4 will fulfill the command to travel that entire distance, even if it takes a few more seconds or minutes. Mach4 will keep telling the ESS how far to move for each time slice, until the commanded position is reached - Mach4 is doing exactly what it was commanded to do. And again just for clarity, the moves are not buffered up (except for the fraction of a second worth of moves inside the ESS's motion buffer), the final position to go to for Mach's trajectory planner was being changed, and that is what keeps the motion going until that destination is reached.
Andrew
-
Hi,
You are talking about *incremental* jog mode. In that version, you are repeatedly increasing the location of the destination, faster than the MPG commanded motion is being output to the motors. Nothing is being buffered up in Mach4 when you spin the MPG wheel fast, but Mach4 realizes that the endpoint is still, for example, 3 inches away, and Mach4 will fulfill the command to travel that entire distance, even if it takes a few more seconds or minutes. Mach4 will keep telling the ESS how far to move for each time slice, until the commanded position is reached - Mach4 is doing exactly what it was commanded to do.
My apologies, yes I am indeed talking about incremental movement, and your description is exactly as I observe on my machine.
When in 'continuous' mode the motion ceases very shortly after button release. My ESS is set to default buffering, ie 180ms, and I would guess that is the delay I
observe.
To be honest I don't really use continuous mode very often, but rather incremental mode.
When using Machs on-screen buttons incremental mode causes one jog unit of movement, effectively single stepping. This is not convenient if you wish to traverse a distance
to work zero for instance. With an MPG however spinning the handwheel results in a stream of 'single steps' which is highly convenient for rapid traverse AND also for fine
and slow speed single stepping when touching off.
In my opinion an MPG used in incremental mode represent the most versatile, usefully safe means of manual control for both rapid traverse and touch off.
Craig
-
My apologies, yes I am indeed talking about incremental movement, and your description is exactly as I observe on my machine.
In my opinion an MPG used in incremental mode represent the most versatile, usefully safe means of manual control for both rapid traverse and touch off.
Craig
No worries!
Yes, a MPG works nicely for user controlled movement.
I don't believe that there are any bugs present in jogging. This thread just required some clarification and education in how the different modes are operating, and how the ESS works with Mach4. Fin.
-
Thanks Nick952. I think that is exactly what happened and the screen shot confirms my opinion that there is a bug to be fixed.
-
In my opinion an MPG used in incremental mode represent the most versatile, usefully safe means of manual control for both rapid traverse and touch off.
Having just installed one, I agree - but there is also a user education factor here. I discovered as well that if you really spin up the MPG, it can take a bit for Mach to process all those pulses and motion can persist surprisingly long after MPG motion stops.
Mach of course is doing exactly what it was told to do - there is no bug. If you generated 1000 pulses with your MPG, Mach is going to move 1000 x the jog increment.
The "so what" here is twofold:
1. The user must modulate MPG spin rate more carefully, so as to not accumulate excessive movement; and
2. Jog rates on the MPG should be 10x slower than expected.
By which I mean, my jog rate switch has settings for 0.1", 0.01", 0.001" per pulse. Those are entirely reasonable values based on the Mach screen jog buttons, but in reality, the 0.1"/pulse setting is WAY too fast for a bench-class machine - the MPG generates more pulses than you think. More human-scaled movements are 0.01", 0.001", and 0.0001" (maybe 0.0005").
Thank Lob I didn't have a 1"/pulse setting!
-
I use a couple of machines at work, that have Centroid controls and with them, if you either spin the MPG hand wheel or press the INC Jog button too fast, the control just ignores the extra pulses, until the input rate is slowed down. With this, you don't get the continuing movement after you've stopped spinning the hand wheel, whilst all the buffered pulses are used up.
Although I use Mach4 at home , the Centroid handling of MPG and INC inputs, always struck me as to be the most sensible and safest way.
I went with Mach4, well before Centroid Acorn was introduced, otherwise I would also be using Centroid at home.
Nick.