>Ok, I've got dents in my wall and lumps on my forehead. It's time to tap
>the collective wisdom of the list.
>
>I'm building a system to control a sensored NEMA23 size brushless motor
>based on a dsPIC33F128MC804.
>I've got the motor spinning and I'm working out my control loops (speed and
>position).
>Earlier, when I was doing simple bench testing, the motor
>was noticeably smoother in one direction
>than the other. Now that I have the gearbox and a load connected to it,
>it's _much_ worse.
>Clockwise, it's smooth as silk and moves my load at about 1.5 Amps.
>Counter-clockwise it's noticeably
>noisier and draws upwards of 7 Amps. The load is very close to the same in
>both directions.
>
>I'm completely at a loss for why it would behave differently depending on
>direction of rotation.
>
>I'm using brand new, Electrocraft motors, (two different motors,
>from different production batches have been tried with the same results)
>
>The board is our design. I've run several tests on it and I'm confident
>that the FET drivers and FETs are operating correctly.
>I've got a small logic analyzer and I've looked at the halls (clean, well
>sequenced, uniform widths - both directions) and the control lines to the
>FET drivers (exactly the expected sequence).
>I've scoped the gates of the FETs and I don't see anything odd.
>
>The Hall sensors and commutation is managed with the CN interrupt.
>Assembled into a three bit value and used as lookup in a sector table.
>The sector value is then incremented or decremented (CW vs CCW) and used to
>lookup the OVDCON value. This is all very much strait out of the appnotes.
>
>I'm fresh out of ideas. Any good suggestions?
>
>-Denny
>
>
>
>
>Here's some snips of the relevant code sections:
>
>//globals
>char SectorTable[] = {0,6,2,1,4,5,3,0};
>unsigned int StateLoTable[] = { 0x0000,  /* All off, guards from bad hall
>data*/
>                                0x0204,  /* PWM2L -> 1, PWM1H -> PWM */
>                                0x0210,  /* PWM3L -> 1, PWM1H -> PWM */
>                                0x0810,  /* PWM3L -> 1, PWM2H -> PWM */
>                                0x0801,  /* PWM1L -> 1, PWM2H -> PWM */
>                                0x2001,  /* PWM1L -> 1, PWM3H -> PWM */
>                                0x2004,  /* PWM2L -> 1, PWM3H -> PWM */
>                                0x0000}; /* All off, guards from bad hall
>data*/
>
>
>
>
>
>//and in the CN interrupt
>
>tempC = PORTC;                                  //grab the pins as quick as
>possible
>tempB = PORTB;                                  //according to stopwatch,
>assembly takes 15 cycles
>HallValue = (0x0007 & (((tempC & 0x0040) >> 4) | ((tempB & 0x0200) >> 8) |
>((tempB & 0x0100) >> 8)));
>
>CurrentHallSector = SectorTable[HallValue];     //linearize hall reading to
>sector number
>
>if (MotorDirection == CW)                       //Calculate the next sector
>based on current sector and direction
>    {
>    NextHallSector = CurrentHallSector + 1;
>    if (NextHallSector == 7)                    //the numbers wrap around...
>        NextHallSector = 1;
>    }
>else
>    {
>    NextHallSector = CurrentHallSector - 1;
>    if (NextHallSector == 0)
>        NextHallSector = 6;
>    }
>
>P1OVDCON = StateLoTable[NextHallSector];        //Load a value into OVDCOn
>based on next position

