Howdy. So we were having issues with M4 freezing. We uninstalled and re-installed the latest. As it happens, our PMDX Smart Bob 411gave up the ghost about the same time (PMDX is graciously repairing it). But, we bought an ethernet Smoothstepper to avoid USB connections. Anyway, after a lot of struggle and paying a company to set up the ESS with M4, our Y axis runs backwards when we try to run a file. New files or files made before the switch. When we hit execute G code, Y crashes into the home switch. I tried a bunch of things that I thought would reverse the issue but so far to no avail. If anyone has any ideas, we really need to hear them. Thank you.

The direction that a motor runs can be affected by many things.

The Config>Control>Motors tab can be used. Highlight the desired motor on the right side of the panel and look for a check box at the bottom for Reverse.

The polarity of the direction signal can be configured in the ESS plugin.

The wiring polarity of the stepper driver outputs to the motor coils can change the direction, though this likely does not apply in this instance since you probably have not changed any of this wiring.

Note that the direction of jogs using the keyboard can be configured independently of all of the above and it is possible to have the keys mapped differently from other motion sources. Using on screen jog buttons would bypass this issue.

Lastly, it is common for machines to be configured such that the home switches double as limit switches. This is done by setting up duplicate entries in the Input Signals table such that the same signal is used by Home and by Motor1--  for example.

Mach4 should stop ALL motion if ANY limit switch is tripped. You should use the Diagnostics tab to view the hardware Input Signals to confirm that limits are configured and working. This screen is accessed from the Diagnostics tab at the right end of the same line of tabs the begins with Program Run, not the Diagnostic tab at the top line of the screen.

Thank you, Steve. It seems that its a very specific issue. After some G code tweaking, we discovered thatM4 is changing the Y direction at the outset of a file run. It holds true for old files that we've run many times before the new setup and new files that we created to see if there was a difference. For instance, the G0 line of code that normally would read G0 X -20.3583 Y 22.0912 Z0.2000 would cause the Y axis to run back into the home position. Conversely, adjusting the same line of code to G0 X -20.3583 Y -22.0912 Z0.2000 (note the Y change to -Y) made it run correctly I tried to tweak pin setting for some time last night but nothing made a difference. I can't help but believe that its some very minor tweak somewhere but its elusive.

I recommend using on screen jog buttons to confirm operation while testing and adjusting parameters. That way you can avoid crashes.

Also confirm that the on screen DRO moves in the expected direction even when machine goes the wrong way.

If that is the case, there must be a configuration problem.

The Y DRO matches the direction of actual travel in both the original file and the adjusted version of the code. In both cases, when Y moves to the minus, the DRO shows the minus and vice versa.

Hi,
Mach does not nor cannot change the direction. It means that you have code written for one machine but your new controller has one axis reversed. Change the direction
in the ESS Prot&Pins tab.

Craig

This case is more than just configuring the motor direction correctly.

The DROs and machine run correctly if you use the on screen jog keys.

When Gcode is run, one axis moves backwards. The Gcode itself has been supposedly been validated on his older setup with a PMDX-411. We have been trying to figure out if a G51 parameter is stuck somewhere. Adding a G51 Y-1.0 to the Initialization string in Mach4 makes things work correctly.

Hi,

The Gcode itself has been supposedly been validated on his older setup with a PMDX-411.

That is the point, the code works with the old setup but not with the new control setup, ie the new control setup has one axis reversed by comparison
to the old setup. Its far from impossible that the old setup had the Y axis contrary to the industrial standard but if the Gcode for that machine had be written
in consonance with that setup it would work.

The simple expedient is to change the direction of the Y axis alone in the new set up and try running the code. If the code work then OP has to decide whether
he wishes to retain the non-standard setup OR change the Gcode to suit the industrial standard OR use a g51 when using old code.

Craig

I guess it is possible that the old setup had the Y axis misconfigured and original poster did not realize that he had worked around it by changing the Gcode. The replacement PMDX-411 is on the way to him and maybe he can reload his old configuration to check that. The testing with using the on screen jog buttons to verify that the DROs and machine moved in the correct direction convinced me that Mach4 was driving the machine correctly in this case. Sometimes people get confused when one axis moves the cutter and the other axis moves the table. I wonder if that could be the source of the problem.

Hi,

The testing with using the on screen jog buttons to verify that the DROs and machine moved in the correct direction convinced me that Mach4 was driving the machine correctly in this case. Sometimes people get confused when one axis moves the cutter and the other axis moves the table. I wonder if that could be the source of the problem.

That has been my experience also. I do not favour using jog buttons to make calibration and/or direction tests either. You can assign a button to jog in either direction whereas a
g0 move is the positive x direction should cause the DRO to increment upwards and the axis advance such that the X ordinate increases, no question about how the jog buttons have been assigned.

Craig