Hello,

I am new to motor controls. I am working through the Insta-Spin FOC labs. They are very nice and all the hardware and software is working very well. This is a great learning tool. I have question about Lab 5a. This lab gives a step by step analysis of the PI gains and how to determine them for your motor loop gain. I noticed in the block diagram in Lab 2a the output of the PI block goes to the INV park and then space vector modulator and then to the motor -the way I would expect. However in lab 5a, the output of the PI block produces a motor voltage and skips the SVM gain. Does anyone understand why the SVM gain is omitted? Is it not needed? I know in DC DCs and in sine wave inverters the inverter gain is required to determine the loop gain. Is this not true for SVM.

thanks,

Chuck 

Hello,

I am developing a motor control for a rotary compressor. I am working through the Insta-spin labs and everthing is ok until I get to Lab5B.  We have no speed feedback sensors -encoder or tach. Does the F28027 allow for self-sensored or field oriented control? I thought the InstaSpin chips used an estimate of the motor's backemf to get speed feedback. Is this wrong? Do I need to use a different chip?

Thanks,

Chuck

Hi Chris

I am having some contradictory expediences trying to interpret the parameter: gMotorVars.Flux_VpHz.

Can you tell me what you understand the units of this parameter to be? In particular - I understand it is as stated "Volts per Hertz" as opposed to the more fundamental units "volts per radian/sec". But are the volts "volts peak" or "volts RMS" and are the volts "volts phase to neutral" or "volts phase to phase"?

I have been assuming it is "Volts peak - phase to neutral per hertz" - but I am now not so sure... having seen some contradictory evidence.

Thanks Chris

Richard.

Dear sir/madam,

Hi,

I've been struggling to get this motor to run but I thought I had it nailed down until I ran it loaded.  Using the GUI (loaded with Lab10a) I can increase the speed by 500 RPMs up until I get to 4500 revs.  At this point the motor abruptly halts but the current still flows about 4.5A.

Here is a screen grab of the GUI:

Is there something that is obvious that I've gotten wrong?

Thanks,

Richard

Hello,

you can read "reliable and robust estimation of flux, angle, speed and torque across use conditions", "Best speed input into the control System", "high quality feedback signals", ...

but is there a rough estimation of the resolution of the estimated speed? I do understand that the estimation gets more inaccurate for low speed, but if my motor spins with 50 Hz for example, is the estimated speed accurate at <0,1Hz, approx. 0,1Hz, 1Hz or more than 1 Hz?

Thank you,

Carsten

With more and more MCU suppliers pouring onto the battlefield, the entrenched players found themselves under siege.  Would MCUs be forced to surrender to the same fate that DRAMs did years earlier in the commodity wars?  With so much at stake, MCU suppliers were determined to not let this happen to them, and to not take this onslaught lying down.  After all, they still represented the dreadnoughts of the industry with big guns and even bigger R&D budgets.  Smaller MCU companies instinctively knew not to engage this fleet head-on, or be obliterated.  But they were becoming more successful and more emboldened at outflanking the bigger MCU battleships in the niche corners of the market where agility was more important than sheer firepower.  As a result, several strategies were initiated by the established MCU players to keep them ahead of the pack:

1.  Powerful New Cores:  To prove that the concept of the proprietary core was not dead, and to combat the plethora of different cores that were flooding the market, established MCU players developed application specific cores designed to excel at certain types of calculations.  Perhaps the most notable example of this is the C2000 core from Texas Instruments.  With its Harvard architecture, single-cycle multiply-accumulate capability, and new vector math instructions, it is a perfect fit for real-time control applications such as digital power, motor control, closed-loop control, etc.  Once a core has proliferated to the extent that the C2000 has, it starts to take on a life of its own, and becomes very difficult to uproot as an incumbent choice for new designs.

