Re: [Dorset] Python Function Appears to be Entered Twice

[Terry Coles]

On Monday, 27 March 2017 00:10:06 BST Ralph Corderoy wrote:
> > No I don't think I tried it because I asked for a clarification and
> > I'm not sure you answered.
> 
> I did, but there were a lot of emails.
> https://www.mail-archive.com/dorset@mailman.lug.org.uk/msg07415.html

It's a fair cop.  I think I did try it, but then got distracted by debouncing 
circuits, etc and forgot to respond.

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Ralph Corderoy]

Hi Terry,

> No I don't think I tried it because I asked for a clarification and
> I'm not sure you answered.

I did, but there were a lot of emails.
https://www.mail-archive.com/dorset@mailman.lug.org.uk/msg07415.html

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Ralph Corderoy]

Hi Terry,

> http://www.hadrian-way.co.uk/Misc/scope.GIF

I interpret that as you holding the switch on for 0.328 s?

> Presumably the way that [the GPIO library] deals with thresholds is
> suceptible to noise and since, of necessity, we have to have lots of
> wires in our system, it's picking up noise, especially when the signal
> is high. 

It seems to me you are trying to match the observations to your model of
how things work, and since that's a hardware model you are assuming
noise, etc.

I'm doing the same, but my model is software so I think it's the library
continually reading "switch on" from the kernel whenever it returns to
ask it for an event for the duration of you holding the switch.  The
strace used earlier would say.

But, this would have been observable with the old hardware and the cut
down test program that had the substitute callback that just printed the
current time.

Try copying my test script and make the handler do nothing but

prev_now = 0

def handle_event(gpio):
global prev_now
now = time.time()
print now - prev_now
prev_now = now

...

So bounces can reach that simple callback that printed the current
time in your cut-down Python test program?

...

If you never tried it, just say.  It would stop me asking.  :-)

I never did get an answer, and stopped asking anyway.  :-)

If it really was crosstalk causing the kernel to keep saying there are
new events, would you expect a nice even stream of time differences to
appear when you hold the button on?  If the Python is running fast
enough, then I'd expect erratic deltas?

If you disconnect your bells circuit from the Pi and just put in place a
single switch, does the Python still act the same way?  Crosstalk with a
small one-switch less-wire circuit?

If you haven't time to investigate, that's fine.

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Terry Coles]

On Monday, 20 March 2017 17:36:39 GMT Ralph Corderoy wrote:
> > If libraries are getting in the way
> 
> It is.  A Python library, de facto standard for GPIO on the Pi, shipped
> with the Raspberian distro, is pretty hopeless in this area.  When it
> returns to asking the kernel for GPIO changes, it turns that into
> calling the user-supplied Python function.  Asking the kernel may be a
> long time after the change occurred, so one can't debounce in software
> in the callback function, and it doesn't supply the new state, so one
> assumes (hopes) the value alternates between 0 and 1.
> 
> The library has optional debounce logic;  it discards all changes it
> learns of within N ms of the one that triggered the callback, regardless
> of whether it's a transition to 0 or 1.  This means when the callback is
> called again, it can't assume the switch is the opposite state to last
> time depending on the parity of "debounce" transitions.  Reading the
> switch state in the callback is a race because it may be different to
> what triggered the callback, and that change is still in the pipeline to
> trigger the callback again upon return.

Well.  I have some good news and some bad news.  The good news is that my GPIO 
I/Ps are now beautifully clean, with soft edges.  See:

http://www.hadrian-way.co.uk/Misc/scope.GIF

The bad news is that it has made no difference to the behaviour of the 
software whatsoever ;-(

I took out the bouncetime argument completely and the moment I clicked the 
switch I got several 'hits'.  If I held the switch down, the hits just kept 
coming.  I also got the hit on release of the switch.

I put the bouncetime argument back and got it back to the way it was, eg, the 
occasional double hit, but generally OK.  So in desperation, I increased the 
bouncetime to 3000 (ms) and double hits virtually disappeared.  However, when 
I  uncommented the announcements code it was just like it was before I did the 
alternative debounce circuit.

However, if you look at the scope trace above, you will see that there is no 
bounce at all, so although the library seems to be reacting repeatedly when 
the switch is activated and when it is released, at least there should be no 
crosstalk.  I've certainly not seen any.  Presumably the way that it deals 
with thresholds is suceptible to noise and since, of necessity, we have to 
have lots of wires in our system, it's picking up noise, especially when the 
signal is high. 

It is now exactly 7 days to opening for the Model Town, so I am going back to 
Plan B, which is to ditch the announcements.  I've already warned the Manager 
that this might occur and he is comfortable that the staff should be able to 
live with it.

Annoying though.

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Ralph Corderoy]

Hi Tim,

> If libraries are getting in the way

It is.  A Python library, de facto standard for GPIO on the Pi, shipped
with the Raspberian distro, is pretty hopeless in this area.  When it
returns to asking the kernel for GPIO changes, it turns that into
calling the user-supplied Python function.  Asking the kernel may be a
long time after the change occurred, so one can't debounce in software
in the callback function, and it doesn't supply the new state, so one
assumes (hopes) the value alternates between 0 and 1.

The library has optional debounce logic;  it discards all changes it
learns of within N ms of the one that triggered the callback, regardless
of whether it's a transition to 0 or 1.  This means when the callback is
called again, it can't assume the switch is the opposite state to last
time depending on the parity of "debounce" transitions.  Reading the
switch state in the callback is a race because it may be different to
what triggered the callback, and that change is still in the pipeline to
trigger the callback again upon return.

Ditching the library makes the code require more expertise so Terry is
happier removing the possibility of bounce in hardware.

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Terry Coles]

On Monday, 20 March 2017 14:13:43 GMT t...@ls83.eclipse.co.uk wrote:
> I've come into this a bit late I know, but get the impression things are
> getting rather involved to read some switches, although I may have got
> the wrong end of the stick.

It didn't start out that way ;-(

> You don't need hysteresis to read input switches. You just need a pullup
> resistor and the switch to ground, or a pulldown and switch to Vcc. I
> prefer the former, as I don't like Vcc wandering around. In the old days
> of TTL it had to be pullups but that was long ago. Typical CMOS
> thresholds will be close to mid-rail, but it doesn't really matter.

Yes.  That's what I had originally.

> Simplest way to debounce is scan keys every 100ms or so and on every 1
> to 0 transition log a keypress. Typical bounce will be much less than 100ms.

These are physical switches connected to the GPIO pins, not keys (the Pi will 
be running headless).   I was getting around 1 - 2 ms of bounce after I put 
0.1 uF capacitors across the switches (but my scope is a £10 Arduino to USB 
device, so the bandwidth may not be good enough to see what is really 
happening).

> You can get more involved than this if you need auto-repeat, and repeat
> times are comparable to bounce times, but assuming that's not needed
> here, we can forget about all that.

The new circuit should provide almost symmetrical roll-off of the edges of the 
signals when the switches are depressed and released.  any bounces will be 
long gone, but more to the point, the cross-talk should be significantly lower 
and hopefully insufficient to pass the pin threshold voltage.

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Terry Coles]

On Monday, 20 March 2017 14:14:35 GMT Ralph Corderoy wrote:
> > > So bounces can reach that simple callback that printed the current
> > > time in your cut-down Python test program?
> > 
> > Hopefully, once by debouncing circuit is complete, there'll be no
> > bounces that are worth worrying about.
> 
> If you never tried it, just say.  It would stop me asking.  :-)

What I was trying to say was that the bounces that I observed (with the 
capacitors across the switches) were only a few ms, so the new circuit should 
deal with them.  When we were testing the switches, it was the rising edge on 
the switch opening bounce that seemed to be triggering the double-hit, not the 
switch being closed.  That would be well after the Library debounce value of 
300 ms has elapsed, so the next rising edge would always cause a hit (whether 
it is aided and abetted by the software or not).

> > March 19th was last year.  It's 1st April this year.
> 
> Perhaps you or Clive can have some success in getting it fixed then.

