Which Compact RIO Chassis and Controlleur for 3 axis control

[Jochen]

Pat,

ok, let's play around with some number here. If you set the PID rate to a value that is close to the highest frequency of your encoer signal, the PID algorithm will get very few if any position counts per cycle. E. g. if the PID runs with 2 kHz and the encoder generates 500 counts per second, the PID will see a single position change every 4th PID cycle.
As you can imagine, this is not ideal. A PID algorithm works much better and is easier to tune, if it gets at least some position counts per PID cycle.

In fact a PID algorithm can only be tuned properly for a certain range of operation conditions (for motion these are mainly load inertia, velocity and friction). The impact of the PID cycle rate is at least as significant as the impact of the other PID parameters and especially at very low or very high velocities it should be considered quite carefully.

Jochen


Message Edited by Jochen on 07-21-2008 10:29 AM

[paubine]

Thanks Jochen!

I will try at 500Hz but I have an other question...?

I have to stop the movement of the slaves when the MASTER do 1 revolution. I have to verify with the RT controller each count to see if it reaches " the value".

If the loop is at 500Hz, the RT controller will miss "the value" and the slaves won't stop...

What do you think...

Thanks a lot again

Patrick

[Jochen]

Patrick,

there is much more about stopping a DC motor exactly at a certain position than just the PID rate. Even if you would do the position compares at a much higher rate, this wouldn't allow you to stop the motor immediately and these are the reasons and things to consider:

1. The mechanical system has some inertia. As long as you don't decelerate smoothly to the target position there will always be some overshot.
2. What do you plan to do when you reach the target position? Do you want to set the current position as the new setpoint for the PID controller and keep it? Again: This will generate some overshot.
3. Another method could be to set the analog output to the maximum negative value (when moving into forward direction), to make the motor decelerate with maximum torque. This will be the fastest method to stop the motor from going forward, but it might become quite tricky to prevent the motor from accelerating into the negative direction.

The best method is to decelerate the motor to a stop, but I don't know if this is possible in your application. If absolutely no overshot is allowed and if you can't decelerate in a controlled way, the PID rate is your least problem, as in this context inertia and the mechanical response times typically have a much more significant impact on the system than the PID rate.

Jochen

[paubine]

Jochen,

My plan was to decelerates smoothly to a stop after reaching a particular value. (example : when you see count 35 000, decelerate to a stop) ...(I can use "if over 35000", decelerate to stop, it's not critical)

But, I will also have to start a movement when the master encoder will be at a particular value. (example : when master is at count 2000, start the 2 slave) ... i don't want to approximate this time, I have to start the 2 slaves when the master is at 2000... and every axes has to be coordinated.... (it's like, if I want to reset the position value with the index pulse, but in the software instead of the fpga, RT is fast enough)

I'm aware of intertia etc... the problem is that I want that the Real Time, be fast enought to detect those counts or find a way to not miss count read in RT...

not sure if i'm clear? 🙂

Thanks

Patrick

[Jochen]

Patrick,

I do understand what you mean. You still could use a faster PID rate than the proposed 500 Hz, but I just wanted to raise your awareness that this could result in a more difficult tuning process. In the end it all comes down to the accuracy that you need. I think it's not that important that you start or stop your move at a certain counter position, but it should be much more important at which real-world position these actions take place.

To me it looks like you seriously should consider using a different encoder with much better resolution. This will allow you faster PID loops and faster reactions.

Jochen

[paubine]

The encoder is already ordered and unfortunatly not refundable!

I will figure in the testing part of the project if I have to change or not the encoder for a higher resolution one... I think I won't have choice but... the good thing is that I know it can be the problem!

A big thank again for your help

Patrick

[paubine]

Jochen,

I have an other question ... (I finally received a 8000 counts master encoder (2000 quadrature) doing 1 rev / sec and giving setpoints to 2 slaves depending on master)

My question is... if I put the PID rate at 4 kHz (to be sure not to get the same setpoint each PID iteration) ...

What should be the RT loop rate (the same???? what is the effect? I have all the velocity, acceleration, time profile...I would like to learn more about target and RT timing...

Thanks again,

Patrick

[Jochen]

Patrick,

if you are using the spline engine of the SoftMotion module, you can run the PID loop on the FPGA much faster than the trajectory generation loop on the RT controller. E. g. you could set the timing for the FPGA-loop to 250 µs and to 8 or 16 ms for the RT loop.  Please note, that the ratio needs to be a power of 2. The spline engine on the FPGA interpolates the missing points smoothly.

If you try to run the trajectory generation loop on the RT controller also at 4 kHz this would result in a very high CPU load which is typically not desirable. Depending on the other tasks that need to be performed by the RT controller you even may not reach such a high loop rate.

I hope that helps,

Jochen 

[paubine]

Jochen,

I understand more now...

But because the trajectory I'm working on has an acceleration/speed not constant...

How will react the spline engine, if there is not enought point between the two setpoint given by the RT controller?

(for each count of the master, the slaves setpoints has a maximum of 102 counts and a minimum of 0 (when changing direction))

thanks for you help!

Patrick

[Jochen]

Patrick,

the spline engine will do it's best to generate smoothly distributed setpoints between the position points of the trajectory generator. In a situation, where there is only a very small difference between two consecutive position points of the trajectory generator, it will generate the same setpoint multiple times. This could look like that:

TGP = Trajectory Generator Position

SES = Spline Engine Setpoint

TGP    SSP

100     100

           100

           100

           101

           101

           102

           102

103     103 

Does this answer your question?