Messages

1

Mach4 General Discussion / Mach4 with ESS Slave Motor running slower than primary

« on: February 27, 2016, 11:15:37 AM »

I am experiencing the issue that seems to be quite accurately described here, except in my case it is Mach4:  http://www.cnczone.com/forums/mach-software-artsoft-software-/241440-slave-axis-slow.html

Put simply, on a Y axis with two motors, one motor moves faster than the other, even though both are configured with the exact same steps per, acceleration, etc values in axis tuning.  Mechanically, both sides are 100% identical in configuration.

While I am not 100% sure that the resolution described in this thread is what I need to do - that being to adjust the frequency settings for each axis, the Mach4 ESS plugin does not offer nearly the configuration options as the Mach3 plugin and those settings do not seem to exist, so I can't even review them to see if they are set properly.  Perhaps one of the other settings in the plugin might resolve the issue (such as misalignment numbers), but I cannot find any documentation anywhere describing these values or what they do.  They may have nothing to do with it...

Is it possible to see and/or review the frequency settings when using Mach4 or otherwise correct this issue?   Maybe it's a different root cause in Mach4 or with the ESS and someone can tell me what the resolution might be?

2

Mach4 General Discussion / Re: Mach4 with ESS only homes Z successfully, on next axis it stops.

« on: February 23, 2016, 07:37:50 AM »

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. 

3

Mach4 General Discussion / Re: Mach4 with ESS only homes Z successfully, on next axis it stops.

« on: February 22, 2016, 04:59:52 PM »

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.  

4

Mach4 General Discussion / Mach4 with ESS only homes Z successfully, on next axis it stops.

« on: February 20, 2016, 04:16:55 PM »

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?