CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Trajectory generator? Servo

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
imET



Joined: 05 Jul 2005
Posts: 4
Location: Canada

View user's profile Send private message

Trajectory generator? Servo
PostPosted: Wed Aug 03, 2005 4:49 pm     Reply with quote

Hello,
I'm newbie in electronics and programming,
but highly motivated Smile, please bear with me.
it took me a while to understand
data types are different between
compilers.
does anyone have example
of trapezoidal motion
calculation for a dc motor
position control(trajectory generation)
base on encoder feedback.
I'd like to know how I could accelerate/deccelerate.
I'm trying to recreate
microchip an696a but can't
understand(yet) the shifting and rotate
that was done in the appnote.
I just want something simpler, if exist.

Thanks.
Ttelmah
Guest







PostPosted: Thu Aug 04, 2005 2:57 am     Reply with quote

Unfortunately, servo control, is quite a complex area, and few systems will actually work acceptably with simpler algorithms.
Consider 'splitting' your learning. First control a motor. Use PWM, and just crack how to adjust it's speed, perhaps using buttons for the input. Then crack getting a position feedback from a shaft, using quadrature encoders. You now know how to read 'where' a motor shaft is, and adjust it's motion. You can then try a very simple approach, of just changing the speed to move 'towards' a target position. You will then learn about the big problem of inertia. By now, you will start to have an idea of the problems of motion control.
Now consider ignoring the servo motor for a while, and look at acceleration profiling on stepper motors. This allows you to ignore the servo algorithm, and just look at the actual 'motion'. There is a good algorithm for an acceleration curve, on the MicroMouse site. The table for acceleration here, can be coded as a look-up table. Once you understand this, go back to the servo algorithm, and now, when asked to move a distance, you can use the values in the lookup table, to adjust the target position and give the required acceleration ramp.
The problem is that there are multiple 'parts' to making a servo system work. You have the basic (probably PID based) motion code for the motor itself, and then on top of this, any acceleration profiling as well. All this has to be handled _quickly_, if the system is to work. If you try to go to 'simple', you have to lose part of the actual control, or become too slow to work properly. The servo system outlined in AN696, is about as simple as it gets!. However going to a stepper based system, for the 'learning' phase, allows you to seperate the motion profiling from the control algorithm, and possibly understand more easily, just what is going on.

Best Wishes
imET



Joined: 05 Jul 2005
Posts: 4
Location: Canada

View user's profile Send private message

PostPosted: Thu Aug 04, 2005 8:03 am     Reply with quote

Quote:
Unfortunately, servo control, is quite a complex area, and few systems will actually work acceptably with simpler algorithms.
Consider 'splitting' your learning. First control a motor. Use PWM, and just crack how to adjust it's speed, perhaps using buttons for the input. Then crack getting a position feedback from a shaft, using quadrature encoders. You now know how to read 'where' a motor shaft is, and adjust it's motion. You can then try a very simple approach, of just changing the speed to move 'towards' a target position. You will then learn about the big problem of inertia. By now, you will start to have an idea of the problems of motion control.


thanks for the reply,
I now realized that this is one
complex project I'm delving into.
After weeks of googling I found
a lot of algorithm used, but unfortunately
my pea size Confused brain were not able to
decipher them.
I have done what you said,
I manually adjust PWM so as to see if
the motor moves, and it does, so is the
counting from the encoder.(btw I'm trying
this on a broken epson1270 with 2 servos
one with rotary the other linear encoders)

What I'm having hard time to understand
is the use of velocity limit and acceleration.
In microchip appnote, when commanded position
is set, something like this is used:
say
velocityLimit = 200
acceleration = 10
velocity = 0
say position is also 0
this is called in Timer2 interrupt
Code:
if(velocity < velocityLimit)
velocity += acceleration;//to accelerate

then the resultant velocity is added to
or subtracted from current position.
Code:
position += velocity

which in turn creates the error for
the PID to correct.
I'm using a 40Mhz crystal on 18f452
setup like this:
Code:

   //The cycle time will be (1/clock)*4*t2div*(period+1) = PWM Frequency
   setup_ccp1(CCP_PWM); //Setup PWM
   //setup_ccp2(CCP_PWM);
   //setup_timer_2(T2_DIV_BY_4,180,16);//((1/40000000)*4*4*180) = 72us = 13.8Khz
   setup_timer_2(T2_DIV_BY_4,120,16);//((1/40000000)*4*4*120) = 48us a little more than 20khz

   set_pwm1_duty(240);              //Set initial duty to 50%
   //set_pwm2_duty(240);


