Machsupport Forum

Mach Discussion => General Mach Discussion => Topic started by: JimKnopf on May 01, 2011, 12:48:25 PM

Title: Homing position is not absolute
Post by: JimKnopf on May 01, 2011, 12:48:25 PM
Hello everyone!

I'm not happy with the homing function in Mach3.
When starting the homing, the machine runs into the switch. It then slow down and stops. The number of steps needed to stop depends on the speed in the moment the switch is closing and the acceleration. The machine is then trying to get to full speed in the opposit direction til the the switch is released. In the moment the switch is released it will be on the same speed like the moment the switch was closed because the distance and acceleration are the same. Now the machine slow down again and stops. And after that the position is set (to zero). This position is the number of steps away from the switch-release-point of needed to come to full stop.
If the the machine is verry close to the switch before homing, may be 4 steps, it will not reach max speed, so not the max breake distance is nedded. 4 steps vor speedup means 4 steps needed to break. In this case the new zeroposition will be ca. 4 steps away from the switch-release-point.

The homingposition depends on the position from where the homing ist started. And if you change the motortuning the position will move as well.

I would like the machine running into the switch. Break and stop while counting the steps needed. As I know a switch (mechanical or optical) can't be released by now. Then travel back these number of steps. Now go on step by steb til the switch is released so the machine can stop with only one step after releasing the switch. This position will never change.
What do you think?
Burkhard (Germany)
(sorry for my bad english)
Title: Re: Homing position is not absolute
Post by: ger21 on May 01, 2011, 12:52:11 PM
Lower your homing speed in Config >Homing/Limits. It sounds like you're homing at 100% speed. Try 10%, or less.
Title: Re: Homing position is not absolute
Post by: JimKnopf on May 01, 2011, 02:11:50 PM
Lower your homing speed in Config >Homing/Limits. It sounds like you're homing at 100% speed. Try 10%, or less.
Hi Gerry!

Thanks for your advice. My machine is not very fast and 10% is really slow, especially when there is a long way to travel. And, it will only lower the effect, not eliminate it. I'm using light barriers for homing and I would like it exact as it can be. If i later change the homing speed the homing position will move, I don't like that. May be I can use a macro. Fist homing run with 100% to come close to the switch and a second one, step by step.
With the light barriers the signal needs max 2 steps to flip and I don't want to give this away.

Burkhard
Title: Re: Homing position is not absolute
Post by: BR549 on May 01, 2011, 02:15:59 PM
The homing is not speed dependant. It acts on the switch change of state when it backs OFF the switch.  Yes the final stop position can change with speed BUT that is not where the home position is derived from.

Just a thought, (;-) TP
Title: Re: Homing position is not absolute
Post by: HimyKabibble on May 01, 2011, 02:27:37 PM
Your understanding of how homing works is incorrect.  When homing, Mach takes a step, then checks the home switches, BEFORE taking the next step.  If it sees the switch has changed state, then THAT position becomes the "home" position.  The fact that the axis continues to move beyond that point does not affect the home position in any way.  Homing at high speed, however, WILL generally make homing less accurate.  It should be done at a low speed.

Regards,
Ray L.
Title: Re: Homing position is not absolute
Post by: ger21 on May 01, 2011, 03:02:16 PM
Here's a macro that will home at the set speed, then re-home at 1/10 that speed, then reset the speed to what it was before.

DoButton(24)
DoButton(23)
DoButton(22)
While IsMoving()
Sleep(100)
Wend
SetParam("XRefPer", GetParam("XRefPer")/10)
SetParam("YRefPer", GetParam("YRefPer")/10)
SetParam("ZRefPer", GetParam("ZRefPer")/10)
DoButton(24)
DoButton(23)
DoButton(22)
While IsMoving()
Sleep(100)
Wend
SetParam("XRefPer", GetParam("XRefPer")*10)
SetParam("YRefPer", GetParam("YRefPer")*10)
SetParam("ZRefPer", GetParam("ZRefPer")*10)
Title: Re: Homing position is not absolute
Post by: JimKnopf on May 01, 2011, 09:04:03 PM
Hello TP, hello Ray!

Set the acceleration of your machine to , let us say, 10. Then do the homing. You will see what i described. That axis run into the switch, slow down to stop. Go back increasing speed til switch release, slow down to stop, and then resetting the coordinates. The machine is not moving again and the machine coordinate is set to zero (if you don't set an offset). And that position do depend on speed! Do the homing with different speed, look at your stepper position (a marker or screw) it will be different while the machinecoordinates in all cases is shown with zero.
If you were right, and as we see, the machine is not moving again towards the switch, the machine will not show the position zero, but the distance needed to come to stop  ;).
I understand that the switch need time to flip, no matter how fast the knob is hit. But why travel the long way with low speed when that is only needed for the way back to release the switch? Is it not stupid to let a fast machine move slow across the whole table while only a few step are needed on that speed?

Burkhard
Title: Re: Homing position is not absolute
Post by: JimKnopf on May 01, 2011, 09:05:31 PM
HelloGerry!

Thanks for the makro. Thats what I like much more :-)
Burkhard
Title: Re: Homing position is not absolute
Post by: stirling on May 02, 2011, 03:56:32 AM
Hi Burkhard

FWIW I think you've made a good catch and a quick scope of Mach's step stream and dir pin would tend to confirm you're correct.

I'd just make a couple of observations re: Gerry's method if he doesn't mind. The crux is that the second homing speed can be anything up to the maximum reliable speed that your axis can move without an acceleration curve. (a bit like the Z axis under THC control).

Also, I think there may be another issue. Whilst this method will allow the axis to stop on a dime the instant the switch deactivates on the backoff phase, depending on the type and quality of your switches this could mean you're setting home at the switch jitter zone. This could be an issue particularly if home and limit share a switch. Maybe at the end of the script, you could move some predefined constant distance further off the switch to counter this.

Ian
Title: Re: Homing position is not absolute
Post by: JimKnopf on May 02, 2011, 04:59:07 AM
Thanks Ian for confirming my observations!

I also use CNC-Player and that program do the homing the way you mentioned. But it only uses the moment when the switch is hit. There are fields for hysteresis (distance between closing- and openingpoint of the switch) and the distance to move the switch free. hysteresis is not needed in Mach3.
I  think the only constant position will be taken, when the releasepoint will be found without an acceleration curve. I have no problem when the machine travel an extra distance (may be 1mm), if it will allways be the same. The optimum would be to run with max speed into the switch, move back step by step til switch is released, reset the coordinates and travel on a defined distance ( or first travel on and reset coordinates on that position). This will be fast and absolute exact. May be something like that could be inserted in the program code.
@Gerry
Is it possible to turn off/on limitswitches inside a macro?
Burkhard
Title: Re: Homing position is not absolute
Post by: Hood on May 02, 2011, 07:11:56 AM
Its been a long time since I used Mach to home (do index homing in my drives now) but on the Bridgeport I had optos and as it had once been a manual it had glass scales so I hooked up a DRO. I went to see how accurate the optos were and I homed around about 100 times and  only once (if I recall) did the glass scales show it other than 0 and even then it was 0.005mm so I concluded that it was repeatable.

Maybe things have changed in Mach in recent years I dont know?
Hood
Title: Re: Homing position is not absolute
Post by: JimKnopf on May 02, 2011, 07:33:28 AM
...
 so I concluded that it was repeatable.
......


Hi!

I think it is absolut repeatable, as long as you don't change the speed and ensuhre, that the axis always reach the maximum travelspeed (means minimum distance from the switch/optos).

Burkhard
Title: Re: Homing position is not absolute
Post by: Fastest1 on May 02, 2011, 07:43:41 AM
Just out of curiousity, what kind of variances are you getting? Is it in the .05mm/.00196" that Hood was referring to?
Title: Re: Homing position is not absolute
Post by: Hood on May 02, 2011, 09:02:54 AM
Fastest, the variance I saw was a factor of 10 less, it was 0.005mm and I put that more down to the wear on the bridgeport than the actual switches.

