• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 82 subscribers
  • Views 1403 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Instaspin Motion (position control) - encoder pulses not recognised

Saturn Z
Prodigy 80 points


Hi Folks,

We are trying to get Lab12 working with an incremental encoder (magnetic, quadrature output) on the 69M kit. With this encoder, the motor does not spin.

Here's what we have tried so far.

a. Tested the same board and known motor with two different brand off-the-shelf optical encoders with 250ppr and 1000ppr resolution respectively. It just works out of the box without much effort and very satisfactory performance in terms of position control.

b. Our magnetic encoder is based on  AS5045B (from austria microsystems), standard configuration taken from datasheet.

The magnet is well aligned to the shaft and we're able to see the expected quadrature waveforms (A/B/Z) on the oscilloscope when we manually rotate the shaft.

c. After connecting the A/B/Z inputs to the 69M kit and following instructions from the InstaSPIN-MOTION "Position Control Motor Commissioning" document from Adam (Linestream) we're able to see the st_obj.vel.conv.Pos_mrev value gradually increase and increment to 1 after the shaft completes one rotation (manually).  This means that the A/B/Z connections and USER_MOTOR_ENCODER_LINES value is correct.

However, the motor does not spin at all when given a speed/position reference.

Questions:

1. Since this is a 4096 ppr encoder, is there a max limit on how large a encoder resolution the eQeP can handle ?

2. The quadrature signals (A/B/Z) show on the scope as expected. Do you suspect any rise time, missing pulses or other signal integrity issue ? 

Any suggestions on how to debug this further ?

Note: In all the above experiments, the same, known good motor with proper identification parameters and inertia values was used. So apart from the encoder, there is no other variable.

Thanks for reading through and appreciate any pointers you might have to offer.

cheers,

saturn.

  • 0
    Guru 12800 points

    Saturn,

    When you manually rotated the motor, you rotated it anti-clockwise correct?  When you ran the sensorlesslabs the motor also rotated anti-clockwise correct?

    1. There is a limit but a 4096 cpr encoder is well below this limit.  I've used that exact encoder in the past to do position control without issues.  In your user.h file what do you have defined for the USER_MOTOR_ENCODER_LINES?  I think for this encoder it should be 1024.

    2. I have seen signal integrity issues where electrical noise was causing control issues.  To test for this, set st_obj.vel.ctl.RES equal to 1 to disable the speed controller while gMotorVars.Flag_enableSys & gMotorVars.Flag_Run_Identify are set to 1.  This will run the PWMs but will not put any current into the motor.  Now watch the st_obj.pos.conv.Pos_mrev variable.  This variable should not change unless you move the motor.  Now manually rotate the motor anti-clockwise to make sure you are still reading 1 mechanical revolution when you rotate 1 revolution.  

  • 0 in reply to Adam D. Reynolds
    Prodigy 80 points

    Hello Adam,

    Thanks for the quick response, appreciate it.

    I didn't get your point about anti-clockwise rotation in sensorless labs.

    1. The USER_MOTOR_ENCODER_LINES = 4096 currently in user.h . But I believe we did try with 1024 as well, nevertheless I will give it a shot again. Do you think it should be 1024 ? because its quadrature output ?

    Also what is the highest PPR the h/w can support ?

    2.  I will try it out to rule out noise related issues if any.

    cheers,

    saturn.

  • 0 in reply to Saturn Z
    Guru 12800 points

    Saturn,

    In order to make sure that the encoder and motor are aligned in direction.  When I work with motors, I will try to connect the motor phases such that the end of the motor shaft will spin in the ant-clockwise direction sensorlessly, so that when I work with the encoder I know that anti-clockwise rotation should be positive direction on the encoder.

    1. I think it should be 1024.  Those encoders are 12-bit encoders, but that refers to post-quadrature accuracy.  In the user.h file we are looking for the number of lines on the encoder which is pre-quadrature.  In this case that will be 1024.

    I've used encoders that are 10000 count/rev  at 3000rpm without issues.  QEP hardware is not just limited by the number of counts, it is also limited by the speed of the motor.  Combining both of those measures there is a limit on the maximum frequency of pulses coming into the QEP hardware.  I'm not sure specifically what that is however.

  • 0 in reply to Adam D. Reynolds
    Prodigy 80 points

    Hi Adam,

    After changing the USER_MOTOR_ENCODER_LINES to 1024, I am able to spin the motor with the same encoder. So this was a configuration issue rather than signal integrity.

    thanks for your help and time in solving this issue.

    cheers,

    saturn.