Forums

Naveen,

I looked at your config1.ini and it looks like the line TARGET_SPEED = 7000 might be a problem. Can you confirm that your target speed in the GUI is 10,000 RPM and not 7,000?

I'm working on the same project that Naveen is working on and the actual speed of the motor hangs at 6423 for any target speed above that. Whether we put 7000 or 10,000, it still hangs at 6243. It just so happened that at the time that we saved the .ini file it was at 7000. Hope this answers your question.

Will...

Note that your 36V supply is extremely close to the max rating for your BLDC board and key power components.  How was this supply chosen - and is the supply able to provide the peak phase current demands of this motor?  A most helpful test would be to measure (even better to data log) the power supply's output voltage during start-up, acceleration runs and at your 6.2K RPM plateau.  I'm not sure your power supply is "holding up" at the higher RPMs.  (and fairly quick, easy test)

Have you disabled any of the fault checking mechanisms w/in your board?  Your Brake-On Voltage and Off Voltage are both set to 14.0V - curious that - no?  Suspect that you've disabled this circuit but you may wish to carefully probe the brake resistor to insure it is not being pulsed on. 

Does your motor accelerate smoothly - and without vibration during start-up and thru 5,000 RPM?  Are all of your tests conducted under no-load?  An interesting test would be to observe (better still to data log) the current measurement as you gently (and progressively and safely) load the motor @ 5,000 RPM.  You should note fairly immediate peaks in current - likely this will cause an over-current trip.

A nice measurement would be your data log of the various duty cycles generated from start-up to eventual motor speed plateau.  If the PWM does not increase - all other things being equal - you will not achieve higher speed.

As encouragement - our group has used variants of the TI BLDC design to run many BLDC motors - some in excess of 15,000 RPM.  We chose to develop our own stand-alone (non-PC GUI) and to more closely model the "Basic BLDC" code - as this put us closer to the code and facilitated critical performance measurements.  Have very limited experience with the TI GUI - it would be nice if the chart recorder feature could be tailored to the individual's needs.  (i.e. display duty cycle upon strip chart)

As a precaution - should your power supply be under powered - it is always wise to properly "clamp down" your motor.  We have "launched" motors (identified flying objects) you should guard against such unplanned excursions...

• We chose 36V as the maximum limit because our power supply was capable of maximum of 32V. We knew 32V was within the limits of the board and we also thought that the problem was the input voltage, so we bumped it up. It actually didn't matter what our input power supply voltage was, the motor would always hang at 6243 (keep in mind 6243 is the self reported speed, the one shown on the GUI. the actual speed is ~300rpm more)
• The dynamic break voltage of 14V shouldn't matter since that option is checked off. Again we tinkered with the dynamic brakes since we didn't know what the problem was that was keeping our RPM at 6243, it is currently off.
• The motor does not accelerate smoothly from 0RPM. However, once it reaches about 1000 RPM it is able to ramp up smoothly. There has always been some jittering at 0RPM that we were not able to fix. We tried connecting the halls sensors but the motor never actually moved in sensored trapeziod mode. If anyone knows why we are not able to run our motor with hall sensors please let us know. We did switch the jumpers to digital and changed the settings on the GUI.
• We have measured the duty cycle as the motor is ramping up in speed and we did notice the duty cycle increasing until it hits 6243. Additionally, once it hits that RPM, the current monitor on the GUI starts showing erratic behavior going from 0 to 2 at a very fast frequency (are we hitting a current limit?)

Reviewed your motor spec - suggest that you make use of the Hall Sensors as that method is easier to monitor & verify and insures faster, smoother starts.  (much can be learned by data-logging the first few hundred RPMs from start-up)  BLDC User Guide diagrams the jumper re-configuration to switch from back-emf (sensorless) to Hall.  Halls on your motor are digital - not analog.  (one would expect - correct if I mis-read/grasped)  Once you switch to hall sensored - change the motor decay parameter from fast to slow.  (provides PWM only to high-side FET - low side FET is fully on during that hall cycle - we/others have had much more success "bringing BLDC motors up" using slow decay)  It would be interesting to learn "why" your team moved away from this hall sensed mode - kindly detail.

