PiFace input delays

There are multiple PiFace products, so which PiFace device are you using?  

I've used multiple PiFace devices in a previous project that used Python and I don't remember any unnecessary delays when talking to the boards, even from a remote system using a web browser interface.

If possible, post the code you are using either an attachment or pasted in the syntax highlighting option.

It is possible that there is something else going on with your config, so you may want to check the output of the 'dmesg' command to see if there are any conflicts with the PiFace device.

What I have made is a Mirror Prop for a haunted house. It is a two-way mirror in a picture frame, with a flat panel LCD mounted behind the glass. There is a photo eye running a 12VDC relay triggering an input on the PiFace Digital2 IO Board on a Raspberry Pi. It shows a blackscreen JPEG until the eye is read, then it plays an audio clip and a scary image is then displayed on the monitor. The way it is now, if the person doesn't stand in front of the mirror for 2-3 seconds, it does nothing. I've checked the eye and relay, and know they are basically instantaneous in triggering. I will post the PYTHON code below. I don't know this language well, and used stuff I found on various websites for what I have.

import pifacedigitalio

pifacedigitalio.init()

import pygame.sys

pygame.init()

pygame.mixer.init()

pygame.mixer.music.load("/media/inhale_scream2.mp3")

screen=pygame.display.set_mode((1280,1024),pygame.NOFRAME)

images=[]

images.append(pygame.image.load("media/BLACKSCREEN.jpg"))

images.append(pygame.image.load("media/creepyclown3.jpg"))

show=0

screen.blit(images[show], (0,0))

pygame.display.update()

pygame.time.delay(1)

while True:

     input_state0 = pifacedigitalio.digital_read(0)

     input_state3 = pifacedigitalio.digital_read(3)

     input_slate2 = pifacedigitalio.digital_read(2)

     if input_state0==1:

          pifacedigitalio.digital_write(0,1)

          pygame.mixer.music.play()

          show=(show+1) % len(images)

          screen.blit(images[show], (0,0))

          pygame.display.update()

          while pygame.mixer.music.get_busy()==True:

               continue

     else :

          pygame.time.delay(5750)

          show= % len(images)

          screen.blit(images[0], (0,0))

          pygame.display.update()

          pifacedigitalio.digital_write(0,0)

     if input_state2==1:

          pygame.quit()

          sys.exit()

     if input_state3==1:

          pygame.quit()

          sys.exit()

     pygame.time.delay(10)

     show=0

it looks that your while loop is introducing the delay. the code is not interface driven.

You are running the loop and polling the status of the input. my bet is that reading the 3 input states is very fast. the rest of your loop, including 5 second delay,waiting for the audio mixer to complete, drawing, ..., hold up the loop.

What would be a better way of polling the input for state change, and react when it goes high? I used this code from someone else's project for making a slideshow, and the input was to trigger the next image, then found the audio file info elsewhere and put it all together. I figured this wasn't the best way of doing this, but I'm not a programmer by trade, just an electronic tech/industrial electrician. This is hobby for me, building haunted house props. I usually use small PLCs or Arduinos, but I wanted to be able to work with video, so thought the Raspberry Pi would be good for this, but there's a lot to getting it ready to even function, especially when adding the PiFace.

When you post code, please use the ">>" insert symbol at the top of the edit screen, select Syntax Highlighting and select the language you are posting, or just Plan if unsure. 

Uh, so you are not that familiar with Python and found some code on the web and just pasted it into your code hoping it works without issue and then blame the PiFace Digital2 IO Board? Okay.

Looking at the code, in the else block you have "show= % len(images)".   Are you missing a (show+{num}) before the "%" cause I am not sure what it does otherwise since you are running the modulo on nothing.

Also, your "pygame.time.delay(5750)" delay is like a 5sec delay, so if there is no input on pin 0 of the PiFace the loop will pause for 5 seconds before it does anything else.  Is that expected?

I think this is the peace of code that makes everything slow (if the image loading is fast and nhale_scream2.mp3 is a short sound):

pygame.time.delay(5750)

As long as the button is not pressed, the program repeats pausing for 5+ seconds.

(I think your code may also miss some key presses because you have to have the luck to have the key down just when the pifacedigitalio.digital_read() is executed)

In your state ==0 part, Instead of pausing, you could use a variable that is increased every loop (declare the variable in the start of your code, update it with one just after your delay(10) at the loop end)..

Remove the delay(5750) line

I expect that a loop without your 5750 delay line would take approx 10 ms, because there's a loop delay of that time at the end.

Once that  variable has reached 575 or more, execute the code in the else part, and reset the counter to 0.

Also reset the counter to 0 in the part where the state == 1. That will reset the timer after someone pressed a button.

I'm not blaming anything, I just wanted help in removing the delay which caused it to not work consistently. People don't stand at a mirror for very long in a haunted house, so many miss the scare. I think the pygame.time.delay(5750) was intended to be a delay between the scare and the system being ready for the next event trigger, (at least that's what I want it to do), so it won't keep running if the eye is triggered again right away.

I'm not blaming anything, I just wanted help in removing the delay which caused it to not work consistently. People don't stand at a mirror for very long in a haunted house, so many miss the scare. I think the pygame.time.delay(5750) was intended to be a delay between the scare and the system being ready for the next event trigger, (at least that's what I want it to do), so it won't keep running if the eye is triggered again right away.