2.  Continuous fab process innovation:  Unlike power semiconductor products where price is dictated by how many acres of silicon are required to support a given power level, MCU costs are heavily impacted by Moore’s law, which eats away at revenues every year like a cancer from the inside out.  Last year Intel demonstrated a laptop containing a processor built using 14 nm geometries.  The semiconductor industry is forecasting 10 nm geometries for 2016, 7 nm for 2018, and 5 nm by 2020!  As geometries shrink, so do the prices, which is undeniably a good thing for the consumer.  But does shrinking fab geometries translate into a sustainable competitive advantage for the manufacturer?  This question is particularly relevant when you consider that many third-party fabs offer geometry capabilities that rival the proprietary fabs.  It’s kind of like steroids.  As long as you are the only one taking them, you have a competitive advantage.  But when everyone is taking them, it levels the playing field again.  While remaining engaged in the fab war is important, it does not represent a sustainable competitive solution.  If DRAMs have taught us nothing else, it should be that shrinking the geometry only provides a temporary “fix” to keep you ahead of your competitors.

 3.  Innovative New Peripherals:  Older MCUs were considered innovative if they simply incorporated the uP core with some memory, and maybe some GPIO.  But today’s powerful MCUs incorporate everything but the kitchen sink!  Reaching out into the system to gobble up support silicon and auxiliary functions is a common strategy for MCU designers.  But in order for this strategy to work effectively, you must have broad shoulders to support a large family of MCUs, since the integrated peripherals you need are different for different applications.  As a result, this strategy works well for larger MCU companies who can afford to do this.

Not only are there more peripherals, but the peripherals are becoming more powerful.  In some cases, the peripherals themselves contain independent processor cores, like the Control Law Accelerator (CLA) from TI.  For much of my career I designed MCU peripherals for the motor control industry.  I was convinced that the best way to establish a distinct competitive advantage was to add unique features to these peripherals.  But I was quickly disillusioned when I realized how short this distinction lasted before someone else had the same or comparable feature.  And if you patented your improvement, all it did in many cases was broadcast your idea so that competitors could develop a work-around solution with the same or similar functionality.  Don’t’ get me wrong…peripheral innovation is crucial, and I am very proud to work for a company that prizes its leadership position in peripheral development.  But as I look at the motor control MCU market, I am compelled to admit that the peripherals from different manufacturers are all very similar in their basic functions with only subtle differences.  Therefore, I would again argue that in and of itself, fancy peripherals are insufficient to keep MCU suppliers ahead of the competition.

But there is one more super-weapon yet to be unveiled which has the potential to keep MCU manufacturers out of the gaping jaws of commoditization for years to come.  It has already been deployed by various MCU companies with varying levels of success.  Can you guess what it is?  I will discuss this in my next and final blog on this topic.

In this series we have been discussing the challenges facing the microcontroller industry over the last few decades, and some of the steps taken by MCU companies to remain competitive in a market that is becoming more and more crowded.  Recently a few MCU manufacturers (including TI) have turned to software as a secret weapon to win this war.

While software is certainly no stranger to the MCU industry, it has until recently been relegated to a support role for the MCU itself.  For example, even though MCU compilers are sold as a separate product, they are intended to support the main money-making product, the MCU.  Reference design software is often free, and again designed to support silicon sales.  This subjugation is understandable considering that the MCU industry was born out of the silicon industry.  At TI for example, 96% of our revenue comes from the sale of silicon based products.  If that much of your revenue is linked to silicon, it is easy to develop a mindset that your product must therefore be silicon.  I would argue that this is not true.  In fact, I would argue that most companies today don’t understand the true nature of their product.  For example, if I were to ask you “what is your product?” what would you say?  I suppose you might respond by telling me what you manufacture.  But your real product is not what you manufacture, but what you sell.

(Are you confused yet?)

Simply put, your customer is buying a lot more from you than what you manufacture.  They are buying your reputation, your support, and most importantly, the unique set of skills, creativity, and IP brought to bear which breathes life into what you manufacture, thus making it unique.  So if you accept that definition, should MCU companies consider their product to be “fancy sand”, or something far far more?  At the last semiconductor company I worked for, I made the statement that “any MCU company who still thinks their product is silicon will be out of business within a decade”.  Needless to say, I wasn't the popular kid on campus anymore.  Despite being harsh and perhaps mildly overstated, this statement makes my point exactly.  I still believe the industry as a whole needs to embrace a broader mindset that silicon is just part of their product; and in many cases, just the wrapper for their product.

