Jon Elson wrote: >Jack Ensor wrote: > > >>I noticed when jogging at my maximum rate of 90 ipm the 2 quadrature >>signals coming at a rate of 1 Khz have approximately 50 micro seconds of >>jitter. Is this excessive? How much would it contribute to tracking >>error? My tracking error is insignifcant when homing but but huge when >>running Axis.ngc. >> >> >Would you please define this term "tracking error"? I do not >know what it means. From context, I believe you mean to say the >machine's position differs from the displayed position. Is that >correct? > > Yes, position displayed on the axis screen differs from what my dro says except when I home they always agree.
>How are you seeing the quadrature signals? On a "box" >oscilloscope, or somehow with halscope? Unless halscope AND the >software or hardware encoder input facility is sampling at a >fast enough rate, you would miss some of the edges. > Yes, I understand the hal (storage scope) better now. When I used the faster sample rate, I then got more resonable results >For >instance, on my minimill, at 60 IPM, with 16 TPI leadscrews and >4:1 motor reduction, and with 500 CPR encoders producing 2000 >counts/revolution, you get 128,000 counts per second. >Therefore, counts are coming at a rate of one every 7.8 us. >Obviously, my jitter must be less than yours. But, a scope >would need to be sampling it at a rate of once a microsecond or >better before you could even begin to discern jitter on the >signal. If you are using an analog oscilloscope, then there is >no sampling. But, without specifying the rate of encoder pulses >when you see the 50 us jitter, it is hard to know what it means. >If you had 50 us jitter when the count rate was one millisecond, >it is not a big deal. If it was when the count rate was 50 us, >it would be reducing the quadrature angle to zero, and would >clearly cause errors. So, you have to compare the jitter to the >count rate. > The rate as I originally stated was 1 Khz which translates to a pulse period of .5 milliseconds low and .5 milliseconds high. So I suppose 50 micreoseconds jitter isn't too bad then. (About 5%). >Ideally, there should be 90 degrees between the 4 >states of the encoder's A and B signals. They never are, due to >tiny errors in the manufacturing of the encoder's optics. The >greater the error, the narrower some of the count states become, >until they become so small the encoder counter's logic misses >them. Then, the position will be off by multiples of 4 counts. > >When you say homing is OK, but axis is bad, is that all due to >speed? > > Slowing things down by a factor of ten makes no difference in position error. It still jumps all over the place. Could you explain why the following speed calculation is in error? I have a unipolar motor, driven in quadrature phase A, phase A not, Phase B, and phase B not., where phase B lags phase A by 90 degrees. Motor plate specifies 200 steps/rev step down from motor to screw: 2.5 to 1 Screw pitch: .2 in/rev .2 in/rev x 1/2.5 rev/rev x1/200 rev/step = .0004 in/step. This is correct because this is what I see the system do. For speed: The max jog speed is set in emc to 90 ipm (1.5 in/sec). When jogging at the max rate I measured a step frequency of 813 Hz on phase A. Calculating the table speed: 800 pulses/sec x 60 sec/min x .0004 in/step = 19.2 ipm However just by looking at the table move, it is moving much faster than that. Is this because due to the nature of quadrature drive, the table actually moves 4 times faster than the step rate? This would put it more in the ball park of what I am seeing. Jack ensor ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
