PDA

View Full Version : Using limit/home switches to autosquare the gantry


Alan_c
Sat 02 February 2008, 13:54
Originally in another thread

J.R.

Are you using one or two limits for the gantry (i.e. at each x motor)?

I planning on using two so that the machine is auto squaring every time one zeros but that requires two inputs to the BOB. (one common for Z, Y and X1 and the second for X2)

J.R. Hatcher
Sat 02 February 2008, 16:04
Alan I used 1 limit switch on the gantry. I'm running both steppers with 2 geckos 1 bob signal.

Greolt
Sat 02 February 2008, 16:31
J.R.

.................... but that requires two inputs to the BOB.



I don't believe that is correct. Two inputs would be desirable but not necessary.

When homing a dual drive axis Mach does one side followed by the other.

So just as X, Y and Z can share an input so can X slave. (I believe)

They can be made to home simultaneously with a custom script but sequentially is the Mach default.

I realise if you have not seen this happen it probably sounds far fetched. Why would a slaved axis home sequentially?

But when you've seen a slaved axis home you'll say "Oh I see what you mean" :)

Greg

Gerald D
Sat 02 February 2008, 22:41
I think I said that auto-squaring needs another BOB input, but I might be wrong. The auto square of the gantry could work on one BOB input if the sequence is as follows:
1. both motors drive until input goes off (switch opened)
2. both motors back off until circuit closes
3. one motor (A) drives until circuit opens
4. motor A backs off until circuit closes
5. motor B drives until circuit opens
6. motor B backs off until circuit closes

There is a reasonable assumption that the gantry is not far out of square to begin with. Steps 1 & 2 put the gantry in the ballpark. Step 3 might make it worse for a while.

After step 6., Mach may do fine tuning and repeat 3 & 4 ? :)

Greolt
Sat 02 February 2008, 23:00
Gerald here is what appears to happen. It happens pretty quick. :)

You press "Ref All"

Z axis does it's homing thing.

Then both motors (X axis) wander off toward the home switches.

Hits X home switch and backs off. Both motors do this.

A axis then goes on it's own. Hits A home and backs off. X motor does not move.

Then Y axis does it's homing thing.

As I say it happens quick but that's how it happens as Mach default.

This is why I say that X and it's slave (A) should be able to share an input.

Greg

Gerald D
Sun 03 February 2008, 00:25
Then both motors (X axis) wander off toward the home switches.

Hits X home switch and backs off. Both motors do this.

A axis then goes on it's own. Hits A home and backs off. X motor does not move.


When both motors are running to the switches the first time, the system doesn't know whether X or A broke the circuit. In your example, for sake of argument, let's say it was the A that "touched" first and X is lagging 2mm behind. Doesn't help "bouncing" only A after that because X will still be unreferenced?

The only way your logic (as observed) will work is if A was intenionally lagged (held back) during the run, so that it is known X will touch first. But that could be risky.

Greolt
Sun 03 February 2008, 00:36
Yes I see your logic. Gantry out of square and A opening before X

Maybe that is reason enough that separate inputs are in fact needed.

Good clear thinking there Gerald.

Greg

Gerald D
Sun 03 February 2008, 00:53
The 1 to 6 logic should work on one input...no?

1. both motors drive until input goes off (switch opened)
2. both motors back off until circuit closes
3. motor A drives until circuit opens
4. motor A backs off until circuit closes
5. motor X drives until circuit opens
6. motor X backs off until circuit closes

Greolt
Sun 03 February 2008, 01:16
I'm not sure if this can be done. The slaved axis homing sequence is hard coded.

Whether it can be made to do your sequence by use of a clever script....

I know that I have got mine doing it simultaneously by using the "RefCombination" command.

This probably needs some thought and a bit of experimenting. :)

Greg

Gerald D
Sun 03 February 2008, 02:12
Greg, this may be interesting:
http://groups.yahoo.com/group/mach1mach2cnc/message/35535

Greg, having looked at various posts on the Mach forums, the motion you are seeing is the way that Art wrote Mach. That logic does seem faulty.

