• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 82 subscribers
  • Views 1875 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.

Encoder with DRV8301

Jesse Corcoran
Intellectual 500 points

Other Parts Discussed in Thread: MOTORWARE

Hello, I am looking to add an encoder to a custom motor that I have had success running with the DRV8301-69M kit. I am wondering what are the ideal specs for an encoder to interface with this kit?


Thanks for the help

Jesse

  • 0
    Guru 12800 points
    Jesse,

    This kit expects to use a 5V single ended quadrature encoder. So electrically, that is what you should be targeting.

    As far as number of lines goes, it really depends on you application. If you are looking for very precise servo-like control you will need at least 2500 lines on your encoder (I've used a 10k line encoder for test purposes and it works really well). For slower dynamic speed or position control a 500 line encoder is more than adequate.

    I really like the encoders from US Digital, they work really well and are priced decently. I've never ran into weird issues with them. I've worked with some customers who are using a hall angle sensor with a magnet, but these can be kind of tricky to work with. I've also ran into customers who are using a Sin/Cos encoder and are converting that into angles.

    Really, just about anything is possible, but the simpilest path would be to pick up a 5V quadrature encoder. It will be very robust and quick to integrate with that kit.
  • 0
    Intellectual 500 points

    Ok so I got an encoder from US Digital it is 10000 CPR and 40000 PPR. The encoder is working great for servo like position control. I am having an issue though with the encoder running lab 12B I run into issues with top speed where once I hit about 1.8 KRPM it seems like the controller not able to track the encoder and suddenly the encoder speed and motor speed are very different. Until reaching this speed it works perfectly. Is there a limit to the number of lines I should have for an encoder using motorware? Are there just to many data points to quickly for the controller to actually read?

    Thanks for the feedback

    Jesse

  • 0 in reply to Jesse Corcoran
    TI__Guru 57255 points

    Hi Jesse,

    Can you take a look at the below forum post:
    https://e2e.ti.com/support/microcontrollers/c2000/f/902/p/531735/1935848


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Intellectual 500 points
    Ok that is what I am looking for but it doesn't actually say what setting to change or how. In hal.c there is a section which this code



    #ifdef QEP
    // EQEPA
    GPIO_setMode(obj->gpioHandle,GPIO_Number_20,GPIO_20_Mode_EQEP1A);
    GPIO_setQualification(obj->gpioHandle,GPIO_Number_20,GPIO_Qual_Sample_3);

    // EQEPB
    GPIO_setMode(obj->gpioHandle,GPIO_Number_21,GPIO_21_Mode_EQEP1B);
    GPIO_setQualification(obj->gpioHandle,GPIO_Number_21,GPIO_Qual_Sample_3);

    // STATUS
    GPIO_setMode(obj->gpioHandle,GPIO_Number_22,GPIO_22_Mode_GeneralPurpose);

    // EQEP1I
    GPIO_setMode(obj->gpioHandle,GPIO_Number_23,GPIO_23_Mode_EQEP1I);
    GPIO_setQualification(obj->gpioHandle,GPIO_Number_23,GPIO_Qual_Sample_3);


    or

    // Set Qualification Period for GPIO16-23, 22*2*(1/90MHz) = 0.48us
    GPIO_setQualificationPeriod(obj->gpioHandle,GPIO_Number_16,22);

    I am assuming it is the first section but what do I change?
  • 0 in reply to Jesse Corcoran
    TI__Guru 57255 points

    Hi Jesse,

    3 qualification periods at 0.48us each is what the above code/comments tell me.  The TRM can give some background too (see GPxCTRL & GPxQSELn).

    The question is, how much filtering do you want there to be?


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Intellectual 500 points

    There does not need to be much filtering I just do not want my limit on speed to be determined by not being able to read the encoder fast enough. I tried to set the qualification to 1 but that does not seem to do anything. I did that by just changing the 3 to a 1. 

    Changing 


    // Set Qualification Period for GPIO16-23, 22*2*(1/90MHz) = 0.48us
    GPIO_setQualificationPeriod(obj->gpioHandle,GPIO_Number_16,22);

    to


    // Set Qualification Period for GPIO16-23, 11*2*(1/90MHz) = 0.24us
    GPIO_setQualificationPeriod(obj->gpioHandle,GPIO_Number_16,11);  

    this seems to be working but is that the best way to do it

  • 0 in reply to Jesse Corcoran
    TI__Guru 57255 points

    The enum of the qualification settings is as follows (defined in gpio.h within motorWARE):

    typedef enum
    {
      GPIO_Qual_Sync = 0,      //!< Denotes input will be synchronized to SYSCLK
      GPIO_Qual_Sample_3,      //!< Denotes input is qualified with 3 samples
      GPIO_Qual_Sample_6,      //!< Denotes input is qualified with 6 samples
      GPIO_Qual_ASync          //!< Denotes input is asynchronous
    } GPIO_Qual_e;

    As a result, changing the 3 to 1 alone wouldn't work.  Note that you should not use asynch mode with the eQEP signals.

    ===

    There's not really a best way.  This is really defined by what you prefer and the constraints of your end-application.  If you know the max speed of your motor, you know the max pulse rate of the A & B signals from the encoder.  This should then impose a limit on the largest amount of qualification you can have.  Qualification will add some delay in the encoder measurement, so some applications may want even less qual.  In noisy environments & long encoder cables, qualification adds robustness.

    If it were me, I'd probably keep 3 samples of qual and reduce the qual period to a level that meets your need (which looks like what you have done).


    Thank you,
    Brett