I may give that a shot as a band-aid to the problem. I suspect that when reversing direction, the backlash is going to drive the PID nuts and cause the table to jerk.
I appreciate everyone's interest to find a workable solution for me, but what I would like to focus on more is making EMC2 a more logical and 'unified' system. Specifically adding the option to use a direct reading scale for joint-pos-fb, instead of inferring this from the motor position minus the screw comp. Lots of robots and machines use a direct reading scale for measuring joint position, in addition to having a scale on the actual servo motor. I really think there should be a provision to utilize it, the way it was intended to be used. Honestly, looking at the architecture of the axis HAL pins, I am surprised that it hasn't been implemented already. axis already does this commanded joint position -> screw comp -> commanded motor position motor-pos-fb -> inv screw comp -> joint-pos-fb Wouldn't it make sense to decouple the screw comp from joint-pos-fb in the event that actual joint position is available? Seems simple enough. Brian On Sat, Aug 7, 2010 at 1:07 PM, Jon Elson <[email protected]> wrote: > Stephen Wille Padnos wrote: >>> >>> >> Nothing has been removed, you would just use the stepgen in velocity >> mode, with a PID driving it (making FF1=1 should give you the equivalent >> of open-loop mode, plus or minus a step here and there). >> >> > I have to retract my previous erroneous statement, after some more > reading, Stephen is right (of course!) > By running stepgen in velocity mode and using PID, you convert your > stepper system into a true servo > system. >> >> The real problem is that screw mapping is meant for systems that have >> the screw between the feedback device and the table, but this machine >> isn't like that since the scale is actually on the table. You can't >> drive the PID very well with only scale feedback since it's too loosely >> coupled to the motors, but that's irrelevant since you can't really use >> steppers like servos anyway. >> >> > An excellent point, the "screw error compensation" would not be > correcting error on the LEADSCREW, it would be compensating for errors > in the linear encoder, which may not be necessary at all. > > Jon > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