Art also once said (http://groups.yahoo.com/group/mach1mach2cnc/message/78295) . . .
"you can home with the switches
being the same for limit or home, ( or not) , and home with slaved axis ( the
slave mey be the same switch as the master axis, or different if you wish to
autosquare. )"
......which left me with the impression that autosquare required 2 switches.

I will make a post to the Mach Yahoo to see if I can make some sense of this.

Greolt
Sun 03 February 2008, 02:28
......which left me with the impression that autosquare required 2 switches.


Yes that certainly makes it sound like it

Greg

EDIT, In the second post you linked to he was talking about the G100. The external devices do homing differently anyway so that may not necessarily apply to the LPT.

J.R. Hatcher
Sun 03 February 2008, 04:54
I'm probably going to open my mouth here and show my ignorance. If you were running the grantry with motors X and A (A as the slave). Could you use softlimits somehow to square the thing?? :o

Gerald D
Sun 03 February 2008, 05:14
As great as what soft limits are.....they are unfortunately not that great....

Realise that we only really need to "square" the gantry if it is out of square. ie. we either moved one end of the gantry while the motors were off, or we overloaded the one gantry motor and only that motor skipped steps. Under both of these conditions, soft limits are messed up too.

A little demo for you JR; Set your soft limits to stop within 1" of the mechanical stops. Switch motors off. Move gantry 2" by hand. Switch motors back on. See where your soft limits are now located (move slowly - one end will hit the stops).

If your soft limits stay set for weeks, then your gantry will stay square as well.

Alan_c
Sun 03 February 2008, 23:39
In my test set up, autosquaring uses two inputs. One is for Z, Y and X1, the second input is for X2 (or A).

This is the sequence as observed:

On ref all...

1. Z moves positive (up) until it reaches the limit, then reverses until the switch closes again...
2. Y moves negative (to 0) until it reaches the limit, then reverses until the switch closes again...
3. Both X motors move negative (to 0) until both limits (two switches) are open...
4. Both motors reverse rotation until the switches close again...
5. X2 (or A) motor then moves negative again until its switch opens, then reverses until the switch closes again.

If the switch ramps are correctly positioned, the gantry will now be square.

This arrangement uses two inputs to the bob: switches Z.Y and X1 in series to one input and switch X2 to the second input.

If autosquaring is not required or if you are using shared drives for the X motors then only one input is required (you dont need the second X2 switch)

Gerald D
Sun 03 February 2008, 23:52
Alan, that would be square and correct if motor X2(A) has its own switch, like yours does.

But Greg seems to think that only one switch is necessary (post #3)?

Alan_c
Mon 04 February 2008, 01:13
When Mach is homing the X axis using slaved drives, it must have two inputs for the limits to enable it to square. The motors only get the signal to reverse once the switch is open for that particular side.

If X1 switch opens, X1 motor reverses, but X2 motor continues to move in the original direction until its switch opens therfore they cannot share the same circuit.

I tried this on my test rig using two switches, when only one switch is actvated that motor reverses, the second motor continues until the second switch is activated, it then reverses until the switch is closed. when the second switch closes, the motor (X2) again moves to make the gantry approach the limit which makes the switch open again, this sends a signal to reverse the motor again until it is off the limit.

the short answer is if you want to autosquare, you MUST have two switches and two inputs.

Greolt
Mon 04 February 2008, 01:57
But Greg seems to think that only one switch is necessary (post #3)?


Greg was convinced by Gerald's logic several posts ago that this is unlikely to be true.

However having said that playing around with the scripts which set this in motion has me suspecting Mach may be made do things that the author did not intend.

But here is not an appropriate place to get into that. Only offers confusion for MM builders.

So lets leave it that two inputs are needed for the X axis auto squaring feature.:)

Greg

Gerald D
Mon 04 February 2008, 02:13
Okay, I think we have it clear how the current Mach3 does autosquaring.

Now I just need to convince Brian Barker that he could modify Mach3's embedded scripts so that the process is executed off only one switch circuit. The BOB sales people won't like it though.

Sorry if I led you astray Greg - it is a character trait drummed into South Africans to dupe Ozzies whenever they can :o.

Greolt
Mon 04 February 2008, 16:03
I see you are not making much progress on the Yahoo forum.

Questions are often not read very well before an answer is shot off.

I have been guilty of this myself. :)

Greg

Gerald D
Mon 04 February 2008, 22:43
Poor old Brian has a lot on his plate. He is not going to get interested in saving a single BOB input now. Besides, if he does that, he is going to confuse the "old guard" who are wired with 2 switches. The only way to make progress on that forum is to get the "old guard" to bite on an idea - heck, they can't even move to a modern forum! :)

stefanv
Tue 05 February 2008, 09:24
Just a stupid addition to an intelligent thread,..

Some months ago I asked about "homing" both X 's. http://www.mechmate.com/forums/showthread.php?p=4913&postcount=6 I was told by Gerald that we never loose steps and a good way of homing is to turn off the motors and push the Gantry against the stop blocks on both sides. That seemed all we would ever need at that time, and, as we didn't need to steer the 2 x's individual, it allowed us to double the x axis and free up one on the BOB board.
I do like the idea of having the extra axis as I have the challenge in mind to turn a piece into different planes and then work that plane with all 3 axes. Like, to make corbels and so.

So here's an idea,

- Go home according to mach3 based on the 1 limit switch on your main X.
- Then, ignore the limit switch and run straight through it until you hit the stop blocks on both sides. The Geckos will limit the motor’s current so running both against the stop blocks for half a second should hurt anything
- Then, back up until the limit switch goes off
- You’re square and home!

Right? … :rolleyes:

Am I making any sense? … :confused:

Stefan

Gerald D
Tue 05 February 2008, 09:39
Hi Stefan,

When we are lazy, we do that (drive against the stops). ;)

