Erratic program operation in simulator, while similar program works fine???

D

dmaxben

Member
Im stumped on this one...the program is for a little Picaxe 14m2-driven controller that controls the transmission torque converter on an engine dyno. (not in a vehicle, just on a stationary dynomometer stand/room)

It works perfectly, one button to lock the converter, one to unlock, and then a third button activates an "automatic" mode that automatically locks the converter when throttle position gets to 100% (measured with the Picaxe ADC).

However I wanted to add the capability of "on the fly" fine-tuning of how "harsh" the converter lockup is (IE, how fast the Picaxe ramps up the PWM from 0% to 98%), without having to reprogram the Picaxe chip with my computer.

So I taught myself how to use the EEPROM/read/write functions of the Picaxe. I also wrote two different "harshness" (PWM ramp up rates) routines in the program. So when you press the "LOCK" button, it will jump to 1 of the 2 "harshness" routines. What determines which routine the Picaxe will follow is set by my "program" feature.

What I have setup is so when you turn power on to the Picaxe while holding the "LOCK" button (Pin C.5), the Picaxe will read this and enter a "program" mode...it will signal that the programming mode has been entered by flashing a blue LED and a red LED alternately in rapid fashion...then after the LED's stop flashing, you can press either the "LOCK" button to select the "aggressive" PWM ramp-up, or the "UNLOCK" button to select the "soft" PWM ramp-up. Once you have pressed either button, the red LED or the blue LED will light up for a second confirming your choice, and then it will write that "choice" to the EEPROM, and then return back to the start of the program and function as normal. So basically now each time you power it down and power it back up again, it will have that "choice" (harsh or soft PWM ramp-up) saved in EEPROM, it will read the value, and then use that saved setting from now on so whenever you press the "LOCK" or "UNLOCK" button, it will use either the harsh or soft PWM ramp-up rate.....and it will keep/use that ramp-up rate until you manually enter the programming mode again and change the setting.

The problem is that in the simulator, when you start the program with the button held-down, it starts acting totally erratically. IE, Pin B.0 starts going high for absolutely NO reason...Pin B.1 and Pin B.3 also start turning on and off when they want to, etc.. You can clearly see the program scrolling through in the simulator, and the Output Pins on the Picaxe clearly are doing different things than what the program is actually saying.

I copied and pasted the first portion of the program into a new file, and it seems to work fine??????? I cant possibly see how something further down in the "long/full" version of the program is messing with something, because it starts acting all wacky before it even gets to the rest of the program.

I know my code is clunky and totally amateur/could be made better in so many ways, but it worked perfectly (up until I tried to add this clever 'self-program' utility into the program) and now I cant figure out why or what is causing the Picaxe to act erratically. Ive attached a video so you can see the two similar programs operating...and how the [long] program doesnt even follow itself properly/logically.

thanks for any advice/help on the issue.

Ben

http://www.youtube.com/watch?v=Vwzi_Si6-nI
 
hippy

hippy

Ex-Staff (retired)
Probably best to post your full code then people can see what is happening for themselves; I couldn't tell what commands were executing in the video.
 
D

dmaxben

Member
Here is the first one, if you dont press/hold PinC.5 on startup (to enter the "program" mode), everything works fine. For some reason it start acting erratically (if you press C.5 at startup), and it will turn B.0 on and off, then 'sometimes' it will start outputting PWM on B.3 randomly....which is odd because NOWHERE in the entire program do I even reference "PWM on B.3". All of my PWM as used in the program is output on B.2. Then other times it will turn on/off B.1 and B.2 before the program even tells it to????

Figuring that maybe, because C.5 is serial-in, maybe thats causing something odd...so I changed that pin assignment to C.1, then C.2, and it still acted weird??? Ive also tried removing the PAUSE before the disconnect, and tried adding in a delay after the disconnect, so that way I can power it up, wait half a second for the program to issue the "disconnect" command, and THEN press C.1...still acts erratically.

Code: 
boot:
pause 15
disconnect
pause 25
if pinc.5=1 then program
pause 15
goto start

program:
pause 15
high b.1
pause 125
low b.1
high b.3
pause 125
low b.3
high b.1
pause 125
low b.1
high b.3
pause 125
low b.3
high b.1
pause 125
low b.1
high b.3
pause 125
low b.3
goto program1

program1:
wait 1
if pinc.2=1 then high b.3 endif
if pinc.2=1 then write 0,1 endif
if pinc.5=1 then high b.1 endif
if pinc.5=1 then write 0,2 endif
wait 1
low b.3, b.1
wait 1
goto boot

start:
pause 15
read 0,b3
low b.3
low b.0
low b.1
PWMOUT b.2,0,0
if pinc.5=1 then start
if pinc.2=1 then start
if pinc.1=1 then auto
goto start2

