Encoder feedback velocity error
09 Nov 2012 11:47 #26394
by eabrust
Encoder feedback velocity error was created by eabrust
Hi there, newbee to CNCLinux coming over from Mach.
I am setting up both a mill and lathe, and have a spindle speed reading error of ~4% on both machines which is bugging me (possibly for no reason), in that speed measured by LinuxCNC is ~104% of what I measure actual spindle speed at with a handheld optical tachometer (ie, setting speed M3 S500 gets spindle speed of 500rpm in LinuxCNC velocity reading, but actual measured is only 480, and the percent error stays same as I increase or decrease speed). In Mach3, measured and reported are spot on with single pulse per rev input.
I'm running LinuxCNC 2.5, through paraport. Same computer on both machines.
My mill is setup with a single index pulse per rev, encoder in counter mode, scale of 60 to convert encoder-velocity from Rev/sec to Rev/min. Using speed out in PID loop, LinuxCNC goes to commanded speed and holds it there, it is just off from 'actual' speed measured with tachometer. Error probably doesn't matter on the mill, as I have no plan for putting on real encoder and doing rigid tapping.
My lathe is similar setup, except spindle has a 2048 line encoder run through a frequency divider circuit (a couple of 74LS74 flip-flops to divide by 8) to result in 256 counts per rev. Encoder is in count mode (channel A and index only), 256 count/rev. I've tried both using just the one/rev and the 256/rev counts, and just like the mill, the speed reported in LinuxCNC is ~4% higher than actual. The lathe encoder setup and PID loop appear correct to me, and threading cycles work correctly. However the speed error does worry me in that it could affect threading operations.
Is this anything anyone has seen before, and does reported velocity error actaully matter, if threading operations actually sync the axis moves to encoder counts, does error in velocity reported matter? I'd hate to change the scale factor of 60 (going from Rev/sec to Rev/min) to something like 57.7 to get correct actual speed... doesn't seem right.
Thanks for any insight
Eric
I am setting up both a mill and lathe, and have a spindle speed reading error of ~4% on both machines which is bugging me (possibly for no reason), in that speed measured by LinuxCNC is ~104% of what I measure actual spindle speed at with a handheld optical tachometer (ie, setting speed M3 S500 gets spindle speed of 500rpm in LinuxCNC velocity reading, but actual measured is only 480, and the percent error stays same as I increase or decrease speed). In Mach3, measured and reported are spot on with single pulse per rev input.
I'm running LinuxCNC 2.5, through paraport. Same computer on both machines.
My mill is setup with a single index pulse per rev, encoder in counter mode, scale of 60 to convert encoder-velocity from Rev/sec to Rev/min. Using speed out in PID loop, LinuxCNC goes to commanded speed and holds it there, it is just off from 'actual' speed measured with tachometer. Error probably doesn't matter on the mill, as I have no plan for putting on real encoder and doing rigid tapping.
My lathe is similar setup, except spindle has a 2048 line encoder run through a frequency divider circuit (a couple of 74LS74 flip-flops to divide by 8) to result in 256 counts per rev. Encoder is in count mode (channel A and index only), 256 count/rev. I've tried both using just the one/rev and the 256/rev counts, and just like the mill, the speed reported in LinuxCNC is ~4% higher than actual. The lathe encoder setup and PID loop appear correct to me, and threading cycles work correctly. However the speed error does worry me in that it could affect threading operations.
Is this anything anyone has seen before, and does reported velocity error actaully matter, if threading operations actually sync the axis moves to encoder counts, does error in velocity reported matter? I'd hate to change the scale factor of 60 (going from Rev/sec to Rev/min) to something like 57.7 to get correct actual speed... doesn't seem right.
Thanks for any insight
Eric
Please Log in or Create an account to join the conversation.
09 Nov 2012 19:48 #26404
by BigJohnT
Replied by BigJohnT on topic Encoder feedback velocity error
Please Log in or Create an account to join the conversation.
09 Nov 2012 21:23 #26409
by eabrust
Replied by eabrust on topic Encoder feedback velocity error
Hi John,
Yes, I did tune PID and it appears to give good performance in controlling during step changes, etc.
It's just that if I put Halmeter on the encoder-velocity pin while it is running, and I just multiply that value by 60, the value is off by 4% from actual measured speed. Since it is the encoder-velocity value (x 60) I'm feeding back into the PID for feedback, it controls it to match the encoder-velocity to the commanded value.
I've attached the ini, and hal, perhaps I've made an obvious error I'm not seeing?
thanks again for the input.
Eric
Yes, I did tune PID and it appears to give good performance in controlling during step changes, etc.
It's just that if I put Halmeter on the encoder-velocity pin while it is running, and I just multiply that value by 60, the value is off by 4% from actual measured speed. Since it is the encoder-velocity value (x 60) I'm feeding back into the PID for feedback, it controls it to match the encoder-velocity to the commanded value.
I've attached the ini, and hal, perhaps I've made an obvious error I'm not seeing?
thanks again for the input.
Eric
Please Log in or Create an account to join the conversation.
10 Nov 2012 04:16 #26419
by andypugh
What thread periods do you see? I have a feeling that the velocity calcs inside the encoder component assume that the period value sent is actual, whereas I rather think it is nominal.
Replied by andypugh on topic Encoder feedback velocity error
Threading uses encoder position, not speed. So you could change the speed conversion scale and not affect threading. (i.e., multiply encoder-velocity by 60 and a bit).The lathe encoder setup and PID loop appear correct to me, and threading cycles work correctly. However the speed error does worry me in that it could affect threading operations.
What thread periods do you see? I have a feeling that the velocity calcs inside the encoder component assume that the period value sent is actual, whereas I rather think it is nominal.
Please Log in or Create an account to join the conversation.
Time to create page: 0.088 seconds