Decelerating motor from 100% duty cycle drives enable pin of H bridge to 0

[Cantafford]

Hello again,

I have finished a project in which I control a DC motor using a PIC18f2550 and a L293D integrated H bridge.
The L293D truth table is this:

This is my schematic:

As I'm sure it's obvious the project is supposed to work this way:
-I press one of the buttons to select direction: CW or CW(RB0 or RB1).
-then I select a speed from Rb2-Rb5 in ratios of 1/4(25%, 50%, 75%, 100%). The CCP1 of the PIC is connected to the enable pin of the L293D to send the PWM signal.

The program is supposed to let me select a direction then the speed in real time. And it does. With a little problem which I can't figure out. When I try to deccelerate from 100% speed(aka when I try to lower the duty cycle from 100% to any of 25%, 50% or 75%) for some odd reason my enable pin is driven to 0 so my motor stops. From there I can accelerate back to 100% but I cannot decelerate again without the motor stopping.




when I try to deccelerate(select a different speed other than 4) it goes to that specific while of the selected speed but the enable pin(RC2 is driven to 0) so the access to the L293D bridge is stopped. Maybe it is a coding issue(altough it does return to the while of the selected speed) or maybe it's something related to the falling edge of the signal. Beats me. Please help me correct this issue.

P.S.: Yes I know I've made a lot of threads today. This is the last one, I promise, sorry for the spam.

 

[fezder]

Does enable pin stay in 0-state, or just ''dips'' there? I don't have experience much in coding, more in hardware....

 

[fezder]

And, does it do that thing with say 75% duty also? or 25/50?

 

[Cantafford]

When I try decelerating from 100% to any other lower speed the enable pins goes to 0 and stays there stopping the motor(and the only thing I can do is accelerate it to 100% again). Any other combination works fine.
Here, I made a video:
**broken link removed**

 

[fezder]

I'm not sure will it mean anything, but will it do that on other direction also?

 

[Cantafford]

Yes it has the same problem on both directions.

 

[fezder]

Well thankfully it's not complicated code as even I can understand it (well, important bits) but so far haven't fount THE reason.

 

[fezder]

Hmm, what about if you modify code so 75% is maxinum? to see whether it does same thing when deceralating? I'm just guessing here.

 

[ronsimpson]

Hmm, what about if you modify code so 75% is maxinum?

Or 99%. That's almost 100%

 

[fezder]

True!. I was wondering whether it is that last while() whatever is set to be there, dunno if it would make any sense...
Well, whatever value is last, there is always last while()

 

[Cantafford]

I will try that when I get home. But I still don't understand this. Direction d = still 1 after the program exists the while with the s = 4 so it should return to the main while(the one nesting the other whiles) . Yeah a lot of whiles in that statement but you get what I mean. The program should return to this:

while(d==1) // if direction is clockwise

and go on all over again.

 

[Cantafford]

Both of the " s==4" while loops take the CCP speed above PR2
Setting the CC1CON to 0b00001100 will make it work as expected.

Credits to Ian Rogers for identifying the issue.

 

[Ian Rogers]

I should have asked you for the project... I had to re-create it in ISIS...

There is also a CCP / PWM autoshut down register... I'm still trying to fathom it out!! That's what I originally though the problem was!!