The Home page has it right, it's just on the Visitor Information Page that it 
is wrong.  The Manager has been told (verbally) and he says that he will fix 
it.

> > As far as I know the Pi deals with DST anyway, but I'm unsure if that
> > applies when an external Real Time Clock is in use.  I don't see why
> > it shouldn't.
> 
> I expect the RTC will be UTC.  Linux works on that too.  Layers of
> software above handle UTC and localtime.  Here, I pretend to be in Paris
> so there's a winter difference to show.

I'll check before I deploy.  I don't remember having to do anything to 
apscheduler to get the time right when I first used it back in August/Sept, so 
I suspect that it just 'deals with it'.

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Ralph Corderoy]

Hi Terry,

> > So bounces can reach that simple callback that printed the current
> > time in your cut-down Python test program?
>
> Hopefully, once by debouncing circuit is complete, there'll be no
> bounces that are worth worrying about.

If you never tried it, just say.  It would stop me asking.  :-)

> March 19th was last year.  It's 1st April this year.

Perhaps you or Clive can have some success in getting it fixed then.
:-)

> As far as I know the Pi deals with DST anyway, but I'm unsure if that
> applies when an external Real Time Clock is in use.  I don't see why
> it shouldn't.

I expect the RTC will be UTC.  Linux works on that too.  Layers of
software above handle UTC and localtime.  Here, I pretend to be in Paris
so there's a winter difference to show.

$ TZ=Europe/Paris python2 -c '
> import time; print time.gmtime().tm_hour, time.localtime().tm_hour'
14 15
$

So it depends if you're telling Python you want UTC or local.  That
scheduling library you're using might explain how.

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[tda]

Hi Terry

I've come into this a bit late I know, but get the impression things are 
getting rather involved to read some switches, although I may have got 
the wrong end of the stick.


You don't need hysteresis to read input switches. You just need a pullup 
resistor and the switch to ground, or a pulldown and switch to Vcc. I 
prefer the former, as I don't like Vcc wandering around. In the old days 
of TTL it had to be pullups but that was long ago. Typical CMOS 
thresholds will be close to mid-rail, but it doesn't really matter.


Simplest way to debounce is scan keys every 100ms or so and on every 1 
to 0 transition log a keypress. Typical bounce will be much less than 100ms.


You can get more involved than this if you need auto-repeat, and repeat 
times are comparable to bounce times, but assuming that's not needed 
here, we can forget about all that.


If libraries are getting in the way, then there must be a way of reading 
raw port inputs. Everything is then under your control.


Hope this helps.

Cheers

Tim


On 20/03/17 13:17, Ralph Corderoy wrote:

Hi Terry,

So bounces can reach that simple callback that printed the current time
in your cut-down Python test program?

In the pub, there was mention of daylight savings time.  I can't
remember how the Pi copes, but you said WMT only opens in the summer.
http://www.wimborne-modeltown.com/visitor-information/basic-information/
says

Wimborne Model Town is open between 1 April and March 19th and 29
October daily

(They were emailed a while ago about the two start dates.)

Assuming `29 October' is correct, DST will end in the early hours on
that day.  ;-)

$ for d in 28 29; do date -d "12:00 2017-10-$d"; done
2017-10-28 12:00:00 +0100 Sat
2017-10-29 12:00:00 + Sun
$

Cheers, Ralph.




--
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Terry Coles]

On Monday, 20 March 2017 13:17:55 GMT Ralph Corderoy wrote:
> So bounces can reach that simple callback that printed the current time
> in your cut-down Python test program?

Hopefully, once by debouncing circuit is complete, there'll be no bounces that 
are worth worrying about.

Something else occurred to me regarding the Schmidt Trigger inputs.  I've used 
these device in the past and, as Peter mentions, they sharpen the edges and 
ensure more consistent cross-over times as the signal traverses the threshold.

In this case, I don't care if the GPIO I/P detects the rising edge after 1 us 
or 100 ms; the user is unlikely to notice the extra delay :-)

What I do care about is those super-sharp edges.  I recall that when I worked 
on an early digital test system in the eighties, the maximum speed that the 
pulses could be clocked out was 100 MHz.  The edges were 'fairly rounded' but 
certainly reached the max well before the 10 ns pulse started to go down 
again.  We were having mega cross-talk problems until we did the sums and 
realised that those sharp edges contained harmonics up to 1.2 GHz!  The wires 
in our interface hardware were acting as excellent aerials ;-( 

Funnily enough the clock speed of the Pi is around 1 Ghz 

> Wimborne Model Town is open between 1 April and March 19th and 29
> October daily

March 19th was last year.  It's 1st April this year.

> Assuming `29 October' is correct, DST will end in the early hours on
> that day.  ;-)

Of course.  We designed it that way :-)  If there is anyone still braving the 
elements by then, I doubt that they will worry too much if the clock is an 
hour out.  

As far as I know the Pi deals with DST anyway, but I'm unsure if that applies 
when an external Real Time Clock is in use.  I don't see why it shouldn't.

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Ralph Corderoy]

Hi Terry,

So bounces can reach that simple callback that printed the current time
in your cut-down Python test program?

In the pub, there was mention of daylight savings time.  I can't
remember how the Pi copes, but you said WMT only opens in the summer.
http://www.wimborne-modeltown.com/visitor-information/basic-information/
says

Wimborne Model Town is open between 1 April and March 19th and 29
October daily

(They were emailed a while ago about the two start dates.)

