Steve's suggestion of using a velocity stepgen with a PID loop and then using the scale feedback to close the loop - works. I have that running on an actual machine and at high speeds - 1100 ipm. The machine is running two shifts right now and is very reliable.
There is no need to add anything else ... seriously ... the parts and pieces to close the loop to the actual axis scale feedback is already there. Backlash is a difficult thing to handle and it just gets worse when you try and put a PID loop around it. Backlash is like having a loose shaft coupling with slop in it. Pretty much a control nightmare. If you move your machine fast enough and lube your ways a lot and the bed starts to "coast or slide" through the backlash then you will be in trouble as any backlash compensation scheme will then be nixed. The only way around this is to run your machine very slowly, which some would say, negates a lot of the benefits of CNC'ing your machine. You might be able to tune a PID loop placed around a velocity stepgen using your scale feedback to correct, but I doubt that you would be happy with the performance of the machine as it would likely be quite slow. I suggest you figure out a way to tighten your nuts or plan on only running your machine very slowly. Software compensation only goes so far. At some point fixing the machine is more productive than trying to work around a machine that has mechanical deficiencies. Dave On 8/8/2010 2:57 AM, Brian wrote: > Ok, I think I may have a perspective that will be clearer. > > In the HAL component axis, joint position and motor position are > thought of as separate concepts. Joint position is related to motor > position through the compensation logic, but otherwise they are their > own entities. This is good design, because in reality, joint position > and motor position are truly two different measurements. There is not > always a 1:1 relationship between motor position and actual joint > position. Besides lash and screw wear, you can have belt stretch, and > machine deflection among other things that can affect the actual joint > position. Up until now, joint position has simply been inferred based > on the motor position plus any known amount of compensation. This is > a good estimate of joint position when no other feedback is available. > Because axis already separates the concepts of motor position vs. > joint position, it would seem natural to have a provision for reading > actual joint position if available, otherwise, simply substitute the > inferred value based on motor position. This would more closely model > reality in a machine. > > Does this make more sense? > > Brian > > On Sun, Aug 8, 2010 at 12:51 AM, Brian<[email protected]> wrote: > >> Jon, >> >> If I had encoders on the screws, the method described on the wiki >> would work. This is basically what Dave suggested a few replies back, >> and what my config already does to some degree. This method will also >> work with steppers, until the motors are disabled, and you move the >> machine by hand. Then the wiki method no longer holds water. Trust >> me, I have tried lots of different things to come up with a usable >> solution without modifying anything. I have thought this problem up >> and down, to no avail. >> >> With respect to backlash being a significant hindrance to my CNC >> system, it is a problem, but with a full screw map, it really isn't a >> huge deal. It is plenty accurate surprisingly so as a matter of fact. >> Because I still use the machine manually, I am not planning on >> changing over to ball screws. Moreover, the fact that I use a machine >> that has acme screws with lash is not a good reason not to allow EMC2 >> to correctly utilize the data available to it. >> >> Why is there so much resistance to this? I must not be effectively >> explaining the situation. I suspect in person, I could better >> describe the benefits to making it work the way I propose. Over email >> however, it just doesn't seem to be hitting home with anyone. Heck, I >> would take this on myself and submit it, but I don't have the time to >> learn EMC internals just to implement this. Especially when I know >> there are people who already know EMC inside, and could probably >> implement such a change without a lot of trouble. >> >> Brian >> >> On Sat, Aug 7, 2010 at 11:11 PM, Jon Elson<[email protected]> wrote: >> >>> Brian wrote: >>> >>>> 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. >>>> >>>> >>>> >>> If you have sizable backlash in your machine, then it becomes very hard >>> for any CNC system to work right, either open- or closed-loop. >>> The problem is the motor can't get from one side of the backlash to the >>> other instantly, so it always leaves the axis uncontrolled for a >>> moment. There is just no way to get around that fact. >>> >>>> 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. >>>> >>>> >>>> >>> This has already been done, and is well documented on the Wiki. You can >>> start >>> here : >>> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Combining_Two_Feedback_Devices_On_One_Axis >>> Stuart Stevenson may also have some info on his web pages, he has the >>> first machine done that way. >>> Here's one link to that project, from the Linuxcnc.org links area : >>> http://jmkasunich.com/cgi-bin/blosxom/shoptask/wichita-trip-02-20-08.html >>> >>> 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 > > ------------------------------------------------------------------------------ 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