Last year I asked a question over here:
http://finance.groups.yahoo.com/group/geckodrive/message/12975

And that sure resulted in a heated debate, even some shouting. But, between all the noise, it was clear that neither the motor nor the drive will get damaged.

stefanv
Tue 05 February 2008, 09:59
So I don't know Mach3 well enough. But can you override the limit switch, make the X-motors push against the stop blocks, back up, and then home again to make sure you're square? (on one x limit switch)

Gerald D
Tue 05 February 2008, 10:42
Yes, you can override limits (left side of Settings screen) to push against the blocks, then re-engage limits to home again. But, if you use this method, why do want to have a switch at all? Push against the stops and call that "home".

There are so many options!

smreish
Mon 04 January 2010, 20:30
Copied from another thread

John,
Let's see if I can explain.
Mach is funny, that it actually has a built-in homing macro for finding home. It is designed to step through it's seek-n-find sequence going x, then x1, then y, then y 2, then z. Depending on the number of motors you have and such, it will configure the routine to home accordingly. If you have and x1 and x2 motor, then the auto squaring feature will be active. If you choose to use this feature, be prepared to make the eccentric holes in the rail adjustable to fine tune the "perfect square" of the machine.

.... back to explaining.

Since Mach already does this homing routine, you can wire the contacts in series to one input on the BOB. The downfall to this "series relay logic" is for some reason any of the axis' that is active is triggered by a limit/prox switch not on that axis, the machine will be improperly homed and usually ends up derailing the machine.

The only time this happened is when I physically triggered a prox sensor on an "alternate" axis during the routine to see what would happen. Good thing my estops work!

The mach3/artsoft manual explains the routine in detail.

Does this answer your request? Sorry for the delay - I have been out on vacation for a while.

