On 06/20/2017 03:27 AM, andy pugh wrote:
On 20 June 2017 at 03:51, <tom-...@bgp.nu> wrote:
Why would I get a following error only while homing
I think it is probably because you are using HOME_USE_INDEX (which will
zero the encoder at the index pulse) and feeding the encoder feedback back
into LinuxCNC.
Now, this is perfectly normal, and with a servo / pid machine the system
knows to ignore the f-error immediately after an encoder reset. What is
puzzling me here is why it isn't working in this case. I think it is
something to do with the fact that your system is set up for open-loop step
position control but has encoder feedback. However I can't immediately see
why this makes a difference.
I think I have an idea. If the jump in position is all
accomplished in one servo cycle, then the jump is handled by
the logic you describe. If the jump is spread over a few
servo cycles or delayed by even one cycle, it will certainly
cause a following error. The key is that Tom reports
setting MIN_FERROR to 1 doesn't suppress the error. That
means the position jump is not occurring during the same
servo cycle where the index pulse is seen. Is the encoder
feeding ANYTHING else than LinuxCNC through a simple
interface? Some external motion controller or drive in the
path between encoder and LinuxCNC could introduce a delay.
I imagine that if you press the home button again it will home Z
seamlessly, and then f-error homing the next axis.
Yes, since the first home operation should zero the encoder
counter at the index position, re-doing the home should
cause a minimal shift in the position.
Jon
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
