• State Resolved
  • Locked Locked
  • Replies 28 replies
  • Subscribers 81 subscribers
  • Views 3413 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.

Lab12a Help DRV8301 Sensored Intertia

Jesse Corcoran
Intellectual 500 points

Hello all, I am attemping to run lab12a with my new encoder and having some issues. 

First issue is when I enable system and run identify the motor starts to spin but not very smoothly, it then will start to accelerate but after couple seconds will stop accelerating and never reaches full speed. The motor then continues to run at about 750 rpm.

Second - the lab manual says to enable, run identify then set goal speed and enable “gMotorVars.SpinTAC.VelIdRun", this part does not work at all. I am able to change the goal speed to desired but when I enable “gMotorVars.SpinTAC.VelIdRun" nothing happens the value immediately changes from 1 back to 0. No matter what i do it will not stay at 1 and run the test.

I think i have verified  my encoder is working by enabling system then rotating the shaft CCW one full turn. The question here is when I do that the value in st_obj.vel.conv.Pos_mrev is 1.005485922 (Q-Value(24)) not 1.0 like I thought it was supposed to be. Also if i continue rotating the shaft the value will continue counting up until reaching 10 at which point it becomes -10 and counts up toward 0 and repeats. Is this normal??

Any help is greatly appreciated

Jesse

  • 0
    Guru 12800 points

    Jesse,

    In lab 12a only the inertia is being identified and so it is expected that the motor will quickly accelerate & decelerate in order to identify the inertia.  

    I wouldn't expect that lab to run the motor at a speed, it is only designed for inertia identification.

    Is Rs Recalibration still enabled via gMotorVars.Flag_RsRecalc?

    Are there any error codes present in gMotorVars.SpinTAC.VelIdError or gMotorVars.SpinTAC.VelConvError?

    I wouldn't expect that after manually rotating the motor one revolution the value would be close to 1.0 but not exactly 1.0.  It would be too challenging to get it exactly a single revolution.  Your description of the position signal is what I would expect.

  • 0 in reply to Adam D. Reynolds
    Intellectual 500 points

    Ok I undestand that it should not be exactly 1.0 after one rotation since I likely don't get it to exactly the same spot. Should it count up like that and then roll over to a negative number and back? I just noticed when I compile in CCS it populates two warnings they are:

    Description Resource Path Location Type
    #62-D integer operation result is out of range hal.c /proj_lab12a line 1466 C/C++ Problem

    Description Resource Path Location Type
    #69-D integer conversion resulted in a change of sign hal.c /proj_lab12a line 1466 C/C++ Problem

    When i click on the warning it takes me to this line of code for both warnings:

    QEP_set_max_posn_count(obj->qepHandle[qep], (4*USER_MOTOR_ENCODER_LINES)-1);

    What would cause this error? My encoder has 10000 lines. I read in another post that someone had to change the  uint16_t num_enc_slots variable in enc.c and enc.h to  uint32_t num_enc_slots because of overflow issues. I tried to change this and the warning stayed.

    Also regarding the lab procedure. I know this is supposed just do an inertia test but that part never happens it doesn't let me change the value to 1 to run, when I change it the value immediately changes back to a 0 and the inertia test doesn't happen. Here is a screen grab of the procedure

    Thank you again for the help

    Jesse

  • 0 in reply to Jesse Corcoran
    Guru 12800 points

    Jesse,

    Jesse Corcoran24 said:
    hould it count up loke that and then roll over to a negative number and back?

    Yes, InstaSPIN-MOTION uses a windowed position system.  There are quite a few posts on here about it.

    Jesse Corcoran24 said:
    I just noticed when I compile in CCS it populates two warnings they are:

    Seems like this is a CCS issue.  The interface specifies the use of uint16_t which won't have a sign flip issue.  CCS must be assuming an int16_t for the type when doing that calculation.  You could probably remove the warnings by casting to uint16_t in that calculation.

    Jesse Corcoran24 said:
    change the value to 1 to run, when I change it the value immediately changes back to a 0 and the inertia test doesn't happen. Here is a screen grab of the procedure

    Is there an error code present?

    Did you remove the setting for gMotorVars.Flag_RsRecalc?

  • 0 in reply to Adam D. Reynolds
    Intellectual 500 points
    I removed the RsReCalc flag and I think it is working. I will try test a couple times to make sure getting consistent readings.

    The warnings in CCS are still there do I need to worry about those or just ignore?

    Thank you again
  • 0 in reply to Jesse Corcoran
    Guru 12800 points
    I would ignore the warnings, especially if it is working.
  • 0 in reply to Adam D. Reynolds
    Intellectual 500 points
    Sorry if this needs a new thread but I was able to successfully perform lab12a and lab12b. I am having a problem with lab 13a, the lab states that it is not supposed to spin the motor and if it does spin to check that everything is wired properly. I have verified that my motor is spinning the direction I want it to so I know that the phase lines are correct. When I manually rotate the shaft 1 full turn st_obj.vel.conv.Pos_mrev returns a value of 1 so I believe that the encode is wired correctly and the number of encoder lines should be correct because if i change it to say 40000 instead of 10000 I no longer get 1.0 from st_obj.vel.conv.Pos_mrev.

    Any ideas where to start troubleshooting. I am doing all this to achieve position control so this is an important lab to be able to do.

    Thank you again you have been very helpful
  • 0 in reply to Jesse Corcoran
    Guru 12800 points
    Jesse,

    Can you describe what happens when you run lab 13a?
  • 0 in reply to Adam D. Reynolds
    Intellectual 500 points
    Once I set enable system and run identify the motor shaft will usually wiggle a bit then settle into a stutter where it will rotate about 1/10th of a rotation and back to its original position. While this is happening I can not rotate the shaft manually it is doing this small rotation with large amount of torque.
  • 0 in reply to Jesse Corcoran
    Intellectual 500 points
    While it is doing the 1/10 rotation you can here a sorta click like it applies power then rotates then stops and recoils back to original position
  • 0 in reply to Jesse Corcoran
    Guru 12800 points
    Have you tried to manually deflect the motor and adjusting the controller bandwidth?
  • 0 in reply to Adam D. Reynolds
    Intellectual 500 points
    I am trying to adjust the bandwidth. Sometimes the shaft will spin up to a full speed like it is losing track of the position when this happens then get an error 2002. If I hold the shaft still while clicking run identify it will hold still and then hold this position very strongly. What is happening most often is that I click run identify and the shaft sorta wiggles back and forth a little bit then sometimes this will stop but mostly it continues wiggling in bigger and bigger sections then eventually rotates entirely
  • 0 in reply to Jesse Corcoran
    Guru 12800 points
    Jesse,

    I'm assuming you copied the inertia found in lab 12a into the user.h file, correct?

    Is the flag gMotorVars.Flag_RsRecalc set to 0 or 1?

    If lab 12b worked correctly and spun at the right speed, that should confirm that the encoder phases and motor phases are correctly aligned.
  • 0 in reply to Adam D. Reynolds
    Intellectual 500 points
    I copied the inertia into user.h it was very close to when I had run the inertia test long ago before the encoder was added so I believe it is correct. I had skipped lab12b until just now. When I run this lab what happens is the motor will run at the set speed but every 5 seconds or so it will accelerate to full speed then back down to the set speed.
  • 0 in reply to Jesse Corcoran
    Guru 12800 points
    I think it is easier to debug these issues using lab 12b since there is less going on.

    Is the flag gMotorVars.Flag_RsRecalc set to 0 or 1?

    I would reverify the encoder pulses and motor pole pairs. Seems like there could be a small issues there where it allows a small amount of operation but runs into a periodic issue where the angle becomes incorrect.
  • 0 in reply to Adam D. Reynolds
    Intellectual 500 points

    The encoder specs say 10,000 Cycles per revolution 40000 pulses per revolution. The RsReCalc flag is set to 1 by default for this lab but the same thing happens if i set it to 0.

    I am also very certain on the number of poles it is a custom motor.

  • 0 in reply to Jesse Corcoran
    Intellectual 500 points
    If I change the encoder lines to 40000 instead then when i manually rotate one full turn i get a reading of approx 1.4 instead of about 1.0like it was with 10000 encoder lines.
  • 0 in reply to Jesse Corcoran
    Guru 12800 points
    Since your encoder has a very large number of pulses, a quick thing to try would be to adjust the Input Qualification. This is accomplished in the hal.c file. Specifically the lines:

    GPIO_setQualification(obj->gpioHandle,GPIO_Number_20,GPIO_Qual_Sample_3);

    Try either removing it or reducing the amount of samples.
  • 0 in reply to Adam D. Reynolds
    Intellectual 500 points

    Ok so I tried to commenting out the line, changing to GPIO_Qual_Sample_2, and GPIO_Qual_Sample_1 all of which had exact same problem. The motor will run at the specified speed but every 5 or so seconds it will accelerate to full speed then back to the set speed.  Also in order to change the GPIO_Qual_Sample_3 line you have to change the declaration in gpio.h also.

    Any other ideas?

    Thanks

  • 0 in reply to Jesse Corcoran
    Intellectual 500 points
    When it does go to full speed is it actually the full speed the motor can possibly go not the the max speed set in the software.
  • 0 in reply to Jesse Corcoran
    Intellectual 500 points
    Ok so apparently I wasn't paying attention when inputting the encoder lines. I had #define USER_MOTOR_ENCODER_LINES (10000) instead of #define USER_MOTOR_ENCODER_LINES (10000.0) changing this got rid of the two warnings and it is now running lab 12b properly.

    Thank you for your assistance

    Jesse
  • 0 in reply to Jesse Corcoran
    Guru 12800 points

    Glad you were able to get it fixed.

  • 0 in reply to Adam D. Reynolds
    Intellectual 500 points

    One final quick question. When doing lab 13c after changing enable system and run identify to 1 it will go through a short process where it sorta wiggles back and forth a few times then comes to a stop before I enable the movement plan. What is happening during this wiggle part? It happens regardless of if the offsetcalc is enabled or not. Can I make it not do this?

  • 0 in reply to Jesse Corcoran
    Guru 12800 points
    Jesse,

    During that period it is doing the RsRecalibration, it is also aligning the motor and the encoder so that the software knows where the motor electrical angle of 0 is.

    In order to remove this you would need to find an alternative way to align your motor with your encoder.
  • 0 in reply to Adam D. Reynolds
    Intellectual 500 points
    Thank you for your response. So is it possible to just have it take the position it was in when started as the 0 position? What part of the software should i be looking at to align motor and encoder.
  • 0 in reply to Jesse Corcoran
    Intellectual 500 points
    Reason I ask is that the motor position control is working great but if there is no load at all on the shaft often times during the rsrecalc it will not just wiggle back and forth it will accelerate to full speed and kinda pulse at full speed. If there is any load at all even just light hold with hand it will not do that.
  • 0 in reply to Jesse Corcoran
    Guru 12800 points
    It is not possible to take the initial position as the 0 position since there is not guarantee that the initial position is aligned to an electrical of 0. In order for the encoder to correctly provide and electrical angle to the motor it needs to be aligned to the motor. This can be done many ways. In InstaSPIN-MOTION we use a simple trick where we inject current along the d-axis of the motor in order to force the motor to an electrical angle of 0 degrees. We then capture this encoder position as the offset via the function ENC_setZeroOffset.

    To help reduce the issues with load impacting the alignment, increase the USER_MOTOR_RES_EST_CURRENT_A in the user.h file. This can be increased as much as USER_MOTOR_MAX_CURRENT_A
  • 0 in reply to Adam D. Reynolds
    Intellectual 500 points

    So the real issue I need to solve is not the little wiggle at startup I understand this is necessary for the alignment. The issue is that often during this process it will just accelerate to full speed uncontrollably. I have my USER_MOTOR_RES_EST_CURRENT set to 10.0A my max current is 20. Is this set too high?

  • 0 in reply to Jesse Corcoran
    Guru 12800 points
    I don't think so, my guess is that it needs to spend additional time during the RsRecalibration in order to ensure that the motor has stopped moving during the time it is trying to align. If it is still moving at the end of the RsRecalibration your alignment might not be valid since the motor isn't at an electrical angle of 0.

    The amount of time spent in those states can be adjusted in (I think) userStates.c.