Your BLDC spec is not crystal clear - unknown is the angular spacing between hall sensors (60 or 120 degrees) and whether hall sensor 1 "matches" what TI describes in the User Guide as Hall "A."  Did your staff properly connect pin 5 of your motor's hall cable to pin 7 of the TI Control Board wire connector?  Pin 4 of the motor cable should connect to the Controller's ground - leaving either connection open would likely prevent proper hall operation of your motor.  You can confirm your motor's hall sequencing and angular spacing by attaching a "flag" to the motor shaft - and then manually rotating the motor with the hall cable connected as described (pull-up each of the hall signals too) and using your scope to observe the resultant logic sequencing of each of the 3 hall lines.  Here's the hall sequencing as described by TI in the user guide: (note your motor may have 60 degree hall spacing - that's described as well w/in the guide)

In your position - I'd gather an in-depth "baseline" of motor and controller data up to your "safe" RPM range of say 5500 RPM.  Motor Current should closely track PWM - we find it best to measure (and log) these by methods/devices independent from the GUI.  (Use Scope current probe and 2nd channel to measure PWM + duty)  Motor tach with output suitable for logger will aid both your development and on-going QC. 

We logged this data to enhance & speed our development: elapsed time from motor start (to mS), RPM, motor current, PWM, Supply Voltage, temperature of power FET.  We "synced" these measurements to a hall active transition.  (will require some set-up analysis/experimentation on your part - recall that you want to make these measurements as close as you can timewise to the center of the PWM burst - this is most true @ low duty cycles)

Always unfortunate to troubleshoot single unit.  Any chance you can beg/borrow a 2nd BLDC board (2nd motor wouldn't hurt, either) - and run same set-up and tests?  You may want to check the max V of the Power FETs - as the Fairchild gate drivers "boost" the FET gate drive to +15V above your supply V - this may have caused an issue.

Suggest that you have the parameters: Max Speed, Max Current, Target Speed and Target Current "track" - such that the Target Speed is always slightly over your desired RPM and Max Speed is about 1000 RPM above that.  If you do this systematically - say at 1000 RPM intervals - you can reasonably predict what a proper Max Current should be - set the target current below this (perhaps by 0.5A)  Somewhere your system is running out of gas - this is the best means I've found to correct...

The screenshots you've promised will be helpful - especially like to see your "start-up" (0 - 500 RPM or so), your mid-range (2500-3000 RPM), and the ramp up to the dreaded 62xx.  Would be most insightful if you can supply both with sensorless and then with hall sensors connected.  Be sure to read, understand and to comply with the jumper settings described in the BLDC User Guide.  (shows Hall Sensor and Sensorless jump insertions)

Lastly - poor form to "rely" upon provided software to "hold off" suspect safety mechanisms.  (can't justify the hi-lo, identical 14V setting of brake - which is very much "in range" - and was a deliberate change by your group from the much higher/safer default value)   Rejecting experienced advice forces extra time/repeated effort upon responders...    While on soapbox - in effort to assist you - other questions were posed - were over-looked and remain unanswered.   (placing unneeded wear/tear upon humble, non-TI content providers seeking to assist from afar)  We've solved 100's of similar issues - always satisfying to get another, "up and running!"  (thus - kindly assist by providing the specific data as requested - there is "some" method behind the madness...)

I attached the screen shots from the GUI. Regarding the hall sensors i used the hall sensor straight from the motor and it seemed like we are getting the right output. our main concern is the rpm as the project dictates the motor reaching 10000rpm. At 6243rpm, as you can see, there are oscillations in the current graph which levels out. We can also hear a humming sound  at that rpm. I couldn't add the screen shots from scope but when the system is ramping up the signal coming out of the controller for one of the phases  looks like (one pulse width) ramps up, reaches the steady state and then ramps down. But when the system reaches 6243 the signal looks like it starts with no ramp up i.e.hits the peak and then ramps down. The duty cycle does not go above 52.41%.

I was talking to some other people about this issue and they told me to mess around with the PWM settings:

Frequency:20KHz

Dead time 2000ns ( i am not sure what this actually does)

Pre-Charge Time:1ms ( i am not sure what this actually does)

Slow Decay: Checked

Min. Pulse Width .1us ( this option i feel that needs to be changed)

Update Rate 1period

I was wondering if we could get the GUI that you were talking about because like you were saying i would like to see and control the duty cycle.

Thank you so much6064.shots.docx for all the assistance.

William Chan

We tried connecting the halls sensors but the motor never actually moved in sensored trapeziod mode. If anyone knows why we are not able to run our motor with hall sensors please let us know.

Hard to troubleshoot when such contradictory data is supplied!  William says exact opposite of your post, today.  (William strongly states you do NOT use the hall sensors)  We urge you/your group to resolve these conflicts as it complicates and wastes our/others time/effort! 

Many of the suggestions we offered to insure your proper hall sensor connections received, "no comment."  Without knowing what you did (or didn't do) we/others seeking to assist will spin our wheels.

We'd like you to set up the BLDC RDK board for "Digital Hall Sensors" (you must configure 0.1" jumper plugs).  Much later we can investigate sensorless - but that is too complex for now and better to build upon small success rather than greater complexity.

Cannot open your screenshot file (MS shows it as in error) - kindly paste screenshots into a PDF so that we can "blow-up" as needed - catch detail.  We really do need to receive/view your screenshots to proceed...  It remains troubling that beyond your inability to reach desired high speed - you have apparent erratic start-up and perhaps current oscillation when speed plateaus. 

Naveen,

I spent some more time reading through the user guide and noticed your PWM frequency may be too low. Pages 53-54 of RDK BLDC user guide have an equation and explanation of what your PWM frequency should be. With your current 20 KHz frequency and a 7 pole motor, the equation for max speed is: 20000/4=(SPEED/60)*(7+1)*6. Solving for speed yields 6250 RPM, which is quite close to your observed readings. Try changing the PWM frequency to from 20 to 40 KHz.

John - yours is a pretty good get - especially as that important speed formula is rather buried in the 70+ pg guide - without benefit of much emphasis or direction.  I agree - raising the PWM frequency potentially will raise the motor's speed - but at the cost of lowered power efficiency, added heating and EMI/RFI generation.  BTW - for those interested - the undocumented "6" in the Max Speed equation is the number of "commutation steps."  (unique combinations of motor drive to phases A, B, and C)

Suspect that the GUI should better instruct users when they enter "unachievable performance parameters" - Messrs. Naveen & William bumped against a near "perfect storm" of extreme motor poles and out of the ordinary RPM requirements.  Believe our group has achieved 10,000 RPM using much more standard 20,000Hz PWM and a more conventional 4 pole, quality BLDC motor.  (as a check: 6250 * 8/5 = 10,000)

All this said - pretty clear that client's PWM_DEAD_TIME is too high when operating @ proposed 40KHz.  At 40Khz each PWM pulse period is 25uS in width - Dead Band of 2uS will unduly restrict PWM Max - and then we must add power losses due to increased frequency.  Propose that client gradually decrease Dead_Band once the higher PWM Frequency is confirmed as viable.  We find 100-250nS Dead Band to be often acceptable - and this will enable higher PWM rates should client "struggle" to reach target RPM - especially when under full load.  (caution - every situation is unique - always start from high value dead band and progress downward in small increments)

It would not be hard for client to re-work the "Set PWM" function - and dial in a lower PWM frequency (40KHz proposed is tad coarse) to reduce power losses and EMI/RFI.  By scaling the Motor Pole to RPM Chart I've created (below) it can be seen that 40KHz PWM yields a theoretical maximum RPM of 12,500 - in excess of client's 10,000 RPM requirement.  This suggests that the PWM Frequency may be reduced by some 20-25% (perhaps to 30KHz) gaining performance and interference savings.

A major issue remains - poor start-up performance and apparent current oscillation when the upper 20KHz PWM limit kicks in.    Something else is likely at play here - which explains my request for attention and reasonable response to the systematic questions I raised earlier.  (most unanswered)  Should either the RDK's GUI or the BLDC software cause PWM "starvation" when the max RPM is reached - that is very much a non-graceful program weakness - should be investigated and corrected.

A nice addition to the BLDC GUI, Datasheet and User Guide would be - at minimum - a chart showing the maximum motor speeds obtainable @ different PWM frequencies and with motors of various pole number.  We (and now others) know that at 20KHz PWM this results:

# of Motor Poles          Max Achievable Motor RPM @ 20KHz PWM (assumes 3 phase BLDC motor)  - 

(May be scaled for use @ other PWM freqs)

2                                 20,000

4                                 10,000

6                                  7,142

7                                  6,250

8                                  5,000

10                                4,545             

Should original poster have read this far - suggest that you not change the PWM Frequency to 40KHz at first!  Instead - safer for you to "bump it up" - say to 25KHz first.  If 25KHz boosts your RPM that is pretty good confirmation that this method is on the right track.  (you'll have to read in detail to see if 30KHz PWM is directly supported by the GUI - but you can easily modify and create any PWM frequency you desire w/in the code)  Always test your PWM output after any code changes - before applying/connecting your motor.

cb1 and John, thank you for all the help thus far and for not giving up on us when you saw conflicting responses. They were largely caused by a misunderstanding and miscommunication between myself and Naveen.

Back on topic, however:

• As cb1 said and John mentioned, I also agree with the "perfect storm" of large number of motor poles and out of ordinary RPM requirements. The number of motor poles is unchangeable now and our RPM was determined by the motor rated nominal RPM, which we thought would be no problem to achieve (we were dead wrong). The PWM frequency has been at 20kHz and it yields a number of 6250 that is eerily corresponds to our 6243 cap we observed. I think the current oscillations when the upper 20kHz PWM limit kicks in is exactly what cb1 suggested, "a non-graceful program weakness". 

• Another "non-graceful program weakness" is the fact that when choosing any option higher than 20kHz in the GUI, the configuration automatically reverts back to 20kHz. When choosing any lower frequency than 20kHz, the GUI complies. I'm very much interested in a rework of the "Set PWM" function that cb1 described as I believe we have hit a GUI limitation. There are various other bugs in the GUI that limits our control of the motor but this PWM frequency is probably the one that receives the most blame for limiting our RPM. Futhermore, our dead time is also has a minimum limit of 500us (which shows up as 25 in the .ini files). When we specify any lower, the GUI will automatically revert back to 500us.

• Also, we are not so worried about power losses due to a higher PWM frequency since efficiency is not paramount in this part of our project. We are most concern with spinning a certain inertia to a speed  of 10,000 RPM and we have not even been able to accomplish 10,000 RPM with an unloaded motor, which is very troubling.

• Finally, we are not sure what is causing the problem but after setting the jumpers on the physical board and changing the GUI to sensored trapezoid drive (with digital Halls at 120 spacing checked in the options), the motor does not respond at all. The only feedback we get is the fault of "STALLED" while the motor does not move one bit and there is not even a slightest hint of a signal. We have tried to characterize the signal on one of the phases while in this mode but the fault appears too quickly for any type of waveform to appear on the scope.

@William - Thank you - very thoughtful, detailed and complete report - appreciated.  We must applaud LMI/TI for the BLDC-RDK - it was a pioneering effort and does in general perform nicely.  I remain concerned that TI posters sometimes "zero in" - and in so doing may miss the more vital, big picture - thus my wider ranging comments.  Special credit to you for acknowledging the contradictory data earlier supplied - hard to fathom that only "outsiders" detect/squawk. (enabling you to fix & strengthen your description - how does one correct if such feedback withheld?)

Have used the GUI long ago - only briefly - as I knew we had to "dig" into the code to get closer to the real control software.  Like you - I was unaware that the GUI performs unannounced, "traffic-cop" upon PWM selection - certainly strange (and unwelcome!) that.  I can best assist you if you temporarily retreat from the GUI and instead use the "Basic BLDC" version of the program.  You interact with this program via a pre-set parameter file called ui.h.  While not allowing "on the fly" parameter variation - this will get you much closer to the actual software - and if you take this tack I can provide both a 25KHz and 30KHz PWM select coding for you. 

As regards your failure when employing hall sensors - suggest that you call motor maker - confirm that 120 degree hall spacing is correct.  (or you could briefly "gamble" and change GUI selection into 60 degree Hall mode.  (this is a GUI selection box)  It really will be much easier for us to proceed if you can get the Halls up/running.  As a quick check you should spin the motor by hand - as past suggested - and confirm that each hall signal properly transitions.  If you then compare these live waveforms with the 120 degree hall chart I placed earlier in this forum thread - you can confirm hall spacing yourself.  *** Vital that you select "SLOW DECAY" w/in GUI or Basic BLDC!  Let us know - and good luck...

BTW - you have typo in Dead_Time (500uS) - you meant 500nS which should not be an issue until we flirt with 90%+ duty cycles.  (recall that 20KHz period is itself just 50uS...) 

For those interested - here is a method for setting the PWM Frequency to one not supplied w/in the GUI or Basic_BLDC: (illustrate with both 30 & 35KHz)

As further benefit for your readership/support - offered herein is a relatively simple means to perhaps safely & effectively "overcome" the (imho) perhaps too restrictive and intrusive Fault Protections built into the BLDC code.  Must advise that as hallowed, "content provider" you hereby release all such providers from any/all liabilities (nice boilerplate @ page bottom) and proceed entirely at your own risk.  In the spirit of risk minimization - my method enables fault overcome by NOT altering any of the Fault Mechanisms - but instead by producing non motor signals which approximate those of a motor and thus serve to "quiet" the in-built fault mechanisms - at minimum enabling one to make the very necessary measurements & observations.  (unfortunately these are too often prevented by the suddenness of Fault ShutDown...)

Step 1: add these additional case code blocks w/in the function, "PWMSetFrequency(void)" which appears w/in BLDC file, "pwm_ctrl.c"

             // The newly proposed PWM frequency is 30 KHz.
             //
        case PWM_FREQUENCY_30K:
        {
            // Set the PWM frequency variable.
            //
            g_ulPWMFrequency = 30000;

            // Get the number of PWM clocks in a 30 KHz period.
            //
            g_ulPWMClock = PWM_CLOCK / 30000;

            //
            break;
        }

             // The proposed new PWM frequency is 35 KHz.
            //
        case PWM_FREQUENCY_35K:
        {
             // Set the PWM frequency variable.
            //
            g_ulPWMFrequency = 35000;

             // Get the number of PWM clocks in a 35 KHz period.
            //
            g_ulPWMClock = PWM_CLOCK / 35000;

            break;
        }

Step 2: add the new #defines as shown w/in BLDC file, "ui.h" so that your newly proposed PWM Frequencies are recognized and accepted:

// The following set of parameters correspond to the parameters that are
// configurable on the "PWM Configuration" tab of the "Configuration"
// panel of the BLDC GUI.
//
//*****************************************************************************
//
// The PWM frequency to use when driving the motor.
//
//#define UI_PARAM_PWM_FREQUENCY      PWM_FREQUENCY_8K
//#define UI_PARAM_PWM_FREQUENCY      PWM_FREQUENCY_16K
//#define UI_PARAM_PWM_FREQUENCY      PWM_FREQUENCY_20K
//#define UI_PARAM_PWM_FREQUENCY      PWM_FREQUENCY_25K
#define UI_PARAM_PWM_FREQUENCY      PWM_FREQUENCY_30K          // newly added  -  Note this one selected!
//#define UI_PARAM_PWM_FREQUENCY      PWM_FREQUENCY_35K       //  newly added

This code is all extracted from "Basic_BLDC" (but for my PWM_Freq additions) which I find gets you much closer to the software - you certainly are clever & persistent enough to "graduate" from the GUI - especially in light of the limitations you've discovered and duly reported here.  Note that neither TI nor predecessor LMI would release the PC GUI code - thus we are unable to confirm nor assist your disabling of the "anything 20KHz or under" PWM Frequency "surprise!" 

Again - scope your PWM outputs prior to motor hook-up and powering.  Confirm that you do generate 30KHz PWM (33.3uS period) before attaching motor.  Dawns on me that years ago I developed 8 pin MCU to serve as "Hall Simulator" - generates both 60 and 120 degree spaced, 3 phase hall signals in response to an analog (i.e. speed control) input.  Same board further generates a "faked" analog output - fooling the GUI and/or Basic code into thinking that a real motor is connected!  Saves you from the immediate (and dreaded) Fault Shut-Down which "imho" should be more easily bypassed.  (I'm reluctant to share this...)  Left for your exercise is determining the rough hall frequency for your 7 pole motor as it achieves say 50 RPM - which should be sufficient to "silence" the various Fault mechanisms - which will shut you down - thus disallowing any measurements.  Can you say, "Catch 22?"  (you now know why my "Hall Simulator" was (and remains) such an asset...  Good Luck...

from the, "did I forget that dep't" - you may be able to get away by having a simple (555 IC like) timer set to ~60Hz fed into "just one" of your Hall Inputs.  Now you have to read the actual code - and w/in hall_ctrl.c I recall that the Basic and GUI versions (in the past) read just one hall sensor to prevent the timeout Fault.  (Study this - I'm out of time/space now but this may simplify - best if you can create true 3 phase signals (I did with maybe 10 lines of code on old 8 bit MCU).  If you use 555 best to V_Divide its output down to 3V (just in case - crazy errata sometimes) 

@cb1 Thanks again for all the hardwork and help you have provided, but I may have some news that could render all your work useless (I certainly hope that's the case)!

You can find the data sheet for our board here

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CG4QFjAB&url=http%3A%2F%2Fwww.ti.com%2Flit%2Fug%2Fspmu041%2Fspmu041.pdf&ei=VmiPT46zKaXe0QH917SOBQ&usg=AFQjCNGGNQrDsFSNqE5pJlvmTQGi6af9kg

On page 3 you will find "Switching Frequency min:8, nom:16, max 20 (units in kHz)

This may explain why we were unable to choose any switching frequency above 20kHz. Unless we can obtain a higher frequency with the code you have provided, I believe this is it for trying to make this board work with our motor.

Will...

Never would a single (and temporary) set-back render effort/focus/sharing useless - I do strive to write broadly enough to benefit many - and wherever possible pass along tips that many years in the trenches have revealed.  (and many readers outside - even some w/in hallowed host firm have thanked - expressed appreciation...)

Too late now - can't search your board - thought it was official TI RDK-BLDC - but any board with TI Stellaris 50-80MHz MCU should be able to achieve my favored 30KHz PWM with exactly the code I supplied!  If you/others have any familiarity with code - should be very quick/simple effort to increase the PWM.  Seems that "fog of battle" has caused you to overlook my "Basic-BLDC" suggestion - which frees you entirely from GUI limitations. 

We've gone full circle - cryptic 1st post - (now this ???) - old habits die slow death - wish you well...

Hi

just for added information here is some data we collected.

7801.shots.pdf

Naveen George