PDA

View Full Version : 1 Continuous MCPWM at a time



barneyfrance
- 11th July 2011, 20:09
Hello guys,

I am currently trying to use the MCPWM on my pic18F4331 (20 MHZ external oscillator)
I am trying to control a brushless dc motor with 12 IGBT's so I need 12 outputs. Amongst these 6 outputs, I want to use the PMW0 to PMW5 one at a time. Because I get inputs from my encoder, telling me when to switch which PWM.

I have been searching the forum, and it helped me a lot, I have used the code described here : http://www.picbasic.co.uk/forum/showthread.php?t=7095&p=43820#post43820
I'm looking over the datasheet, i'm still pretty new at this but, i can't figure out how to use one pwm at a time. (I only need one duty cycle for all of them)

Thank you very much in advance for your answers..

mark_s
- 11th July 2011, 20:33
Barney,

Have a look at this thread. One of the guys discovered that the "ovdcond" register can be used to switch
the pwms on and off.

http://www.picbasic.co.uk/forum/showthread.php?t=12522&highlight=ovdcond

barneyfrance
- 12th July 2011, 02:15
Hello mark_s,

Thank you for your quick reply, it is exactly what I was looking for.

I Know need to adjust my pwm duty cycle with a potentiometer 1K on AN0.
Is 1K enough ?

Can someone help me to understand the process with that A/D module ?
I'm not sure i'm understanding quite well the process.

barneyfrance
- 12th July 2011, 19:40
Hello, it's me again.
I went through the registers in the datasheet and used the example of Bruce here : http://www.picbasic.co.uk/forum/showthread.php?t=6768
I tried to understand and apply it to my case, but it's not doing anything my duty cycle ?

Thank you in advance for your help, it'd be really appreciated


Duty VAR Word

TRISA = %11111111
TRISB = %00000000
TRISC = %00000010
TRISD = %00000000
TRISE = %00000000

' Analog setup
' Single shot, single channel, Group A is taken and converted, A/D converter enabled
ADCON0 = %00000001

'
ADCON1 = %00010000

ADCON2 = %11001111 ' Right justified, 24 Tad, Frc
ADCON3 = 0 ' Disable all triggers
ADCHS = 0 ' Channel select for AN0
ANSEL0 = %00000001 ' AN0 analog input, rest digital



PORTB = 0
PORTD = 0 ' clear port


PTCON0=$00 'timebase
PTPERL=$A0 ' $01A0 = 12kHz
PTPERH=$01

PWMCON0 = %01001111
PWMCON1=%00000001
DTCON=$00
OVDCOND = %00000000
OVDCONS = %00000000 'PORT PINS

PDC0L=$00
PDC0H=$00
PDC1L=$00
PDC1H=$00
PDC2L=$00
PDC2H=$00

PDC0L = Duty.LowByte
PDC0H = Duty.HighByte

PDC1L = Duty.LowByte
PDC1H = Duty.HighByte

PDC2L = Duty.LowByte
PDC2H = Duty.HighByte


PTCON1=%10000000



GoTo Main

Main:
ADCON0.1 = 1 ' Start the conversion
While ADCON0.1=1 ' Wait for it to complete
Wend

Duty.HighByte = ADRESH ' get result from AN0
Duty.LowByte = ADRESL ' Increment buffer pointer

OVDCOND = %00000010 'PWM on PWM1

Bruce
- 12th July 2011, 20:55
Is this all of your code? If it is, can you explain what you "think" should be happening, and how you know it's not?

Folks here love to help, but what you're showing here doesn't indicate even a modest amount of homework..;o)

cncmachineguy
- 12th July 2011, 21:29
If it is the entire code, maybe looping back to main would help? Otherwise I agree with Bruce.

Bruce
- 13th July 2011, 11:42
Something like this might help so it doesn't drop-off the end and restart from the beginning. It also loads the new duty-cycle values.



PTCON1=%10000000
OVDCOND = %00000010 'PWM on PWM1

