-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PRUencoder does not calculate velocity correctly #56
Comments
Hmm... I must say that I have not used the velocity for anything. I've only used the PRUencoder component for closed loop stepper control. In what scenario does it jump between 0 and the velocity? At constant speed? Ramping up / down or close to zero velocity? The LinuxCNC encoder component that I used as a reference has a lot of stuff going on for velocity. I did a very simple version. |
I'm also looking into the component of the original encoder and there are a lot of things about the zero speed solution. https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/components/encoder.c#L495 The jump to zero happens at a constant speed. It has nothing to do with the timer overflowing, rather with the step update, where a zero speed is calculated based on the same number of steps (delta_pos 0).
|
Yeah at constant speed it happens. I thought it had something to do with software hal signal filtering (or lack of), combined with the motor im using , so i didnt bring it up. The readings appear correct but the value jumps between 0 and (the velocity )constantly. I assumed it was a setup problem on my side based on the guys who rigid tapping, but idk if they use the velocity signal or not. |
Thanks for the Halscope images, it gives some hints. What is your encoder configuration? Counts per rev, speed of rotation when you are seeing this. I'm thinking that pulse output frequency is less than the servo period. So we are not seeing any change in count during a servo period occasionally, which would send the velocity to zero.
If so, we'll need to implement the velocity estimation stuff from encoder.c |
Thank you for your interest in this issue. I am currently using a 38S6G5-B-G24N encoder with 200PPR which is in the hall: It is very likely as you say. During the capture period, the position does not change, which causes the speed to be counted to 0. Could something be done about it and implement some kind of "filter" on the side of the PRUencoder component ? Thank you in advance |
I have 2 encoders I am using, 4096 and 16384 as my scales. My spindle RPM is between 100-4000rpm. I can test it on the bench today |
sorry for my lack of halscope, my screen is too small at lower speeds (around 4-5 velocity) i expect a less stable reading like in the video, as my motor has heavy cogging, but at higher speeds like 20, it is much smoother. Kazam_screencast_00014.mp4 |
Hi, So far I have not managed to modify the Linux component so that everything works reliably. For now, I've helped HAL with a lowpass component that smoothes out speed drops. If I have time over Christmas I would like to look into this issue more,
|
Hi,
after problems with the QEI encoder, I'm turning to you again with a request for help. Now I have a problem with the Linux component PRUencoder, which, among other things, has the task of calculating velocity. I use the encoder in the feedback of the closed loop of the spindle speed control of the lathe. The pulse counting works correctly, the increasing works continuously, however the calculated speed value jumps between 0 and the actual value, causing problems in the rotation control feedback. Can I ask you for some advice? Thank you in advance
The text was updated successfully, but these errors were encountered: