TMS320F2800157: Position control of the 48V ABZ+PWM motor using F2800157 launchpad with DRV8353 power board using encoder feedback

Kirana,

That's unfortunate. I have one clarifying question. When running with MOTOR1_ENC enabled, is MOTOR1_FAST enabled or disabled? There's a few differences between those two options. This can be checked in the predefines or during runtime by checking the value of systemVars.estType ( EST_TYPE_ENC vs EST_TYPE_FAST_ENC ).

For debug steps, please let me know the following:

1. When running MOTOR1_ENC, is the value of motorHandle_M1->motorState changing? When it's operating at a steady speed and ignoring speedRef_Hz, what's the current state?
2. When operating at steady speed and ignoring speedRef_Hz, what's the current value of encHandle->encState ?
3. What is the constant speed the motor is running at? Is it equal to the #define macro USER_MOTOR1_SPEED_FORCE_Hz located in user_mtr1.h?

Basically, what I think is happening here is that we're somehow getting stuck in a startup state. These questions will let us know whether it's stuck due to motorState or due to encState. From there, I'll be able to help further.

Regards,
Jason Osborn

Hello @Jason Osborn,

Thanks for your reply.

Below is the attached screenshot.

MOTOR1_ENC -> ENABLED

MOTOR1_FAST ->DISABLED

motor state changing and stuck with fault as module overcurrent. even tried increasing over current value to 300 but still got the error "Module over current'.The same code-only configuration was changed to Hall (enabled MOTOR1_HALL)and checked working fine.

The same code changed the configuration to Encode(MOTOR1_ENC) not working and getting always like Module over current fault.

Shankar,

1. Is this referring to the same project as Kirana? Before, they stated the motor was running at a steady speed, but not responding to speedRef_Hz. What changes were made between then and now?
2. Is the answer to my questions from my prev. post in regards to the old behavior known?
3. Have all IO configurations for the MOTOR1_ENC configuration been verified? By default, they are different than those for MOTOR1_HALL.

Regards,
Jason Osborn

Hello Jason,

While running the motor in MOTOR1_ENC method MOTOR1_FAST is disabled.

1. while motor is running value of motorHandle_M1->motorState is MOTOR_CTRL_RUN

2. Current value of encHandle->encState is  ENC_WAIT_FOR_INDEX

3.Motor is running in the defined value, #define USER_MOTOR1_SPEED_FORCE_Hz - (60.0)

Hello Jason,

1. Me and @Shankar Prabhakaran referring the same project. Before while enabling the MOTOR1_ENC motor is running in the constant speed irrespective of the speed_Ref value and MOTOR1_FAST is disabled on that time. I am using GPIO20, GPIO21 and GPIO43 for encoder feedback previously those pins were not configured properly and now I configured those pins.

2. But now I am facing the module Overcurrent fault.

3. I have verified the IO configuration for MOTOR1_ENC but still facing the same error. Even tried increasing over current value to 300 but still got the error "Module over current.'

Below I have shared the screenshot for motorHandle_M1->motorState and encHandle->encState values after enabling the flagEnableRunandIdentity flag.

Please suggest the method to run the motor in MOTOR1_ENC method.

Regards,

Kirana H P

Kirana,

Thank you for the responses! That's quite a bit of very useful information.

Before starting code debug, one quick piece of advice for CCS, if you're not already aware, which makes this process a lot easier:

• 
• 
• 
• Additionally, if CCS enables 'scalability mode', I recommend unchecking the option in the settings which says "disable editor live parsing."

Now, for the actual debug.

1. encHandle->encState = ENC_WAIT_FOR_INDEX
   1. Let's take a look at the encoder.h file to see what this means.
   2. 
   3. Notice the yellow highlighting. In ENC_WAIT_FOR_INDEX, the encoder is waiting for the eQEP index event interrupt to latch.
   4. Debug Steps:
      1. Check that the eQEP Index pin is configured properly. Ensure that the correct GPIO is configured using the pin config option GPIO_x_EQEP1_INDEX, where 'x' is the GPIO number of the pin the encoder's Index signal is routed to. IO configuration is found in hal.c
      2. Additionally, double-check the configuration of the other eQEP pins. GPIO_x_EQEP1_A and GPIO_x_EQEP1_B must also be configured correctly. IO configuration is found in hal.c
      3. Finally, for eQEP configuration, ensure that MTR1_QEP_BASE is assigned to the correct eQEP module. This is found in hal.h.
         
         
         
2. Hardware configuration for the eQEP
   1. Debug: Certain C2000 EVMs allow the eQEP pins to be routed to different places on the board. For example, the LAUNCHXL-F2800157 has S5 (QEP Select Switch). This must be in the correct position for your connection, otherwise the eQEP pins aren't actually connected!
   2. 
   3. For GPIO20/21/43 on the LAUNCHXL-F2800157, this means S5 SEL1 (left) = 0 (down).
      
      
      