refer to my post WAY back in time for the wiring part (http://www.mechmate.com/forums/showthread.php?p=9510&postcount=247)of this reply.

Sean

Greolt
Mon 04 January 2010, 20:58
Sean

Do you have slaved axis homing working to "square the gantry" with all home switches sharing an input?

I ask this because it has been my experience after helping many Mach users set up slaved axis homing, that for whatever reason, many can only get it to work by using the RefCombination command.

When using RefCombination you must, by definition, have the slaved axis home switches on separate inputs.

Brian of Artsoft, always recommends using RefCombination for slaved axis homing.

In fact, I think he believes it is the only way it will work, although I know that is not so. I don't use it.

Greg

smreish
Mon 04 January 2010, 21:04
Greg,
Good to hear from you. I haven't tried this in a while so your most likely right about the RefCombo.

I found that the machine actually works better (both of them #5 and #28) by NOT using them. I just mechanically set the square of the machine on the hard stops, engage the racks.

I only use the prox sensor on the x2 rail for sensing "home" during the routine.

My x1 and x2 motors share steps between the BOB and the G203 drives via a "Y" cable. Note: this is so I have the 4th step/dir output available for my indexer.

...Now I just might go and try it sometime soon during my next build which starts next week! Yeah - machine # 3 - PLASMA cutter.

Greolt
Mon 04 January 2010, 21:57
G'day Sean

My recommendation would be to have the two home switches on the slaved axis to be on separate inputs.

Until I hear of a couple of users with equivalent experience to yourself, successfully using a shared input for slaved axis homing, I will stick with that recommendation. :)

Greg

Greolt
Tue 05 January 2010, 01:50
My x1 and x2 motors share steps between the BOB and the G203 drives via a "Y" cable. Note: this is so I have the 4th step/dir output available for my indexer.
Sean I should have read your post more carefully. I missed the above line.

As far as Mach is concerned you do not have a slaved axis. You have a cloned axis. There is a big difference.

X axis signals are being sent to both motors driving the X axis by virtue of the way you have it wired. It is not possible to "Auto square the Gantry" with Mach using this setup.

When Mach homes a slaved axis, it first de-couples the two axis, deals with them separately, and then re-couples them together at the end of the homing routine.

Of course this is not possible when both sides are running from the X axis signals. As far as Mach is concerned there is only one motor on X.

So if you have slaved motors driving the X axis, and you have a home switch on both sides with the intention of "auto squaring the gantry" then they must not share an input.

Greg

smreish
Tue 05 January 2010, 08:05
Greg,
I won't spend a lot of time here, but you are correct. My point that I didn't get across was I had them separate and slaved and didn't get the added benefit of auto squaring when the machine design allows for mechanical squaring of the y axis. Thus, I freed up my BOB output #4 so I didn't have to buy another card for the added axis.

Plus, on my Multicam 1000 series, the 3:1 drive belts always seem to break when the machine was "auto squaring". Which was about 1 to 2 times per year. Really annoying.

But, in retrospect, it was fun trying the auto squaring function before I changed it back on this MM.

The machines that I am aware that are similar in control this sharing of the axis steps are:
#5
Nils MM
#28

...Any others?

Sean

aniljangra
Tue 05 January 2010, 12:54
On my mm I am using the same thing, sharing same step/dir for 2 drives.

Banging on stopper blocks is a quick and easy way to square the Gantry :)

J.R. Hatcher
Wed 06 January 2010, 06:29
Mine shares 1 signal ..... like yours .... as per our conversation Mon 07 January 2008, 16:20

http://www.mechmate.com/forums/showthread.php?p=19437&postcount=4

smreish
Wed 06 January 2010, 17:24
...and then finally JR finds the thread where we discussed this and the "ubersmart" Mike explaining the details. I love this place in MM land.

Sean

Greolt
Wed 06 January 2010, 18:09
Yes the forum works well and Mikes technical help is very valuable.

Both X axis drives sharing an output is certainly a valid way to have things set up.

However this thread is called "Using limit/home switches to autosquare the gantry" ( at least it is now, maybe it did not start with that title) :)

It needs to be clear for those new members reading this thread that "Auto squaring the gantry" in the Mach sense can not be done with a cloned axis.

It can only be done with slaved drives, separate home switches on each side of the X axis and separate inputs for each of those switches.

And of course there are alternative manual methods to square the gantry, other than using Mach's auto squaring feature.

Greg

smreish
Thu 07 January 2010, 04:10
Thanks Greg,
I think I should tag this thread now for some significant editing.

...thanks for keeping me focused on the point. (little kids and too much coffee will make me loose focus:)

Sean

Belli
Thu 07 January 2010, 11:41
If you are homing two axes at the same time, remember to check 'Home slave with master' under 'General config'. This will stop the little dance that the A axis does afterwards.

Greg

Kobus_Joubert
Thu 07 January 2010, 11:57
Hi Greg, glad to see you are still following the forum. Everything of the best there in Edenvale.

Greolt
Thu 07 January 2010, 13:58
If you are homing two axes at the same time, remember to check 'Home slave with master' under 'General config'. This will stop the little dance that the A axis does afterwards.
If you do check "Home slave with master" then that means "Auto squaring the Gantry" will be disabled.

Greg

Belli
Fri 08 January 2010, 13:40
Um, no.

