Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
Forum Thread Details
  • Replies 2 replies
  • Subscribers 706 subscribers
  • Views 517 views
  • Users 0 members are here
Related

PiFace not reliably detecting external button press

e14 Contributor

Hi

 

First project with the Pi/PiFace. The intent is  to switch 12V solenoids on an air valve with drives a large cylinder.  The solenoids pull 4.8W at full load (and I measured the current draw at 370mA)). The power supply is rated at 2000mA for both 5V and 12V. The solenoids are connected as +12V -> solenoid -> PiFace central terminal then PiFace lower terminal -> ground. The external switches are simple push to close arranged with a common to the +5V and then each one to one of the inputs on the PiFace. There are various LEDs as well - each with a 270 ohm resister between the LED and the PiFace output terminal. That's about as well as I can describe it  without a diagram image

 

The problems seem to be around reliably detecting the button press and, possibly, the relay current draw 'resetting' the system. I immediately thought of a short circuit for that last one - but I can find no evidence of one. Also - the relay seems to 'lock' shut - keeping the power running continuously through the solenoid (which I fear has been damaged before i realised what was happening). I've (hopefully) attached the code - it's taken fairly directly from the latest github docs - and all the s/w was updated yesterday (June 2). The comments are in there as I was trying to trace where the breakdown was - and it seems that the input key events are simply not being detected or are  doubles. Key bounce? If so - how do we avoid that with the pifacedigitalio libraries. Or do we use something else?

 

Comments and thoughts welcome

 

Thanks

Derek the confused

Attachments:
t1.py.zip
Parents

  • I guess you've learned the hard way that it's a good idea to use an LED for testing, and only connect real world devices after you have confidence that the software works.

     

    It could very easily be a problem with contact bounce.  I'm not familiar with the PiFace software, so I don't know if they have a debounce option.  I believe contact bounce occurs on the order of milliseconds -- you can observe your own switch if you have a digital 'scope.  My favorite scheme to debounce is to sample the switch every millisecond or so and use the on/off value to increment or decrement a counter which saturates at 0 and (say) 20.  The bouncing causes a series of increments and decrements which keep the count value low, and the counter only counts to its full value once it has reliable contact.

     

    Or, you can simply check the switch 20 msec after it changes value and see if it's still at the new value.

     

    If PiFace has inputs with hysteresis you can use an RC network with your switch.

Reply

  • I guess you've learned the hard way that it's a good idea to use an LED for testing, and only connect real world devices after you have confidence that the software works.

     

    It could very easily be a problem with contact bounce.  I'm not familiar with the PiFace software, so I don't know if they have a debounce option.  I believe contact bounce occurs on the order of milliseconds -- you can observe your own switch if you have a digital 'scope.  My favorite scheme to debounce is to sample the switch every millisecond or so and use the on/off value to increment or decrement a counter which saturates at 0 and (say) 20.  The bouncing causes a series of increments and decrements which keep the count value low, and the counter only counts to its full value once it has reliable contact.

     

    Or, you can simply check the switch 20 msec after it changes value and see if it's still at the new value.

     

    If PiFace has inputs with hysteresis you can use an RC network with your switch.

Children
  • in reply to johnbeetem

    >I guess you've learned the hard way

     

    Actually - what's *really* painful is that I know that.  Notch up another failure due to being in a hurry. image

     

    So - using your idea I added this method to check what was happening

     

    def debounce(self,pin):

         state = 0

         for i in range(0,10):

              state += p.digital_read(pin)

              sleep(0.01)

         print ("debounce " + str(state))

         return state

     

    Then the callback thread checks for verification (>8 or <2) before initiating anything. Turns out that one of the relay control input switches is hosed. Sigh. A classic 10c part taking out a $80 one.