3. Overcurrent Fault
   1. In the Universal Motor Control Lab, there are 2 possible (redundant) sources of overcurrent faults.
      1. The CMPSS compare peripheral, which uses our #define values. It sounds like you've changed these a few times and haven't had positive results.
      2. The DRV8353RS-EVM board has built-in overcurrent protection which can trigger an overcurrent fault. In my experience, this is often caused by one of a couple different problems. Debug Steps:
         1. Ensure the SPIA_PTE signal (also known as SPIA_STE) is correctly jumped from the LAUNCHXL-F280015x to the DRV8353RS-EVM's pin J2-17.
            
            1. 
         2. Add "drvicVars_M1" to the expressions window.
            1. Once initialization is complete, check the values in the configuration registers. Compare these values against the configuration of the DRV8353RS-EVM in hal.c. If everything matches, SPI configuration is good. If not, check all SPIA pins again!
            2. Function name --> HAL_MTR_setGateDriver(HAL_MTR_Handle handle)
         3. If SPI configuration is good and you're still seeing overcurrent faults, check the status registers in drvicVars_M1. Which status registers read '1' ?

There's a lot of debug steps here. I suggest going through them in order for best results. Additionally, on the other thread, I mentioned that user_mtr1.h must be updated with accurate physical motor parameters. This remains true.

Regards,
Jason Osborn
Note: Key topics and debug suggestions from this post are bolded.

Hello Jason,

Thank you for your brief explanation about the issue.

I have followed your instructions and now I am not getting the over current fault.

 1. I have set the USER_MOTOR1_STARTUP_CURRENT_A value to (3.5) because for closed loop. Now I am not getting any errors, but motor is not running, its vibrating and I am not getting any encoder pulses from motor side.

2. After connecting the encoder ABZ feedback to J12 I have measured the voltage level of ABZ pins, and I have mentioned it below.

          GPIO20 (A) = 0V

          GPIO21 (B) = 5V

          GPIO43 (Z) = 5V

3. The QEP (S5) switch position is as follows Q1=Low and Q2=High.

4.I have observed that encHandle->encState = ENC_WAIT_FOR_INDEX after enabling the flagEnableRunandIdentity flag.

5. I have suspected that problem in the USER_MOTOR1_STARTUP_CURRENT_A value because when I am running the motor in MOTOR1_FAST method it is not running at USER_MOTOR1_STARTUP_CURRENT_A = 3.5, it will through over current fault but if I set it to 20 motor is running properly.

So please tell me the proper USER_MOTOR1_STARTUP_CURRENT_A value to run the motor in encoder feedback.

If the above problem is not with the USER_MOTOR1_STARTUP_CURRENT_A value, please suggest the method to resolve the above issue. 

Regards,

Kirana H P

Kirana,

Glad to hear that my instructions were helpful.

1. What is the rated current of the physical motor you're using according to the motor's datasheet/spec sheet? This is important for points 1, 4, and 5 of your prev. post, as well as your final question.
2. Please note that C2000 is a 3.3V device, and is not designed to handle 5V.
   1. The following excerpt is from the F280015x datasheet, under Absolute Maximum Ratings:
      1. 
3. Using an oscilloscope, I suggest monitoring the Index/Zero signal of your motor. This should pulse once per rotation. Does this happen?

Regards,
Jason Osborn

Jason,

1. Rated current of the motor is 150A according to the data sheet.

2. Yes, C2000 is a 3.3V device. But motor encoder feedback is 5V, this we are giving to the J12 and level shifter IC and then converted 3.3V pulse we are giving to the controller.

3. When I giving USER_MOTOR1_STARTUP_CURRENT_A = 3.5, motor is vibrating and not giving any encoder pulses.

If I rotate the motor by manually by connecting the 5V and GND encoder pins, I am getting the 5V signal after one rotation.

Regards,

Kirana H P

Kirana,

Thank you for the clarification on the 5V, I had misunderstood your previous post. My apologies!