Main:
ADCON0.1 = 1 ' Start the conversion
While ADCON0.1=1 ' Wait for it to complete
Wend
Duty.HighByte = ADRESH ' get result from AN0
Duty.LowByte = ADRESL ' Increment buffer pointer
PDC0L = Duty.LowByte
PDC0H = Duty.HighByte
PDC1L = Duty.LowByte
PDC1H = Duty.HighByte
PDC2L = Duty.LowByte
PDC2H = Duty.HighByte
GoTo Main
It's untested, but should work. I didn't check the A/D part, but it looks ok at a glance.

You might want to insert a PAUSE before the GOTO Main?

barneyfrance
- 13th July 2011, 14:02
Hello,

Thank you very much for your answers guys ! For you that code is nothing but for me it is what I wrote after spending hours on the forum and on the datasheet... trying to understand what i'm writing. So I am sorry if you feel that way..
Bruce, thank you for putting in the right order my code, it is working now but somehow when my potentiometer is at its maximum i'm only able to have 50% duty cycle ? Where does this come from ?

Bruce
- 13th July 2011, 16:26
We're just messing with you when you miss something simple. Don't take any of it personal..;)

When you forget to loop back to Main it runs off the end and loops back to the start. But that wasn't the only problem.

PCPWM on these can be a bit intimidating. Give this a shot.


DEFINE OSC 20

Duty VAR Word
TRISA = %11111111
TRISB = %00000000
TRISC = %00000010
TRISD = %00000000
TRISE = %00000000

' Analog setup
' Single shot, single channel, Group A is taken and converted, A/D converter enabled

ADCON0 = %00000001
ADCON1 = %00010000
ADCON2 = %11001111 ' Right justified, 24 Tad, Frc
ADCON3 = 0 ' Disable all triggers
ADCHS = 0 ' Channel select for AN0
ANSEL0 = %00000001 ' AN0 analog input, rest digital

PORTB = 0
PORTD = 0 ' clear port
PTCON0 = 0 ' timebase
PTPERL = 0 ' ~19.4kHz at 20MHz
PTPERH = 1
PWMCON0 = %01001111
PWMCON1 = %00000001
DTCON = 0
OVDCOND = 0
OVDCONS = 0
PTCON0 = 0
PTCON1 = %10000000
OVDCOND = %00000010 'PWM on PWM1

Main:
ADCON0.1 = 1 ' Start the conversion
While ADCON0.1=1 ' Wait for it to complete
Wend
Duty.HighByte = ADRESH ' get result from AN0
Duty.LowByte = ADRESL ' Increment buffer pointer
PDC0L = Duty.LowByte
PDC0H = Duty.HighByte
PDC1L = Duty.LowByte
PDC1H = Duty.HighByte
PDC2L = Duty.LowByte
PDC2H = Duty.HighByte
PAUSE 500
GoTo Main
All-in-all I would say you're doing pretty darn good just getting started with one of the hardest to use/understand PIC types in this range....:eek:

barneyfrance
- 13th July 2011, 17:09
Hi bruce,

Thank you for your quick reply, and yes apparently this chip is pretty complicated but well I do not mind ;) it's challenging.
I have tried your code, changing the register "PTPERH" seems to do changing, I now have around 66% duty cycle.

Now i'm looking at the datasheet of the pic page 187, and I am wondering one thing and maybe it has to do something with my duty cycle problem.
Figure 18-11 shows the duty cycle comparison. Now PTMR(H and L) has 14 bits with 2 reserved for a clock and PDC(H and L) register has 14 bits as well.
However, tell me if I am wrong but the analog digital converter module only operate on 10 bit. Would this be one of the reason ?

If I could figure this out, it'd be amazing.. Thank you again for your help, I really appreciate !

Bruce
- 13th July 2011, 18:41
You're getting the picture..:)

12kHz you tried before bumped it up over 10-bit resolution. If you're stuck with 10-bit A/D just figure out a frequency with 10-bit resolution.

I think 12kHz worked out to around 10.7-bit, but it was enough to shift it up >10-bits.