Greolt
Fri 08 January 2010, 15:40
Um yes. :)

I did what I always do when someone says I have it wrong. I went and did some tests.

And testing confirms,

"If you do check "Home slave with master" then that means "Auto squaring the Gantry" will be disabled."

Greg

Alan_c
Sat 09 January 2010, 15:01
If its not doing the dance, its not auto squaring...

Belli
Sat 09 January 2010, 23:55
If its not doing the dance it means the axes are homed simultaneously as opposed to sequentially. Look at the machine coordinates for X and A and see if they are zero after homing.

Greolt
Mon 11 January 2010, 16:19
If its not doing the dance it means the axes are homed simultaneously as opposed to sequentially. Look at the machine coordinates for X and A and see if they are zero after homing.

I'm sorry Greg but this assumption is wrong.

I have only responded to this post because new readers looking for info on Mach's "Auto Gantry Squaring" may be misled.

Personally I don't care, as I know how it works and do not feel the need to convince anyone who disagrees, so I will not be entering in to a debate about it.


"If you do check "Home slave with master" then that means "Auto squaring the Gantry" will be disabled."

Greg

Greolt
Mon 11 January 2010, 17:43
I re-read my post and can see that it may be taken as rude or arrogant.

Please believe that is not my intention. In light of some recent experience, I am just feeling a bit jaded with debates over technical issues at the moment.

That is my problem and no one else's and I apologise.

Greg

Robert M
Mon 11 January 2010, 18:38
Greg ( Greolt),
Well said….Very humble & noble of you ;)

bradm
Mon 11 January 2010, 20:08
(quietly applauding Greg)

Gerald D
Mon 11 January 2010, 22:34
Okay, here we have two Gregs respectfully disagreeing with each other. There is no point in pursuing this debate unless somebody goes out to the workshop, knocks the gantry out of square for a start, and then runs Mach to see what happens under different settings. If someone comes back with a report, we need to know the Mach version as well as maybe some other factors which could muddy the waters.

Greolt
Mon 11 January 2010, 22:50
Already done those tests Gerald. See post #40.

Here is a section of the Mach3 change log,

May 14 2007 Version 2.00.073

New selection in Config/general for "Home slave with Master. " , this selection turns off autosquaring
of a gantry and keeps the slave engaged during homing. Config/Toolpath "Use Origin sphere" also controls
display of the bounding box.

http://www.machsupport.com/downloads/Changelist90.txt

Greg

ger21
Wed 13 January 2010, 12:07
I'll back Greg (Greolt) up on this. The "Home Slave with Master" was added for users wanting to home both the slave and master to a single home switch.


Gerry

Belli
Thu 14 January 2010, 23:56
OK, I'm with Greg on this one. ;-)

This is what I did:
Hook up breakout board, connect two switches on individual inputs. Slave X -> A, enable X and A home switches.

'Home slave with Master' - unchecked. Press Ref X and then press and release A home switch, I get the green light on A (axis homed), press and release X, normal behavior observed on X axis, get the 'X' (axis homed) green light.

'Home slave with Master' - checked. Press Ref X and then press and release A home switch and I don't get no green light on A (axis not homed), press and release X, normal behavior observed on X axis, get the 'X' (axis homed) green light.

While I don't have motors connected and so can't determine at what point the motors stop, this behaviour I think is just as Greg (the other one) described it. It does of course beg the question, 'How do we use home switches to square the gantry without twisting the gantry up each time?'.

Cheers,
Greg

Greolt
Fri 15 January 2010, 02:16
G'day Belli

I will use our user names to avoid confusion. Our Mothers are both clever people to give us both such a fine name. :D

"How do we use home switches to square the gantry without twisting the gantry up each time?"

I assume you are concerned about the "little dance" twisting the gantry.

What happens with the standard homing sequence on a slaved gantry is this,

First the master motor travels to it's home switch and backs off. All the while the slaved motor moves along with the master in unison.

Then after that has completed, the slaved motor goes to its home switch and backs off. This time the slaved motor does it on its own. Master motor stays still.

This second movement is what you call the "little dance"

However in practice this second movement is only about 1 or 2mm. No problem there for a MM gantry.

Then there is another option.

Replace this part of the homing macro,

DoButton( 22 )
DoButton( 25 )

