I am experiencing a homing issue with a 3 axis machine running ESS.   I have seen this particular issue mentioned here and there, but there has never been any "closure" on the issue, I.E. and indication of either whether it was solved, or if it was, how it was solved.  Any help would be appreciated.
 
Machine Details:
 
-          Mach4 Hobby (Latest version as of today).   The software is licensed. 
-          Windows 8.1 AMD64
 
-          Ethernet Smoothstepper.  The smoothstepper plugin is the latest available from Warp9’s site. 
 
-          This is a 3 axis, 4 motor machine with two motors driving Y.
-          The system uses 7 limit switches:  X++, X--, Z++, Z--, Y++, Y1--, Y2—
-          X--, Z++, and Y1—and Y2—are configures as home switches as well as limit switches.
 
All limit switches function as limit switches properly.  When actuating each limit switch, the appropriate indicator in Mach lights up, and movement stops as expected. 
If X—or Z++ is actuated, Mach reflects that those limits were hit, as well as their home indicators. 
If either Y- switches are hit, the limit indicator lights, and if both Y- switches are simultaneously hit, the Y- indicator and Y home indicator lights.
 
Homing is direction is defined as Z positive, Y and X negative.  Order is Z-X-Y.  When attempting to perform a homing procedure, Z moves to the upper limit/home switch, stops and backs off until the limit switch un-actuates.  The axis indicator turns green in Mach and zeroes, then it continues to X.    When the X--/home switch is reached, the switch actuates, and at that point the machine stops moving.  The axis never zeros, and never backs off the home/limit switch.  Sometimes I can regain control of the machine by disable-enable and can jog away from the limit switch, but other times all movement stops and we have to close and re-open Mach.  In the latter case, the ESS remains in communication the whole time (fast blink, and when restarting mach, the board communication error that happens during an ESS issue does not appear).
 
I have tried:
 
-          Disabling the switch inputs as limit switches and defining them only as home switches.
-          Reinstalling Mach and the smoothstepper plugin. 
-          Changing the order of axis homing.   
-          Tinkering with the buffer value in the ESS plugin configuration.  No value tried resolves the issue.
 
No matter the order in which the axes home, Z is the only one that homes properly and only if it is the first one.  If X or Y are set to home first, both exhibit the problem and it never gets to Z.  If X or Y are set to home second with Z homing first, Z completes and the issue arises during X or Y, whichever is defined as the second axis to home.   

It may be worth noting that Y is configured as a master/slave axis with two motors.  When Y is homing, it seems to perform properly in that the first side to hit the home switch’s associated motor stops, then the other side continues (to align the axis), but once both Y home switches are actuated, the aforementioned stopping is occurring. 
 
The behavior is the same whether the home switches are also defined as limits or not.  When the switches are defined as limits, Mach4 message history reflects a limit switch strike and a home switch strike.  If we disable the limit switch functionality, it only reflects a home switch strike.  In either case, the same behavior results, Z homes properly, X and Y do not. 
 
Can any insight be provided as to what is going on and how to correct it?

Can you post your machine.ini file, would be easier to check your setting, but off the top of my head check the backoff velocity in the homing tab of the ess config, if this is too low then this will normally halt the machine.

DazTheGas

Thank you very much!  That fixed the issue.  

To all who might be experiencing the issue:

In the smoothstepper plugin, for each axis there is a homing velocity and a backoff velocity.   In my case, I had the homing velocity set to 20 units for each, but the backoff velocity was set to the default value of 1.  Changing those values to 10 for each axis solved the problem.  



I am having an additional issue that I discovered during this process.   After homing the axis, if I either let it sit at home position or I move one or more axes then let it sit for a while, when I return to the machine and attempt to move it, it will not move until I close and re-open mach4.  I am able to positively reproduce the issue by letting it sit for an hour or more, but I believe I have seen it happen after sitting for only a few minutes.  Any ideas ?   I can post the INI file if necessary but I was wondering if anyone knew the issue off the top of their heads.  

I would also look at the same issue of backoff velocity, although it has backed off if it is still too slow then it can be right on the brink of triggering as a limit, the faster it backs off the better ( but dont over do it ) this is what the home offset is for, but at this time doesnt work with the ESS unless you implement some scripting. But is this really worth it with a new plugin on its way.

Another issue could be noise on your system from a VFD or other equipment that will lock the ESS.

DazTheGas

I have further information based on further testing I did pursuant to your response. 


I don't think the ESS is locking up, at least not totally.    Changing the backoff velocity did not change the behavior any further than initially.


The first thing I did was isolate whether the homing routine had anything to do with it (at least in my humble estimation) by doing the following:

1. Removing power to all components.
2. While the machine is powered down, manually moving all axes well away from the limit/home switches
3. Restarting the system.
3. Opening Mach4, and ensuring that all 3 axes do in fact move.   Do not home!
4. Letting it sit for a while. 

Upon returning to the machine, the issue had presented even though no homing routine had ever been run since power-up.    I have not yet gotten far enough to set up or install any type of spindle or related hardware, but the spindle relay on the BOB is present.  I accidentally discovered that when the issue is occurring, even though the machine will not move, hitting the Spindle CW button does actuate the relay, so something is still going through that ESS. 


These discoveries have been made:

- When the machine is unresponsive to move commands, the spindle relay still switches on and off.  Further investigation revealed that if a relay is connected to the other output on the G540 and is configured as a mist or flood relay, is also still responds when the machine is not able to move. 

- After I start mach4 fresh, test that the machine moves, I cleared the message history.  When I returned and find that the machine is not moving, I checked the message history and found that no messages were logged, so it apparently did not log a limit switch strike or anything else that would explain it.

- By placing a piece of metal in front of the limit switches to actuate them, the limit switch indicators still respond in the diagnostics tab of Mach4, even while move commands do not work.

- If the problem presents (the machine is not responding to jog, mdi, homing, or code), manually actuating any limit switch momentarily reflects properly in the diagnostics tab, and afterwards, the machine will move again without restarting Mach.

- After the aforementioned "limit switch momentary actuation procedure,"  The machine will suddenly stop dead in it's tracks during a jog anywhere from 1-20 seconds afterwards.  In other words, if I touch off one of the limits to get the machine moving again, then immediately start jogging and do not stop, anywhere from 1-20 seconds afterwards, it will just stop dead and need either a limit switch to be touched or Mach4 to be restarted. 

I don't know if the ESS plug-in has any debug log capability, but you can try opening the Mach4 log and see if that shows anything useful.  Go to the 'Diagnostic" menu and select "Logging...".  In the "Log Facility" window, click on the "right arrow" icon (like a "play" button) to start the log.

Bob