what happening is the velocityLimit
is quickly reach before the actual
movement of the motor, I guess that's
where the inertia problem is, or maybe
the update rate is just to fast.
some algorithm I found deals with measuring
time,
given:
starting point
target point
velocity limit
acceleration

I just don't know where I should base
the time, from the Timer2 interrupt?

Thanks again.
Ttemah
Guest







PostPosted: Thu Aug 04, 2005 9:34 am     Reply with quote

OK. You have got quite a long way already. Think about it like this. If you have the motor at one position, and tell it to move to another spot a log way away, the servo algorithm, will 'see' a massive positional error, and slam the power on 'full bore'. The motor will then try to accelerate very hard indeed, and may even cause damage. At the other end, a similar problem will apply as you slow down.
Instead what you do, is look at how far you want to move, and move the desired position in a series of steps towards this target. If these steps start very small, then get larger, then get smaller again as you approach the target, the servo algorithm will 'chase' this moving target, but not have to deal the single large massive error, or the large acceleration this deals with. If you limit the maximum step to the fastest you want the motor to move, you have the ramped acceleration profile.
What the code does is add numbers in the required direction, to the desired position, till a maximum required speed is reached (velocity limit). At the point where maximum speed is reached, or the half way point whichever comes sooner), a 'note' is made of the offset from the start, and when this distance from the destination is reached, the same algorithm is run the other way (moving the target successively smaller amounts), till the final destination is reached.
The attached below, is my own ramping code used for this on a servo sytem.
Code:

//Acceleration/deceleration code - call once every eight servo loops
//velact, is the actual 'velocity' being tried for
//Flatcount, is the count of time spent at full speed
//'next' is the required next position
//'sat', is a flag to show that the servo algorithm is 'flat out', and
//position should not update till this is corrected.
void DoMove(void) {
   int32 vel;
   if (!sat) {
      //This part is the acceleration/hold at max for the first half
      //of the motion
      if (!phase) {
            //Accelerate if below maximum allowed
            if (velact.word<MAXACCEL) {
                velact.word=velact.word+accel.word;
              }
              //Otherwise increment the 'flatcount', and leave velocity
                //unchanged.
            else {
                ++flatcount.word;
              }
              vel=div256(velact.word);
              //Phasedist is half the required total movement distance
              //Subtract the movement generated in this loop
                phasedist.word=phasedist.word-vel;
                //Handle the actual movement of the target position - can be in
                //either direction
                if (stat.neg_move)
                    next=next-vel;
   else
                    next=next+vel;
   //If the distance in this phase has gone negative, I now need to
                //start counting 'down' if in the flat time at full speed, or
                //decelerate.
                if (phasedist.b[3] & 0x80) {
       phase=1;
   }
           }
      else {
         //Here I am in the second phase.
         //If I am in the 'flat' period, decrement the counter, and leave
         //velocity unchanged.
         if (flatcount.word>0l)
            --flatcount.word;
         //Otherwise reduce the amount to move the target.
         else {
            //'VSTART', is the initial velocity to use. Normally 0, ot 1, for
            //a slow startup.
            if (velact.word>VSTART) {
               velact.word=velact.word-accel.word;
            }
            //Here I have decelerated, and should be practcally 'on' the
            //target
            //Move to the final location, and turn off the 'move in progress'
            //flag.
            else {
   next=required;
   stat.move_in_progress=false;
   velact.word=0l;
            }
         }
     vel=div256(velact.word);
     if (stat.neg_move)
         next=next-vel;
     else
         next=next+vel;
     }
   }
}

Now to get maximum speed in the actual servo loop, and because the is relatively 'low geared', only giving a few hundred pulses per loop in the main servo, I call this every eight loops of the servo. Also the actual offsets are 256* the actual motions required, and I use a byte based shift operation to divide by 256 quickly (div256).
This is very like the section in the MicroChip code, but perhaps the comments may make it easier to understand what is being 'done'.

Best Wishes
imET



Joined: 05 Jul 2005
Posts: 4
Location: Canada

View user's profile Send private message

