Try it at 5-10 rpm and see if the processor can keep up, or it may be the quality of the encoder signals.
The emc user form is a great place to ask this question!
emc-users@lists.sourceforge.net
CalG
Hello,
I've setup EMC with a manual lathe that I've fitted with a stepper motor and simple gear tooth sensor as an encoder. I'm getting awful spindle synchronization, I think it is bad trajectory planning since stepgen is keeping up with what it is told to do. For the first half an inch or so, the stepper does jerky accel/decel cycles and eventually converges on the approximate spindle-synched feed rate.
Here's a HAL scope screengrab, it is very dramatic. Green straight line is spindle-revs (showing it's relatively stable,) and curved lines are both the commanded position and the stepgen's feedback position. It's almost like the motion generation has a PID that needs tuning. What I'd expect is an initial acceleration to get up to speed, and then a decel to match the synchronized speed. Instead, it alternates between too fast and too slow, each time a little less off of the ideal synchronized speed, until it eventually sounds like it's converging (awful noisy stepper.)
I had to hack the encoder HAL module to generate the index pulse, which it's possible is the cause of the problem, but as far as I can tell it works correctly: spindle-revs increases steadily, spindle-index-enable gets set high by controller on g33, and encoder sinks it at the appropriate time. Also spindle-velocity seems correct
I've tried looking around at all the tunable parameters in the .ini and hal files, but I couldn't find anything that makes much difference. I'm truly stuck.
Any suggestions?
-Matt
P.S. A few numerical ballparks: encoder 66 pulse/rev (plus synthetic index pulse,) 4000 steps/inch, RPM was probably 100-200, thread pitch (K in g33) was 0.0625, step accel set to about 9, max velocity 1. I think base thread was 40us, servo thread maybe 800 us or so.
Try it at 5-10 rpm and see if the processor can keep up, or it may be the quality of the encoder signals.
The emc user form is a great place to ask this question!
emc-users@lists.sourceforge.net
CalG
Why did you hack the encoder module?
What did you want/need that it didn't support?
Just off hand I would look at the acceleration and max velocity settings.
As CalG said try really slow rpm and see if the tracking improves.
If that were a classic PID controller i would have said cut back on integral coefficient... the loop is almost unstable
To expand from my original post: There is just a single channel spindle sensor with no index, feeding a "phase A" signal into the encoder which is in counter mode. So I hacked the encoder module to create a synthetic index each time it counts the number of pulses/rev (the number of teeth on the sensed gear.)I had to hack the encoder HAL module to generate the index pulse
This was required because g33 waits for spindle index so each pass is synchronized.
Sensor setup is fine - I've used it for quite awhile with my own lathe module I wrote for the HAL system. So I'm new to using the actual machine controller in EMC.
I tried at lower and lower spindle speeds - it doesn't seem to be a matter of the processor keeping up, and it doesn't seem to be a matter of step accel/velocity limits. It seems to be that EMC is trying to reach a moving target and isn't planning ahead correctly.
I did try playing around with accel/velocity in both axis and global config, but that didn't seem to make any difference. I was hoping there was some setting that can simply be tweaked to fix it, but I couldn't find anything that made any difference.
-Matt
Mat,
So the spindle encoder outputs a pulse per revolution.
Is there a way of synchronising speed of spindle to the individual tooth pulses and then using the synthetic index for final positional locking?
In other words increase the update rate to the velocity control of the spindle with regards to the other axis ( ie keep the spindle slaved to the other axis ) and on top of that velocity feedback loop implement positional loop using the synthetic index.
I think your problem is the trajectory planner needs to run at the servo rate.
In your .HAL file, ther is probably a long line that looks like this :
loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD servo_period_nsec=[EMCMOT]SERVO_PERIOD traj_period_nsec=[EMCMOT]SERVO_PERIOD key=[EMCMOT]SHMEM_KEY
Note that in my file, traj_period_nsec is set to SERVO_PERIOD, you likely have it set to TRAJ_PERIOD, which is slower, typically 5:1 slower.
If you are using an old version of EMC2, you should update, as some substantial improvements were put in sometime early this year, and a big improvement went in in the summer of 2007 at the CNC Workshop/EMC Fest.
Jon
Hi Zig,
I previously implemented a HAL module with just the goal of having a stepper driven leadscrew for manual lathe work, to get around not having a set of change gears and threading dial:
http://www.fricktion.net/~mfrick/lat...lsDoc_v0_1.pdf
The stepper output is a strict interpolation of the spindle encoder, assuming encoder pulse intervals are constant. Emphasis is on locking position rather than trying to match the right proportional speed.
-Matt
That's exactly what it sounds like!
I don't have a traj_period_nsec setting - I'm running latest 2.3.4~pre built from source code I fetched a few days ago. I searched through the code and it looks like it defaults to the servo period if left unspecified.
Good avenue to investigate though, it sure seems like somethings not happening frequently enough.
-Matt
Matt,
I am not qualified to comment on your electronic screw algorithm.
I just want to highlight the fact that if You are interested in zero positional error ( type 0 system ) You need to provide velocity feedback.
Similarly if You wish to see zero velocity error ( type 1 system) you need to provide acceleration feedback.
In other words for the loop to track a parameter it needs an estimation of the first derivative of the parameter.
Hence my comment provide velocity feed back as well in order to have zero positional error.
For type number.. http://books.google.com.au/books?id=...20loop&f=false
Hi Zig,
Fascinating book there, I'll have to read through it. Ouch, I guess the $186 price tag reflects that it's for a limited audience. Lets see how much Google books lets me read.
The controller has the encoder spindle-revs, and could figure out the velocity from that. I'm not sure at all how the guts of the machine controller work.
I did see some info that suggested the spindle-velocity signal (fed from encoder) is used only on rough work like feed per rev rather than spindle synchronized operations.
-Matt
Hello Matt,
It has been over 30 years since I last looked at these issues seriously.
My refferences back then were a book by D'azzo and Houpis in the area of ananlog controls and Smith in the the digital and hybrid process control.
My controls systems lecturer used to work at the Government Aircraft factories and was involved in some interesting remote control work back then ( when Australia had a world class rocket program ).