As for distance, well I would think as long as you were far enough away that the motor could get to its homing speed then it should not make a difference how far away you were from the home switch as it would be at its max velocity. Obviously that distance would be determined by the accel in motor tuning and steppers are by their nature slow, I think at the time my accel was 40mm/s/s but reducing the max vel in motor tuning from 2500 to I think 2300 allowed me to get the Accel up to 120mm/s/s. That was a vast improvement and speeded up maching time significantly as the small decrease in Vel was well offset by the increase in Accel.
That is why I love servos, even on my heavy lathe I can get 800mm/s/s accel and it is just so nice not to be able to see an axis accel/decell although at first it was a bit scary being used to steppers.
Hood
Title: Re: Homing position is not absolute
Post by: JimKnopf on May 02, 2011, 09:46:07 AM
My variances are about 0.1 mm with low acceleration
Title: Re: Homing position is not absolute
Post by: Hood on May 02, 2011, 11:55:20 AM
How slow is the accel?
Hood
Title: Re: Homing position is not absolute
Post by: BR549 on May 02, 2011, 12:28:58 PM
hIYA JIM, NOPE been there tested that one. I tried to argue the same point with ART. BUT after he explained how it actually worked and I spend days testing it, the results were that mach homing is NOT speed dependant, other than the time span of one step cycle(very very fast).

Yes the final stopping point will change BUT not the actual trip point of the home switch. The trip point is where the home position is recorded not where the motion stops.

Same thing with the G31 probe cycle. Argued that one as well and ART was correct.  I stil prefer the alternate method that  the rest of the world uses BUT that is another story.

NOW IF you are using a spring loaded switch that has a flip flop mechanism it can change depending on how hard you slap the switch. BUT that is a switch problem not a MACH problem.

Just a thought, (;-) TP
Title: Re: Homing position is not absolute
Post by: stirling on May 02, 2011, 01:02:18 PM
Hiya Terry - Before I start we have to promise not to fall out on this one OK?  ;D ;D ;D

I tried to argue the same point with ART. BUT after he explained how it actually worked and I spend days testing it, the results were that mach homing is NOT speed dependant, other than the time span of one step cycle(very very fast).

Shoulda argued harder. Do the SCOPE thing. Mach comes off the switch, slows down, stops and sets THAT position as home. It's not just a case of speed, it's more acceleration but obviously the two are linked.

Yes the final stopping point will change BUT not the actual trip point of the home switch. The trip point is where the home position is recorded not where the motion stops.
But what do you mean, IF Mach records the actual trip point somewhere, it would only be any use if it then moved BACK to that point before setting that as home - but it doesn't do that.

This is subtly different from G31 which does indeed store the trip point.

FWIW I've come up with these observations...

For a given acceleration and homing speed:

Let's call "D" the distance it takes to accelerate from rest to the homing speed.

If we commence homing at a distance from the switch greater than D then the homing position will be set at D from the switch.

If we commence homing at a distance from the switch LESS than D then the homing position will be set at that same position we started from.

If we reduce the homing speed but keep our accel the same then D will get smaller but the above will still hold.

However, once we reduce the homing speed to a level that requires NO acceleration curve, home will be set at the very step that deactivates the switch REGARDLESS of whether we start at, greater or less than D.

Increasing or decreasing acceleration just makes the above less and more obvious respectively.

Cheers

Ian
Title: Re: Homing position is not absolute
Post by: JimKnopf on May 02, 2011, 01:44:22 PM
Hi Ian!

Thank you for your explanation! That's exact what i mean, and that is what I don't like. It would be really OK if the point of releasing the switch is recorded and after that the machine comes to stop. The coordinates displayed then would not be zero but the distance D. That would be always exact :).
I find it annoying to need to search the speed with no acceleration curve, if it is possible. I think that is the job of the program. Like I said, moving back step by step.

@BR549
It is so easy to test. Set your acceleration on a low level, 10 for example. Move away from the switch and do the homing. You will see what we described. And look at the diagnostic page, you will see the machinecoordinates are set to zero where the machine has stopped. If you where right the distance from the switches must be displayed.

@hood
I set the acceleration to 40 for testing. That is not what I will later use, but why do the user have to care about these things?
There is another possible problem. If the switch is released before the machine stops, it won't move back at all. As I said, I used light barriers with a small pin moving thru the opto ( in fact a needle). That doesn't work, I have to use a thin plate. I think good code should handle that (if switch is released before coming to full stop, move back first til switch closes again and then expect the release).
I don't like to have to find the best speed for homing. That's the job of the program. Why should I travel with 10% of the speed across the table when only 3mm are needed.

Mach3 is a great program, but homing is a fundamental function that should work perfect I think.

Burkhard
Title: Re: Homing position is not absolute
Post by: Hood on May 02, 2011, 01:53:52 PM
Really though you dont have to find the best speed, you just have to use one and not change. Granted if you have slow accel and are closer than your axis can accel to full speed then that distance may change but the double homing should prevent that being an issue.

Homing is best done with a switch and then an encoder pulse after the switch has been found but sadly the PP is not good enough for that. There were products on the market a while back that could do Index homing but unfortunately the guy (Ed Gilbert) stopped making them for several reasons. In the near future however there should be the capabilities in several of the external motion devices for Index homing but I dont think the Parallel Port will ever get there as it just is not fast enough to read an index pulse.

My servo drives not only seek the index after the switch is seen but they gate the A and B pulses with the Index.
Hood
Title: Re: Homing position is not absolute
Post by: JimKnopf on May 02, 2011, 02:29:52 PM
Really though you don't have to find the best speed, you just have to use one and not change. Granted if you have slow accel and are closer than your axis can accel to full speed then that distance may change but the double homing should prevent that being an issue.

Hi Hood!

You are wrong!
If you are to close to the switch (closer than the distance needed to accel to homing speed), the axis stops exact at the same distance from where you started, because the accel and break distance are the same. You can do the homing 10 times. If you are to close at the first one, you will be also on the last run. I have tried it!

Do the homing from a distance. Watch the stepper position. Make a very littel move towards the switch without activate it. Do the homing again. You will see, it will be a different position. Do the homing again and you will get the same position as the last one.

If I optimise my stepper driver I want to increase speed.

Burkhard
Title: Re: Homing position is not absolute
Post by: Hood on May 02, 2011, 03:47:17 PM
Well afraid I dont follow, you will probably be best contacting Andrew at machsupport and giving him an exact test method so he can replicate there and I am sure Brian will then be able to find the issue. Homing  however is likely to be a driver function so that would then fall to Art to supply a solution.
Hood
Title: Re: Homing position is not absolute
Post by: BR549 on May 02, 2011, 07:15:09 PM
Now it was years ago that it was tested  AND it was on a scope BUT I remember that it set the position from the trigger point of the switch not where it stopped.

It really would not make sence to do it any other way.

I will have to dig out the old trouble notes again.

Not to worry Ian, I respect all opinions and occasionally I am almost kinda maybe sorta incorrect(;-). AND every once in a long while I am flat out WRONG.

(;-) TP
Title: Re: Homing position is not absolute
Post by: BR549 on May 02, 2011, 08:52:05 PM
OK JUst a question are we talking PP or SS??  (;-)  I do know that homing is control through the driver on the PP.  SS??? should be on the board.

(;-) TP
Title: Re: Homing position is not absolute
Post by: JimKnopf on May 03, 2011, 03:09:26 AM
OK JUst a question are we talking PP or SS??  (;-)  I do know that homing is control through the driver on the PP.  SS??? should be on the board.

(;-) TP
Hi TP!

I have a very simple machine, self constructed. I use stepper motors (dir/step controlled) using the parallelport. The homing sequence is full controlled by Mach3. The optos are connected to the parallelport.

