From cwilson@deltatau.com Mon Jun 23 14:51:54 2003 Date: Mon, 23 Jun 2003 16:26:52 -0700 From: Curt Wilson To: denault@jeans.ifa.hawaii.edu Cc: Stavros Boglou Subject: Fw: PMAC questions [The following text is in the "iso-8859-1" character set] [Your display is set for the "US-ASCII" character set] [Some characters may be displayed incorrectly] Tony: Let me try to take each of your questions in turn, but start with a few statements of principles. First, you are correct that it is a lousy idea to get your host computer into the area of correcting for servo errors. It will basically end up fighting the servo controller in this regard. The host computer can and should be involved in modifying the desired trajectory as conditions warrant, but you should let the controller alone compensate for any deviations between desired and actual trajectories. Second, you will need to make a fundamental distinction up front in your control architecture as to whether you are going to send new desired position information at deterministic intervals or not. (It seems that you will not.) If you can be deterministic about it, you can use one of our "definite" move modes, such as the PVT mode you have examined, which produces Hermite spline trajectories, or our SPLINE mode, which produces cubic B-spline trajectories. However, if you cannot be deterministic, then you must send "indefinite" commands like jog moves, then somehow either modify these or break in with a new command. Our "J+" and "J-" jog commands are truly indefinite, although many people give some (far) destination even if the command is to be in principle indefinite. Jogging positions and speeds are expressed in raw counts. If you want to do similar commands in scaled units (e.g. degrees), you can use our RAPID move moves (yeah, a misnomer in your case...) or a variant. Without writing a motion program, you can use the "altered destination" variant, which is done with "on-line" (immediately executed) commands (e.g.: !A1.234B5.678). Like jog moves, you can break into presently executing moves at any point (and at non-deterministic intervals). For you, the destination wouldn't be important, but the fact that you could modify the speed between each command could be (e.g.: I116=10.002 I216=9.998 !A1.234B5.678). The next decision you need to make is whether you want to make your corrections velocity-based, as you say most controllers do, and my above example does, or position-based, in which you add a relatively quick position corrrection on top of a constant-velocity move. The nice thing about position-based corrections is that you don't have to try to yank back the velocity correction at just the right time. I suspect you are groping for the latter solution. PMAC has some good tools for injecting position corrections on top of a running move. Our position following (a.k.a. electronic gearing) function can be run in "superimpose" mode, on top of a mathematically generated trajectory. If you can tolerate step changes in the correction, you can just write a number to the "master position" register involved in following. Some people create a virtual motor in PMAC for corrections like this, and use its command position registers like a master encoder. With this you can command profiled small moves to introduce the correction more smoothly. Other people will create a rapidly looping motion program that takes as inputs your various parameters of motion and computes a new move every few milliseconds using the latest values of the input parameters. This approach does not require that the parameters be updated on any deterministic basis. In this mode, it would also be possible to convert on the fly between slewing and tracking. If you have already settled on closing the velocity loop in your amplifiers, a PMAC(1) controller should be fine. You understand correctly that PMAC2 controllers mainly add the capability for other styles of control. In your mode, I do hope you have a very good tachometer for the velocity loop. Best regards, Curt Wilson > > ----- Original Message ----- > From: "Tony Denault" > To: > Sent: Friday, June 20, 2003 3:59 PM > Subject: PMAC questions > > > > Hello Delta Tau, > > > > We are evaluating the PMAC for a telescope control servo system. This > > system will drive a telescope at a slow velocity (300 counts/sec) but high > > resolution (1 count = 0.05 arcseconds). Driving a telescope is an > > unusually servo task because endpoint of a move is not known, and the > > speed are very slow. Traditional servo motions with > > acceleration-deceleration profiles can not be used. > > > > For telescope control, a computer will calculate an absolute motor based > on > > the exact time, star coordinates (RA, Dec). This calculation happen every > > 50 to 100 ms. Normally the velocity would be constant, however other > external > > event (guiding camera, joystick adjustment) can make position adjustment > > randomly. As a result the computer only knows it's where it should be now, > > and based on past calculations loops, it can estimate a velocity using a > > simple linear interpolation. > > > > I know of other telescopes driving their motors using a JOG modes, every > > 100 or 50 ms comparing the motor position with the calculated position. > > Any errors (motor - calculated) are taken care of by trying to adjust the > > velocity of the JOG. I find this unfortunate as the computer is trying to > > do servo correction. > > > > We have been searching for motor controller that can provide additional > > features to support our application. The PMAC see very attractive (but > > complex). I was wondering if you can comment on how the PMAC can be used > > most effectively in our situation. > > > > Other question: > > > > 1. Our telescope has 2 axis. Each axis has a DC motor with a velocity > > control amplifiers. From the product description, it seems PMAC is the > > right product for us. PMAC2 seem to handle addition type motors and > > amplifiers. Is this correct? > > > > 2. If we were using JOG to maintain our tracking. We would typical > > interpolate the next position using the last few time-position > > calculations in our 50 ms loop. Is there a way of adjusting the position > > register (adding an offset) while maintain a steady JOG velocity. Then the > > PMAC's servo would adjust the velocity to compensate for the error. I > > don't what to have my application try to servo out the error by adjusting > > the JOG velocity. > > > > 3. Are they other servo algorithms that are better suited to my > > application? Your PVT seem interesting, but it seems the time interval > must > > be fixed. Ideally I like to tell the controller "You should be a position > > P, going a velocity V". It maintains the velocity, until a new update is > > given. Although my loop runs a 50 ms, it isn't real-time so jitter may > > cause problem. What happen when the PVT interval expires, it decelerates? > > Can I set a PVT interval of 100 ms, then when I have a new P,V (45to55ms > later), > > issue a new PVT. Does the 100 ms PVT get cancelled and just blend > > into the new command? > > > > 4. Driving the motor using this time-position calculation loop is called > > tracking. We track about 98% of the time. When moving to another object > > (star), we slew. Slew is just a higher speed move (velocity and > > acceleration rates are increased 3x). In a Slew the target position is > > known. After reaching the slew, the TCS would go back into tracking mode. > > It seems possible to do a linear move (for slews), then change mode for > > tracking (JOG for example). Can blending work so that the linear move > > does not decelerator to zero, but just adjusts the velocity to the JOG > > velocity. Can we termination any movement with another move command, and > > the PMAC will just blend into the new move smoothly? > > > > Regards, > > > > Tony > > /-----------------------------------------------------------------------\ > > | Tony Denault | Email: denault@irtf.ifa.hawaii.edu | > > | Institute for Astronomy | Phone: (808) 932-2378 | > > | 640 North Aohoku Place | Fax: (808) 933-0737 | > > | Hilo, Hawaii 96720-2700 | | > > \-----------------------------------------------------------------------/ > > > >