Which brings me back to software.  I believe that the surviving MCU companies of the next decade will recognize and embrace the importance of software as part of their product portfolio.  I am glad that TI management understands this very well, and is aggressively instituting this concept with products like InstaSPIN-FOC^TM.  For those of you who are unfamiliar with InstaSPIN-FOC, it is a powerful sensorless field oriented control algorithm used in motor control applications which is instantiated in ROM on select C2000 based products.  It’s a win-win proposition that solves an industry problem for our customers at a fraction of the cost it would take them to develop a comparable solution.  PLUS it allows TI to field a value-added non-commodity solution to the market.  You can find more information about InstaSPIN-FOC here.  Of course, embracing software as a product instead of a support mechanism comes with a unique set of challenges that require MCU manufacturers to change how they do business.  Here are a few examples…

1.  You can’t please all the people all the time.  This statement is doubly true when it comes to software.  Most engineers agree that C should be the language of choice for embedded software, but that’s pretty much where the agreement ends.  For InstaSPIN-FOC, TI has made a conscious decision to embrace an object-oriented approach which is documented in a 487 page User’s Manual.  The code that interfaces with InstaSPIN-FOC is contained in MotorWare^TM, which is TI’s new suite of software modules which adhere to our object-oriented coding standard.  But despite our best attempts to make MotorWare as easy to use as possible, we still get complaints that our software is too complicated, or is too structured, or ________(fill in the blank).  We recognize the challenge that this presents, and are continuously updating our training strategies and documentation in an effort to make our software easier to use.

2.  Some customers don’t trust the “black-box” approach.  As one who has a hard time trusting software tools and plug-in libraries, I can identify with this concern.  This has come up from time to time with InstaSPIN-FOC, but the number of instances I personally know of where we couldn't resolve this problem can be counted on one hand.  In many cases we can diffuse this issue by pointing out that if they are using our API libraries or IQ math routines (which are in ROM), then they have already been using a black-box approach.

This also means that whatever portions of your algorithm you chose to put in ROM must absolutely be tested through and through, because bugs in ROM code just confirm the black-box fears.  So far we have been very pleased with how robust and error-free the InstaSPIN-FOC ROM code has been.

3.  Some customers feel threatened by this approach.  When I sat down after delivering this speech in Milwaukee, I was immediately approached by an engineer who worked for a drives company who expressed this exact sentiment.  These customers typically fall into one of two categories:

a.  Engineers who feel you are doing THEIR job.  These are mostly software engineers responsible for writing the product code itself.  This can be a real problem, especially if their concerns are legitimate.  The last thing you want to do is alienate the very customers you are trying to help!  With InstaSPIN-FOC, engineers need to realize that it is NOT a complete motor drive solution.  Each module is designed to make your job easier, not replaceable.  Also, the structure of these modules is designed to allow you to use just as much or as little of the functionality as you want.

b.  Companies who worry that you are entering THEIR market.   For the case of TI and InstaSPIN-FOC, this is very easy to address.  I can unequivocally state that TI has no intention to enter the motor drives business.  We don’t have the expertise to navigate the complexities of this market, and would just as soon leave that to you, our customers.  We are content to offer pieces of the motor drive solution, but let our customers put them together.

4.  Marketing Approach.  MCU suppliers will need to be more flexible and adaptive with their marketing strategies.  For example, we have seen that certain segments of the market (like appliances, automotive, medical, hobby, etc.) have embraced InstaSPIN-FOC much more enthusiastically than we could have ever imagined!  But conversely, there has been less interest than expected from other segments, such as Industrial Drives.  This actually makes sense when you think about it.  The motor drives industry has already invested years of R&D to develop their own proprietary sensorless observers that are perhaps as good as (or maybe even better than) InstaSPIN-FOC in some cases.  So we have had to adapt our marketing tactics to serve our customers when and where it makes the most sense.

5.  Applications Support.  Finally, we have had to shift our applications support model from one that was almost exclusively silicon oriented, to one which also includes end application and software expertise.  This doesn't mean that we are reducing our hardware support capabilities, but it does mean that more software resources are being added.

__________________________

In conclusion, will MCUs go the way of DRAMS?  How do we as an industry keep from being sucked into the commodity black hole?

Should we continue to improve our fab processes?  Of course!

Should we integrate more peripherals?  Absolutely!

Should we continue to make our peripherals more powerful?  Again, the answer is yes.  But I am concerned that these actions alone do not represent a sustainable competitive strategy.  Unless we as an industry take bold steps to change how we perceive our products, I fear that we are in constant danger of becoming commoditized.

TI has shown the way for MCU manufacturers to remain relevant in this highly competitive market by providing high value-added solutions to our customers in the form of applications software running on powerful, control-oriented cores.

