Motion profile generator.

[Darrel Taylor]

(For that you need multiple axis interpolating, all with different accelerations and velocity constraints - up for another challenge?).

Sure, but it will take several months, many thousands of dollars, and a trip to Sweden.
Let me know when you want to start.

[HenrikOlsson]

Hi Darrel,
I've played around with the profile generator code and it's very cool. Unfortunately I won't pretend to understand half of it.

There are a couple of issues, one of which I think is a bug.
If you can, do a move with A=7, V=23, T=12345 - what do you get? When I do that it accelerates properly, runs at a velocity of 23 for a while then decides to decelerate to a velocity of 5 and finishes the move at that velocity. If I change to A=7, V=25, T=12345 it's fine but it does do similar things with other settings as well. So, I think something weird is going on there.

The other issue is the WORD size limit on the lenght of move. I've managed to change it to LONGS (changed Position, TargetPosition, RampTotal and Value) and it seems to work that way but it is SO (I mean really) much slower to execute. What seems to be taking the longest time is the step right at the "corners" of the profile, I've seen times above 2500 cycles. I'm not sure there's anything that can be done to make it better but wanted to run it by you in case you may have some ideas.

The last thing is one which I knew would come up from the start but I honestly couldn't imagine the code for this having to be THIS complicated and thought I'd be able to handle it outside of the actual profile generator but now I may need your input on what effects it will have on the profile generator code. The issue is resolution, or rather lack of resolution.

Imagine a 3000rpm motor with a 500 line encoder giving 2000 counts per revolution. The servo-loop needs to run at ~1000Hz which means that lowest speed I can command is 1 count per interrupt (1000 counts per second) or 30rpm - not that great. And, even at the lowest possible acceleration of 1 count/tick/tick it'll still go from 0 to 3000rpm in 100ms.

One possible solution might be to run the profile generator maby one in every ten servo-loop ticks. That would make it better but still pretty crude. Slower than that and it would be noticable I think.

My original idea, which I've used before and thought I could use here as well is to use something like this:

Scratchpad = Scratchpad + VelocityCmd.LowByte  'Accumulate scratchpad...

If ABS (ScratchPad) > 127 then              ' If it's time to move 1 count...
   Scratchpad = Scratchpad - 256           ' reset the acumulator and...
   IF Direction = FWD THEN        
       Setpoint = Setpoint + 1
   ELSE
      SetPoint = SetPoint – 1
   ENDIF
ENDIF
    
IF Direction = FWD THEN
   SetPoint = Setpoint + VelocityCmd.Highbyte
Else
   SetPoint = Setpoint – VelocityCmd.HighByte
Endif

This allows me to set the velocity in steps of 1/256 counts per tick which is good enough and the idea was to use something similar for the acceleration. But, as I said, the profile generator code turned out to be much more complicated than I imagined and now I'm not sure I can do it without messing up the generator completely. I'm thinking I can make the velocity and acceleration variables WORD-sized and then handle the rest outside of the profile generator. What do you think, do you see any major issues with that?

Sorry for the lengthy post and thanks again for all your help!
/Henrik.

[Darrel Taylor]

Yeah, I guess you could call that a bug.
I wasn't planning on such long low speed moves.

I can probably fix it, but it doesn't sound like this is really what you want.
If it has to use Longs, and needs to run faster ... the time it takes my approach to process each step will never meet your requirements.

Maybe a different approach is in order.
But I don't know what that would be.

Sorry.

[HenrikOlsson]

Hi Darrel,
Now I feel really bad.
It's not that it doesn't do what I want. It does exactly what I want just not under all conditions. Conditions which are a given for me but definitely not for you and now you've wasted a lot of time on something just because I didn't manage to explain the application in enough detail. I'm the one who should say I'm sorry.

I keep finding articles and application notes on acceleration profiles and positioning but they all seam to targeting step motor application where you obviously move the motor only one step per "tick" so you can easily "hit" the exact centerpoint and deceleration point of the move. Not so here....

I will keep dwelling on this and trying a couple of things. I keep thinking that perhaps I could live with the acceleration constraint being violated (to some extent) on deceleration, what I can not accept is not overshooting the target.

Thanks!
/Henrik.