On Fri, May 24, 2013 at 05:18:28PM +0100, andy pugh wrote: > > To maintain this separately, it'd be great if you want to make a new > > branch off v2.5_branch with this change. Buildbot will even build > > and package it for you (seb pointed me to "Sorting of..." on > > http://buildbot.linuxcnc.org/dev.html when I asked about this) > > The advantage of this would be that it is a less-experimental branch > than master, and so probably OK for Jon to use on a customer machine?
Yeah that's my thought. Your new branch would also be suitable for merging into master, and maybe could be the right place for us to later work on joint slaving...? If you want to name it with that in mind, that'd be cool with me. > I understand that gentrivkins and ja3 works acceptably, but I have no > idea if this also includes index-homing. It seems to me that it can > only really work if the two indexes are set up in the right place. > (or, I suppose, if the encoder components grew a fixed-offset pin) I think it just uses the "start homing both joints simultaneously" scheme, which often will work. A true slaved homing scheme would be better though: at each homing state you'd improve the situation, instead of possibly making it worse. Imagine a situation where one side is barely sitting on its switch and the other barely isn't. With the start-both-simultaneously scheme, one would start by backing off, and the other would start by moving forward into the switch (that side has skipped the backoff states). I think there is even a timedelay state after the backoff that only one side would obey. Those two joints will be quite out of sync for the entire homing, often moving in opposite directions, and it sure might cost you some spaghetti. If you are set up to have a rapid to final position, you'll probably rapid one side while the other side is still searching for switch or index. I think starting simultaneously and hoping for the best is actually a pretty poor solution although it often appears to work fine. With a slaved scheme, all joints would backoff if necessary (notice this improves the alignment already) and then when they're all done with backoff, they'd all jump to the next state and delay together, and then start moving forward searching for the home switches together. Notice I said all - I don't see why we should assume only one slave. I agree with you that you need your indexes aligned. Rotating the encoders would be the way you'd perfectly square up your gantry. That'd be much more precise than trying to move the switches. ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