auto:
pause 20
readadc c.4, b0
high b.3
if b0 < 150 and pinb.5=0 then preapply
if pinc.1=0 then start
goto auto

preapply:
pause 500
goto apply

start2:
pause 75
if pinc.5=1 then unlock
if pinc.2=1 then apply
if pinc.1=1 then auto
goto start2

apply:
high b.0
low b.1
low b.3
pause 75
if b3 = 1 then harshapply
if b3 = 2 then softapply
pwmout pwmdiv64, B.2, 155, 312
pause 250
if pinc.1=1 then autolock
goto lock

harshapply:
pwmout pwmdiv64, B.2, 155, 312
pause 50
if pinc.1=1 then autolock
goto lock

softapply:
pwmout pwmdiv64, B.2, 155, 156
pause 200
pwmout pwmdiv64, B.2, 155, 312
pause 125
pwmout pwmdiv4, B.2, 249, 750
pause 75
pwmout pwmdiv64, B.2, 155, 562
pause 50
goto lock

autolock:
pwmout pwmdiv64, B.2, 155, 612
readadc c.4, b0
pause 75
if b0 > 200 then start
if pinc.5=1 then autounlock
if pinc.1=0 then start
if pinb.5=1 then start
goto autolock

lock:
pwmout pwmdiv64, B.2, 155, 612
pause 75
if pinc.2=1 then start
if pinc.5=1 then unlock
goto lock

autounlock:
high b.0
low b.3
pause 20
pwmout b.2,0,0
high b.1
pause 75
if pinc.5=1 then autounlock
goto autounlock2

autounlock2:
high b.0
low b.3
pause 25
pwmout b.2,0,0
high b.1
readadc c.4, b0
pause 50
if pinc.2=1 then apply
if pinc.1=0 then start
if b0 > 195 then start
pause 25
if pinc.5=1 then start
goto autounlock2

unlock:
high b.0
pwmout b.2,0,0
high b.1
pause 75
if pinc.5=1 then unlock
goto unlock2

unlock2:
high b.0
pause 75
if pinc.1=1 then start
if pinc.2=1 then apply
if pinc.5=1 then start
goto unlock2
 
D

dmaxben

Member
And here is the "abbreviated" code just to try to debug the thing...this portion works fine...I can hold C.1 (or whatever pin) on startup and it enters the "program" mode successfully.

What is strange though, is that it is identical to the first portion of the other [erratically-acting] program...so until the Picaxe gets to the 53'rd line, why would it act any differently if there was some random "error" in my coding starting at line 53/54 and continuing towards the bottom????

Code: 
boot:
pause 15
disconnect
pause 25
if pinc.5=1 then program
pause 15
goto start

program:
pause 15
high b.1
pause 125
low b.1
high b.3
pause 125
low b.3
high b.1
pause 125
low b.1
high b.3
pause 125
low b.3
high b.1
pause 125
low b.1
high b.3
pause 125
low b.3
goto program1

program1:
wait 1
if pinc.2=1 then high b.3 endif
if pinc.2=1 then write 0,1 endif
if pinc.5=1 then high b.1 endif
if pinc.5=1 then write 0,2 endif
wait 1
low b.3, b.1
wait 1
goto boot

start:
pause 15
read 0,b3
low b.3
low b.0
low b.1
PWMOUT b.2,0,0
if pinc.5=1 then start
if pinc.2=1 then start
if pinc.1=1 then program1
goto start
 
T

tiscando

Senior Member
Start1, start2, start 3 and start 4 mark the start of several threads in a multi-tasking PICAXE program. The start2 label in your program is what's causing the erratic behaviour, as a second execution path starts there in the same program. (if there is no start1, the program simply starts at the top as normal)
 
W

westaust55

Moderator
tiscando said:
Start1, start2, start 3 and start 4 mark the start of several threads in a multi-tasking PICAXE program. The start2 label in your program is what's causing the erratic behaviour, as a second execution path starts there in the same program. (if there is no start1, the program simply starts at the top as normal)
Click to expand...
Close, for the M2 parts when using multi-threading the first label is by default Start0: whether or not actually typed into the program listing.
For the 08M2 and 18M2 the last labels is Start3: whereas for the 14M2 and 20M2 the start labels go up to Start7:
 
D

dmaxben

Member
ah-ha!!!! Yes!!

Thank-you so much everyone for the help. I was literally sitting here for 3 hours screaming at the computer screen, running the simulator, retyping all the code by hand, and changing EVERYTHING around.......except the label names, go figure. :D

Ive actually never really bothered to learn about/look into how the multi-tasking stuff works in the new M2 chips...I guess I kinda stumbled upon it by accident here. I cant wait to actually intentionally use it in a future 'widget' to do some really cool stuff.

again, really appreciate it

Ben
 
You must log in or register to reply here.
Top