1 Continuous MCPWM at a time

[barneyfrance]

The only problem i'm now having is with my reverse sequence...
I tried with select case and oldstate and it does not work I don't know why

If the only thing controling the sequence of the commutation is the desired direction then there's no reason to keep track of the previous state because then it doesn't matter.

Yep that's what I thought so for the reverse sequence I tried something like this :
If encoderstate = 62 Then
'switches ON/off
endif
IF encoderstate = 63 Then
'switchesON/off
endif
IF encoderstate = 62 Then
'switches on/off
endif


The probem is that the switches (for a same encoder state (62)) should not be the same. When I tried the above code, it is kind of like it's doing the both If..Endif at the same time which is not good.
Any more ideas ?, there's gotta be a way...
Thank you in advance..

[HenrikOlsson]

Hi,
No, I'm sorry, I've misunderstood this. You need to keep track of the old state since 62 are on both sides of 63 there's no way for a simple IF-THEN to determine if the if next commutation "step" should be that equaling encoderstate 60 or 63.

In the forward direction that is not a problem since the same value isn't on both sides of any other value but in reverse it is so you'll have to keep track of the previous state as well.

I must admit though that I still don't understand how this thing work. Let's say the motor is turning forward and then stops at "step" 7, ie EncoderState is 7. It now reverses direction, what is the next expected encoderstate? I don't see 7 in the expected sequence when moving in reverse but it has to be there since, no?

I can't see how the actual numbers can change depending on the direction of rotation. I would guess that if going forward gives you this sequence:

0, 1, 3, 7, 15, 31, 63, 62, 60, 56, 48, 32

the reverse sequence would be:

32, 48, 56, 60, 62, 63, 31, 15, 7, 3, 1, 0

But you're saying it's not. Can you explain, show a diagram or a photo of how this thing works. How can the sensors give out the value 7 in one direction but not in the other? I mean, at that specific rotation angle some sensors are activated and others are not giving the binary value of 7, I can't see how it can be different depending on in which direction the shaft got there.

I'm clearly missing something here but untill I understand how this thing really works there's no use in trying to come up with a solution.

/Henrik.

[barneyfrance]

you're right lol... I'm sorry that you've waisted your time with me, I also figured this out yesterday :s I waisted my time too.
My last problem is to be able to switch frequency only if my pot = 0 (duty cycle = 0) so that the motor won't stall..
Any ideas ?

[HenrikOlsson]

You mean switch direction when the pot is 0, right?

GOSUB GetADC
 
If PotValue = 0 THEN
  Direction = PortB.7  ' Or whatever
ENDIF

This won't touch the Direction variable if PotValue is >0.

[barneyfrance]

Hello,

With your help, my motor works perfectly fine. Thank you very much.
However, a weird thing happens every 1/2 mins, it seems that my chip reset by itself. Does anyone know where does that come from ? I have a 6.7k resistance on MCLR is that not enough ?

[HenrikOlsson]

Almost impossible to say although noise on the MCLR pin or supply lines are likely causes. There's a register, I believe it's called RCON (check the datasheet), which you can check to see what caused the reset. There will be various bits set depending on if it was a brown-out reset etc - that might help.

Make sure you have sufficient decoupling as close to the supply pins as possible and make sure you coonect ALL the supply pins - not just one pair.

/Henrik.

[Jumper]

Add some capacitors to the MCLR. Maybe 0.1 uF and 2.2uF and hopefully you can still program the pic. If you have a long trace on the pcb to the programming connector you can also try to add the capacitors close to the connector since that trace will act like an antenna.