> Ok, I've got dents in my wall and lumps on my forehead. It's time to tap
> the collective wisdom of the list.
>
> I'm building a system to control a sensored NEMA23 size brushless motor
> based on a dsPIC33F128MC804.
> I've got the motor spinning and I'm working out my control loops (speed and
> position).
> Earlier, when I was doing simple bench testing, the motor
> was noticeably smoother in one direction
> than the other. Now that I have the gearbox and a load connected to it,
> it's _much_ worse.
> Clockwise, it's smooth as silk and moves my load at about 1.5 Amps.
> Counter-clockwise it's noticeably
> noisier and draws upwards of 7 Amps. The load is very close to the same in
> both directions.
>
> I'm completely at a loss for why it would behave differently depending on
> direction of rotation.
>
> I'm using brand new, Electrocraft motors, (two different motors,
> from different production batches have been tried with the same results)
>
> The board is our design. I've run several tests on it and I'm confident
> that the FET drivers and FETs are operating correctly.
> I've got a small logic analyzer and I've looked at the halls (clean, well
> sequenced, uniform widths - both directions) and the control lines to the
> FET drivers (exactly the expected sequence).
> I've scoped the gates of the FETs and I don't see anything odd.
>
> The Hall sensors and commutation is managed with the CN interrupt.
> Assembled into a three bit value and used as lookup in a sector table.
> The sector value is then incremented or decremented (CW vs CCW) and used to
> lookup the OVDCON value. This is all very much strait out of the appnotes..
>
> I'm fresh out of ideas. Any good suggestions?
>
> -Denny
>
>
>
>
> Here's some snips of the relevant code sections:
>
> //globals
> char SectorTable[] = {0,6,2,1,4,5,3,0};
> unsigned int StateLoTable[] = { 0x0000,  /* All off, guards from bad hall
> data*/
>                                0x0204,  /* PWM2L -> 1, PWM1H -> PWM */
>                                0x0210,  /* PWM3L -> 1, PWM1H -> PWM */
>                                0x0810,  /* PWM3L -> 1, PWM2H -> PWM */
>                                0x0801,  /* PWM1L -> 1, PWM2H -> PWM */
>                                0x2001,  /* PWM1L -> 1, PWM3H -> PWM */
>                                0x2004,  /* PWM2L -> 1, PWM3H -> PWM */
>                                0x0000}; /* All off, guards from bad hall
> data*/
>
>
>
>
>
> //and in the CN interrupt
>
> tempC = PORTC;                                  //grab the pins as quick as
> possible
> tempB = PORTB;                                  //according to stopwatch,
> assembly takes 15 cycles
> HallValue = (0x0007 & (((tempC & 0x0040) >> 4) | ((tempB & 0x0200) >> 8) |
> ((tempB & 0x0100) >> 8)));
>
> CurrentHallSector = SectorTable[HallValue];     //linearize hall reading to
> sector number
>
> if (MotorDirection == CW)                       //Calculate the next sector
> based on current sector and direction
>    {
>    NextHallSector = CurrentHallSector + 1;
>    if (NextHallSector == 7)                    //the numbers wrap around...
>        NextHallSector = 1;
>    }
> else
>    {
>    NextHallSector = CurrentHallSector - 1;
>    if (NextHallSector == 0)
>        NextHallSector = 6;
>    }
>
> P1OVDCON = StateLoTable[NextHallSector];        //Load a value into OVDCOn
> based on next position

>  Hmmmm... Possible I suppose. So I guess my next question is, How would one
> go about creating the hall table?
>
> My procedure was to excite a winding pair at lowish current (by loading one
> of my commutation states into OVDCON and setting 10% DC), waiting for the
> rotor to stabilize and reading out the current hall data.
>
> So, P1OVDCON = StateLoTable[1]; and the hall sensors read 011. Thus the
> third position in my sector table is set to one.
>  P1OVDCON = StateLoTable[2]; and the hall sensors read 010. Thus the second
> position in my sector table is set to two.
> and so on...
>
>
> -Denny

> Hi Denny,
>
> The manufacturer should provide a commutation table - sadly, they
> often do not provide them, but it is definitely worth asking for one.
> If they don't know the commutation table, ask them for a particular
> drive that is compatible with this motor and then look at the
> datasheet for that drive.
>
> You can determine the table by the method that you describe, but the
> result is not as simple as "apply phase combination X, record Hall
> output Y, and then whenever you see hall combination Y, apply X to the
> phases". This is because the goal of commutation is to achieve the
> minimum torque ripple and the maximum torque amplitude. If you lock
> the rotor by applying DC to a phase pair (winding), you have
> positioned the rotor at one of the zero torque positions for that
> particular phase pair. The hall to phase voltage mapping has to
> provide max torque, not zero torque, so for each given hall sensor
> output, you need to drive the phases in the combination which causes
> max torque for that rotor position, not zero torque.
>
> For most BLDC motors, the hall signals (call them A, B, and C) will
> each be in phase with the voltage between one pair of motor leads. If
> you can spin the motor externally while using a scope to look at both
> hall signals and back-EMF waveform, then you should be able to
> re-construct the commutation table. Your commutation should apply
> voltage which is in-phase with the back-EMF voltage.
>
> I know I am not being all that clear here on the exact procedure but
> that's because it is difficult to explain without showing someone in a
> hands-on way and I don't have time at the moment to write out a whole
> procedure here for you :)
>
> Some motors will have a phase offset between hall signals and the
> phase pairs but those type of motors will usually be ones that are
> designed to run in one direction only and at high speed, like hobby
> brushless motors for airplanes. The motivation here is that the phase
> shift in the winding current versus winding voltage due to inductance
> becomes significant at higher speeds and so the optimum commutation
> switch points change with speed. Servomotors like the one you are
> using operate at a wide range of speed and direction and so therefore
> cannot simply shift their hall sensors to optimize for one particular
> speed but rather they optimize around zero speed which gives good
> overall performance. Hobby motors optimize for the speed range where
> they will be generating the most output power and operating most
> frequently.
>
> Sean