barneyfrance
- 13th July 2011, 22:30
My oscillator is 20MHz, and my PWM can't be over 15 KHz frequency.
If I understand this right, (with the formula resolution page 185, equation 18-4), to have a 10 bit resolution to match the analogue/digital module, I probably need to change the value of my oscillator ? (as I don't want a PWM frequency above 14KHz).

Bruce
- 13th July 2011, 23:41
You should be able to divide the frequency by setting it up for Center-Aligned mode. Try my example for 19.455kHz, change PTCON0 = 0 to PTCON0 = 2.

That should give you roughly 9.7kHz, and let you keep the 10-bit resolution.

At least that's my guess after reading the note just above table 18-2. Seems like it would work just fine, and you can keep the 20MHz osc. If this freq will work for you?

barneyfrance
- 14th July 2011, 00:13
yes, that would work, thank you, I will try that first thing in the morning tomorrow :) I will, of course, let you know.
Thanks again for the help, really appreciate !

barneyfrance
- 14th July 2011, 13:23
I have tried this, and it is still at 68% duty cycle maximum... I also tried with a 4MHz oscillator and PTCON0 = 0, and it gives also 68%.
What are we missing ? :(
Getting desesperate as I thought this would work but it seems it's not really the problem.. is it ?

Bruce
- 14th July 2011, 14:09
Have you checked the output of your potentiometer? It works just as expected for me from 0 to 100% duty-cycle on an 18F4431 @ 20MHz.

Try the attached without making any changes.

5761

barneyfrance
- 14th July 2011, 15:05
Thanks it is working now, I made a huge mistake that I am so ashamed to make you waste your time with me. I am testing everything on a breadboard and my potentiometer was still connected to a resistance somewhere... I feel silly. Well at least it is working.

I am grateful for your time and your patience.

I am now getting started with my commutation sequence. Thank you again !
Even if this pic is complicated, I'm starting to see how powerful it is.

Bruce
- 14th July 2011, 20:41
I made a huge mistake
Been there - done that - just spank yourself, take notes & move on...;)

barneyfrance
- 18th July 2011, 19:32
Been there - done that - just spank yourself, take notes & move on...;)
I did :)

Hi again !

I would like your opinions guys in terms of "state of the art" way to write a picbasic pro program
I am getting inputs from an encoder, I have 12 positions possible, therefore 12 values. here is an example of my code for 2 values. I was wondering if the use of "Case" would be a better idea, that way if I decide to turn off my "switch" my program stops immediatly and is not finishing its loop before seeing that the switch's value changed.


encoderstate1 var Byte
duty var Word

Main:
encoderstate1 = PORTA
If switch = 1 Then


If encoderstate = 0 Then
GoSub GetADC
GoSub SetPWM
OVDCOND = %00100010 'Q4 (PWM5) and Q10 (PWM1)
PORTC = %00000011 'Q1 and Q7 ON
EndIf
If encoderstate1 = 1 Then
GoSub GetADC
GoSub SetPWM
OVDCOND = %00000110
PORTC = %00001100

EndIf

GoTo Main


Getadc is my subroutine for my pot and pwm to adjust the duty cycle regarding the value of the pot.

Suggestions ?

HenrikOlsson
- 18th July 2011, 22:46
Hi,
Sure, Select-Case is an option. It's "cleaner" but does result in slightly larger code than multiple IF-THEN statements. But if you're not short on space go ahead.

Another option might be to use BRANCH.

Also, perhaps you can move the GOSUB GetADC and GOSUB SetPWM to right after the If Switch=1 Then statement? That will save you a couple of bytes of program space and since, if I'm not mistaken, all twelve different encoder states calls both those routines you might as well do before evaluting the encoder value.

/Henrik.

barneyfrance
- 19th July 2011, 00:14
Hello Henrik,