It really would not make sense to do it any other way.
That is what I mean, but it does not work that way.
It is so easy to test, I can only repeat it. As long as during the homing, a acceleration curve take affect, the machine will travel on after releasing/leaving the switch. You can see, that the machine doesn't travel towards the switch again. Look at the machine coordinates. If they show zeros that will be ugly, and that is what I see on my machine. And it is not to clear the jitter area.  It is not the speed of the parallelport it is the software.

@hood
that was the first thing I wanted to do, but I did not find an email adress.

Burkhard
Title: Re: Homing position is not absolute
Post by: stirling on May 03, 2011, 05:30:40 AM
Hi Burkhard

I think we're agreed that this issue is amplified the lower the accel capabilities of the machine. Putting my practical hat on, I think the accel issue alone is probably going to prove your real problem. I don't know how far down the road you are with your build, but CV for example must be (or will be) a PITA. Although I put home and limits on machines I build for others, I don't have either on my own wood router and to be honest I've never missed them, but I'd be lost without CV and to get that to perform you need hot acceleration.

Just an (alternative) thought.

Ian
Title: Re: Homing position is not absolute
Post by: JimKnopf on May 03, 2011, 06:39:01 AM
Hi Ian!

Now you got me :)
I'm not familiar with all terms, especially in English. What means CV. I'm now ready with my second machine. The first one was build of wood :D. And it was working. Not very stable but OK for PCB milling. I was using cheap materials like "trapeze" screws. Now I'm using quality components, like supported rail, ball screws.
The only things missing now are the limit switches and the toolsetter.
Basically I can live with the effect I described, because I know how to prevend it. But I think it will be simple to change the code in the program to avoid these things.
Burkhard
Title: Re: Homing position is not absolute
Post by: stirling on May 03, 2011, 10:08:30 AM
Hi Burkhard

I'm darn sure your English is waaaaaaay better than my Deutsch  ;D

CV - is so called "Constant Velocity" contouring. See 10.1.16 Path Control Modes in http://www.machsupport.com/docs/Mach3Mill_1.84.pdf (http://www.machsupport.com/docs/Mach3Mill_1.84.pdf)

Cheers

Ian

Title: Re: Homing position is not absolute
Post by: BR549 on May 03, 2011, 10:41:42 AM
OK I will have to setup a machine here to run MACH. The last couple of years I have been on the dark side (EMC2).

(;-) TP
Title: Re: Homing position is not absolute
Post by: JimKnopf on May 03, 2011, 01:35:41 PM
Hi Ian!

Thanks for the explanation, now I know about CV :-). Your Deutsch was perfect :)
I will increase my acceleration, when I finish the new drive circuit wit FETs. But I will drill and engrave the PCB with my machine ;-)

I just thought that the way of the homing with dir/step controlled steppers could be improved. I will write to Andrew when I get the email address.
Burkhard
Title: Re: Homing position is not absolute
Post by: Hood on May 03, 2011, 03:15:14 PM
http://www.machsupport.com/forum/index.php?action=profile;u=26658
Title: Re: Homing position is not absolute
Post by: BR549 on May 03, 2011, 10:11:31 PM
AAARRRRGGGG, Yoous guys were correct (;-) It sets the home position AFTER it comes to a complete stop.

(;-) TP

Title: Re: Homing position is not absolute
Post by: JimKnopf on May 04, 2011, 03:52:12 AM
Hi All!

Thanks Hood for the link, I've send andrew a mail.

Thanks TP for confirming ;)
Thanks everyone for your suggestions and advises.
Now I will wait if I can get an answer from Andrew.

Burkhard
Title: Re: Homing position is not absolute
Post by: stirling on May 04, 2011, 07:15:06 AM
Burkhard - just a post script. I set up a temporary home switch on my system (turned the accel waaaaay down so I could measure things - I'm normally at 2500mm/s/s) and found one slight twist. I homed from a distance and noted where it stopped (I'll call this the ORIGINAL home point) and then moved closer to the switch (about half way) and then re-homed. Because of the switch hysteresis it actually travelled slightly FURTHER off the switch than I started from. I then just kept re-homing from wherever it finished, and this effect builds until eventually it gets back to the ORIGINAL home point. Of course once there it "settles" and returns there no matter how many times you re-home as we'd expect. I think the biggy though is (as you've said) - if you change your homing %speed then your home position WILL change.

