Mach3 fails to send signals to axes

I need a little help.

I've been working on DYI CNC for several years with lots of interruptions. Before the last break the machine seemed to be working well except I was having issues with the Y-Axis alignment. After several months I finally had a new Y axis built that is true. Upon installing the axis, I noticed issues with stalls and chatter on the Y-Axis. This turned out to be a loose wire, the bane of all DYI projects. After fixing the issue, I could move all axes with keyboard commands easily and to any position on the machine. However, when I clicked on the Ref All button, only the Z and Y axes moved to home while the X just sat quietly with the DRO showing movement. Frustrated, I switched to MDI mode and issued some G code commands to move all of the axes simultaneously. Encouraged that the machine always responded to the commands, I loaded a G code file that I use to calibrate the table for levelness and motion accuracy. After manually homing all axes I clicked start. Everything was working as expected moving to several measurement locations, then the Z failed to descend to the measurement height. On the next command, it retracted at the rapid rate and continued on as though nothing was amiss, except that the Z was now .50 higher that it should be. After several more successful measurement moves, the Z repeated the non-descent issue followed by another .5 retraction then continued to process all commands as expected. I finally had to cancel the job because of repeated Z descent issues that were moving the Z too close to its home location.

I'm running Mach 3 on XP Pro using ESS with separate BOBs, X & Y on one BOB and Z on the other. My ultimate goal is to use one of the Step/Dir outputs on the second BOB to control spindle speed. I have no idea where to go from here being a newbie with CNC and with Mach3. The fact that all axes respond to keyboard commands tells me the Mach3 is working. What might I be missing to get Mach3 to function consistently? Maybe something in the ESS plugin configuration?

Sounds to me that it's just a motor tuning issue and your just missing steps which is the most common problem with things like this.! So before doing anything else lower the motor tuning on each axis by 50% and see if your troubles go away, this will verify if it's a Motor tuning issue. If it still loses position then I'd check for binding on the axis that's causing the problems.

If you give more information about the machine ie: Screw pitch and/or ratios, motor size and voltage drives are running along with velocity and acceleration settings it will help to know if you are over tuning the machine. Pics of the machine will help as well because mechanical components and build quality all play some part in how the machine is tuned.

Thanks JazzCNC for the response.

All of the axes are properly tuned and will move at rapid speeds consistently. This is an intermittent issue. Studying through the problem, I realized that when the machine is REF HOMED for all axes, the first axis to move is the Z followed by the Y and X is last or the third to move only it doesn't. When the Z decent issue occurs during the calibration code, the X & Y have all ready moved together and the Z is the third to move to make a measurement. Unfortunately, the issue is not consistent for a better diagnosis. The more that I ponder the issue, I'm inclined to believe that the issue is some sort of buffering issue within the communications between Mach3 and the MotionControllers via the ESS. The only configuration item that I have identified associate with buffering is around the Kernel Speed which is currently set at the lowest frequency for the max buffer size. But, that doesn't seem logical as the REF HOME process is moving one axis at a time, while the calibration code moves X & Y together and Z separately, which implies there is a counting issue within some piece of the communication process that isn't being managed properly.

I'll try to do some more investigating and post any findings that might pin point the issue.

I've been able to reproduce the issue consistently. 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. This tells me that it is an issue with either MACH3 or with the communications to the control box. 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.

This is a very big long shot from glancing at the replies regards to buffering, have you had a look at what your baud rates are set for the port/s in use?

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.

Quote:

---

Originally Posted by scsmith1451

I've been able to reproduce the issue consistently.

---

Good - if you can reproduce, you can diagnose.

Quote:

---

Originally Posted by scsmith1451

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.

Quote:

---

Originally Posted by scsmith1451

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.

Quote:

---

Originally Posted by scsmith1451

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?

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.?

I'm using the Ethernet SmoothStepper, so baud rate is not applicable. My secondary NIC operates at 10/100/1000 Mbps so what every rate the ESS uses the NIC can handle. I did try to find out what rate the ESS operates at, but did not find it in the documentation, regardless it will not exceed 1000 Mbps so I don't think that is the issue.