I tried the code below with case and it does not work :(

encoderstate1 var Byte
duty var Word

Main:
encoderstate1 = PORTA


If switch = 1 Then

Select case encoderstate1

Case 0
GoSub GetADC
GoSub SetPWM
OVDCOND = %00100010 'Q4 (PWM5) and Q10 (PWM1)
PORTC = %00000011 'Q1 and Q7 ON

Case 1
GoSub GetADC
GoSub SetPWM
OVDCOND = %00000110
PORTC = %00001100
End Select

EndIf

GoTo Main

What am I doing wrong here ???? in my 2 cases, portA = 0 and portA = 1 in the other one (PORTA.0=1). The first code given with IF... THEN works but not this one ?


PS : I'll try tomorrow morning (don't have access to my pic right now) to put the subroutines just once as well as that "Branch"

HenrikOlsson
- 19th July 2011, 07:18
Hello,
I can't really see any problem with it.... What does doesn't work mean in this case, what does it do?

The only think I can think of is if you have anything else connected to PortA so that the actual value assigned to EncoderState1 isn't 0 even when the encoder is in the zero-position. But since it works with the IF-THEN version it can't be that (?).

Do you have a serial connection setup? If so you can HSEROUT some debug information which will make it easier to figure out what's going on. If not perhaps you could blink a LED the same number of times as the value that gets assigned to EncoderState1, just to see what's going on.

/Henrik.

barneyfrance
- 19th July 2011, 11:25
Hello,

Thank you for your reply,
The IF...THEN code still works (thanks for the tip putting just the subroutines at the top of main).

Do you have a serial connection setup? If so you can HSEROUT some debug information which will make it easier to figure out what's going on.
I am only using a PICkit 2 programmer. ?!



If not perhaps you could blink a LED the same number of times as the value that gets assigned to EncoderState1, just to see what's going on.

What do you mean ??


This morning I've tried a different code :


Main:
encoderstate1 = PORTA

Select encoderstate1
Case %000000
GoSub GetADC
GoSub SetPWM
OVDCOND = %00100010 'Q4 (PWM5) and Q10 (PWM1)
PORTC = %00000011 'Q1 and Q7 ON
Case %000001
GoSub GetADC
GoSub SetPWM
OVDCOND = %00100010 'Q4 (PWM5) and Q10 (PWM1)
PORTC = %00000011 'Q1 and Q7 ON
Case Else
PORTC = 0
OVDCOND = 0
EndSelect

In case 0, it is doing what it should do, now if I'm trying to give the value of 1 (I have a switch on portA.0, that is all !!) it jumps to case else, it means that it does not see the value 1 ??? Why not ? it is working with IF... THEN...
Moreover, after switching my switch and giving the value 1 to portA.0, 4seconds after, it acts like if the value on portA.0 was 0... ???

AHHH sometimes those pics know how to make you crazy, doesn't they ?
Thanks for the help. Very much appreciated :)

HenrikOlsson
- 19th July 2011, 12:32
Hi,
It's strange if it really does work with the IF-THEN version. However, as is common on these PICs there are analog inputs on PortA. These normaly needs to be switched to digital in order to work in digital mode (no surprise) and this PIC is no exception. I know you're using the ADC in your GetADC rotuine so I know you have it setup some way or another but are you sure that the pins used for the encoder are setup as digital? (ANSEL0 and ANSEL1 registers)

My thought with the LED was something in the line of:

i VAR BYTE
LED VAR PortB.7

EncoderState1 = PortA

For i = 0 to EncoderState1
High LED
Pause 200
Low LED
Pause 200
NEXT

'Rest of code

Pause 2000 'Just to make a visual "mark" that the loop starts over
Goto Main
This should make the LED blink the number of times equal to the value loaded into EncoderState1. It should help you figure out what's going on.

My money is on the ADC being configured to have its inputs on some of the pins you're trying to use as digital. I don't know why it seems to work with the IF-THEN version though....

If this doesn't help can you post a schematic and the complete code?

/Henrik.

barneyfrance
- 19th July 2011, 13:19
Hello,

I'll try this as soon as I can. I have configured correctly ANSEL0 and ANSEL1 and I'm using my pot on AN6 in order to have all of my inputs encoder on portA.
Now, if this doesn't work i'll post my code and everything.
However is there anyway to switch off my commutation sequence anytime using IF.THEN ? for instance :

main :
If switch=1 then
if encoder=1 then
PWM 1,2

else if encoder = 2
PWM 2,3 ==> I'm turning my Switch "Start/stop" here and I want the program to stop everything here and not wait the end of the loop ?

else if encoder= 3
PWM 4,3
Endif

Endif

Goto Main

barneyfrance
- 19th July 2011, 14:31
The case code now works, now idea what happened... ?
Now I have another question (I'm still interested about the one in the previous post).
When I move my motor forward, my encoder gives 12 different values, however, when I will operate it backward, I have still 12 steps but within these steps there are some similar values.
for example :
0, 32, 48, 56, 60, 62, 63, 62, 60, 56, 48, 32
Now for these 12 steps I need to activate different pins even though some values are the same, from my understanding, I will not be able to use select case / case in that "case" lol ?

HenrikOlsson
- 19th July 2011, 15:09
Hi,
What is this encoder you're using? Is it some kind of resolver with digital output? And why does the seqeunce change (not just reversing) when you reverese the direction of rotation? Or am I missunderstanding?

If knowing the intended direction of rotation isn't enough then I currently don't see how it's going to be done since the sequence is the same in both directions.

Are you sure you don't have a second output on that encoder? This looks like a low resolution sine-wave to me which leads me to belive what you have is some kind of SIN/COS resolver with a digital interface. (?) Do you have a datasheet you can link to?

The MCPWM module on the '4431 has dedicated faultinputs which can be setup to shut down the PWM. Either until the fault-input is cleared (good for cycle-by-cycle current limit) or untill a fault reset of the module is performed. Perhaps you could use that to stop the commutation. Otherwise you'll simply need to check the state of the switch as often as you need to - or use an external interrupt.

/Henrik.

barneyfrance
- 21st July 2011, 10:15
Hello,

Sorry for the late reply, it is nothing complicated like that. it is just 6 optical switches mounted on the rotor therefore 6 inputs on my pic that gives me a truth table. (in function of the inputs ON or OFF, I know what phases of the motor I need to turn ON/OFF).
For the clockwise rotation, it goes like this :
000000
000001
000011
000111
001111
011111
111111
111110
111100
etc

and for anti clockwise it goes like this :
000000
100000
110000
111000
111100
111110
111111
111110
111100
etc, as you can see for anti clockwise I am getting the same values but it is not the same phases ON, I need to turn ON (for 360 mechanical degrees, I have 3 times these 12 "cases").



Otherwise you'll simply need to check the state of the switch as often as you need to
Can you give me a simple example ?

Many thanks again for your answers ;)

HenrikOlsson
- 21st July 2011, 13:00
Hi,
OK, if I get this right it should be enough to remember the previous state of the input.

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

If the current state is 15 and the previous state is 7 we're going forward, if the current state is 15 and the previous state is 31 we're going backwards.


EncoderState = PortA
If EncoderState <> OldState THEN ' Don't run commutation code if shaft hasn't moved.

Select Case EncoderState

Case 0
If OldState = 32 THEN 'We're moving FWD
'Code for FWD
ELSE
'Code foe REV
ENDIF

Case 1
If OldState = 0 THEN 'We're moving forward
'Code for FWD
ELSE
'Code for REV
ENDIF

Case 3
If OldState = 1 THEN 'We're moving forward
'Code for FWD
ELSE
'Code for REV
ENDIF

' And so on for all twelve states.

OldState = EncoderState 'Remember current state.
ENDIF

As for the switch, I just mean that if you don't think it's enough to check at the beginning of the loop you'll have to check it as often as you think is neccessary, for example in each case statement. Personally I think that it's enought to check it one time in the main loop since only one of the Case blocks will get executed anyway. But I may have missed something.

barneyfrance
- 21st July 2011, 19:15
mhhh that sounds great !!! this will work I think ! I have a switch that tells me to go forward or backward I can add it to this !
yes effectively the switch at the top of the loop in "case code" is enough.
However when I start my pic it won't move, will it ? because no previous state ? or am I missing something ?

