what's wrong 16F877A simple code?

Printable View

- 27th October 2009, 14:57
Macgman2000

what's wrong 16F877A simple code?

Hello all,

I have been looking at this code for a couple of days. No matter how I rewrite it I get the same problem. This is what it is supposed to do....

sequence of button activations:

1). start button, goes low when pressed, I have 10K pullup on port.
2). Limit reached leaf switch, goes low when activated, 10K pullup on port.
3). optical phototransistor, 40K on collector, IR emitter cranking out a strong signal no issues on scope. Set up as basic breakbeam. works flawlessly.

What happens is the start button activation works, the limit leaf switch activation works, then it gets hosed on the optical switch. Nothing happens, in fact it looks like it vectors back to a part of the code that it should never revisit again except on power up. When I remove the leaf switch code, everything works including the optical switch. This is very confusing....HELP!!!

Code is below.

INCLUDE "Modedefs.Bas"
@ device pic16F877A, HS_OSC, LVP_OFF, WDT_OFF
PROTECT_OFF

DEFINE OSC 20

;set ports to output
TRISA = %00001111
TRISB = %00000111
TRISC = %00000000
TRISD = %00000000

; analog portA direction
ADCON1 = 7
CMCON = 7

;constants
brake Con %00000011
stmot con %00000000
runmot con %00000001

;variables
timeout var byte

;initialization
portc = stmot

checkOn:
if portb.0 = 1 then
goto checkon
else
portc = runmot
endif

main:
gosub checkLeaf
gosub checkopt
goto main

checkleaf:
if portb.1 = 0 then
portc = brake
pause 500
portc = stmot
else
goto checkleaf
endif
return

checkopt:
if portb.2 = 1 then
portc = runmot
else
goto checkopt
endif
return

end
- 27th October 2009, 15:57
Acetronics2

Harware issue ??? forgotten action ???

Hi,

1) If your opto- transistor emitter has no load to ground , no chance it works properly.

add to that you are supposed to have a HIGH level @ input when there's nothing between photodiode and and photo transistor.

2)

Code:

checkopt: if portb.2 = 1 then portc = runmot else goto checkopt endif return

This is an endless loop that DOESN'T CHANGES ANYTHING !!!! if you reach required position ...

I do not think you wanted that ... ( stopping motor is doing something ... don't you think ??? so ... )

Alain
- 27th October 2009, 17:03
Macgman2000

thanks for the feedback. Faulty ground on optical switch is not the problem. Like I said I can take out a portion of the code and the optical switch works well..... I rewrote the code yet again and see the same issue. I realize it is not elegant, and it should dwell in each loop until the correct cadence....but what I see is it vectors outside of the loop and enables the start switch which is deliberated left out of the normal loop....it is only used once upon start up to kick start the checkleaf and checkopt loops. see below.

Code:

@ device pic16F877A, HS_OSC, LVP_OFF, WDT_OFF ; @ Device pic16F877A, HS_OSC, BOD_OFF, PWRT_ON, WDT_ON, PROTECT_OFF DEFINE OSC 20 ;set ports to output TRISA = %00000000 TRISB = %00000111 TRISC = %00000000 TRISD = %00000000 ; analog portA direction ADCON1 = 7 CMCON = 7 ;constants brake Con %00000011 stmot con %00000000 runmot con %00000001 ;variables timeout var byte ;initialization portc = stmot HomeStart: if portb.0 = 0 then portc = runmot goto checkleaf endif goto homestart checkleaf: if portb.1 = 0 then portc = brake pause 500 portc = stmot goto checkopt endif goto checkleaf checkopt: if portb.2 = 1 then portc = runmot goto checkleaf endif goto checkopt
- 28th October 2009, 03:11
Darrel Taylor

Would you like some Marinara to go with that spaghetti? :D

Welll, here's my interpretation of your program.

HomeStart:
  Wait for button press on RB0
  When pressed, start motor

checkleaf:
  Wait for Leaf switch on RB1
  When triggered, apply brake for .5 sec. then stop motor

checkopt:
  Wait for Optical interrupter on RB2
  When triggered, start motor, and go back to checkleaf:
  Never ending loop
<br>
- 28th October 2009, 14:17
Macgman2000

Yes, not elegant at all but it should run. The never ending loop is supposed to tell me whether it got to this point and it should dwell there.
It was supposed to go back originally to checkleaf but that seemed not to work either. The end result is still the same, It would get to the never ending loop and fall out going back to homestart which should never happen since I trap it in the lower loops.

Just wondering if somehow it is being vectored back to the beginning of the code or what. I turn off analog channels, comps, interrupts are not used, watchdog is off....

I guess I am having one of those days.

Nick
- 28th October 2009, 14:33
Darrel Taylor

Why do you think it's somehow jumping where it shouldn't?
Are you running it on a simulator?

The only indication of what the program is doing is a motor running.
And according to your program it's going to be doing a LOT of running, with no way to stop it.
- 28th October 2009, 15:04
Macgman2000

I know it jumps out and goes back to homestart because that button when pressed retriggers the sequence of loops over again when it shouldn't. If I am stuck in an endless loop at checkleaf, homestart shouldn't do anything after the first time it falls through the code upon startup correct?

As far as motor running, the motor runs only when homestart is triggered, it goes through homestart (1 time upon start up of MCU), then when I hit checkleaf it works correctly (since it sits in a loop)....but after that the motor is off at checkopt and does not sit in that loop. The motor stays off until I hit homestart again (which should never happen except on power up).

I may start from scratch....I don't know. Any reference code to get started would help since I seem to be stuck in a loop mentally :D

Nick
- 28th October 2009, 15:45
Darrel Taylor

Question ...

Are the Brake and the Motor supposed to run at the same time?

;constants
brake Con %00000011
stmot con %00000000
runmot con %00000001

The only way I can see that your symptoms can happen is if the PIC gets reset at the point where it applies the brake.
Possibly from over current (Brake+Motor).

The code itself will not do that.
<br>
- 28th October 2009, 15:56
Macgman2000

Good point...I think you are correct. After I wrote my previous post, I was thinking about possibly a brown out condition where it would come up in reset mode. I will check it out and post back.

Thanks!
Nick
- 28th October 2009, 16:01
Macgman2000

Darrel you are correct!! The brake was hosing the MCU....even though I have 1K resistors...strange I will need to dive more into the hardware.

Thanks for your help!!!

Nick
- 28th October 2009, 18:42
Darrel Taylor

Quote:

Originally Posted by Macgman2000

The brake was hosing the MCU....

Hmmm, must be one of those Canadian brakes (Hoser). :D
<br>
- 30th October 2009, 01:11
comwarrior

Quote:

Originally Posted by Macgman2000

checkleaf:
if portb.1 = 0 then
portc = brake
pause 500
portc = stmot
else
goto checkleaf
endif
return

checkopt:
if portb.2 = 1 then
portc = runmot
else
goto checkopt
endif
return

end

Actually, I was wondering if the GOTO's befor the ENDIF's were causing the problem, something like a stack overflow... then again i havn't looked to see how PBP codes the IF statements...