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.

Add HALL3_DRV to InstaSPIN FOC project

Other Parts Discussed in Thread: CONTROLSUITE, MOTORWARE

Hello,

I haven't succed to add the module HALL3_DRV in the lab7 of instaSPIN FOC yet.

In Code Composer Studio, I added the search path to the include file of this module (f2805xhall_gpio.h) : "C:\ti\controlSUITE\libs\app_libs\motor_control\drivers\f2805x_v1.0"

I added this include in proj_lab07.c (see below)

// **************************************************************************
// the includes

// system includes
#include <math.h>
#include "main.h"


#ifdef FLASH
#pragma CODE_SECTION(mainISR,"ramfuncs");
#endif

// Include header files used in the main function
#include "f2805xhall_gpio.h"

// **************************************************************************

when I built the project, I have 5 errors :

#20 identifier "GPADAT" is undefined

#20 identifier "GPADAT" is undefined

#20 identifier "gpioCtrlRegs" is undefined

#29 expected an expression

#29 expected an expression

It is my first project with CCS and I haven't found my mistake yet.

Thank you in advance,

Best regards

  • Hi Sebastien,

    I have moved your thread to the InstaSPIN forum as they will better be able to assist you.

  • several questions.

    1. why are you trying to add hall sensor captures for sensorless InstaSPIN-FOC?

    2. why are you using controlSUITE software mixed with MotorWare? MotorWare has eCAP drivers:

    C:\ti\motorware\MotorWare_1_01_00_09\sw\drivers\cap\src\32b\f28x\f2806x

    3. why are you using an f2805x version of software if you aren't using an 5x device?

  • Hello Chris,

    1. why are you trying to add hall sensor captures for sensorless InstaSPIN-FOC?

    --> My application needs to know the position of the motor but without the accuracy of an encoder. So I thought to use hall sensors to do that.

    2. why are you using controlSUITE software mixed with MotorWare? MotorWare has eCAP drivers:

    C:\ti\motorware\MotorWare_1_01_00_09\sw\drivers\cap\src\32b\f28x\f2806x

    --> During my investigation about C2000 MCU to do a BLDC driver, I found in controlSUITE the module HALL3_DRV to manage hall sensors. So, I thought it was a good idea to use this module but I didn't know it's not recommanded to mix controlSUITE and MotorWare.

    3. why are you using an f2805x version of software if you aren't using an 5x device?

    --> In fact all the macro in f2805xhall_gpio.h are quite generic and I replaced f2805xbmsk.h by f2806xbmsk.h to be compatible with 6x device. May be it wasn't a good idea.

  • 1. when does it need to know the position of the motor? Once the rotor is moving > 1-3 Hz FAST will provide much more accurate position information than hall sensors.  Do you need to know the exact start position at start? There are other methods to do this w/o using hall sensors.

    2. Yes, there is a HALL3_DRV in controlSUITE. It actually just uses GPIOs (not eCAP) for hall counting. I suppose you could mix the functions. If you intend to use this long term I'd probably take the time to turn it into a MotorWare API function. We don't really have any intention of making a hall counter for MotorWare because Halls are essentially useless for the types of control we focus on.  (there are some exceptions, but I doubt we include these examples - and hence the needed drivers - anytime soon).  I can check and see if I can share some example code in MotorWare format though...

    3. Ah yes, there isn't a 6x version of the controlSUITE drivers...you did the right thing in porting a 5x or 3x.

    Do you have the right GPIO set-up as input captures for this to work?

     

  • Hello Chris,

    1. In my application, I have to move an obstacle from the position 0° to +90° or -90° or any combinations of these 3 positions. I'm using a gearbox with a gear ratio of 86:1. So In my mind, I would like to use a position regulation loop to do that and keep the postion even if we try to move manually the obstacle. So I'm not sure I need to know the exact position at start because hall sensor are incremental sensors and I tested the faisability with a drive from Maxon based on hall sensor for the position.

    I'm using GPIO54 to 56 for hall sensors and I set them up as "General purpose mode" for HALL3_DRV but I could set them up as HRCAP.

    Thanks for your help.

  • Hello Chris,

    Have you had time to check if you can share some example code in MotorWare format regarding my issue with hall sensors?

    And yes, I intend to use this long term.

    Thanks for your help

  • Sebastien,

    I did check and unfortunately the HALL FOC project it not in MotorWare format, the FAE did this on his own to a customer's software specification.  He uses the hall sensors as inputs to a full order observer which generates an estimated angle. This is then used in a standard torque control FOC SVPWM controller.  This is just a speed control application though, he isn't using the estimate for position control. I'm not sure the resolution he's able to achieve with the halls.  Typically with any position control we use an encoder or resolver, we really don't have any experience with hall for position.

    What sort of resolution do you need on your +/- 90 mechanical degree positioning?

    How many poles does your motor have?

     

     

  • Hello Chris,

    The motor I'm using has 24 poles so I should have 72 steps/ revolution with hall sensors. I'm also using a gearbox with a gear ratio of 86:1.

    So, for +/- 90 mechanical degree, I should have a precision around 0,058 mechanical degree

    ( 0,058° = 360° / (86 * 72) ) and the resolution is 3096 ( (72 * 86) / 2 ).

    I will need a precision around 0,5 to 1 mechanical degree in the worst case.

     

  • Sebastien,

    I have a code example that may help you. Post or message me your email address.