Assuming `29 October' is correct, DST will end in the early hours on
that day.  ;-)

$ for d in 28 29; do date -d "12:00 2017-10-$d"; done
2017-10-28 12:00:00 +0100 Sat
2017-10-29 12:00:00 + Sun
$

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Ralph Corderoy]

[Peter's reply arrived off list;  passing it on.]

> > The 74HC14; 74HCT14 is a hex inverter with Schmitt-trigger inputs.
>
> So that's duplicating the work of the Pi's ill defined BCM2835's
> inputs that I mentioned earlier?  Schmitt-trigger, input hysteresis.
> But with known qualities?

Exactly, using the circuit from Fig 2. as it was intended to be used to
do the whole job in a perfectly defined way, (within the limits of the
tolerances of the components).

> http://elinux.org/RPi_Low-level_peripherals#Interfacing_with_GPIO_pins
> GPIO input hysteresis (Schmitt trigger) can be on or off

Drawing your attention to :-

GPIO input hysteresis (Schmitt trigger) can be on or off, output
slew rate can be fast or limited, and source and sink current is
configurable from 2 mA up to 16 mA. Note that chipset GPIO pins 0-27
are in the same block and these properties are set per block, not
per pin.

This means that ALL the pins 0 - 27 will be set to the same parameters
which may be VERY undesirable if, foe example, you need a high current
output from one pin when you've set th ewhole block to 2 mA.

> 
> http://www.mosaic-industries.com/embedded-systems/microcontroller-projects/raspberry-pi/gpio-pin-electrical-specifications#gpio-pin-circuitry
> To provide noise immunity and prevent chatter on transitions, you
> can configure the input gate to act as a Schmitt trigger, with
> input hysteresis.  With hysteresis there are different threshold
> voltages for rising and falling transitions.  Broadcom doesn't
> specify the degree of hysteresis

...But Table 1 offers some representative values from other
ARM1176-based devices. For a better understanding of how it works,
you can read our more detailed description of input pin hysteresis
for the Freescale 9S12/HCS12 MCU. That description pertains to a
different processor, but the operation is the same.

Table 1 includes

Schmitt trigger input low threshold1.09 - 1.16 V
VT-0.9 V
Schmitt trigger input high threshold   2.24 - 2.74 V
VT+0.90 V

These figures suggest that there is a 1.08 to 1.65 Volts of Hysteresis
window, and since 1.08 Volts is almost 1/3 of the supply voltage, it
range should be plenty enough to make Bounce Free signals.


http://www.mosaic-industries.com/embedded-systems/sbc-single-board-computers/freescale-hcs12-9s12-c-language/instrument-control/interfacing-hardware-digital-io#s12-input-pin-hysteresis

Further, each input/output pin exhibits a little hysteresis provided
by weak pullup and pulldown transistors on the input pins. The
consequence of this hysteresis is that the threshold between a logic
high and a logic low depends on whether the input voltage is rising
or falling.  The following diagram shows the measured threshold for
a single pin.  9S12/HCS12 input pin logic levels showing input
hysteresis

The 0.14V gap between the rising and falling thresholds provides
some noise immunity and prevents chatter on the pin during voltage
transitions. When the input voltage rises from a logic 0 toward a
logic 1 level, the logic 1 is recognized when the voltage rises to
2.582 volts. Negative going noise on the input voltage will not
cause a false transition back to a logic 0 unless it is greater than
0.14V. Likewise, during a logic 1 to logic 0 transition, the input
is protected against positive going noise spikes of less than 0.14V.
The actual threshold values and degree of hysteresis will vary from
pin to pin.

The hysteretic input works together with any source impedance
driving the pin to provide some immunity against noise and to
debounce the input signal.

The circuit that we are now discussing, with the 74HC14 at the end of
the R(esistor)C(apacitor) network should produce stable, bounce free
signals to the RPi.

-- 
Cheers Peter

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Peter Washington]

Hi Terry,

This is the second email that was blocked by the DLUG List for being too
large, here is the link to my Google Drive directory containing the files :-

https://drive.google.com/open?id=0Bz6HCEerir6kY3ZuRE9TVDZfbzA

On 16 March 2017 at 15:33, Terry Coles  wrote:

> On Thursday, 16 March 2017 15:20:15 GMT you wrote:
> > You're correct, my mistake, but this just goes to illustrate why Pull
> Downs
> > are not usually used.
>
> I can make it into a pull-up circuit.  It would mean changing a few wires
> (or
> simply labelling them illogically.


If i were you I'd just wrap some black electrical tape around each end of
the red wires, like electricians do on light switch installations.

> Your diagram looks pretty much like Fig. 2, but you had to adjust it to
> > achieve the Pull *Down* and you didn't include the invertor that provides
> > the Hysteresis that makes it much more robust.
>
> Sorry.  What invertor?  Fig 2 is entirely passive.


The Fig 2. in the paragraph "An RC Debouncer" on page 2 of the attached
document, (blatantly plagiarised from Ganssle :-( ),  is *NOT* entirely
passive; the triangular block on the right hand side with the little circle
on the right hand tip is an Inverter gate from a 74HC14 and this contains
the Hysteresis that we've been discussing, (this chip contains 6
Invertors).  The last paragraph on Page 3 and the first 3 paragraphs on
Page 4 of the attached document explains the use of the Inverting Buffer,
finishing at the paragraph titled "Doing The Math".
I'll attach the datasheet for the 74HC14, *Important Note* : you *MUST* use
the HC version of the 7414, *NOT* the HCT version that requires 5 Volt
power, (the HC is High speed CMOS, the 'T' indicates TTL Voltage levels).


> OK, so definitely I goofed, your circuit will work, BUT, the discharge to
> > the power rail, rather than the ground rail, (normally the ground plane),
> > *could* possibly create impulse spikes on the Power rail and that is why
> > Pull *Downs* are never normally used, because everything is based from
> the
> > Ground rail / plane, not the power rail.
>
> OK.
>

I'm glad you've got that.


> > *But*, to get the full benefit of doing the debounce in hardware you
> *need*
> > to have *something* between the capacitor and the RPi pin, whether that
> is
> > a buffer with Hysteresis, or an RS latch that will prevent incorrect
> > switching of the state.
>
> Fig 2 doesn't have anything and neither do any of the similar circuits on
> the
> interwebs.


See my comments above, regarding "An RC Debouncer" on page 2.

> Just how much space do you have for the Resistor, (Debounce sounds
> better),
> > Board ?
>
> At the moment approx 3 cm x 4 cm.  The new one can grow in the 3 cm
> direction,
> but only by around 2-3 cm.


OK, 5 x 4 cm should be big enough to hold one 14 pin DIL Hex Invertor IC
and the 2 Resistor Packs plus connecting wiring.


> > If you can fit the 14 pin DIL 74HC14 in you will get a much more robust
> > system, it would only consist of 3 components, or 4 if want to add the
> > diode network, (probably not necessary since the recharge time is so
> short).
>
> I'd probably need 5 V for that and I'm using the two O/Ps from the Pi to
> supply the RTC.


I have mentioned elsewhere that the 74HC14 can run from as low as 2.0
Volts, so it will certainly run correctly from 3.3 Volts.

> You could try one of these two Diode Packs :- D83A Diode Pack
> >  diode-network-is
> > olated/dp/SC14191> and D83C Diode Pack
> >  diode-network-is
> > olated/dp/SC14192>, I haven't checked what the differences between them
> are.
>
> Thanks.


having re-considered your RC timing calculations, I wouldn't bother with
the Diode Packs, I just wanted you to know that they *could* be used if
needed.

Finally, the suggested use of the 74HC14 will provide ALL the Debounce that
is required and if the Firmware can find a way to ignore the transition
from switch closed to switch open then you will have solved the entire
problem.

As always, any questions, just ask.

On 19 March 2017 at 13:14, Peter Washington  wrote:

> Hi Terry, Ralph, et al,
>
> Ralph has now kindly sent the 'secret' email to the list, so thanks for
> that.  This email chain will now be kept open to the DLUG mailing list, so
> I've attached Terry's circuit diagram, as well as the text of his 'secret'
> reply to me :-)
>
> Originally, I attached 2 fairly large documents to this email, but the
> DLUG List rejected this email and another one for being too big, so I am
> resending theses emails with with a link to a directory in my Google Drive
> so that anyone with the link can read them.  The first is a slightly edited
> copy of the Ganssle page that we have been discussing, the second is the
> datasheet for the 74HC14.  The editing of the page *only* takes out the
> advertising and most 

Re: [Dorset] Python Function Appears to be Entered Twice

[Ralph Corderoy]

Peter Washington wrote:
> I believe Ralph has offered to introduce my previous narrow
> circulation emails into the mix.

Here's the content.

> Hi Ralph and Terry,
> 
> I've been following the conversation fairly carefully and I've read
> the RasPi and Ganssle "Debounce" links and in my humble opinion you
> have two options :-
> 
> 1. *Firmware Solution* :
> Ask Eben Upton to find out what the Hysteresis values are, (min & max
> values on BOTH thresholds), and use a pair of resistors to force the
> Bias Voltage, (as opposed to Pull Up / Down), to exactly the mid point
> of the hysteresis so that the Pi can do the full debounce in it's
> hardware, then turn Python's Debounce OFF.
> 
> 2. *Hardware Solution* :
> Use the Ganssle Fig 3 configuration with the diode and two resistors
> of near equal value, (just the Diode Volt drop to take into account).
> Modern Resistors are available for around o.05 to 0.10 GBP in pretty
> much ANY value and to within +/- 1%
> 
> I can't confirm whether either of these approaches are guaranteed to
> work because I don't have a setup ready to try it myself, but I know
> enough about electronics to be hopeful.
> 
> Another suggestion for testing is to take your Arduino, and programme
> a "Staircase Waveform Generator" to start at 0.4 Volts and step to 1.0
> Volts in .1 Volt increments, then jump to 1.6 Volts and then step to
> 2.1 Volts.  This can then be used to test the Pi's Hardware Hysteresis
> circuitry.  I would suggest using 1+ second per step into a DVM
> initially, just to make sure that the DAC works as anticipated, then
> reduce the step time to either 100 ms or 500 ms if you want to check
> the Python code Firmware Debounce.
> 
> If Eben Upton can find out what Hysteresis Values are then that is the
> solution to use because you can limit the external hardware to a
> single 100 Ohm series from the switch to the input pin, not forgetting
> to ensure that the Input Voltage for most of the Pi's pins *MUST NEVER
> exceed* 3.6 Volts, (3.3 V would be even better) !!
> 
> I hope this helps , if there is anything unclear just ask !
> 
> -- 
> 
> Cheers Peter

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Terry Coles]

On Thursday, 16 March 2017 12:02:20 GMT Peter Washington wrote:
> As i said before, (in my '*secret*' email), if there are any questions,
> just ask !

Peter,

I just replied to your 'secret' email, with an attachment, so I couldn't have 
sent it to the list anyway.  For the benefit of the list, the attachment shows 
a solution that uses positive logic and pull-downs instead of pull-ups 
(because the current design is wired that way).

It doesn't include the diodes, yet. 

I'm happy for you to respond to the list. 

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Peter Washington]

Hi Terry, Ralph, et al,

First of all I need to apologise for sending information to just Ralph and
Terry, and not including everybody who is involved in this project, so I'm
replying to the "DLUG" mailing list this time, I believe Ralph has offered
to introduce my previous narrow circulation emails into the mix.

Now on to my response to Terry.

> 1. *Firmware Solution* :
> > Ask Eben Upton to find out what the Hysteresis values are, (min & max
> > values on BOTH thresholds), and use a pair of resistors to force the Bias
> > Voltage, (as opposed to Pull Up / Down), to exactly the mid point of the
> > hysteresis so that the Pi can do the full debounce in it's hardware, then
> > turn Python's Debounce OFF.
>
> This will have to go on the back burner for the moment, because I have no
> guarantee that Eben will be able to help and as you acknowledge you can't
> say
> whether it will work.   It is now only just over two weeks to opening day,
> so
> I'd rather go with a solution which has been suggested as working by lots
> of
> people.
>

OK, that makes sense, so I'll ignore the Software Solution for now.


> Besides, I can understand how the hardware solution works :-)
>

Yes, I can sympathise with that.


> > 2. *Hardware Solution* :
> > Use the Ganssle Fig 3 configuration with the diode and two resistors of
> > near equal value, (just the Diode Volt drop to take into account).
> > Modern Resistors are available for around o.05 to 0.10 GBP in pretty much
> > ANY value and to within +/- 1%
>
> Yes.  I'm looking into using a couple of resistor packs to replace the
> discrete resistors that I'm currently using to pull-down each pin.  That
> way I
> can simply build a new board as a drop in replacement for the current one.
>

That would be a good solution, those resistors would be much more tightly
matched than discrete ones, so you will more consistent results.


> Also, the diode isn't necessarily needed, but I can make provision for it
> on
> the board and add one for each channel if needed.


The Diode IS needed if you want to achieve symmetrical timing performance,
and until you can ignore the Kernel / Python code that is firing on both
edges that *could* possibly be a problem, so I would *definitely* layout
space for them, 1N4148's would be entirely satisfactory as long as you're
using resistors above about 10K.

Are you switching to ground through a pull UP resistor ??  If so then as
long as you lose the Firmware Debounce code I would recommend using a 0.1
uF capacitor and calculating your resistors to suit a 20 - 50 ms delay as
suggested by Ganssle.  i would *still* recommend using R2 set to iK, (to
stop drawing too much current from the Pi and possibly damaging it), and R1
as the Timing Resistor, minus the the 1K of R2.  You could use a separate,
(4 parallel Resistors in 8 pins), resistor pack for R2 to keep space down
and have the batter matching performance too.

I think that just about covers it all, good luck .

> Another suggestion for testing is to take your Arduino, and programme a
> > "Staircase Waveform Generator" to start at 0.4 Volts and step to 1.0
> Volts
> > in .1 Volt increments, then jump to 1.6 Volts and then step to 2.1 Volts.
> > This can then be used to test the Pi's Hardware Hysteresis circuitry.  I
> > would suggest using 1+ second per step into a DVM initially, just to make
> > sure that the DAC works as anticipated, then reduce the step time to
> either
> > 100 ms or 500 ms if you want to check the Python code Firmware Debounce.
>
> Unfortunately, my Arduino is a bought in dedicated scope and can't generate
> the signals that you suggest.
>

I have a couple of Arduino boards that I can lend you if that helps, but
since we're ignoring the Software Solution for now that probably isn't
relevant.  However other people on the list as well as yourself might find
the suggestion useful at some weird time in the future.

As i said before, (in my '*secret*' email), if there are any questions,
just ask !

-- 

Cheers Peter
-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Terry Coles]

On Thursday, 16 March 2017 09:41:41 GMT Ralph Corderoy wrote:
> As distinct from them being the "0" that you were expecting to be
> filtered out because you asked for "rising" edges?

Yes.  Exactly.

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Ralph Corderoy]

Hi Terry,

> I think there is some bounce because when I increased the value of
> bouncetime it pretty much disappeared (until this).

As distinct from them being the "0" that you were expecting to be
filtered out because you asked for "rising" edges?

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Terry Coles]

On Thursday, 16 March 2017 09:17:43 GMT Ralph Corderoy wrote:
> Good.  I don't understand the electronic side enough to judge if the
> capacitor circuit he gives is sufficient for this purpose.  Give me
> bits!  :-)

Looking at what I've got and what the RC circuit should really be, I'm coming 
to the conclusion that my circuit debounces the switch when it is released and 
not when it is depressed.

However, that doesn't quite stack up with the behaviour I've seen.  I'm still 
analysing that.

> > I was trying to avoid that and my single cap and pull-down resistors
> > technique seemed to work until this cropped up. 

> The GPIO's software debounce logic is poor and removing the bouncetime
> argument gets it out the way.  It seems there could be finer grade
> debouncing already happening lower down the software/hardware stack and
> that may be sufficient.  If no bounce ever reaches the Python then the
> GPIO library can just call your handler on both 1 and 0 and you can keep
> a tally of which it must be and only act on the 1s.  Ensuring no bounce
> makes it through might already be happening without you modifying your
> existing circuit.  Perhaps now you know why ganssle.com suggest the
> change you can try and recreate that circumstance?

I think there is some bounce because when I increased the value of bouncetime 
it pretty much disappeared (until this).

I've just got in from running errands, so I'll report back when I have a bit 
more of an understanding of what is going on.

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Ralph Corderoy]

Hi Terry,

> > Try copying my test script and make the handler do nothing but
>
> For clarity, you are suggesting that I modify the handler in your
> original script to the one you have just given?

Yes.  It's aiming to execute "quickly" and return allowing you to study
the deltas in seconds to see if bounce ever gets all the way through to
the Python.

> > http://www.ganssle.com/debouncing-pt2.htm
>
> Yes.  I did.

Good.  I don't understand the electronic side enough to judge if the
capacitor circuit he gives is sufficient for this purpose.  Give me
bits!  :-)

> I was trying to avoid that and my single cap and pull-down resistors
> technique seemed to work until this cropped up.

Perhaps it is working well enough, thus the modified event handler above
to find out.  You are doing these tests with the same model of switch as
will be installed?

> Before I embark on that, can you confirm that you are suggesting that
> the debounce software appears to be the cause of this and I could
> avoid it if I could remove the debounce argument and simply improve
> the debouncing in hardware?

The GPIO's software debounce logic is poor and removing the bouncetime
argument gets it out the way.  It seems there could be finer grade
debouncing already happening lower down the software/hardware stack and
that may be sufficient.  If no bounce ever reaches the Python then the
GPIO library can just call your handler on both 1 and 0 and you can keep
a tally of which it must be and only act on the 1s.  Ensuring no bounce
makes it through might already be happening without you modifying your
existing circuit.  Perhaps now you know why ganssle.com suggest the
change you can try and recreate that circumstance?

(If I get time I'll look at the kernel to see how EPOLLET, edge
triggered, affects epoll_wait(2).)

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Ralph Corderoy]

Hi Terry,

> http://www.hadrian-way.co.uk/Misc/strace(2017-03-15).out

Thanks.  Here's the interesting lines from the gpio thread.

39.843544 epoll_wait(5, {{EPOLLIN|EPOLLPRI|EPOLLERR, {u32=4, 
u64=8559147510508027908}}}, 1, -1) = 1
39.843666 lseek(4, 0, SEEK_SET) = 0
39.843769 read(4, "0", 1)   = 1
39.843870 epoll_wait(5, {{EPOLLIN|EPOLLPRI|EPOLLERR, {u32=4, 
u64=8559147510508027908}}}, 1, -1) = 1

You move the switch after 43.619511 - 39.843870 = 3.775641 seconds.

43.619511 lseek(4, 0, SEEK_SET) = 0
43.619745 read(4, "1", 1)   = 1
43.620749 write(1, "enter 22\n", 9) = 9
43.620998 write(1, "exit 22\n", 8) = 8
43.621209 epoll_wait(5, {{EPOLLIN|EPOLLPRI|EPOLLERR, {u32=4, 
u64=8559147510508027908}}}, 1, -1) = 1

Then you let it spring back after 44.641369 - 43.619511 = 1.021858 s.

44.641369 lseek(4, 0, SEEK_SET) = 0
44.641594 read(4, "0", 1)   = 1
44.641966 write(1, "enter 22\n", 9) = 9
44.642211 write(1, "exit 22\n", 8) = 8

And we've a second callback.

> I then ran your invocation of strace and pressed the switch and
> released it fairly quickly; only one hit.  I then repeated it but held
> the switch down for a bit longer; two hits.  This was repeatable.

That matches what I was thinking from looking at the GPIO library's
code.  You remember you said it wasn't debounce, and that your "scope"
saw a bounce of the order of 1 ms?  Yet, when the callback is added, the
library is asked to debounce in software for 300 ms;  a long time for a
bounce.

GPIO.add_event_detect(pin, GPIO.RISING, callback=handle_event,
bouncetime=300)

I think you said this was increased until it was 300 to get rid of the
bounce problems.  But they weren't bounces.  They were the library
calling the callback on the spring-back transition to off.  The 300 ms
managed to blot out most of the "offs" of the quick on-and-off flicks of
the spring-to-off switch.

Hold the switch on so the off occurs outside that 300 ms window and the
callback runs a second time.

Why does a time.sleep() or call()ing and waiting for an MP3 to play show
the same problem on a really quick, sub-300 ms, flick of the switch?
From the earlier email, here's the gpio thread from that first
time.sleep() strace.out.

0.003247  epoll_wait(5, {{EPOLLIN|EPOLLPRI|EPOLLERR, {u32=4, 
u64=8556526274787409924}}}, 1, -1) = 1
0.003437  lseek(4, 0, SEEK_SET) = 0
0.003520  read(4, "0", 1) = 1
0.003620  epoll_wait(5, {{EPOLLIN|EPOLLPRI|EPOLLERR, {u32=4, 
u64=8556526274787409924}}}, 1, -1) = 1
4.915550  lseek(4, 0, SEEK_SET) = 0
4.915790  read(4, "1", 1) = 1
4.916720  write(1, "enter 22\n", 9) = 9
4.916970  select(0, NULL, NULL, NULL, {3, 0}) = 0 (Timeout)
7.920410  write(1, "exit 22\n", 8) = 8
7.920720  epoll_wait(5, {{EPOLLIN|EPOLLPRI|EPOLLERR, {u32=4, 
u64=8556526274787409924}}}, 1, -1) = 1
7.920950  lseek(4, 0, SEEK_SET) = 0
7.921130  read(4, "0", 1) = 1

The GPIO library learns that it can read the "0" from the kernel at
7.92.  It was actually there a lot earlier because you held the switch
at "1" very briefly, but it's only now got around to asking the kernel,
after our time.sleep(3), and the kernel doesn't give an "age" of the
reading.  The GPIO library then measures the gap from when it read the
"1" that triggered the callback, 7.92 - 4.91 = 3.01 s which is well over
300 ms so it's time to callback again.

7.921470  write(1, "enter 22\n", 9) = 9
7.921690  select(0, NULL, NULL, NULL, {3, 0}) = 0 (Timeout)
10.92520  write(1, "exit 22\n", 8) = 8

Here's the essence of the interesting part of the GPIO library from
RPi.GPIO-0.6.3/source/event_gpio.c's poll_thread().  You should see
correlation with the syscalls observed with strace.

 1  epoll_wait(epfd_thread, , 1, -1);
 2  lseek(events.data.fd, 0, SEEK_SET);
 3  read(events.data.fd, , 1);
 4
 5  g = get_gpio_from_value_fd(events.data.fd);
 6  if (g->initial_thread) { // ignore first epoll trigger
 7  g->initial_thread = 0;

When a pin and its callback are registered, a bunch of data is set up
for it, referred to here by `g'.  initial_thread is initialised to 1.
It's used to ignore that "0" that's read from the kernel telling us its
initial state.

 8  } else {
 9  gettimeofday(_timenow, NULL);
10  timenow = tv_timenow.tv_sec*1E6 + tv_timenow.tv_usec;
11  if (g->bouncetime == -666 ||
12  timenow - g->lastcall > g->bouncetime*1000 ||
13  g->lastcall == 0 ||
14  g->lastcall > timenow) {

This is deciding whether to call the callback.  The code uses 666, or
-666 here, as a special value in various places in at least two
contexts.  Sniff.  If line 11 is true then you didn't set a bouncetime
so call the callback.

Otherwise, you did, so if the time difference between now, the point
when we've learnt the new value from the kernel, not the time when that
transition happened, and `lastcall', the time we last called 

Re: [Dorset] Python Function Appears to be Entered Twice

[Terry Coles]

On Wednesday, 15 March 2017 14:28:57 GMT Ralph Corderoy wrote:
> Then the space between `python' and `2.7' in the first line couldn't
> have been there in the version that worked?

I did spot that, but when I changed it, I hadn't made the file executable or 
tried your invocation with 'python2.7'.  Then I made it executable, but had 
forgotten about the space by then

> So that leaves the GPIO library and whether it has code to cope with
> this and why it isn't working.  I expect it's timing.  Can you repeat
> the test but with the time.sleep(3) commented out so the callback runs
> quickly and you are unable to re-create the double-callback problem?
> Meanwhile, I'll look at the library now I know what's happening above
> and below it.  (Might be this evening.)

OK.  See:

http://www.hadrian-way.co.uk/Misc/strace(2017-03-15).out

One thing.  After I had commented out the time.sleep(3) and tried it from 
within IDLE.  I definitely got the double-hit.  I then ran your invocation of 
strace and pressed the switch and released it fairly quickly; only one hit.  I 
then repeated it but held the switch down for a bit longer; two hits.  This 
was repeatable.

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Ralph Corderoy]

Hi Terry,

> > > pi@raspberrypi:~/WMT/Code/Minster_Functions $ sudo strace -tt -o 
> > > strace.out -f
> > > > -e trace=process -e trace=file -e trace=desc \
> > > > changerings3.py
> > >
> > > strace: Can't stat 'changerings3.py': No such file or directory
> >
> > File changerings3.py isn't in the current directory.
>
> But it was.

Ah, OK.  strace was looking for the file in every directory mentioned in
$PATH and when it still wasn't found it complained it couldn't stat(2)
it.

Here's a non-executable Python script in the current directory.  If I
run strace under another strace then we can see the stat()s it attempts.
They match my $PATH.  (The last is just its strace's abuse of stat() on
an empty string.)

$ ls -l env.py
-rw-r--r-- 1 ralph ralph 49 Mar 15 11:14 env.py
$
$ strace -e stat strace env.py
...
stat("/home/ralph/bin/env.py", 0x...)  = -1 ENOENT (No such file or 
directory)
stat("/usr/local/sbin/env.py", 0x...)  = -1 ENOENT (No such file or 
directory)
stat("/usr/local/bin/env.py", 0x...)   = -1 ENOENT (No such file or 
directory)
stat("/usr/bin/env.py", 0x...) = -1 ENOENT (No such file or 
directory)
stat("/usr/bin/mh/env.py", 0x...)  = -1 ENOENT (No such file or 
directory)
stat("", 0x...)= -1 ENOENT (No such file or 
directory)
strace: Can't stat 'env.py': No such file or directory
+++ exited with 1 +++
$

The current directory, `.', isn't in your $PATH, which is good from a
security point of view, but it means you have to run things in the
current directory with ./foo rather than just foo.  (Unless the current
directory happens to be one of the directories in $PATH.)

> > > $ sudo strace -tt -o strace.out -f \
> > >   -e trace=process -e trace=file -e trace=desc \
> > >   ~/WMT/Code/Minster_Functions/changerings3.py
> > > strace: exec: Permission denied
> >
> > Success!  It found the file, but it isn't executable.
>
> Why?  I didn't do anything special to your example and that did
> execute, so why won't mine?  However, after I made my file executable
> strace worked.

Yes, that's why.  The strace immediately above doesn't complain about
stat() failing because the absolute path, one beginning with a /, means
$PATH isn't searched.  stat() is instead called once with the full path
and succeeds.  strace continues with trying to execve(2) the file, but
that fails because the file isn't executable.

> So I say again, how come yours worked when I didn't make it
> executable? !!

Because I said

> > It should run
> > with
> >
> > python2.7 test-callback.py
...
> > Then trigger the problem again under strace.
> >
> > sudo strace -tt -o strace.out -f \
> > -e trace=process -e trace=file -e trace=desc \
> > python2.7 test-callback.py

Both times I specified python2.7.  That's the file that will be sought
using $PATH.  And it is executable.  test-callback.py is a mere string
argument to python2.7 that it happens to open and read.

> > I think even if changerings3.py was made executable, it would still
> > have problems because it's running env(1) with `python 2.7' as
> > arguments, and that would run python(1), which might be version 2 or
> > 3, and pass it `2.7
> > /home/terry/WMT/Code/Minster_Functions/changerings3.py'.  It
> > wouldn't like 2.7 as the script to run.
>
> No.  It did work.

Then the space between `python' and `2.7' in the first line couldn't
have been there in the version that worked?

$ cat env.py
#! /usr/bin/env python 2.7

print 'hello world!'
$
$ python2.7 env.py
hello world!
$
$ chmod +x env.py
$ ./env.py
/usr/bin/env: ‘python 2.7’: No such file or directory
$

> > sudo strace -tt -o strace.out -f \
> > -e trace=process -e trace=file -e trace=desc \
> > python2.7 test-callback.py
>
> See http://www.hadrian-way.co.uk/Misc/strace.out

Thanks, strace is grabbing the things of interest.  Here's the end of
it, skipping Python's start up, to study.  I've changed the thread ID to
be either `main' or `gpio', and adjusted the clock time to be seconds
relative to the first line.

 1  main0.00  write(1, "0.6.3\n", 6) = 6

Our print of GPIO.VERSION.

 2  main0.000145  open("/dev/gpiomem", O_RDWR|O_SYNC) = 3
 3  main0.000381  open("/sys/class/gpio/export", O_WRONLY) = 4
 4  main0.000486  write(4, "22", 2) = 2
 5  main0.001514  close(4) = 0
 6  main0.001657  open("/sys/class/gpio/gpio22/direction", O_WRONLY) = 4
 7  main0.001870  write(4, "in\0", 3) = 3
 8  main0.001978  close(4) = 0
 9  main0.002070  open("/sys/class/gpio/gpio22/value", 
O_RDONLY|O_NONBLOCK) = 4
10  main0.002193  open("/sys/class/gpio/gpio22/edge", O_WRONLY) = 5
11  main0.002336  write(5, "rising\0", 7) = 7
12  main0.002450  close(5) = 0

Telling the kernel what GPIO we're interested in, 22, and how.  

Re: [Dorset] Python Function Appears to be Entered Twice

[Terry Coles]

On Tuesday, 14 March 2017 18:38:37 GMT Ralph Corderoy wrote:
> OK, though I think it's a software problem.  Out of interest, what kind
> of cabling and runs are we talking?

It is plain wire and it was about 40 cm from the switches to the pull-downs 
board (via a D-Type).  Then there is about 4 to 5 cm between the resistors and 
the GPIO pins.  The capacitors (0,1 uF) are connected across each switch 
contact.

> > pi@raspberrypi:~/WMT/Code/Minster_Functions $ sudo strace -tt -o
> > strace.out -f \> 
> > > -e trace=process -e trace=file -e trace=desc \
> > > 
> > > changerings3.py
> > 
> > strace: Can't stat 'changerings3.py': No such file or directory
> 
> File changerings3.py isn't in the current directory.

But it was.  The path in the prompt matches the one below that was found, but 
wouldn't execute.  Also, I used tab completion to confirm that I'd got the 
right filename.

> Success!  It found the file, but it isn't executable.

Why?  I didn't do anything special to your example and that did execute, so 
why won't mine?  However, after I made my file executable strace worked.

So I say again, how come yours worked when I didn't make it executable? !!

(I've never made any of my Python files executable because I usually launch 
them from within IDLE or by executing:

python myfile.py

(This may well have changed by the time I get round to deploying this software 
to launch at boot-up.)
 
> I think even if changerings3.py was made executable, it would still have
> problems because it's running env(1) with `python 2.7' as arguments, and
> that would run python(1), which might be version 2 or 3, and pass it
> `2.7 /home/terry/WMT/Code/Minster_Functions/changerings3.py'.  It
> wouldn't like 2.7 as the script to run.

No.  It did work.
 
> sudo strace -tt -o strace.out -f \
> -e trace=process -e trace=file -e trace=desc \
> python2.7 test-callback.py

See http://www.hadrian-way.co.uk/Misc/strace.out

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Ralph Corderoy]

Hi Terry,

> so I only got onto all this again this afternoon.

No need to explain.  I'm used to email threads having days between
posts.  :-)

> Clive has shortened the cabling considerably and we've removed the
> outer plastic sheath and teased out the wires on all of the cable runs
> to reduce the cross-talk to a minimum.

OK, though I think it's a software problem.  Out of interest, what kind
of cabling and runs are we talking?

> /usr/lib/python3/dist-packages/RPi.GPIO-0.6.3.egg-info
> This ties in with the version in the Raspbian Package Manager.

And the latest tar file of source I could find on the SourceForge site.

> I've put the complete script, cut-down as you suggested, in:
>   http://www.hadrian-way.co.uk/Misc/changerings3.py.txt

Very handy, thanks.

> > sudo strace -tt -o strace.out -f \
> > -e trace=process -e trace=file -e trace=desc \
> > your-python-script.py
>
> pi@raspberrypi:~/WMT/Code/Minster_Functions $ sudo strace -tt -o 
> strace.out -f \
> > -e trace=process -e trace=file -e trace=desc \
> > changerings3.py 
> strace: Can't stat 'changerings3.py': No such file or directory

File changerings3.py isn't in the current directory.

> pi@raspberrypi:~/WMT/Code/Minster_Functions $ sudo strace -tt -o 
> strace.out -f -e trace=process -e trace=file -e trace=desc changerings3.py
> strace: Can't stat 'changerings3.py': No such file or directory

Ditto.  (Though you have removed the backslashes correctly.)

> pi@raspberrypi:~/WMT/Code/Minster_Functions $ sudo strace -tt -o 
> strace.out -f -e trace=process -e trace=file -e trace=desc 
> ~/WMT/Code/Minster_Functions/changerings3.py
> strace: exec: Permission denied

Success!  It found the file, but it isn't executable.

> pi@raspberrypi:~/WMT/Code/Minster_Functions $ sudo strace -tt -o 
> strace.out -f \
> > -e trace=process -e trace=file -e trace=desc \changerings3.py 
> strace: Can't stat 'changerings3.py': No such file or directory

Now you're guessing.  :-)  That still looks for file
`./changerings3.py'.

I think even if changerings3.py was made executable, it would still have
problems because it's running env(1) with `python 2.7' as arguments, and
that would run python(1), which might be version 2 or 3, and pass it
`2.7 /home/terry/WMT/Code/Minster_Functions/changerings3.py'.  It
wouldn't like 2.7 as the script to run.

And when the script is run, it sets up the GPIO requirements and then
exits.  There's nothing to make the main thread hang around whilst your
dalliance with the GPIO thread occurs.

Here's your test script with even more lines deleted.  It should run
with

python2.7 test-callback.py

without needing to make it executable.  Hopefully, you can exhibit the
problem with it.  Then trigger the problem again under strace.

sudo strace -tt -o strace.out -f \
-e trace=process -e trace=file -e trace=desc \
python2.7 test-callback.py

 8<  cut here 
#! /usr/bin/env python2.7

import time
import RPi.GPIO as GPIO

def main():
print GPIO.VERSION

GPIO.setmode(GPIO.BCM) # Pin numbering scheme.
for pin in (22,):
GPIO.setup(pin, GPIO.IN)
GPIO.add_event_detect(pin, GPIO.RISING, callback=handle_event, 
bouncetime=300)

print 'main sleeping'
time.sleep(42)
print 'main done'

def handle_event(gpio):
print 'enter', gpio
time.sleep(3)
print 'exit', gpio

main()
 8<  cut here 

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Terry Coles]

On Tuesday, 14 March 2017 17:21:12 GMT Stephen Wolff wrote:
> >> What's the line look like that registers your callback?
> > 
> > I've put the complete script, cut-down as you suggested, in:
> > http://www.hadrian-way.co.uk/Misc/changerings3.py.txt
> > 
> >> Taking the stripped down, simple as possible, test program, have it do
> >> the time.sleep(2) and not import the subprocess module.  Run it under
> >> strace(1) to capture its interactions with the kernel.  (The Python
> >> module is a poorly documented black box there to provide a "helpful"
> >> abstraction; we're now trying to see through it to understand its
> >> behaviour.  :-)
> >> 
> >> sudo strace -tt -o strace.out -f \
> >> 
> >> -e trace=process -e trace=file -e trace=desc \
> >> your-python-script.py
> 
> Can you put the ‘add_switch_events()’ under an if __name__ == ‘main’:
> 
> see
> 
>  - http://stackoverflow.com/questions/4041238/why-use-def-main
> 
> could it be that the script is called each time the file is imported?

So I rewrote the last line of the script as:

if __name__ == '__main__':
add_switch_events()

but the code didn't do anything!

-- 



Terry Coles
-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Stephen Wolff]

>> What's the line look like that registers your callback?
>
> I've put the complete script, cut-down as you suggested, in:
>
>   http://www.hadrian-way.co.uk/Misc/changerings3.py.txt
>
>> Taking the stripped down, simple as possible, test program, have it do
>> the time.sleep(2) and not import the subprocess module.  Run it under
>> strace(1) to capture its interactions with the kernel.  (The Python
>> module is a poorly documented black box there to provide a "helpful"
>> abstraction; we're now trying to see through it to understand its
>> behaviour.  :-)
>>
>> sudo strace -tt -o strace.out -f \
>> -e trace=process -e trace=file -e trace=desc \
>> your-python-script.py
>

Can you put the ‘add_switch_events()’ under an if __name__ == ‘main’:

see

 - http://stackoverflow.com/questions/4041238/why-use-def-main

could it be that the script is called each time the file is imported?
-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Terry Coles]

Ralph,

It's been a while since you wrote.  Yesterday was model town day + shopping 
and this morning, I had other errands to run. so I only got onto all this 
again this afternoon.

In the meantime, Clive has shortened the cabling considerably and we've 
removed the outer plastic sheath and teased out the wires on all of the cable 
runs to reduce the cross-talk to a minimum.

I monitored the 'Change Runs On'  GPIO pin with my (fairly limited) Arduino 
based scope and saw a little bounce when the switch was depressed (less than 1 
ms) and no bounce when it was released (as you would expect).  Of course, a 
very fast edge or ringing wouldn't show up on that scope, although I have been 
offered the loan of a real one, if it would help. 

On Sunday, 12 March 2017 18:10:45 GMT Ralph Corderoy wrote:
> What version is the GPIO Python module you're using?  If it's not
> obvious, then there may be a GPIO.VERSION string that can be printed
> from Python.

pi@raspberrypi:~ $ find /usr/ | grep -i RPi.GPIO
/usr/share/doc/python-rpi.gpio



/usr/lib/python3/dist-packages/RPi.GPIO-0.6.3.egg-info




This ties in with the version in the Raspbian Package Manager.

> What's the line look like that registers your callback?

I've put the complete script, cut-down as you suggested, in:

http://www.hadrian-way.co.uk/Misc/changerings3.py.txt

> Taking the stripped down, simple as possible, test program, have it do
> the time.sleep(2) and not import the subprocess module.  Run it under
> strace(1) to capture its interactions with the kernel.  (The Python
> module is a poorly documented black box there to provide a "helpful"
> abstraction; we're now trying to see through it to understand its
> behaviour.  :-)
> 
> sudo strace -tt -o strace.out -f \
> -e trace=process -e trace=file -e trace=desc \
> your-python-script.py

I couldn't get that to work.  See what I tried:

 pi@raspberrypi:~/WMT/Code/Minster_Functions $ sudo strace -tt -o strace.out -
f \> -e trace=process -e trace=file -e trace=desc \
> changerings3.py 
strace: Can't stat 'changerings3.py': No such file or directory
pi@raspberrypi:~/WMT/Code/Minster_Functions $ sudo strace -tt -o strace.out -f 
-e trace=process -e trace=file -e trace=desc changerings3.py
strace: Can't stat 'changerings3.py': No such file or directory
pi@raspberrypi:~/WMT/Code/Minster_Functions $ sudo strace -tt -o strace.out -f 
-e trace=process -e trace=file -e trace=desc ~/WMT/Code/Minster_Functions/
changerings3.py
strace: exec: Permission denied
pi@raspberrypi:~/WMT/Code/Minster_Functions $ sudo strace -tt -o strace.out -f 
\
> -e trace=process -e trace=file -e trace=desc \changerings3.py 
strace: Can't stat 'changerings3.py': No such file or directory

I'm not sure why it can't find the script; I used tab completion to get the 
name right.

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Ralph Corderoy]

Hi Terry,

> I get one  'Message Played' text output when *both* the time.sleep()
> *and* the subprocess.call() lines are commented.  I get two 'Message
> Played' text outputs when *either* of those two lines are uncommented.

So it looks like the problem occurs if the callback runs for any
significant amount of time.

> I just held down the switch until the first 'Message Played' text
> output was printed (eg, after the 2 second delay) and then waited ten
> more seconds before releasing it.  I then got the second 'Message
> Played' text output.

What version is the GPIO Python module you're using?  If it's not
obvious, then there may be a GPIO.VERSION string that can be printed
from Python.

What's the line look like that registers your callback?

Taking the stripped down, simple as possible, test program, have it do
the time.sleep(2) and not import the subprocess module.  Run it under
strace(1) to capture its interactions with the kernel.  (The Python
module is a poorly documented black box there to provide a "helpful"
abstraction; we're now trying to see through it to understand its
behaviour.  :-)

sudo strace -tt -o strace.out -f \
-e trace=process -e trace=file -e trace=desc \
your-python-script.py

Those backslashes at the end of the line allow the command to continue
on the next line.  -tt timestamps each line.  -o sends the output to
strace.out.  -e says to trace some initially interesting things.
Because we're tracing the Python interpreter we'll see lots related to
its internal workings so we don't want the default of tracing all system
calls.

If strace.out is too big to put in the email then you might find a
pastebin useful:

curl -sSF 'sprunge=<-' http://sprunge.us http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Terry Coles]

On Thursday, 9 March 2017 23:16:15 GMT Ralph Corderoy wrote:
> What
> https://docs.python.org/2.7/reference/simple_stmts.html#the-global-statement
> is saying is that you only need to point out global variables with `global'
> when you want to write to them, not just read them.  And using `global' is
> an indication to the reader that you intend to write, so it isn't used just
> to point out a variable is global as that misleads. (The reader can
> probably recognise a global that's only being read due to its longer name.)

OK.  Thanks.  I picked up the idea from a bit of code that I saw, but didn't 
realise the distinction.

> I echo Patrick's question;  that seems inconsistent with there only
> being one line printed in the other email.
> 
> > > Are the callbacks defined to be edge triggered, so on the switch's
> > > transition from off to on?

Yes.  the ARG is GPIO.RISING.  I don't believe that the Library supports level 
triggering and I wouldn't want that anyway.

> You didn't mention whether the Python library says what triggers the
> callback.  Have you tried moving the switch from off to on and holding
> it there against the spring and observe what happens?  Does the callback
> run once with one line printed?  Once it's all finished, let the switch
> spring back to off;  does it call the callback again?

Se my response to Patrick.

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Terry Coles]

On Thursday, 9 March 2017 20:40:48 GMT Patrick Wigmore wrote:
> In your first email, you said that there was only one 'Message
> Played' text output when time.sleep() is commented.

I did and this is true, although I was probably less than clear.

I get one  'Message Played' text output when *both* the time.sleep() *and* the 
subprocess.call() lines are commented.  I get two 'Message Played' text 
outputs when *either* of those two lines are uncommented.

> So, does this mean that sometimes you get one 'Message Played',
> but sometimes you get two with no delay between them? Does it
> depend on whether the line to invoke the player is commented out?

Yes.  See above.

> Just trying to think of possiblities: Is there any kind of
> feedback loop occurring through you (the human operator), whereby
> the delay influences the way in which you operate the switch?
> 
> Does it make a difference how long you hold down the switch
> before releasing it?

A good point, which I hadn't pursued because it only occurs when those lines 
aren't commented out.

I just held down the switch until the first 'Message Played' text output was 
printed (eg, after the 2 second delay) and then waited ten more seconds before 
releasing it.  I then got the second 'Message Played' text output.  This 
implies that there may be wiring issues, except that without those two lines 
the code behaves as expected.

We did have cross-talk issues, but we've solved those by putting some small 
capacitors across the switches and by removing the outer insulating sheath 
from the cable that connects the switches to the pull-down resistors.

We also had switch bounce issues originally, but that was resolved by the 
capacitors and the bouncetime argument in GPIO.add_event_detect() statements.

The result of this test implies that the program is reacting to a GPIO.FALLING 
event, but there aren't any programmed.  In any case, why does this event only 
get detected when the two lines aren't commented?

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Ralph Corderoy]

Hi Terry,

> On Thursday, 9 March 2017 17:46:45 GMT Ralph Corderoy wrote:
> > > def change_rings_2(channel):
> > > global msg_subdir, chr_subdir, c_player
> > 
> > You can delete that global, just to make the test simpler still.
> 
> I will still need the msg_subdir; it's used in the code.

What
https://docs.python.org/2.7/reference/simple_stmts.html#the-global-statement
is saying is that you only need to point out global variables with
`global' when you want to write to them, not just read them.  And using
`global' is an indication to the reader that you intend to write, so it
isn't used just to point out a variable is global as that misleads.
(The reader can probably recognise a global that's only being read due
to its longer name.)

> > > If I uncomment the time.sleep() line, then it prints two.
> > 
> > Two `Message Played'?  Do they appear roughly together, both after a
> > two-second gap?  If you're not sure, increase the 2.
> 
> Increasing the delay increases the time between the messages being
> played, when leave the time.sleep() commented, there is no delay.

I echo Patrick's question;  that seems inconsistent with there only
being one line printed in the other email.

> > Are the callbacks defined to be edge triggered, so on the switch's
> > transition from off to on?

You didn't mention whether the Python library says what triggers the
callback.  Have you tried moving the switch from off to on and holding
it there against the spring and observe what happens?  Does the callback
run once with one line printed?  Once it's all finished, let the switch
spring back to off;  does it call the callback again?

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Patrick Wigmore]

On Thursday, 9 March 2017, at 18:01:43 GMT, Terry Coles wrote:
> > > If I uncomment the time.sleep() line, then it prints two.
> > 
> > Two `Message Played'?  Do they appear roughly together, both
> > after a two-second gap?  If you're not sure, increase the 2.
> 
> Increasing the delay increases the time between the messages
> being played, when leave the time.sleep() commented, there is
> no delay.

In your first email, you said that there was only one 'Message 
Played' text output when time.sleep() is commented.

So, does this mean that sometimes you get one 'Message Played', 
but sometimes you get two with no delay between them? Does it 
depend on whether the line to invoke the player is commented out?


Just trying to think of possiblities: Is there any kind of 
feedback loop occurring through you (the human operator), whereby 
the delay influences the way in which you operate the switch?

Does it make a difference how long you hold down the switch 
before releasing it?


Patrick.

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

Re: [Dorset] Python Function Appears to be Entered Twice

[Ralph Corderoy]

Hi Terry,

> def change_rings_2(channel):
> global msg_subdir, chr_subdir, c_player

You can delete that global, just to make the test simpler still.

> msg_file = 'Change_Rings_On.wav'
> msg_path = os.path.join(msg_subdir, msg_file)
> 
> #subprocess.call(['aplay', '--device=plughw:1,0', msg_path])
> #time.sleep(2)
> 
> print 'Message Played'
...
> If I uncomment the time.sleep() line, then it prints two.

Two `Message Played'?  Do they appear roughly together, both after a
two-second gap?  If you're not sure, increase the 2.

> If I uncomment the line that invokes the player, I get two lots of the
> 'Change_Rings_On.wav' message to the speaker.

In addition to the sleep, or instead of, or doesn't it matter?

There was some debounce option when registering the callback?  Are you
still using that and to a big enough time?  Are the callbacks defined to
be edge triggered, so on the switch's transition from off to on?

Cheers, Ralph.

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR

[Dorset] Python Function Appears to be Entered Twice

[Terry Coles]

Hi,

It's me again.  My program is all but fully working and those who were at the 
Meeting on Tuesday may recall me foolishly saying how I didn't have much left 
to do ;-(

One of the few things left is playing the announcements before the Change 
Rings, MP3 Player, etc start.  The functions all work fine until I add this 
code at the beginning.  When I do, the triggered function seems to be executed 
twice.

Here is a cut down version of the change_rings_start() function, which I've 
been using to analyse what is going on:

def change_rings_2(channel):
global msg_subdir, chr_subdir, c_player

msg_file = 'Change_Rings_On.wav'
msg_path = os.path.join(msg_subdir, msg_file)

#subprocess.call(['aplay', '--device=plughw:1,0', msg_path])
#time.sleep(2)

print 'Message Played'

(In the full function, the mpg321 player is invoked using subprocess.Popen() 
to play the bells/music straight after this code.  I have changed the callback 
so that this cut-down function is called instead when I press the switch.)

As written, this code executes as expected and prints a single line 'Message 
Played' to the Python console.

If I uncomment the time.sleep() line, then it prints two.  If I uncomment the 
line that invokes the player, I get two lots of the 'Change_Rings_On.wav' 
message to the speaker.

In the original change_rings_start() function, I get two announcements and the 
change rings start playing, twice.  (The first playback is terminated by a call 
to change_rings_stop() just after the announcement.)

(Please ignore the fact that I am now using aplay instead of mpg321.  I 
couldn't get the message to play at all for some reason and when I did, by 
using aplay, two came along.)

Has anyone any ideas what is going on here?

-- 



Terry Coles

-- 
Next meeting:  Bournemouth, Tuesday, 2017-04-04 20:00
Meets, Mailing list, IRC, LinkedIn, ...  http://dorset.lug.org.uk/
New thread:  mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well:  http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR