Hello Guest it is October 16, 2021, 06:30:12 PM

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

0 Members and 1 Guest are viewing this topic.

Offline Hood

*
  •  25,838 25,838
  • Carnoustie, Scotland
    • View Profile

Offline BR549

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

Re: Homing position is not absolute
« Reply #32 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

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: Homing position is not absolute
« Reply #33 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
Re: Homing position is not absolute
« Reply #34 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.
Regards,
Ray L.
Re: Homing position is not absolute
« Reply #35 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
« Last Edit: May 05, 2011, 03:23:34 AM by JimKnopf »

Offline stirling

*
  • *
  •  2,188 2,188
  • UK
    • View Profile
    • www.razordance.co.uk
Re: Homing position is not absolute
« Reply #36 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
« Last Edit: May 05, 2011, 05:36:47 AM by stirling »

Offline BR549

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