I'm tired of this.  Seriously considering asking for a refund.

Mach 4 keeps running away and breaking my tooling and workpieces.  The latest incident is pictured below.  Runaways have broken TWO 1/2" carbide bits, knocked my mill out of tram (more than once), bent a brand new ER40 collet holder and now trashed my home made 3" cutoff disk mandrell.

After repeated incidents, I can now anticipate when it might occur.  In every instance, I was jogging from my wireless keyboard.  If it fails to respond to a quick jog keypress, it is time to stop and restart Mach!  What happens is this;

It will fail to respond to the keypress, so I bump it again and again, several times.  All are very short keypresses, looking for a response.  What has always happened is that it fails to respond several times, and then takes off in the attempted direction like a bat out of H***.  Many times the distance is short to the crash point and I don't have time to hit the estop button before it crashes.

Here is what I think is happening.  In every case the keypresses are very short and quick, simply looking for a response so I can position the bit.  Sometimes I make as many as four or five unresponsive keypresses before it takes off.  I think it is probably a delay in Windows (it's busy servicing some background task maybe....) or the wireless keyboard routine.  AHA!  Yes, say the Mach 4 programmers.  It's not our fault.  But wait!  There is a serious deficiency in the Mach 4 programming if it is not continuously monitoring for the keypress and stopping movement IMMEDIATELY if it sees the key is not down.  Apparently there is a windows cache which remembers keypresses (I've seen this in different programs) and implement they keypress when windows catches up.  In Mach 4, that is a dangerous thing.  The problem is, there seems to be NO keypress duration information retained that is associated with the keypress.  If there were, what I should see when windows catches up is a series of short blip moves on the mill that correspond to the keypresses I made.  Instead, Mach 4 just takes off in the indicated direction and never slows down until it hits something, which is more often a workpiece than a limit switch.

If Mach 4 were properly engineered, it would constantly be looking for confirmation that you were still trying to jog in the indicated direction and not just keep moving.  Here are photos of the latest crash because of this.

The first photo, Mach4Crash, shows the ER40 collet holder that was bent when a 1/2" carbide bit crashed into it in a similar incident.  You can see a short (2 minute) video of the impeccable runout this collet holder had when it was brand new here;
https://www.youtube.com/shorts/0zlhomrTiik
Now, the runout after the crash is about two thousandths.

The next photo shows how this latest crash bent my home made cutoff disk mandrell.  That was half a day of work down the drain.

The last photo shows how the crash broke off two of the tungsten contact points on my prototype magnet motor commutator.

Not the expert, but first thing I'd do is lose the wireless keyboard.

This isn't necessarily a Mach4 problem... it is more than likely a motion controller issue.  The keyboard jogging plugin is on the Mach4 side, but the way the motion it is handled and interpreted is on the side of the motion controller.  I have no idea how the keyboard jogging code works, it could be a Mach issue, it could be a motion controller issue... but....Thosj is right.  Get rid of the wireless keyboard.  I had similar problems with wireless keyboards in the past.  I have never had these problems with a wired keyboard or an MPG handwheel.
We have something like 12 machines that I have Mach4 on plus helping some friends out with their machines with Mach4.  The only time I have ever seen this issue is with a wireless keyboard. 
I suggest getting a wired keyboard and see if the problem persists.

Hi,
a few things to note:

Windows is not real time but a multitasking operating system. Thus there will be substantial periods of time, milliseconds at the very least where Windows is doing tasks other than Mach
or even monitoring the keyboard. That is what a multitasking system is and does.

If you want genuine realtime control...well you can have it, Fanuc, Siemens, Mitsubishi all make and sell them. If you have to ask the price then you cant afford one.

Mach gets service for a few milliseconds very ten milliseconds or so.

The next issue is that Mach is not one large chunk of code, but rather two chunks. One is the screen code chunk which maintains and updates the screen and coincidentally receives the keystrokes
of the keyboard from Windows. The other chunk of code is the Gcode interpreter and trajectory planner, i.e. that part of Mach that controls movement. The two chunks cannot run simultaneously,
but rather sequentially. Further the 'sharing' is cooperative rather than deterministic. If the Gcode interpreter/trajectory planner is fully engaged, maybe a complex tool path with a vast
number of very tiny moves, then it will not release the CPU, and thus the screen code will not get CPU service and in effect the screen is frozen.

I encountered this the other day where I accidentally ran a macro which did not release the CPU, even temporarily to the screen chunk, and thus I could not stop the macro because the screen
was in effect turned off while the macro was running. When I wrote the macro I did not anticipate the need to use the keyboard while it was running and did not therefore run run macro as a coroutine.

So there are circumstances when the keyboard is ignored, either because Windows is doing something else or Machs Screen code chunk is not running or otherwise prevented from getting CPU service.
Having said that it is not a situation that I've encountered often at all.

In the ten years I've been using Mach4 I've had one run-away, and that was my fault.

I agree with other posters, ditch the wireless.

It was explained to me many years ago that when a PC is engaged to control a machine, it is no longer a PC, but a machine controller that just happens to use Windows as an operating system.
In short you should treat it as a machine controller, and anything that renders that control unreliable must be eliminated. Failure to do so will result in the unexpected excursions .

Craig