Hello Guest it is April 19, 2024, 12:09:25 PM

Author Topic: Homing position is not absolute  (Read 18609 times)

0 Members and 1 Guest are viewing this topic.

Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
Re: Homing position is not absolute
« Reply #10 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
Re: Homing position is not absolute
« Reply #11 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

Offline Fastest1

*
  •  920 920
  • Houston, TX
    • View Profile
Re: Homing position is not absolute
« Reply #12 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?
I want to die in my sleep like my grandfather, not like the passengers in the car! :-)

Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
Re: Homing position is not absolute
« Reply #13 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
Re: Homing position is not absolute
« Reply #14 on: May 02, 2011, 09:46:07 AM »
My variances are about 0.1 mm with low acceleration

Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
Re: Homing position is not absolute
« Reply #15 on: May 02, 2011, 11:55:20 AM »
How slow is the accel?
Hood

Offline BR549

*
  •  6,965 6,965
    • View Profile
Re: Homing position is not absolute
« Reply #16 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

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: Homing position is not absolute
« Reply #17 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
Re: Homing position is not absolute
« Reply #18 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

Offline Hood

*
  •  25,835 25,835
  • Carnoustie, Scotland
    • View Profile
Re: Homing position is not absolute
« Reply #19 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