Gentlemen, I will try to adjust the scale to allow the comps to be bi-sided. I think I will be able to. I was attempting to use the calculated scale and do the complete comp with the comp file. Thanks for looking at this so close. Thanks in advance for the fix. Everyone blew by one question (or ignored it). :) Can I effectively bypass the SCR tuning by increasing the gain a lot (much past what the motor can handle) and using the tuning in EMC to control the motor. Could this turn the SCR into a dumb amp. thanks Stuart
On Wed, Oct 8, 2008 at 10:04 PM, John Kasunich <[EMAIL PROTECTED]> wrote: > John Kasunich wrote: >> Stuart Stevenson wrote: >>> John, >>> There are two pictures on www.mpm1.com:8080/cinci >>> one is the positive capture - the one that jumps - >>> positive-jumps.png >>> >>> one is both the positive and negative capture - >>> pos-neg.png >>> the positive on the left and the negative on the right >>> I moved the axis .0001 positive and then .0001 negative >>> >>> they both look the same >>> >>> it must be the machine - SCR amp? >> >> I only now got a chance to see the scope pics. Something doesn't make >> sense. >> >> In BOTH sets of traces, the backlash-corr signal jumps (as expected) >> both directions. But backlash-filt is only filtered when going >> negative, when going positive it jumps too. >> >> Both edges should be filtered. >> > > OK, we've been looking at this a bit on IRC, and we found that there is > indeed a problem, and identified the cases when it happens. The bug is > in the filtering code. > > For normal backlash compensation, the unfiltered values are always above > and below nominal by one half of the total lash. For a typical screw > comp curve, the values may vary from place to place, but again, the one > value is usually above the nominal, and the other is below nominal. The > code works correctly in both of those cases. > > But in your file: > >> -0.5 -0.502 -0.4972 >> 0.0 0.000 0.0043 >> 0.5 0.5005 0.5052 > > The third line describes an area of the screw where both values are > above the nominal value. The filtering code doesn't work right in that > case - it only filters in one direction, the other direction is > completely unfiltered. The same thing happens if both values are below > nominal. > > We will be looking into a fix (or maybe two fixes, one for CVS trunk and > one for version 2.2.x), but that might take a bit of time. > > In the meantime, you can avoid the problem by adding or subtracting a > small constant offset to all of your correction values. The goal is to > have one column of numbers always be less than nominal, and the other > column always be greater than nominal. Hopefully your data will let you > do that. > > Thanks for spotting and reporting this - we'll get it fixed. > > Regards, > > John Kasunich > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
