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.

Semi-working Encoder

Other Parts Discussed in Thread: MOTORWARE

Hey folks --

I've connected an optical encoder, and I am following the directions in Lab 12. When I change the speed reference, the motor doesn't move at all. However, if I remove the encoder from the shaft and turn it by hand, the motor precisely tracks how much I turn the encoder.

If it were a wiring issue, I wouldn't expect this behavior. Any ideas?

Thanks!

  • "However, if I remove the encoder from the shaft and turn it by hand, the motor precisely tracks how much I turn the encoder."

    You mean that FAST is providing a reasonable speed estimate through gMotorVars.Speed_krpm?

    When you spin it by hand are you spinning it in the same + direction that the encoder uses, and is the Speed_krpm showing a positive speed?  If not, swtich two phase wires.

    The phase wire order is important if using a mechanical rotor sensor so that you align electrical and mechanical direction.

     

  • Are you allowing the motor to go through RsRecalibration?  In the demo projects we use this state in order to align the encoder and motor together.

  •  - Yes, it's providing a reasonable speed estimate.

    - Yes, the direction is the same. I had to swap my A-B wires accordingly. It was reversed earlier.

    Hmm, I don't know if the RSRecalibrate state is occurring. How would alter or check this?

  • There is a flag to enable or disable this feature in gMotorVars.  You can check if it is working by watching the gMotorVars.EstState variable.  We should go through this step after gMotorVars.Flag_Run_Identify is set form 0 to 1.  When you are in this state gMotorVars.EstState will be set to EST_State_Rs

  • Matthew,

    for RsRecalc

    IF

    gMotorVars.Flag_enableRsRecalc  = 1

    when

    gMotorVars.Flag_MotorIdentified = 1 and

    gMotorVars.Flag_Run_Identify = 1

    then the RsRecalibration will be run. You will see this by monitoring

    gMotorVars.EstState

    and note that it changes to

    EST_State_Rs

    before the motor starts up.

     

    This is the default configuration.

     

     

  • Thanks for the help. I had the encoder seated out of alignment (silly me), and it's working now... sort of.

    Still have a few questions:

    1. It runs above 0.2 krpm, but at any lower, it rotates in jerks.

    2. It works when I set the encoder lines to 2048 (quadrature encoding number), but not 360 which is the actual number of encoder lines.

    3. In lab 13a, adjusting the bandwidth doesn't seem to change anything observable.

    4. I don't get any movement out of lab 13b.

    and possibly unrelated:

    5. My inertia measurements (lab 5) exhibit quite a bit variance (roughly 0.1 to 0.2) depending on the measurement settings. Also, I have to really adjust settings for it to not give negative friction. Any ideas?

  • seems like a fundamental setting is off. what is your USER_IQ_FULL_SCALE_FREQ_Hz?

    USER_IQ_FULL_SCALE_FREQ_Hz 125 USER_MOTOR_NUM_POLE_PAIRS

     

    I believe for the next release we will be changing this so that the FREQ_Hz used by SpinTAC is a different variable than what we use for the sensorless projects.  If you just work your way through the sensorless labs this is a big difference and the default value used for sensorless will cause an issue for the sensored projects.

     

  • Matthew,

    Glad to hear you got it working.

    1. What is the bandwidth you are using when spinning your motor in lab 12?

    2. Your encoder most likely has 2048 lines (or pulses).  360 lines seems low, also there is no way to go from 360 pulses to 2048 post quadrature.

    3. If you manually disturb the motor during lab 13a, increasing the bandwidth should make the motor hold a zero position tighter.

    4. What happens to the motor if you give a position step command?

    5. If you get a negative friction value that is ok.  Just set it to zero in the user.h.  There will be some variation in the estimated inertia value.  But you will get the best value when you set the goal speed equal to the maximum speed of your application, and adjust the torque ramp time until it completes the inertia id process.

  • Thanks again for the quick replies. I re-estimated inertia and ended up setting friction to 0 rather than playing with the estimation settings. This seemed to fix all the jerkiness I was observing. Position control seems to work well now!

    I do have one more question regarding the USER_IQ_FULL_SCALE_FREQ_Hz. My motor has 4 pole pairs. Thus, the maximum full scale would be 500hz. Does this limit the max speed of the motor? I need to get up to roughly 15krpm, is this possible with this system?

  • Matthew,

    Glad to hear you were able to get it working.  Setting USER_IQ_FULL_SCALE_FREQ_Hz to 500 Hz will limit the maximum speed of your motor to 7.5krpm.  We are addressing this issue in the next release of MotorWare which should be happening soon.  We are expanding the configurable range of USER_IQ_FULL_SCALE_FREQ_Hz for position control.  In the next MotorWare you will be able to set it as high as MOTOR_POLE_PAIRS / 0.002, which is 2000 Hz in your case.

  • Actually, the IQ_FREQ isn't a top limit.

    I think you will actually be limited to 1.999 times IQ_FREQ, so you should almost be able to reach 15 krpm with 500 Hz setting

    This 1.99 is due to the IQ scaling done internally inside the library.

     

    Can you confirm you can run your motor to near 15 kRPM?  Be warned, right at 15 kRPM your speed command will roll over to a negative per unit, causing an instantaneous command to your torque controller....don't attempt this if you aren't protecting your inverter / power supply appropriately.

     

    BTW - this 1.99 limit is for all MotorWare solutions.  If using FAST for IS-F and IS-M sensorless we also currently have the stipulation that you MUST set

    #define USER_IQ_FULL_SCALE_FREQ_Hz        (4 * USER_VOLTAGE_FILTER_POLE_Hz)

    // this is due to some filtering inside of FAST

    when moving to sensored feedback the IS-M stipulation is that

    #define USER_IQ_FULL_SCALE_FREQ_Hz ( >= 125 * poles; 500 max)

    and this will be updated in the next release to (up to MOTOR_POLE_PAIRS / 0.002)

     

  • Let me correct that last post.

    For IS-MOTION - using SpinTAC:

    the frequency command is limited to 1 per unit, meaning Max Frequency command = USER_IQ_FULL_SCALE_FREQ_Hz.

    When using sensors this is bounded by 125 * #poles today and will increase to POLE_PAIRS / 0.002 in the next release.

    For IS-FOC - NOT using SpinTAC

    the frequency command is limited to 1.99 per unit, meaning Max Frequency command = 1.99 USER_IQ_FULL_SCALE_FREQ_Hz.

    and is further bound by USER_IQ_FULL_SCALE_FREQ_Hz     =    (4 * USER_VOLTAGE_FILTER_POLE_Hz)

     

  • Alright, thanks. So for IS-FOC not using SpinTAC, will this be updated to POLE_PAIRS / 0.002 in the next release? And, if so, do you know a rough timeframe of this release?

    Using the lab 12 code, I can't seem to get the motor above 5krpm right now. I have USER_MOTOR_MAX_SPEED_KRPM set higher, but I assume that there must be an additional setting I'm overlooking.

  • MotorWare _12 will be sometime in the late Feb - early March timeframe. We are finishing some things up.

    you can look at your Vs value (in lab12) to see if your voltage is saturated at 1.0

    If it is, you can't go faster unless you up your modulation to allow up to 1.33, increase your bus voltage, or add field weakening.