Homing and <goto zero> issues

[Red]

Hi,
Firstly, please forgive me for my ignorance.  I'm pretty new to this and I notice from the level of discussion on the forum that many posters are seasoned hands at CNC.
I'm commissioning a 3x1.2m 3 axis MechMate that I built and things are going fine.  It's able to move correctly in response to G code and the e-stop, feed hold and resume buttons all work. I'm running a PMDX-126 and Gecko 203v's and Mach 3 (2) is installed on a 32 bit gaming (i.e. high specced) PC running 32 bit Windows 7

I'm having problems setting up home are returning to zero. I do not have limit switches and have yet to get my proximity circuit sorted, so I'm slamming into end stops a bit!

1. I set zero for x,y,z with the machine co-ordinates lit.  This should be "table zero", right?
2. I can jog off this zero, switch off machine co-ordinates and re-zero, then regenerate path and and run through g code.  The display shows the work correctly relative to the table and the machine moves correctly in response to the g code.
3. If I <goto zero> at the end of the routine the gantry or car overtravel dramatically, which means I have to be quick hitting <esc> or <reset>.  I have tried debounce values of 500, 1000 and 2000.
4. I cannot subsequently zero any of the axes via the on screen buttons and have to restart the software to be able to do this.

Is there something I'm missing?

[ger21]

Sounds like you don't have any home switches setup? Or do you?

1) you "Home" the machine with the Ref All button, not by zeroing the machine while in Machine Coordinates. Even though you are in machine coordinates, you're actually zeroing the current offset, as you can't zero an axis in machine coordinates other than the "Ref" buttons.

3) GoTo Zero should be taking you right back to where you set your zero position. Debounce has nothing to do with goto zero.

Can you post your .xml file?

[Mountaincraft]

A little advice from a fellow newbie with a big table that just went through similar struggles...

Interrupt everything for a bit and install home switches... at least on the x and y axis (but why stop there.. do the Z too)... once you have installed them, go to the Mach 3 tutorials page and there is a homing/limits tutorial video that will walk you through the setup...

Once you do all this and get the homing system going, you can then set up soft limits, and you will not have to worry about slamming into hard stops anymore... You gust do a G53 ref home first thing whenever you power up the table... no more slamming! I have concluded that this slamming stuff just isn't good for the machine and causes continual alignment headaches...

Then once you have done that, buy Gerry's 2010 screen set for $20... Life will be better after that... It is for me...

The momentary interruption in playing with the machine to do this will pay itself back tenfold in reduction of hassle and headache and confusion.... Totally worth the effort and minimal expense...

[Red]

Thanks for the replies and advice.
I downloaded an update of Mach 3, installed it and ran off my old xml file.  The software now zeros after running G code and acts the way I expect.

I'm using proximity switches for home and limts, but have not got them working yet.  I have had a bit of difficulty with the circuit.  I had N/O switches in a parallel circuit, which is fine, but in my application I had them always closed and open on error, which of course does not register in a parallel circuit!  Now I've figured out what was wrong I can get homing working.

1) you "Home" the machine with the Ref All button, not by zeroing the machine while in Machine Coordinates. Even though you are in machine coordinates, you're actually zeroing the current offset, as you can't zero an axis in machine coordinates other than the "Ref" buttons.

This is gold.  Thank you.
I remember somewher that <ref all home> will only work if there are home/limit switches on all axes.  Is this true?

I have tried the <ref> buttons on the diagnostics page.  The Y works fine, but the X results in a horrible grinding that I put down to the 2nd (slaved) X motor turning in the wrong direction.  Is it possible for jogging and cutting to work OK, but not <ref>?

[ger21]

This is gold.  Thank you.
I remember somewher that <ref all home> will only work if there are home/limit switches on all axes.  Is this true?

No. If you don't have home switches, then "ref all" will zero machine coordinates at their current location.

I have tried the <ref> buttons on the diagnostics page.  The Y works fine, but the X results in a horrible grinding that I put down to the 2nd (slaved) X motor turning in the wrong direction.  Is it possible for jogging and cutting to work OK, but not <ref>?

If you don't have home switches installed, than no axis should be moving. Again, can you post your .xml file?

[Red]

Ger21,
Thank you for your responses.
I have attached the xml file.
Regards
Red

[Red]

Got the proxies working so now the machine "refs home" nicely in the Z and Y axes, and the X travels to zero but then much grinding ensues.  It's as through the 2 proxies (one either end of the Y-gantry) are confusing Mach 3 and driving the motors in opposite directions (even though one is slaved).  Is this possible?  I thought that the zero sequence allowed for two home switches on a gantry so that the gantry could be squared?

[ger21]

You may have made the changes, but I found these issues in the .xml you posted.

In Config > Homing/Limits, make sure all the A settings are the same as the X. You have them set to home in different directions (home negative setting).

The A home switch is not enabled. I'm assuming you have it enabled now?

[Red]

Thanks Ger21,
That's exactly the feedback I needed.  A is enabled,but in the wrong direction.

Got my router bracket built and installed.  Time to make some dust!

[Red]

Finally had time to check out homing.
I have a Y gantry that runs along twin X axes.  The X motors are installed at opposite sides of the gantry, so they need to run in opposite directions in order to move the gantry in the same direction.
I dropped one motor off the rack (so it could turn but not engage) and went through a few homing tests.  I could jog my gantry fine, but in homing the two motors (X and A) were turning in opposite directions.

I've solved my problem by having one motor (the X) home negative and one (the slaved A) home positive.  I don't know whether this is the usual way of dealing with this issue?
Ger21, you pointed me in the right direction, thanks.  Just my particular setup seems to require an alternative approach?