Most people don’t realize just how vast the field of motor control is. In fact, when you think about it, motor control is the biggest sandbox in engineering! It encompasses field theory, analog design, digital design, control theory, filter design, digital signal processing, power electronics, sensor design, EMI, heat transfer, mechanical dynamics, and embedded software engineering, all rolled up into one package.

Because motors are such a widespread application, questions about this complex technology are bound to come up! With this in mind, we would like to invite you to our Twitter chat covering all-things motors on Thursday, July 31, from 11:00 a.m. – 12:00 p.m. CT.

The Twitter chat will be an opportunity for you to ask any burning questions you may have about motors. My colleague, Mike Firth, and myself will do our very best to answer your questions and direct you to the best resources in the motor field. We’re also looking forward to getting some insight from you about what may be your biggest concerns or your opinion on how the technology is changing.

Join in the conversation by using the hashtag #TImotorHr and watch the @TXInstruments’ handle for questions and answers from Mike and me. I’ve also heard rumor that an exciting surprise will be announced at the end of the chat, so stay tuned!

Some of you may be asking, “Who will I be talking to on the other end of the Twitter connection?” Great question! One I would ask myself. To learn a little more about me and my colleague, Mike, keep reading:

Mike Firth

Mike Firth is the marketing manager for the Motor Driver Business Unit at Texas Instruments Incorporated. He is responsible for overseeing the marketing efforts of TI’s DRV8x and DRV10x motor drivers and DRV5x Hall sensors. With 20 years’ experience working in the IC industry, his professional experience includes a variety of positions in business development and product marketing.  Mike holds a BS in Engineering Physics from the University of Oklahoma. 

Dave Wilson

Dave Wilson is a senior engineer in the C2000 MCU group focusing on motor control applications. In his current assignment, Dave focuses on algorithm development and motor control systems simulation.  He has 35 years of experience working on projects ranging from nuclear pulse processing to artificial intelligence pattern recognition. He has designed motor control systems as simple as trigger controls for power tools, and as complex as a six-axis DSP servo stage controller for a scanning electron microscope. He is the author of several articles, patents, and conference papers related to motor control. Dave holds a BSEE from John Brown University and an MSEE from the University of Wisconsin.  His passions include hiking, camping, photography, guitar, target shooting, and, of course, rotating metal.

Looking forward to chatting with you during #TImotorHr!

Hello! 

I am new to TI DSPs and find learning and programming pretty tedious and difficult. I'm trying to control 3 phase inverters (6 switches - for IM and PM machines) and also 2 phase switching legs with varying duty cycles and phase shifts (for power converters) using suitable PWM signals on the TMS320F28335 Delfino microcontroller with the Peripheral Explorer c2000 board.

Three basic functions that I want to implement are

1. Changing the frequency of the PWM output using an ADC input from a potentiometer on the board connected to pin A0 of the control card

2. Changing the phase shift of PWM 2A and 2B wrt PWM 1A and 1B and 3A and 3B wrt. 1A and 1B (etc.) to a suitable value

3. Applying a suitable dead time so as not to short any switching legs

I have configured matlab to do this since I still have major problems with coding. I've also tried SIMCODER (PowerSim), but in this program, the provision to change the switching frequency of the PWM as an input from the ADC is not available. Also, even without using the switching frequency variation, SIMCODER has problems in creating a sinusoidally modulated PWM signal.

I have 3 basic questions

1. Does anyone have any suggestions about software other than PSIM and MATLAB which can do this easily, without the need to code and also to be able to see the simulation of the whole system with the micro.. in the loop, so to speak. 

2. Can anyone share a basic project with code (in CCS V5 - that actually works!) to achieve these functions for the ePWM module, so that I can get an idea of things.. even one properly configured PWM pair will do, I can edit the code from there. It's a bigger problem to write from scratch without any prior experience. Right now I've tried to write code a few times, but I'm not comfortable with the coding environment and it takes a lot of time to get it right. I'm not sure I'll ever be able to do it on my own. I use CCS5 with XDS 100V2 and control suite and a blackhawk emulator, but I don't particularly understand all of it in a high degree of detail

3. Does anyone have any comments about the pros and cons about using MATLAB (embedded coder) and PSIM (simcoder) or any other software..