PostPosted: Thu Aug 04, 2005 2:31 pm     Reply with quote

thanks so much,
this considerably helped me understand
how things work in the an696a appnote.
I'll digest this some more and see how it goes.
dani



Joined: 02 Jun 2004
Posts: 16
Location: Pakistan

View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger

what about step and direciton input machanisim..?
PostPosted: Thu Nov 23, 2006 4:20 am     Reply with quote

hello,

<qoute>
Think about it like this. If you have the motor at one position, and tell it to move to another spot a log way away</qoute>

What if we want to drive servo motor with step and direction input comming realtime from parallel prot through some cnc software.

thanks

Dani[/quote]
Ttelmah
Guest







PostPosted: Thu Nov 23, 2006 6:03 am     Reply with quote

Two seperate parts to this.
What you do, is build the servo control algorithm, as already outlined. Then seperately, use hardware (probably one of the CCP modules), operated by the 'step' signal from the PC, to determine the position input to the servo algorithm. Step/direction, is slightly awkward with the CCP modules on the PIC, since these do not support a 'direction' control. Normally, this can be done by using both CCPs', and external logic, so one becomes the 'up' counter, and the other the 'down'. On the simple servo system, this can't be done, since one CCP is already used for the PWM. It is actually much simpler to let the PIC do it all, and just send it movement commands via RS232, or USB. This is what I have done in the past for such systems, and is what most commercial systems do. If step/direction, must be used, then the simplest way, is to use an external counter (typically an 8bit up/down counter), interfacing it's parallel output to one port of the PIC. Then use it's 'carry/borrow' bits to feed the hardware interrupt on the PIC, to handle the extra count bits. I'd suggest using an external quadrature counter, like the LS7166, or a PIC with built in quadrature support, otherwise the workload in the processor will start to become unacceptable.
It is worth saying, that CNC software using the parallel port, is a 'dangerous' way to go for the future. The lifespan of this port is already visibly shortening, and the better motion control units are already offering alternative interfaces. For a 'homebrew' system, the port is acceptable, but for commercial applications, it would be well worth considering alternatives.

Best Wishes
dani



Joined: 02 Jun 2004
Posts: 16
Location: Pakistan

View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger

Cheaper retrofit solution with parallel port.
PostPosted: Fri Nov 24, 2006 1:14 am     Reply with quote

Hi,

This is true that the parallel port in modern pc mother boards is being replaced by USB etc.

There is another fact is that CNC software like MACH3 which controls stepper motor board directly with its step and direction output are cost effective solution to make a good retrofit for cnc machines.

Now using stepper , It is ok with parallel port step and direction output.

But with bldc servo motors on cnc machine... I we can convert these step/direction output for servo motor the quick retrofit is almost ready to serve lots of people.

At the moment finding Mother board with Parallel prot is not too difficult. For future we may switch to USB.


So thats y i want to work on PIC based STEP/DIR Servo Controller. Can any one help me in this regard...
your views plz...?
adrian



Joined: 08 Sep 2003
Posts: 92
Location: Glasgow, UK

View user's profile Send private message

PostPosted: Fri Nov 24, 2006 4:54 am     Reply with quote

Another problem with using a PC is that if you accidentally blow up your parallel port, then you need to replace the motherboard. One option is to use a 'sacrificial' PCI card with a parallel port.
Ttelmah
Guest







PostPosted: Fri Nov 24, 2006 11:28 am     Reply with quote

Seriously, 90% of the 'work' in Mach, is generating the acceleration profiles, and outputting the data for steppers. this is completely uneccessary for servos. They are capable of ramping their own accelerations. I did a system like this about ten years ago, and at the time used a couple of Z80's, with their CTC chips. The motor controllers are just fed the maximum speed, and acceleration rates, on a serial bus, pulled from the G codes', and are then just told to move. Far easier to do, than trying to make a servo behave like a stepper, and smoother too. The PC code to take the required data from the G code, was only a few tens of hours of programming, and still runs in a few systems today. Trying to make a servo behave like a stepper, just so you can drive it from Mach, is a 'sledgehammer/nut' solution.
Also, you may well find, that Art, is quite happy to do you a version of Mach, which outputs just position commands in serial for each motor. He is friendly to talk to, and has done custom versions like this for other motion solutions.

Best Wishes
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group