Rpi GPIO controlled relay sometimes failing

reyalp

13716

Re: Rpi GPIO controlled relay sometimes failing

« Reply #10 on: 17 / March / 2018, 16:29:50 »

Advertisements

Quote from: waterwingz on 17 / March / 2018, 14:27:41

so I can't tell if when it returns nil for status, does that mean the script failed to run on the camera or the script did run and returned an error code? What I would do next depends on the answer to that question.

I think preshooting error comes from the code starting at line 46

Code: [Select]

status, bv, try_focus, i = con:execwait_pcall[[

All the _pcall functions just wrap the named function in a pcall, so the exceptions are caught and returned as status.

So execwait_pcall returns false if the underlying execwait threw an error. This could happen due to a connection error, or lua errors in the camera side code (compile, runtime, or explicit calls to error)
pcall returns any error message in the second return value on failure, so in the above code, you could see the specific error by changing the print to

Code: [Select]

print('*** *** *** Pre-shooting error: '..tostring(bv))

Regarding temperature: @manoweb found the cameras got very hot because in the default settings, the sensor + live view are on all the time.
To avoid this, you can use the cameras auto screen off functionality.

In the canon menu, under power saving set
Auto power down OFF
Display off <10 sec>
Then in CHDK settings, you need to make sure "disable display off" is not enabled.

If the camera is not physically accessible, you can navigate the Canon menu using lvdumpimg and key presses (or live view GUI if you have a fast connection), and set the CHDK setting with set_config_value. I can provide more specific instructions if you have to do this.

If you do this, the camera will turn off the display (and sensor) after 10 seconds, and wake it up the next time the script issues a key press. set_lcd_display only turns of the display not the sensor, so it has little effect on temperature, but is still desirable to avoid internal reflections.

Very high temperatures could cause the camera to shut down or become unreliable, so this may be relevant to the other errors.

Logged

Don't forget what the H stands for.

Sdack

Re: Rpi GPIO controlled relay sometimes failing

« Reply #11 on: 18 / March / 2018, 19:10:32 »

Hi Waterwingz,
I can't tell you you grateful I am for your insights and support. I am learning how to debug soft and hardware in a very logical manner and it reduces my panic greatly.
It's Monday here in Australia and, at 9am this morning, after an hour and a half of running smoothly, the camera failed again, with the same error...

Code: [Select]

Sleeping 38s
Temperature: sensor = 50 optics = 33
SSTT,20180319-085501,50,33
Checking brightness level
*** *** *** Pre-shooting error
Turning camera OFF
ERROR: I/O error
ERROR: Could not close session!
Waiting 5s...
Making sure camera is OFF
Waiting 5s...
Turning camera ON
Waiting 5s for boot...
Connecting
ERROR: no matching devices found

Interesting that the reported sensor temperature was 50. Because when I just rebooted it and started again, the first sensor temp was only 33 and in the last ten minutes I've watched it rise very quickly back up to 46.

I've examined the multilapse log which was reset on Friday and started afresh this morning
The first temperature readings, at 7:30 this morning, were

Code: [Select]

Temperature: sensor = 25 optics = 24The temps at failure were

Code: [Select]

Temperature: sensor = 50 optics = 33The temps now, 10:00am are

Code: [Select]

Temperature: sensor = 48 optics = 31So I'm wondering if it's an overheating issue for the camera, rather than the mechanical power switch activator that's at fault. If it were the bolt holding down the button that had shifted due to heat, I imagine it would stay shifted wouldn't you?

Do you think the camera might simply be crashing? Because, when it throws this error, multilapse tries and fails to switch the camera off, claiming there's no device there but a full reboot of the Pi removes power from both the Pi and the Camera.

Code: [Select]

*** *** *** Pre-shooting error
Turning camera OFF
ERROR: I/O error
ERROR: Could not close session!
Waiting 5s...
Making sure camera is OFF
Waiting 5s...
Turning camera ON
Waiting 5s for boot...
Connecting
ERROR: no matching devices found

Cheers
Sdack

UPDATE:
After this morning's reboot, the camera has been working steadily for 6 hours despite reaching 58 degrees C.

« Last Edit: 19 / March / 2018, 01:20:27 by Sdack »

Logged

reyalp

13716

Re: Rpi GPIO controlled relay sometimes failing

« Reply #12 on: 19 / March / 2018, 01:34:35 »

@Sdack If you modify the pre-shoot error code as I posted above, it should give a much better idea of what went wrong.

Logged

Don't forget what the H stands for.

Sdack

Re: Rpi GPIO controlled relay sometimes failing

« Reply #13 on: 19 / March / 2018, 02:02:09 »

Hey Reyalp,

Thanks heaps for your message above... somehow I missed it until now.

If I'm understanding your diagnosis, it could be the CHDKPTP software on the camera.. or maybe the SD card, or just the overheating that's causing the fail.

I've added the print ..tostring element in multilapse.lua as you suggested and will see what we get tomorrow, if the camera fails again. It is happening more and more, maybe three times in the last couple of weeks.

As for changing the display setting..

Unfortunately the camera is difficult to access, especially in button hold down contraption I made.

I'd very much like to have live view working, for setting the camera angle on installation but I don't currently have the lua gui packages installed. I remember trying but failing to build them when I first got started, before I found the binary versions, so I'd really appreciate some guidance on that.

The connection is pretty responsive for ssh (for Australian Internet speeds anyways).

Cheers
Sdack

Logged

Sdack

Re: Rpi GPIO controlled relay sometimes failing

« Reply #14 on: 19 / March / 2018, 02:17:12 »

Quote

Then in CHDK settings, you need to make sure "disable display off" is not enabled.

I looked at the CHDK settings on another camera that I have ready to build a rig with and the setting:

Disable LCD Off

Has the following options

Always
Never
Script
Alt

Would you recommend Never as the best option?
Sdack

Logged

reyalp

13716

Re: Rpi GPIO controlled relay sometimes failing

« Reply #15 on: 19 / March / 2018, 03:34:29 »

Quote from: Sdack on 19 / March / 2018, 02:17:12

Would you recommend Never as the best option?

Yes, but you need to make sure the the canon "Auto power down" is turned off first.

You can set the CHDK setting from the chdkptp CLI using something like

Code: [Select]

=set_config_value(require'gen/cnf_core'.alt_prevent_shutdown,0)

To get the current value

Code: [Select]

=return get_config_value(require'gen/cnf_core'.alt_prevent_shutdown)

To set the canon UI values: If you can connect the camera USB to a laptop that already runs the chdkptp GUI, that should be easy.

If not, to navigate the menu you can do something like

Code: [Select]

=post_levent_to_ui(4484)
=click'menu'
lvdumpimg -bm=screen.pam
=click'left'
lvdumpimg -bm=screen.pam
...

The initial post_levent ... is needed to unlock the keys in the canon firmware.

Then download screen.pam somewhere so you can view it. pam is a somewhat obscure netpbm format. If you have imagemagick installed on the pi, you can have chdkptp pipe it through that to generate PNGs like

Code: [Select]

lvdumpimg -bm='convert - screen.png' -pipebm

Repeat the lvdumpmg command and download the image after each key press to see where you are in the canon menus.

Logged

Don't forget what the H stands for.

Sdack

Re: Rpi GPIO controlled relay sometimes failing

« Reply #16 on: 19 / March / 2018, 04:28:16 »

Thanks,
Will give all that a go tomorrow.
Sdack

Logged

reyalp

13716

Re: Rpi GPIO controlled relay sometimes failing

« Reply #17 on: 19 / March / 2018, 12:58:54 »

FWIW, the Canon settings could probably also be set using "UI properties" (see https://chdk.setepontos.com/index.php?topic=10624.0) but I don't know the numbers/values

Logged

Don't forget what the H stands for.

Sdack

Re: Rpi GPIO controlled relay sometimes failing

« Reply #18 on: 31 / March / 2018, 02:49:41 »

Hey folks,

I've been quiet on this subject because, since those couple of days of random failure, the camera started working and has become solid as a rock again.. Maybe it was a period of poor main supply!

However, I've run into another little problem in my attempt to replace the relays I've been using with an N channel Mosfet.

After careful studying of this page
http://bildr.org/2012/03/rfp30n06le-arduino/

And duplicating the wiring on the top most of the three images

I managed to cobble together a working system. Working that is, in a multimeter test.

However, when I attached the camera, I found that, once turned on, the camera didn't go off again when the Mosfet was deactivated. Eventually, after much head scratching, I discovered that the CHDKPTP mini USB connection which connects to the microcontroller (a Raspberry Pi in my case, not an Arduino), also contains a connection to ground, so the camera had a live circuit and didn't react to the Mosfet's disconnecting it's path to ground.

I'm wondering if and how I can re arrange the connections so that the source (I prefer to think of it a the 'live' connection) is the one that the Mosfet connects and disconnects.

Would this work?

EDIT:
The 10K resistor between the gate and the ground is still something I find confusing. I get that it's a "pulldown" supposed to ensure that the connection isn't floating, so in my mind, it allows the voltage to "drain away to zero" once the GPIO high signal is cut off. I guess the GPIO voltage is significantly higher than the 10K draining to ground therefore it doesn't prevent the gate opening during activation

Cheers

Sdack

« Last Edit: 31 / March / 2018, 04:27:08 by Sdack »

Logged

waterwingz

12123

Re: Rpi GPIO controlled relay sometimes failing

« Reply #19 on: 31 / March / 2018, 13:06:53 »

Quote from: Sdack on 31 / March / 2018, 02:49:41

However, when I attached the camera, I found that, once turned on, the camera didn't go off again when the Mosfet was deactivated. Eventually, after much head scratching, I discovered that the CHDKPTP mini USB connection which connects to the microcontroller (a Raspberry Pi in my case, not an Arduino), also contains a connection to ground, so the camera had a live circuit and didn't react to the Mosfet's disconnecting it's path to ground.

Hmmmm .. so can you switch the camera ON & OFF with the MOSFET if you disconnect the USB connection?

Does the camera go ON & OFF if you physically connect / disconnect the "control 18" wire from the Pi (leaving the 10K resistor connecting the MOSFET gate pin to ground? With or without the USB connection in place?

What's most likely happening here is that you are getting enough leakage out of "control 18" to keep the MOSFET latched when it's ON (but not enough to turn it ON when it's OFF).

Quote

I'm wondering if and how I can re arrange the connections so that the source (I prefer to think of it a the 'live' connection) is the one that the Mosfet connects and disconnects. Would this work?

You'll need to switch to a P channel MOSFET and do a little research about how to configure it. It's somewhat more complicated than N channel MOSFETs - especially if it's switching a different voltage than the uController output produces.

Some light reading (after a quick google search -there may be better ones):
https://www.baldengineer.com/p-channel-mosfet-tutorial-with-only-positive-voltages.html
https://www.electronics-tutorials.ws/transistor/tran_7.html

EDIT:

Quote from: Sdack on 31 / March / 2018, 02:49:41

The 10K resistor between the gate and the ground is still something I find confusing. I get that it's a "pulldown" supposed to ensure that the connection isn't floating, so in my mind, it allows the voltage to "drain away to zero" once the GPIO high signal is cut off. I guess the GPIO voltage is significantly higher than the 10K draining to ground therefore it doesn't prevent the gate opening during activation

Not quite. What happens when a digital output switches off is not the exact same thing as opening a mechanical switch. There are other paths (usually with high resistance) where very low leakage currents can still flow from the output, through the load, to ground. Usually the series resistance is high enough that the current levels are very low and don't affect anything. But if my theory about 'leakage out of "control 18" to keep the MOSFET latched when it's ON' is correct, then the 10K resistor is the culprit. It's too high a resistance to pull the off state voltage from control 18 low enough to switch the MOSFET off. Try a 1K resistor instead?

« Last Edit: 31 / March / 2018, 13:27:55 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16