Mach3 fails to send signals to axes

[Doddy]

I'm only dipping my toe in this, I've no experience of the ESS (but assume it's an "Ethernet Smooth Stepper"?). Probably a longer long shot than Robs.

I've been able to reproduce the issue consistently.

Good - if you can reproduce, you can diagnose.

I recorded the operation starting at the beginning of the code recording the sequence of moves and each time the Z failed to move. Then I re-ran the code and found that the Z failed to move at the same instructions during the second run. I was also able to identify that the failure is not a dependency of the previous XY location prior to the failure.

I'm guessing you've examine the GCode, and with experience of previous failure you're confident that it's not the GCode itself that's at fault?, if so we don't need to know too much of what's going wrong. Although... clutching at straws here (and this is just cause/effect analysis) - worth checking the integrity of the wiring from the ESS outputs to the drivers (though process: a short on e.g. Y-DIR to Z-PULSE could mean that you lose Z only if the last direction that the Y axis travelled was in one direction - in the other direction Z would be unaffected). Long shot, but explains the observation.

This tells me that it is an issue with either MACH3 or with the communications to the control box.

Possibly - I'd be checking CPU utilisation on the host machine just to take it off the table. Mach3 and its trajectory planner are, irregardless of anything else, well proven.

At one point I received an ESS buffering error which leads me to believe that there is an issue with the ESS driver that communicates with the control box or the ESS board itself.

Possibly - hence the above utilisation check. Here's a question. And this is from my inexperience with ESS. Do you have a dedicated ethernet link from the PC to the ESS?, if not, is there a chance that you're getting congestion on the network? (running Wireshark in promiscuous mode may help to understand traffic flow on a given interface). This WOULDN'T explain the apparent repeatability though. So I'm not sold on this.

I'm curious with your wording - is the ESS inside the control box, co-located with the drivers?

Faced with this problem I'd be measuring the step pulse-train on one axis on a scope - but that's an obvious test if you have a scope - my guess that level of diagnostics is not on the table for you?

[JAZZCNC]

Did you try running the code at half feed like I suggested.? Just becuase the Axis Jog at Rapid speed ok doesn't mean they will work when running the G-code, it's a common problem when Mach is overly tuned.

Now I ounce had an 10x5 Machine I built and while running my test G-code cutting air which is basicly 1000's of moves covering all the cutting area would E-stop at exactly the same point in the code and location on the machine.? Only while cutting AIR did it do this. I could cut a Job in that location with no problems and had surfaced the bed etc without any issues.
All logic told me it was a software/Code problem because it was repeatable and exactly at the same point in the Code.

After 3 days tearing my last strand of hair out and going over the PC and machine top to bottom I found the issue.! . . . It was a poorly crimmped ferrel which at that exact location on the machine, which happened to be in the middle of the gantry and roughly half way down the machine, must have caused an harmonic vibration which was just enough to trigger the E-stop.
Now the Controller was a CSlabs IP-S which are very fast reacting to input signals which is a good thing, this might not have hppened on lesser controllers if the wire didn't lossen any more but more likely it would as it worked lose over time much further down the road.

So check your wiring very carefully it could be something silly like this.?