Not reading I/O Pins consistently

hmlittle59

Hello All,
Hate to start a new thread but, got no comments on my schematic post at the "Bottom" of my "KitchenAid" post.....That was just for (GP), but now I've run into a problem.

:See Code and Attached Schematic for review and comments.

When I (SHORT) across the (EOLR) End of Line Resistor the voltage changes as its suppose to at specific locations (U3.1 Pin 3) into the OP-Amp. The reading displayed are what I got on my O'Scope. OK fine, everything has been tweaked in and seems to be working as planned. Got the new PCB's in, built up and with one correction all is swell.

BUT.....

After testing over and over and over again trying to make the circuit fail (shorting across the EOLR), something finally did fail. I was using a pair of tweezers to create the short, then put a momentary switch in place to simulate the same effect. Both test are to created the same effect like when the relay activates and by-passes the (EOLR).
NOTE: I'm doing this at a much more rapid rate then a relay would...meaning, I'm tapping very very quickly trying to make it fail (hoping it would not) for reliability purposes. I was hoping the program would catch the shorting effect and branch to an error. But sometimes the program would not catch the short even though the I/O pins in the code matched and the "Debug Terminal" shows them matching. But the code would still fall through on occasions (randomly).
I added "DEBUG" code to display variables and kept the code within a very tight loop. I also added the "DO/LOOP" to correct any failures like this and it worked. But I need find the cause of the problem (if any) and fix it in Hardware/Software.

My other thought:(Button Command)
As with the Button Command that can eliminate the Bounce effect, my shorting very rapidly may create this same Bounce problem and should not happen within normal operation with a normal relay and if it does.....The DO/LOOP (3 - 5) times can help to eliminate it before executing other code.

Note: 2 I/O pins mean 4 states to read.. (High/High..Low/Low..High/Low..Low/High). The "Debug" shows the proper I/O pin reading but the code is sometime not being executed(IF/THEN).....(Head scratchier)

Can the code be moving to fast to execute properly??????

Thanks for any help.

idx = 0  : work = 0                     ' Reset Counter
   GET 7,down                           '
      IF down = 0 THEN ProPane          ' "0" = Not Turned 'ON' from Main Menu...Branch
'                                       '
DO                                      ' Start of Loop to ensure correct READING of I/O Pin
AUXIO  :                                '
'                                       '
 IF (CO_Detect = 1) AND (CO_Detect1 = 0) THEN ProPane 'No_Error  
 IF (CO_Detect = 0) AND (CO_Detect1 = 1) THEN work = 23:GOTO Start_Error 
'                                       '
 IF (CO_Detect = 1) AND (CO_Detect1 = 1) THEN work = 20:GOTO Start_Error 
 IF (CO_Detect = 0) AND (CO_Detect1 = 0) THEN work = 22:GOTO Start_Error 
'                                       '
 idx = idx + 1                          ' Increment counter

DEBUG "NO Wrk1= ",DEC3 work,CR,CR
DEBUG "IDX = ",DEC3 idx,CR,CR
LOOP UNTIL Idx = 3                 ' Program should never get here but if it does, LOOPBACK
DEBUG "IDX2= ",DEC3 idx,CR,CR
                                       ' and Check again....Max. of 3 time then program CRASH
work = 31                               ' "Program or Controller Crash
RUN 7                                   ' Code needs be set up in SLOT 7
'                                       '

hmlittle59

Hello All,

Still need feedback on my first functional in-circuit (Op-Amp/Voltage Divider) circuit. The first 2 that I designed were horrible (to much voltage swing and current draw).
Thanks ahead for any and all feedback/comments/insight.

NOW:
I think that I figured out what was happening.
Remember...I said that I was Testing more "RAPIDLY" then how a "Normal" relay response would be (constantly ON/Closed or constantly OFF/Open) for instance under normal conditions. But I had already added code to do a catch-all in case none of the 4 conditions of (High/High, Low/Low, High/Low, Low/High) were matched. Not knowing that it would happen. Well it did. kinda... And I think it was because of the way I was "TESTING" for that type of error. Shorting across the "EOLR" (Normal) to simulate an Alarm Condition...."RAPIDLY"....multiple times.
My PBASIC code may have already pass that testing point (IF/THEN) conditional statement and was never evaluated. But my catch-all routine, now showed this as an error and that.......STUMPED ME. I just was not expecting this code to ever execute.
Adding the (DO/LOOP...3 times if needed) has caught this situation every time out of the last 100 test (shorting).

I guess that's why we test!!!

After typing out the issues above and then talking to Parallax Tech. Support. It was a few hours later that a "Light Bulb" went off in my head, that it may be as simple as the PBASIC CODE already passing that testing point...OOOP's.
I am still fine tuning the DO/LOOP using the "DEBUG TERMINAL".

FeedBack,FeedBack,FeedBack please.

erco

A tight sampling loop works infinitely faster than you can flick a switch (tweezers) or a relay can operate. If you're getting "failures" (as you call misreads) I suspect that it is because of your DEBUG command, which brings your tight loop execution to a grinding halt. A DEBUG command uses glacially slow serial comms to display your info on-screen. DEBUG is certainly helpful during program development, but your program will run much faster (and give different results in some cases) without it. Try it without any DEBUGs and perhaps use an LED or two as an output indicator. HIGH, LOW, and TOGGLE commands execute very quickly.

To see for yourself, write yourself a short for/next routine to loop 1000 times. Compare that loop's execution time with and without an embedded DEBUG statement. Obviously sending more DEBUG characters (more variables and/or longer strings) gobbles up more time.

hmlittle59

Thanks Erco,

I will set up an LED loop also to ensure to myself that I'm not having any failures...along with a Piezo. Thanks

Please have a look at the attached schematic and give "ANY" feed back. So far it's held up without any drift or problems.

Thanks again

erco

Piezo is good, I like these 12-cent "active beepers" even better: http://www.ebay.com/itm/10pcs-NEW-5V-Active-Buzzer-Magnetic-Long-Continous-Beep-Tone-2300-500Hz-U-/272274641121

These send a high pitch beep on 5V, you can power them from a Stamp pin. No Freqout or anything. Just insert a TOGGLE command in a tight loop and you can hear how fast it's going without slowing down like a DEBUG command does. That's exactly the sound here, the beeper chirps every other time the sensor is sampled.