Dave Wilson, Motion Products Evangelist, Texas Instruments
Earlier this week, the federal government flexed its muscles and assumed control of all of the broadcast media in the United States. It was the most expansive test ever of the Federal Emergency Broadcast System. The result was a colossal failure. Many people on cable and satellite TV were redirected to the home shopping network, where they discovered that in the event of a nuclear attack, they could buy beautiful home decorative ornaments for just three easy payments of only $19.95! Others said that instead of hearing instructions in the event of an actual emergency, they were redirected to a channel were they were subjected to the wit and wisdom of Lady Gaga. For those who actually heard the intended message, it sounded like a bad 1950s recording which was barely intelligible. No doubt the government will now spend millions of dollars to upgrade their technology to do a function that the media already does very well.
As I listened to the amusing stories of federal bungling, my attention was drawn to the contrast in technology between the government's mass communication system and the standard we have grown accustomed to today. I laughed to myself as I thought, "this is like the government trying to program in octal in an object-oriented world!" But my amusement became more contemplative as I wondered how antiquated our current software development practices will seem to engineers just ten years from now? There are some exciting changes on the horizon which will have a dramatic impact on how motor control projects are developed in the future. Looking into my crystal ball, here is what I see:
- 1. Most motor control code will be computer generated. Please note that I am NOT suggesting that C programmers will be out of a job. There are many aspects of motor control software that are subjective in nature (like what background color to use on a display, or how fast to blink an LED). A computer has a much harder time dealing with subjective issues like this. But if your job today is strictly coding control loops and filters, then I suggest you start looking for a different job. I don't say that flippantly or to be callous. Since controlling a motor is governed by a strict set of immutable physical laws, this will be one of the first areas to fall to machine domination. Companies like Visual Solutions and Mathworks are currently teaching the laws of physics to computers, and how to translate those laws into C source code. Writing your own Clark-Park transform code will soon become as absurd as programming in machine language.
- 2. Demand for motor control systems engineers will increase. Although the demand for "carbon-based" code generators will decrease, there will be more demand for engineers who can see the motor control problem from a system level. These engineers will be the wizards of motor control, who can interact with the computer through programs like VisSim and Simulink to "frame" the control problem for the computer. The computer will then "check for understanding" by playing back the system response to the engineer to make sure the motor performs as intended on a system level. Once the engineer "blesses" the system configuration, the computer will then proceed to generate all the code necessary to make the motor spin. In fact, I have already witnessed this process happen.
- 3. Computer speeds will allow the simulator to interact in real time with the plant. This is already happening with applications where the plant response times are slow. If you don't believe me, check out the following video:
http://www.vissim.com/downloads/movies/vissim-ECD.html
I just about wet my pants the first time I saw this! Imagine this technology being extended in real-time to a high performance FOC system! The implications of this are staggering! Also, one of the most difficult tasks of a computer is to simulate the non-linear behavior of a motor. But this technique takes that issue completely off the table by removing the motor from the simulation environment altogether.
- 4. Nonlinear modeling techniques will merge with parametric modeling. The most accurate motor models today use Finite Element Analysis (or something similar) to describe the magnetic nonlinearities of the motor. However, most control system simulators use parametric models for the motor, which are much faster, but not as accurate. It is likely that these two techniques will merge together to allow both FEA and parametric modeling to coexist in one seamless environment.
- 5. The demand for floating point processors for motor control will decrease. I realize I might be out on a limb with a saw on this one, since TI currently dominates the floating point market in the motor control space. But let's think this through for a moment. Why do our customers typically choose floating point? I have observed two main reasons:
- a. The application requires a wide dynamic range. A good example of this is the Industrial Servo market, where the positional dynamic range typically exceeds what a fixed-point processor can elegantly handle. In this case, I don't think model-to-code tools will affect demand, since it is the application itself that dictates the requirement for floating point. But most motor control applications don't require floating point.
- b. Ease of use. In many cases, engineers choose floating point processors because they simply don't want to deal with the hassle of radix scaling in their code. But with model-to-code tools, the computer generates the motor control code for you, including any radix scaling! So if your application doesn't require floating point, then why in the world would you pay extra for a floating point processor anymore? Worrying about the radix position on fixed-point machines will become a thing of the past.
One concern I hear over and over again relates to code efficiency of model-to-code generators. I will admit that some of the examples I have heard about are less than stellar. But hasn't that been the case with every new software methodology? Indeed, I was the last person on earth to turn out the lights on assemblers, because I thought there was no way a compiler could ever generate code as tight as I could with an assembler. I won't make that mistake again. Besides, one source claims that code efficiency is no longer an issue. Pete Darnell, CEO of Visual Solutions states, "We've actually worked very hard the past few years to increase <code> efficiency to the point that is only 4% slower than expert hand coded C + assembler!"
Currently, there are more "model-to-code" simulation options for TI processors than any other semiconductor supplier. We intend to stay in the lead of this exciting technology by continuing our investment with numerous industry partnerships. I could go on and on about this, but hopefully I have painted enough of a picture for you to see the exciting possibilities on the horizon!
Now that I have your attention about using simulation as part of your design process, stay tuned for my next blog, "Garbage In, Garbage Out", which provides an ominous warning about blindly trusting your simulation results just because "the computer says so."