Would this code work like I think it would

slackjack

HEy all,

Because I dont have the proper hardware to test my program, I cant be sure if its gonna work like how I see it. Here is the block I am interested in:

up:
DEBUG "Going up...",CR
PAUSE 600
DO
move_UP = 0
IF opto_in = 1 THEN df = df + 1
DO
LOOP UNTIL opto_in = 0
LOOP UNTIL (cf = df)
move_UP = 1
cf = df
GOTO initial

By default opto_in is low. When ever opto_in goes high, the variable df is incremented by 1. But opto_in may remain high for 1 second or so. Because of the fast execution of the loop, df may be incremented multiple times, when I only want one incrementation per high state. So I've added a second DO LOOP in hopes of stopping this. After opto_in is high, df gets incremented, but the second DO LOOP will halt the program from going further until opto_in is back to its default low state.
Would the the code actually do this?

--thank you

slackjack

[noparse][[/noparse]quote]I was trying to adapt your code to my program but don't understand what "cf" is, and not sure if you can do more that one "loop until" per "do" command.


This is part of a code for an elevator project. The "cf" variable is for storing the current floor as this is needed for looping so that the program knows where the position of the elevator.
When I compiled the code, the compiler gave no error about multiple "do" and "loop until". So I'm guessing its alright.

PAR

agfa said...
...·and not sure if you can do more that one "loop until" per "do" command.

There are _two_ "do"s in his code, one for each "loop until..."

PAR

PAR

slackjack said...

up:
DEBUG "Going up...",CR
PAUSE 600
DO
move_UP = 0
IF opto_in = 1 THEN df = df + 1
DO
LOOP UNTIL opto_in = 0
LOOP UNTIL (cf = df)
move_UP = 1
cf = df
GOTO initial

By default opto_in is low. When ever opto_in goes high, .... After opto_in is high, df gets incremented, but the second DO LOOP will halt the program from going further until opto_in is back to its default low state.

How/where/when is opto_in set high and/or low?

PAR

slackjack

Well opto_in (PIN 3) is hooked up to the output of a transistor (collector). Depending on the base current, the transistor is either high or low. I rely on a transistor that uses an LED to initiate the base current. There is a motor spinning that has the ability block the LED from the base so there is no base current. By default opto_in is low, but when the LED is blocked, opto_in is high. Opto_is high at least once per cycle.

TechnoRobbo

I'm not quite sure if this will help, but, instead of using a Do...Loop that could hang the code on a mechanical failure why don't you use a debouncing code like this. Changing the binary mask if you need more debouncing. This is similar tothe BUTTON command but for inline code.

initialize the Dbounce variable as a nibble -> Dbounce VAR BYTE

up:
DEBUG "Going up...",CR
PAUSE 600
Dbounce =Dbounce << 1 ' shift bits creates debounce delay
Dbounce = Dbounce |opto_in & %11111100· ' binary mask·must be have least 2 or more zeroes on on the right
IF Dbounce = 1 THEN
··· CF= CF+1
ENDIF
GOTO initial

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Have Fun


TR

TechnoRobbo

Sorry,my mistake I flipped the bits. I couldn't figure out what MoveUp did so you may have toput it back in. Here's the corrected code-

up:
DEBUG "Going up...",CR
PAUSE 600
Dbounce =Dbounce << 1 ' shift bits creates debounce delay
Dbounce = Dbounce |opto_in & %00000011 ' binary mask·must be have least 2 or more·ones on on the right
IF Dbounce = 1 THEN
··· CF= CF+1
ENDIF
GOTO initial

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Have Fun


TR

Post Edited (TechnoRobbo) : 11/12/2006 10:14:11 PM GMT

slackjack

Hello TechnoRobbo,

MoveUp is simply a variable name assigned to a pin which is initialized as an output. I noticed that you changed 11111100 to 00000011. Why did you do that? I'm still unsure what the two lines that have the Dbounce variable do. Can you explain?

Back to the original question? Would my original code work?

TechnoRobbo

I think your code can work but it has the potential of hanging up in a loop if there's a failure in the opto_in circuit.

This line keeps shifting the bits tothe left through each cycle:
···· Dbounce =Dbounce << 1 ' shift bits creates debounce delay

This line assigns·the Opto_in Pin tothe first bit of the Dounce byte and masks off the upper bits:
··· Dbounce = Dbounce |opto_in & %00000011 ' binary mask·must be have least 2 or more·ones on on the right


If the Opto_in pin goes high it will only generate a value of 1 during the first cycle see examples below
first loop:
00000001
second loop:
00000011
Third loop and beyond (due to mask):
00000011

If the bit goes low it will never generate a value of 1
first loop:
00000010
second loop and beyond (due to mask):
00000000

Therefore the "IF Debounce=1 THEN·" can only be true the first loop that the Opto_in goes high.

increasing the zeroes in the mask buffers the code from an electrical stutter (bounce - if it were a·button)

Since the code doesn't stay in a loop the rest of the program can·perhaps have·a "fail safe" routine that can catch the failure.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Have Fun


TR

Post Edited (TechnoRobbo) : 11/12/2006 10:55:36 PM GMT

slackjack

Thank you for verifying. Also many thanks for the alternate code!