With this ,

RefCombination (9)

With this command the master and slave will home simultaneously. I am told by Brian (owner of Artsoft) that this also "auto squares" the gantry.

I use the first option on my router, which has less tolerance to the "little dance" than does a MM.

I just find it reassuring to actually see the "little dance" happen and know that all is square.

Greolt

ger21
Fri 15 January 2010, 06:47
Note that refcombination(9) is for the X and A axis. For X and B, it's refcombination(17). For X and C, it's refcombination(33).

sailfl
Fri 15 January 2010, 06:52
Greolt

You talk about replacing the homing macro. You are talking about that macro used with the screen to do refCombination? So what is the name of that macro?

Thanks

Greolt
Fri 15 January 2010, 13:33
So what is the name of that macro?


I don't know that it has a name.

Access it by going to menu/operator/edit button script, then the refall button will start to wink.

Click on it and the homing macro will open in the VB editor.

Button scripts are not in the macro folder like a lot of others are. They are stored in the screenset file.

Info on using the RefCombination command can be found here,

http://www.machsupport.com/MachCustomizeWiki/index.php?title=Mach_specific_Subroutines/Functions_grouped_by_purpose

Greg

sailfl
Sat 16 January 2010, 03:50
Greg,

Thanks for the information.

Robert M
Sun 17 January 2010, 05:34
The beauty of a well organized WIKI !
I fell it’s Unfortunate the MechMate community abandon it/ never pursuit it ! :o

cab. guy
Sun 17 January 2010, 14:40
Been doing the dance for 8 months,drawback? It cost the whole price of one extra proxy switch and one extra Bob input.Value = priceless.:D

rotorzoomer
Wed 09 June 2010, 03:06
I am up to that awkward part of the planning stages where there is much debate on which method of homing / referencing is best to use and as you know the parts you buy changes with each design.

What is the latest accepted method that is on average the most reliable, robust and dependable.

BTW - I have configured and tested on the test bench every mode possible under Mach3 (Slaved, Independent, Soft Limits, Ref All with Limit Switches e.t.c.) but what is the reality in a production environment?

A show of hands of what people are using for homing / referencing these days?

Gerald D
Wed 09 June 2010, 03:44
Here's 5 votes (have 5 running machines) - No electronics used for squaring

bradm
Wed 09 June 2010, 05:30
Mark, what part changes are you considering?

The proximity sensors are used for detecting limit excursions and bit crashes as well as their (optional) use for homing and squaring. So there's more than one reason to have at least a Y-Car proxy.

It's hard to argue with the simple reliability of running/pulling the axes against the stops, but even if you choose this method, you might want proxies.

rotorzoomer
Wed 09 June 2010, 05:46
I think i will just start with the stopper blocks but wire enough cable to the MechMate for an install of limit switches or other device to detect the ends at a later date.

I have faith in Mach's ability to use soft limits in the short term of my build and learning curve journey.

riesvantwisk
Wed 09 June 2010, 08:03
Mark,

For squaring I use : pulling the axes against the stops.
For homing I added 3 micro-switches to find the zero of my machine for each axis.

Ries

gmcclure
Mon 28 February 2011, 05:37
Can I check I have this correct

It I wire X, Y and Z proxy to a common input and X slave (A) to its own input then I can auto square the gantry by editing the macro with the substitution to RefCombination (9) when referencing X.

Can I use the offset feature of MACH3 to assist in squaring rather the bothering with the eccentric targets that go in the holes in the rails? (assuming they are close enough so as to not over rack the gantry in the process).

Assistance would be great as I am planning the wiring of the unit.

I am using a PMDX126 BOB (when it arrives) so have 8 inputs to use. With touch pad and touch probe, and 2 inputs for proxy switches I will have allocated 7 inputs so far.

regards

Graeme

smreish
Mon 28 February 2011, 09:08
Graeme,
To my knowledge, you still need to have the proximity limits sense something, even if you use an offset macro of some sort. The only way I have been able to dial in the mechanical square on a stepper (without encoder) machine is the with adjustable targets.

Others please step in here if they know something better.

Sean

ger21
Mon 28 February 2011, 09:37
Not sure if the home offsets can be different for slaved axis. One thing to look out for though, is that the homing speeds can be different, but need to be the same