barneyfrance
- 21st July 2011, 19:20
also, if my motor is moving forward and then suddendly i turn on switch to go backward, that won't be beautiful... I need to add some sort of security that allow to start the commutation code only if my pwm is 0 or something like that, no ?

HenrikOlsson
- 21st July 2011, 19:55
That's correct, since the shaft can be in any location on powerup you need to establish the proper encoderstate at bootup and then initialise OldState to the apropriate value depending on the desired direction of rotation - before entering the Main routine. You could do it with something like this but please doublecheck the sequence here, I'm not sure I've got it right.

'Get index of current encoderstate, Temp will be 0-11
Lookdown EncoderState, [0,1,3,7,15,31,63,62,60,56,48,32],Temp

'Now initialise OldState to correct value depending on desired direction of rotation.
If DesiredDirection = Forward THEN
Lookup Temp, [32,0,1,3,7,15,31,63,62,60,56,48], OldState
ELSE
LookUp Temp, [1,0,7,15,31,63,62,60,56,48,32], OldState
EndIf

barneyfrance
- 22nd July 2011, 00:14
thx i'll keep try that in the morning =)

barneyfrance
- 22nd July 2011, 16:50
actually this can't work because my reverse values are :
0, 32, 48, 60, 62, 63, 62, 60, 56, 48, 32....
I'm getting desesperate :( with these switches...

barneyfrance
- 22nd July 2011, 17:00
fwd values : 0, 1, 3, 7, 15, 31, 63, 62, 60, 56, 48, 32
reverse values : 0, 32, 48, 60, 62, 63, 62, 60, 56, 48, 32

I have 2 truth tables with switches to turn on/off for these values.
Now i have a pot and a switch start/stop and a switch fwd/reverse..
Now we should not be able to change the sequence commutation if the pot is not 0 so I did a little code like this :



Direction VAR bit
direction = 0

Main:

encoderstate1 = PORTA

GoSub GetADC

If ADRESH = 0 Then 'value of the pot stored in ADRESH
If ADRESL = 0 Then ''value of the pot stored in ADRESH
direction = PORTE.1 'switch for direction
EndIf
EndIf

if encoderstate = 0 then
'switches turn ON/OFF
elseif encoderstate = 1 then
'switches turn on OFF
elseif encoderstate = 3 then
..... etc
endif

goto main


I'm getting desesperate to put all this together with my switches :(
and my reverse sequence with if then. ifelse isn't working properly (need to have oldstate stored like you told me, Olson no ?)

HenrikOlsson
- 23rd July 2011, 10:37
I'm sorry, I can't keep up with you here.

Did the Select-case version not work? Is that the reason why you're now using IF and ELSEIF? And did keeping track of the previous state thru the OldState variable not work? Or why did you skip that.

If I got the sequence wrong did you try to correct it and see if the aproach I took would work or not or did you just abandon that idea because I had the reverese sequence wrong?

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.

/Henrik.

barneyfrance
- 24th July 2011, 10:09
hello, no I did try your great ideas, the case work for the forward direction but as my elseif code the case code for the forward does not work because the second half of the commutation is the same as the previous one. So in that case I think I need to have the old case. I will keep trying experiments, thank you for your time and ideas ;)

barneyfrance
- 24th July 2011, 11:15
Do you have a good software for schematics ??

HenrikOlsson
- 24th July 2011, 13:34
Hi,
Personally I use EAGLE from CADSoft, other popular packages are DipTrace and KiCAD but there are many many other in various priceranges. TARGET, OrCAD, Protel, DesignSpark, EDWIN, AutoTrax are a couple that springs to mind.

barneyfrance
- 24th July 2011, 16:38
thanks eagle seems pretty nice, we have orCAD at the university but I really don't like it...
I'm gonna try this eagle thing

barneyfrance
- 25th July 2011, 11:21
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
- 25th July 2011, 12:42
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
- 26th July 2011, 12:22
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
- 26th July 2011, 13:51
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
- 4th August 2011, 17:34
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
- 5th August 2011, 09:13
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
- 5th August 2011, 10:14
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.