Haberler Michael wrote: > Am 21.10.2009 um 02:40 schrieb Jon Elson: > > >> Well, there's the problem, the sampling rate is just too low. >> > > well that's what Steve said about his setup, but it's not the problem > I described > > Well, that HalScope trace sure indicates SOMETHING is really wrong. I don't have enough experience with a wide variety of encoders and other systems to begin to diagnose the problem. But, I do have ONE data point. I have a mini-mill with a high-resolution encoder (it is just an oddball one I had lying around here) on the spindle, and it performs quite well for rigid tapping. I have demoed it doing 4-40 (Imperial) threads at 1200 RPM. I have also looked at the axis following action with HalScope, and there is an initial bump as the Z axis has to follow whatever alignment appears when the index pulse is seen. It then settles quite nicely. One trick is you need to have the trajectory planner running at the servo thread rate. In years past, the traj. planner was run at 1/10th the servo rate to reduce CPU load. This will cause the axis slaving to be MUCH less stable. I think having the traj. planner at the servo thread rate has been standard for a couple of years, but you should check that in your hal file.
loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD servo_period_nsec=[EMCMOT]SERVO_PERIOD traj_period_nsec= [EMCMOT]TRAJ_PERIOD key=[EMCMOT]SHMEM_KEY num_joints=[TRAJ]AXES If you have a line like this, then your trajectory planner is running at a rate specified in your .ini file in the [TRAJ] section, the parameter is named "TRAJ_PERIOD". > in fact I had it appear with a 45PPR homebrew encoder funneled into a > Mesanet board with firmware quadrature decoder > > but yes, with a decent resolution encoder my problem likely would go > away and that's what I'm going to do > > still.. I dont get why the problem is there in the first place, which > seems *not* to be a sampling issue > No, the fact you have a Mesa card says it is not a sampling rate issue, as the frequency of the oscillation is about 2 Hz. The fact that the error increases linearly and then suddenly reverses indicates your servos are in either current or velocity limit, and the system is completely open-loop all the time. You might look at the output of PID and see what it looks like. (I am expecting it will appear as a square wave, always on one limit or the other.) I now doubt a higher resolution encoder will help this at all. Is the Z axis servo totally stable with other moves, even when you command a high velocity? Jon ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