It would also be a great help if anyone could tell me if there is a "simulator" for the TMS320F28335.. a program which could show me what the board will do - at the pins and the LEDs etc. when a certain .out file is uploaded onto it.

Many thanks!

HI,

We ran the induction motor in a closed loop. We can’t control RPM below 60 RPM.electrical angle going haywire in below 60 RPM.i adjust gains also. Is there any other method for controlling induction motor in Low RPM. is there Voltage feedback(U-V-W) required for smooth control on low RPM. Awaiting our valuable suggestion.

Thanks,

BIPIN PATIL. 

Hi.

I am wondering if there are any recommended hardware isolation to connect the

TMDSCNCD28377D & 4 - DRV8303 to drive 4 motors?.

I looked at the evaluation boards schematics but I did not find a clear answer.

I am considering Isolating the

1) digital PWMs

2) analog current sense

3) and power current circuits

Which to use galvanic isolation?

Which to share GND ?

any other consideration you could help me with...

Is it engulf to keep good pcb separation for all 3 types of voltages?

Thank you,

David.

P.S. I asked similar question without getting replies from TI's experienced experts.

So I would be very thankful if you could refer this question to them.

Hello,

I am new to motor controls. I am working through the Insta-Spin FOC labs. They are very nice and all the hardware and software is working very well. This is a great learning tool. I have question about Lab 5a. This lab gives a step by step analysis of the PI gains and how to determine them for your motor loop gain. I noticed in the block diagram in Lab 2a the output of the PI block goes to the INV park and then space vector modulator and then to the motor -the way I would expect. However in lab 5a, the output of the PI block produces a motor voltage and skips the SVM gain. Does anyone understand why the SVM gain is omitted? Is it not needed? I know in DC DCs and in sine wave inverters the inverter gain is required to determine the loop gain. Is this not true for SVM.

thanks,

Chuck 

Hello,

I am developing a motor control for a rotary compressor. I am working through the Insta-spin labs and everthing is ok until I get to Lab5B.  We have no speed feedback sensors -encoder or tach. Does the F28027 allow for self-sensored or field oriented control? I thought the InstaSpin chips used an estimate of the motor's backemf to get speed feedback. Is this wrong? Do I need to use a different chip?

Thanks,

Chuck

Hi,

i'm editing TI's project PM sensorlessfor the kit DRV8301 hc c2 kit.I'm not workingwithNEMA17 motor .I noticedthat if IsetthecurrentiqRef to 0.95  , I get a current on the power supply of about 2.8 Ampere.

Now , I would like to understand how I can change the code to get a current on the power supply of 10 Ampere , when I set IqRef = 0.95.

thanks in advance.

Hi,

I am monitoring the BEMF trapezoidal control with hall effect sensors. I notice the spike in the graph (red circles). What is the cause?

Hello,

I have been trying to measure my system inertia in order to close the speed loop on my motor controller. I am using the boostXL-DRV8301 REVB with the F28027 microcontroller.

I am trying to follow the procedure outlined in Dave Wilson's article "Teaching Your PI Controller to Behave (Part VIII)". I am having a problem because I don't know how to get the static friction plus acceleration and the static friction torque out of the FAST and at the required sampling time, Ts -which think is Ti in the code. 

The lab manual shows that lab 5C, inertia ID, does not apply to the F28027.

Is there any way to get the torque and sample data from the FAST in a 28027, or do you just have to poke in numbers for the gains until it works?

-Chuck

Hi Chris

I am having some contradictory expediences trying to interpret the parameter: gMotorVars.Flux_VpHz.

Can you tell me what you understand the units of this parameter to be? In particular - I understand it is as stated "Volts per Hertz" as opposed to the more fundamental units "volts per radian/sec". But are the volts "volts peak" or "volts RMS" and are the volts "volts phase to neutral" or "volts phase to phase"?

I have been assuming it is "Volts peak - phase to neutral per hertz" - but I am now not so sure... having seen some contradictory evidence.

Thanks Chris

Richard.

Dear sir/madam,

Hi,

I've been struggling to get this motor to run but I thought I had it nailed down until I ran it loaded.  Using the GUI (loaded with Lab10a) I can increase the speed by 500 RPMs up until I get to 4500 revs.  At this point the motor abruptly halts but the current still flows about 4.5A.

Here is a screen grab of the GUI:

Is there something that is obvious that I've gotten wrong?

Thanks,

Richard