Open francofusco opened 1 year ago
TL;DR of the issue:
2000
.2.0
.So, the snapshot delay from the profile is not being used when clicking the test button, but rather a default delay of 2 seconds is used. I'm not sure why I did it that way exactly (the snapshot delay isn't sent at all), but probably just to fill in the parameters for the script.
As for the parameters sent to the actual call, the real delay in seconds is used. This was done intentionally since the sleep (both windows and linux prompt) takes seconds, and is documented in the description of the parameters:
SNAPSHOT_NUMBER=$1 DELAY_SECONDS=$2 DATA_DIRECTORY=$3 SNAPSHOT_DIRECTORY=$4 SNAPSHOT_FILENAME=$5 SNAPSHOT_FULL_PATH=$6
You could pretty easily multiply by 1000 to get seconds pretty easily.
I'll look into passing the snapshot delay, but I don't want a situation where someone enters a really large value for the delay and thinks their webcam isn't working. Thoughts?
the snapshot delay from the profile is not being used when clicking the test button, but rather a default delay of 2 seconds is used
Ok, I did not figure this out due to an unfortunate coincidence: I was using a 2s delay and therefore I thought it was the same value given by the user. I think it is reasonable to use a set value in testing, especially if it would require several changes to pass the user-supplied value.
You could pretty easily multiply by 1000 to get seconds pretty easily
Indeed. What I did was to check if the delay was less than 60: if this was the case, then I would assume the delay was in seconds and multiply it by 1000. However, in my opinion it would be better to have a consistent unit everywhere. Taking into account what was said before, I think a good solution would be to change the default value sent during the execution of the test script to 2.0
: still a set value, but in seconds. Also, I think it would be worth mentioning somewhere that a default value will be used during testing, and that the unit will always be seconds.
Finally, I think that my understanding of the parameter itself was wrong: I thought that the delay was to be used by the script, while after testing a bit more I believe that the delay refers to an additional sleep time that will be added after the script returns. If this is the case, maybe it would be better to just add a new parameter named, e.g., SNAPSHOT_EXPOSURE_SECONDS
. Scripts could use this parameter to make sure that a DSLR exposes for the correct amount of time - if this feature is available on the camera and/or program used to capture the image.
If this is a feature request describe it here
_REPLACE_THISFEATURE_REQUEST_DESCRIPTION_GOES_HERE
Version of Octolapse
Octolapse Version: 0.4.2
Version of OctoPrint
OctoPrint Version: 1.8.7
When you ran into the problem, did you have diagnostic logging enabled?
Diagnostic Logging was Enabled: YES
What were you doing when the problem occurred
I wanted to capture images with 2" exposure using an old camera that cannot be triggered from software. I was creating a script that (using some relays) activates the camera and then need to wait a bit, since the camera is doing long exposure. I want the wait time to be set using the "Snapshot Delay" value (which serves exactly this purpose, to my understanding). While doing so, I think I found an issue that can be replicated easily with the following steps - no actual camera needed:
debug.sh
and make it executable./home/pi/debug.sh
as scriptcat ~/.octoprint/logs/plugin_octolapse.log
should show the following at the end:What should have happened?
In the log, the
echo
to STDERR should show the same output.What happened instead?
Operating System running OctoPrint and Octolapse
OS Name: OctoPi Os Version: 1.0.0
Link to plugin_octolapse.log
Link to plugin_octolapse.log: https://pastebin.com/rrwK212V
Link to octoprint.log
Link to octoprint.log: _REPLACE_THISLINK_GOES_HERE
Please consider becoming a patron
If you like this project, please support my work by becoming a patron, and consider adding a 'star' to the repository. It takes a lot of time and effort to maintain the project and respond to issues. The cost of test prints, software, cameras, printer parts, etc. can quickly add up, so every bit helps.
You can find various videos and tutorials by subscribing to my Youtube channel. You can also follow me on Twitter.