As for USER_MOTOR1_STARTUP_CURRENT_A, this needs to be a value high enough to run the motor's startup. This is going to vary depending on the motor, but typically, I've seen that this should be at least 10% of the rated motor current. Depending on many factors, it may need to go higher than that- if your startup is failing due to the current being too low (i.e. the motor isn't turning), then increase it further.

I've bolded the most relevant parts of that paragraph. Let me know how the motor runs when USER_MOTOR1_STARTUP_CURRENT_A (as well as the other motor current parameters, including USER_MOTOR1_ALIGN_CURRENT_A, USER_MOTOR1_OVER_CURRENT_A, and USER_MOTOR1_MAX_CURRENT_A ) are scaled to match the motor's specifications.

Additionally, now's a good time to verify that the other motor specs in user_mtr1.h are accurate as well, such as USER_MOTOR1_RATED_VOLTAGE_V, USER_MOTOR1_Rs_Ohm, USER_MOTOR1_RATED_FLUX_VpHz, etc.

Regards,
Jason Osborn

Jason,

Thank you for your reply.

1. As I mentioned Rated current of the motor is 150A according to the data sheet. I was varying the USER_MOTOR1_STARTUP_CURRENT_A from 3.5 to 10, in this case motor is not running its vibrating because from motor side I am not getting any encoder feedback.

2. However, the motor ran for two seconds when I kept the USER_MOTOR1_STARTUP_CURRENT_A values between 11 to 19, and I then received a startup_failed fault. In this instance, I am receiving encoder feedback for those two seconds.

2. If I increase the USER_MOTOR1_STARTUP_CURRENT_A = 20 motor is running in a constant speed irrespective of the encoder feedback. In this case if I remove the encoder feedback from launchpad and restart the motor then also motor is running in the constant speed irrespective of the speedRef value. Motor is running in the defined value, USER_MOTOR1_SPEED_FORCE_Hz = (60.0) and MOTOR1_FAST is disabled in this case.

3. I have maintained the following values in the user_mtr1.h, 

              USER_MOTOR1_STARTUP_CURRENT_A = 3.5 A

              USER_MOTOR1_OVER_CURRENT_A = 75 A

              USER_MOTOR1_MAX_CURRENT_A = 50 A

              USER_MOTOR1_RATED_VOLTAGE_V = 48 V

              USER_MOTOR1_Rs_Ohm = 0.0046000001 ohm

              USER_MOTOR1_RATED_FLUX_VpHz = 120 Hz

Please refer the above values and suggest the method to run the motor in MOTOR1_ENC method.

Please refer to the file I personally shared with you previously.

Regards,

Kirana H P

Kirana,

The bolded text in this post will indicate key points:

All of the parameters listed should come from the motor or the board's physical characteristics.

• USER_M1_ADC_FULL_SCALE_CURRENT_A needs to be the maximum possible current measured by the ADC. In other words, when the ADC reads 3.3V, what current does this represent in your system? This will depend on your hardware.
  • If this parameter is lower than the highest peak current you expect to see in your motor, then I would expect poor performance.  
• USER_MOTOR1_STARTUP_CURRENT_A needs to be a minimum of 10% of the rated motor current (150A). 10% * 150A = 15A. Based on your experimentation, it likely needs to be higher than that as well, ~20-25A.
• USER_MOTOR1_MAX_CURRENT_A needs to be the maximum possible current you expect to see through your motor. This should be ~100% of the motor's rated current, ~150A.
• USER_MOTOR1_RATED_VOLTAGE_V, USER_MOTOR1_Rs_Ohm, and USER_MOTOR1_RATED_FLUX_VpHz should all be values from the motor's datasheet- the rated voltage (in V), the stator resistance (in Ohms), and the rated flux (in V/Hz).

The startupFailed fault indicates that according to the speed calculations, the motor speed did not exceed a minimum value (USER_M1_FAIL_SPEED_MIN_HZ) during the startup process. For safety, this is assumed to be due to a fault in the startup, and the system enters a fault state.

So, let's walk through why your system is stuck at one constant speed, assuming FAST is disabled and ENC is enabled. When MOTOR1_ENC is enabled, the following code controls the target speed of the motor:

In other words, if we're in the MOTOR_CL_RUNNING state (which means we've completed startup), the motor accelerates towards the user-set speed reference value.

However, if we're not in that state (which means we're still in startup), the motor accelerates towards USER_MOTOR1_SPEED_FORCE_Hz.

When the motor starts, motorState goes to MOTOR_ALIGNMENT. After a short delay, it enters the MOTOR_OL_START state. In MOTOR_OL_START, the encoder is set to ENC_WAIT_FOR_INDEX.

In this state, the next time the encoder sees an index pulse, it immediately enters the ENC_CALIBRATION_DONE state.

When the encoder reaches ENC_CALIBRATION_DONE, motorState becomes MOTOR_CL_RUNNING, and the speed target is set to speedRef_Hz.

If your code never leaves ENC_WAIT_FOR_INDEX, the eQEP is never seeing your index event.

Regards,
Jason Osborn

Jason,

I have followed the steps you had mentioned above. But still I am not able to run the motor. 

The Encoder state is showing as wait for index.

I have attached the screenshot of the debug window. I have also shared the Project file to you in the personal chat.

Can you please check it and help me out. 

Regards,

Kirana H P

Kirana,

Based on that screenshot, speed_Hz is zero. This should not be the case. Add "motorVars_M1.angleHall_rad" and "motorVars_M1.speedHall_Hz" to your debug view. Are they changing?

Regards,
Jason Osborn