SETTLING TIME
Bo,
My old chf eng has been telling me for some time now he can run a servo loop on a FPGA and achieve 10usec servo loop times. It seems to me that we could, on our controller de-couple servo and real time traj generation and drive traj gen to 20 usec and servo update to 10usec. Can you tell me by your math models what type of difference this high speed loop could make on a linear motor system's settle time. I ask because I'm trying to make a case for actually doing something like this. Steven
Steven,
Thank you for your comments and inquiry. Regarding the technique of decoupling update rate from trajectory generation I will have to refer this question to Mega-F controller experts since they write the DSP code. I will try however to address your question regarding modeling settling time in details.
I am not sure what is meant by 10usec servo loop times, or 20 usec trajectory generation. Is it for one axis or multiple axes? The most powerful controller I know of is Mega-F MAC-2xx. Mega-F specifies Update rate of 40 Khz ( i.e. 25 usec ) for driving 8 axes simultaneously with 1 usec latency time per axis ( 1 MHz ), where latency is defined as the time to read the encoder, running at Max 30 MHz AQB, calculate trajectory, run the filters and send command to the amplifier.
In system performance modeling the magic estimator number is 10. The reason is that you need at least 10 points to trace a fairly smooth Sin wave cycle. Therefore, it is considered proper to assume 10 times higher update rate than axis bandwidth. This means that with 40 Khz update, as reported by Mega-F for driving 8 Axes simultaneously, you can expect 4 Khz bandwidth for the current loop of each axis running at 20 Khz PWM. The velocity loop will then be 10 time lower, or 400 Hz, and the position loop will be 10 times less, or 40 Hz. These values are considered typical for high performance positioning systems.
High performance machines of this type are typically driven by linear motors. The reason is that to get 40Hz close loop bandwidth on position loop you need to have 3-5 times higher Natural frequency. A 200Hz Natural Frequency is considered very high for positioning system, although I have seen 700 Hz when using Beryllium Copper and Shell structures. To achieve this value of natural frequency you need to have a system with very low inertia and very high stiffness according to the formula Fn = sqrt ( K/M ) with units in rad/sec. Linear Motors have zero stiffness open loop but in close loop their stiffness equals to the Maximum Force / Minimum Encoder Resolution. This is an order of magnitude higher than Ball screw, Rack and Pinion or Belts.
With position Bandwidth estimated from various system parameters, as described above, we can estimate settling time if we define two additional values: Deceleration Force and Settling window. Where, deceleration force equals Moving Mass Times deceleration and the settling window is defined by the process. If we now divide the deceleration force by the stiffness, we get the Maximum wind up deflection. The servo will fight this deflection and will try to bring it to zero at the position bandwidth frequency where every cycle period it will reduce it exponentially to 1/3 of its previous value until it reaches the specified window.
Lets take a look at a simple example-
Given-
Calculation
In this example it will take 80 msec to settle to 0.1 micron.
Bo,
Referring to the high bandwidth updates and the terms Traj loop and servo loop.
What I am saying is that on the ACR (Acroloop) products, they update all servo loops and and all traj generation within one period. This period is addressable by the user and there is a tool much like the processor load tool in windows to monitor the CPU load. The fastest a two axis traj can close all servo and Traj generation for those servos in about 200-250usec. Now Delta Tau and ACS and other controllers that run compiled code take traj generation and run it once as a result of the compiling of the code. The ACR never does this and is always running traj generation real-time. In the case of the ACR controller, if we left the main DSP to do real time traj calculation and all other tasks, but broke individual servo loop closure out of the main DSP and run that out on a separate FPGA then the tasking of the DSP drops dramatically and update times of the traj loop can be run much quicker now that the main DSP is not tasked with 8 servoloops. Concurrently, the FPGA that is tasked with only servoloop closure can run in the 10usec range. So the each axis target from the traj loop is loaded to the FPGA and the terms that reside now in the FPGA can chase servo error as the only task. Of course the traj would be running an order of magnitude slower than the servo loop but that is typical of inner and outer loop timing issues.
The point of my letter to you was to see if your tool kit can model what type of error we can expect in 10usec and then what closing a loop that quickly will buy us. I expect fantastic results from loops running at these speeds and if you and your toolset can model what fantastic means it would bring us closer to winning the argument for making controls as I have described. ( I also expect the error that can occur in 10usec to be small and so I would therefore expect tuning would fairly easy. I believe that this may mean even an automatic tune would work better than what is typical now.)
Steven
Boaz,
I see that you conduct very interesting discussions. Thanks for allowing me to have some participation. The following are some highlights of our experience, we hope they will clarify some of the questions raised by your colleagues.
Sample Rate. There is not much to add to your example. Mega_F has today 40 KHz for simultaneous control of 8 axes, and this is a lot faster than typical industrial motion control application needs. In fact it is as a minimum twice faster than all other standard motion controllers provide. One of the advantages of the higher than 20 KHz sample rates is that it can achieve higher quality of the filters at higher frequencies. It is shown in the example charts below. The charts represent two notch filter frequency responses for different sample rates. One filter is running at 200 Hz notch, the second is 500 Hz, where all other parameters of the filters are the same.
As shown in the charts, the higher the notched frequency of the filter, the higher sample rate is required.
Sample Rate and Encoder Resolution. In case of incremental A quad B encoders, the resolution of the encoder takes the major role in providing the "effective" sample rate value. Indeed, from one encoder count to the next count there is no feedback updat. Using powerful filters like Luenberg Observer can help, but High Sample Rate (Small Sample Period) limits the necessary computing time.
Sample Rate and PWM. There is no update of the drive command during a PWM period. Increasing the PWM period is limited by two serious factors. First it leads to more power dissipation in the power transistors, and second, it also decreases the PWM resolution. 20 – 40 KHz PWM frequency is what can be achieved in industrial drives with today’s technology.
Sample Rate, Algorithms and Settling Time. Regarding the question- what is more important for getting the shortest settling time – high sample rate or an advanced control algorithm? The answer is clear. High sample rates limit the computing resources required to run advanced algorithms.
Sample Rate and FPGA. Indeed, there is nothing faster than FPGA. Large FPGA's allow implementation of multi-axis sophisticated algorithms in very short samples periods. The reason is that in FPGA computing can be performed in parallel, while in Processor they are done sequentially. We can see today some trends of using FPGA instead of processors. An example is a SIMULINK block diagram tools for Xilinx FPGA devices. The problem however is that an industrial motion controller must perform many more functions than just closing the loop. It requires to habdle user programs, communications, protections and more. Practice shows that the computational algorithms for closing the loops in industrial controllers take not more than 5-10% of the computing resources. Another problem is that the Analyzing, Debugging and Development tools, are too difficult to get with an FPGA at the same level which they are available today in most industrial controllers.
FPGA and Floating Point DSP. Mega_F uses this technology to get both huge computing power and a most advanced development tools like WizAlg. Our Multi-Axis Control module MAC-2xx consists of a 200 MHz floating point SHARC DSP processor and 12K Cyclon FPGA device. We use the FPGA not only for PWM, encoder interfaces and the like. We also use its power to implement time critical algorithm tasks, such as over sampling – decimation filtering, for fast analog encoders interpolation and real time tolerances compensation. In one of our applications this approach allowed us to get 800 KHz Sample Rate for 3 axes total. Please note that it is only 1.25 micro second. The MAC-2xx module, due to its combined SHARC-FPGA computing power, is capable to be a target device for our WizAlg, which is a Real Time – Real Plant Visual Tools for Feedback Algorithm Development in a user friendly Block Diagrams environment.
So, in summary, like in many other real life cases, it really depend on the specific requirements of the application.
P.S. Boaz, please advise if you or your colleagues have any other questions, we will be pleased to be of assistance in any way we can.
Max