Cheers

Ian
Title: Re: Homing position is not absolute
Post by: HimyKabibble on May 04, 2011, 11:20:50 PM
AAARRRRGGGG, Yoous guys were correct (;-) It sets the home position AFTER it comes to a complete stop.

(;-) TP



Which, BTW, will be exactly as accurate as setting the zero when the switch actually opens.  The number of steps the machine takes after the switch opens will be exactly the same, as long as the home velocity and acceleration do not change.

Regards,
Ray L.
Title: Re: Homing position is not absolute
Post by: JimKnopf on May 05, 2011, 03:18:27 AM

Which, BTW, will be exactly as accurate as setting the zero when the switch actually opens.  The number of steps the machine takes after the switch opens will be exactly the same, as long as the home velocity and acceleration do not change.

Regards,
Ray L.
Hi Ray!

And here you see one point. I don't want to be fixed on the speed and acceleration settings while I may improve my machine. That's the one thing. And the second, if you are closer to the switch as needed for accel to full speed, you will get different results. That is simply not perfect but easy to change.
I got a very fast answer from Andrew. He will think about changing the code and if he does it may not stand at the top of his list.
He advised me to use a macro, and I'm going to write one but I first have to learn more VB and how it is working with Mach3.
Here is the structure I will follow:

struct x (homingDir,homingSpeed,maxSpeed,resolution,signal,homing button)
struct y (homingDir,homingSpeed,maxSpeed,resolution,signal,homing button)
struct z (homingDir,homingSpeed,maxSpeed,resolution,signal,homing button)
struct u (homingDir,homingSpeed,maxSpeed,resolution,signal,homing button) //universal
//reading the homing config
set the variables with the values in the config

//reading motor tuning config
set the variables with the values in the config
//reading ports and pins config
set the variables with the values in the config
x(homing button) =1022
y(homing button) =1023
z(homing button) =1024
u=z //copy the set of variables
do homing
reset coordinate
u=y
do homing
reset coordinate
u=x
do homing
reset coordinate

End program

subroutine homing

while u(signal)// make sure the switch is released
   move axis inverted(u(homingDir) about u(resolution)
end while

dooembutton (u(homing button)) //to get fast to the switch or something to make the axis move til the switch is hit

while not u(signal)// closing the switch
   move axis u(homingDir) about u(resolution)
end while

while u(signal)// release the switch
   move axis inverted(u(homingDir) about u(resolution)
end while

move axis inverted(u(homingDir) about 1mm //clear jitter area
end subroutine

I don't know if the function struct is part of VB, and if it is possible to get the value of the switches.
With this macro the homingpoint will never change unless you change the resolution of your axes.

I even don't know if it is worth the time and power to write such a macro.

Burkhard
Title: Re: Homing position is not absolute
Post by: stirling on May 05, 2011, 04:18:38 AM
Ray - Neither Burkhard nor I have ever questioned accuracy - but then I think you know that...

Terry was just having the good grace and balls to admit he was wrong. Give you any ideas Ray?

Burkhard - don't forget Gerry's macro and my comment after it. As long as the second homing speed is below that which requires an accel ramp then it will be independant of your max vel and accel settings and will stop as soon as it's off the switch regardless.

Ian
Title: Re: Homing position is not absolute
Post by: BR549 on May 05, 2011, 08:35:23 PM
I still did not go down easy. I found the test notes and had to email ART to confirm it as well.  The test were to test the overall accuracy of the home. It is acccurate as you confirmed contengent on the vel/accel staying the same.

The motion test was actually the G31 test as the notes confirmed.

SO dang that is twice this year I have been WWWWWRROOOONNNNNGGG.   AAARRRRRUUUUUGGGG. as Snoopy would say.

I never really use homing  so I never really paid attention to it.

Getin old, (;-) TP