• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 29 subscribers
  • Views 832 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DRV10975EVM: Motor Speed digital input and read back

Rob Oppen78
Prodigy 170 points
Part Number: DRV10975EVM
Other Parts Discussed in Thread: DRV10975

Hi,

I'm having an issue with the reported speed using the DRV10975 EVM GUI. Here are my motor parameters:

Nominal Voltage: 9v
Nominal Current: 1.06A; Stall Current: 3.06A
No Load Speed; 3720RPM; Nominal Speed: 2060RPM
Phase-Phase Resistance: 2.87 ohm
Phase-Phase Inductance: 1.61mH
Kt: 56.3RPM/V = 35.8mV/HZ
Number of Pole Pairs: 4

My first question is that the automatic conversion from Hz to RPM seems wildly off. For example, I've set the Speed Control register to 100. When I poll the Motor Speed register it comes back as 62.4Hz, which according to the GUI equals 7164.18RPM. The RPM isn't even close to the actual speed (936 using a conversion factor of 15). What is the GUI using to do this conversion?

My second question is in regards to the reported Motor Speed and actual RPM. I'm comparing the actual RPM using a alternative motor controller, which is known good, and the reported speed is off by ~150RPMs. For example, the conversion factor to go from Hz to RPM should be 15, however, it dropped to 14.12 when pumping water. I verified this by comparing flow rates to the alternative motor controller. Any idea what's going on here?

  • 0
    TI__Mastermind 18900 points
    Hello Rob,

    Thanks for giving a good amount of information for context. Let me address your questions below:

    For your first question, the GUI actually doesn’t have an automatic conversion to RPM from electrical frequency in Hz. There is a box towards the top of the display tab that requires user input of the number of poles (in your case, 8 because 4 pole pairs).

    The equation of the conversion is:
    RPM=60*Hz/(#polepairs)

    Your second question is a bit more complex. To start, there is undeniably some lag in the reads for RPM on the GUI which gives a general RPM. A more accurate way to track it would be FG or monitoring the current waveform.

    As for the decrease in speed, the drop occurs because the presence of water increases the load that the motor is driving. This would be like comparing the speed of fan with and without its fan blades.

    Essentially, the presence of a speed command will translate into some amount of current. And load determines how easy it is to translate that current into motion. Higher load with same current means lower speed that is kind of close to the RPM conversion I have earlier.

    This behavior is expected. Designers will often decide that the speed is “good enough” or some sort of feedback is needed in the form of speed regulation (e.g. PI Loop by monitor the frequency generated by FG).

    Hope this help,
    -Cole
  • 0 in reply to Cole Macias
    Prodigy 170 points

    Hi Cole,

    Thank you very much for your helpful response. Wow, I can't believe that I didn't realize that the Pole textbox is editable. Oops. I've updated the number of poles and the GUI calculated RPM is now correct. However, using the equation you provided, which is what I was using previously, is giving me a different RPM output than what's displayed. (60*177.1)/4 = 2656.5RPM. 2577.32RPM is actually correct based on my flow rate testing.

  • 0 in reply to Rob Oppen78
    TI__Mastermind 18900 points
    Hey Rob,

    I'm glad to hear that you can cross reference the GUI with your actual flow rate.

    As for the descrepancy between calculated RPM and Motor Speed in Hz, there is some lag between calculation for RPM and read command for Motor Speed (registers for Motor Speed1 and Motor Speed2). Since we expect some variation in Motor Speed (6Hz is fine, especially in a pump application), it might have read some value, calculated RPM, and then updated Motor speed with some new value before the next RPM calculation.

    As mentioned before, monitoring the FG pin will give a more accurate frequency if the pseudo-real time calculations are not sufficient in the GUI.

    Thanks,
    -Cole